[Basti]

Hallo.

Mich nervt gerade mein Entwurf und ich würde mich über Anregungen freuen:

Prinzipiell hab ich eine hierarchische MVC-Architektur, es gibt also einen Baum an Modulen.

- Nur die Controller können jeweils Kinder in diesem MVC-Baum bauen und einhängen.
- Es gibt ein Modul Page mit einem Controller für die verschiendenen Aktionen (Seite anzeigen, bearbeiten, verschieben, löschen etc.).
- Jede Seite besteht aus verschiedenen Komponenten.

Ich würde gerne, um eine Seite (oder Seitenversion) zu löschen aus dem Seiten-Controller einfach ein $this->Page->remove() ausführen. Nun hat $this->Page (also das Daten-Objekt) zwar natürlich diese Methode, kann aber die Komponenten nicht selbst bauen, um ihnen ein remove() zu schicken bzw. den Baum des Controllers manipulieren.


Habt ihr schonmal mit diesem Problem zu tun gehabt? Gibt es bewährte Lösungen?

Basti

[mepeisen]

Kennt denn deine Page ihren Parent im Objektbaum? Wenn ja, dann kann sie die Arbeit an diesen delegieren, sowas wie:
$this->parentController->remove($this);

[Basti]

Nein. Die Datenobjekte kennen ausschließlich ein jeweils übergeordnetes „Manager“-Objekt, dass alle Objekte diesen Typs verwaltet (ähnlich, wie die Peer-Objekte oder die statschen Methoden von DataObjects in einigen ORM-Paketen).

Diese Manager kennen wiederum nur eine DaoFactory und einen Zugang, um an andere Manager dranzukommen. Aber sie kennen weder Controller noch Views.

Basti

[dr.e.]

Hallo Basti,

wenn ich deine Struktur richtig verstanden habe, hälst du irgendwo in deiner Applikation / oder deinem Applikationsrahmen eine Objekt-Struktur aus unterschiedlichen Seiten und Modulen als Daten-Objekte.

In diesem Fall bietet sich zunächst die Struktur nach dem Composite-Pattern zu erzeugen, da du dann sicher sein kannst, dass die Objekte die entsprechenden Methoden für die grundlegende Manipulation unterstützen.

Weiterhin bin ich der Meinung, dass ein Controller nicht in der von dir beschriebenen Form im Baum integriert sein soll, da deine Knoten streng genommen jeweils kleine MVC-Einheiten sind. Damit sollte ein Controller höchstens seinen Knoten - bzw. vive versa - ein Knoten nur seinen Controller kennen, der den Knoten manipulieren kann.

Aus meiner Erfahrung ist es mit der beschriebenen Variante möglich, dass du deinen Baum im Controller manipulierst. Einen derartigen Eingriff in den Baum wie Löschen ist jedoch heikel, da in Baum-Strukturen dann ganze Zweige verschwinden könnten. Ist das von dir so gewollt, ok, aber dann würde sich der Controller den Ast weg sägen.

Ich glaube, dass es für deine Problemstellung eine elegante Lösung geben kann, jedoch solltest du nochmal einen konkreten Anwendungsfall aufzeigen, dann wird es vielleicht klarer.

[Basti]

http://www.javaworld.com/javaworld/j...vc.html?page=2

http://c2.com/cgi/wiki?HierarchicalModelViewController
http://c2.com/cgi/wiki?RecursiveModelViewController

Ich glaube, mein Problem ist gerade, dass ich fü ein Datenobjekt, wie z.B. „Page“ einmal einen „offiziellen“ Controller habe und zum anderen dieses Objekt selbst Methoden zur Manipulation kennt. Ist ja auch klar, nur hab ich gerade keine scharfe Trennlinie
bzw. mein Baum existiert quasi doppelt: Einmal im Datenobjekt in Form von Daten eben (Seite x besteht aus den und den Komponenten) und einmal im Controller (Kinderknoten sind die Controller der Komponenten).

Basti

[dr.e.]

Hallo Basti,

verstehe ...
Eine harte Trennlinie wäre an dieser Stelle in der Tat ästhetischer. Hast du die Möglichkeit die Objekte in deinem Controller lediglich zu referenzieren? Falls ja, sparst du dir die doppelte Haltung der Objekte und die Verarbeitung wird einfacher. Sinnvollerweise sollte jede Schicht der HMVC-Implementierung auch einen eigenen Dispatcher haben, der die Verarbeitung regelt.

Was die Verarbeitung von Controller und Manipulationsmethoden der Objekte selbst angeht, kannst du zwei Wege verfolgen:

1. Timing-Model des Dispatchers so modifizieren, dass bei der Verarbeitung eines Objekts in definierter Reihe Methoden zur Verarbeitung aufgerufen werden. Das kann so aussehen (Pseudocode

...
$Object->firstMethod();
$Object->onBeforeTransform();
$Controller = new Contoller();
$Controller->setCurrentNode(&$Object);
$Controller->executeTransformMethod();
$Object->onAfterTransform();
...

2. Jegliche Logik von Daten-Objekten entfernen und die Verarbeitung entsprechend den Business- und/oder Präsentationsschicht-Modulen überlassen. Diese Möglichkeit sehe ich deshalb, da deine Datenobjekte für mich so aussehen, als wären sie quais Model-Informationen innerhalb deiner Applikation.

Ich hoffe, ich konnte dir einen Denkanstoss geben.

[Basti]

Zitat von dr.e.

1. Timing-Model des Dispatchers so modifizieren, dass bei der Verarbeitung eines Objekts in definierter Reihe Methoden zur Verarbeitung aufgerufen werden.

Ich hab halt nicht genau ein Datenobjekt je Controller. Das hatte ich anfangs so, hat sich aber für mich nicht bewährt. also meistens hauts schon hin, aber eben nicht immer.

2. Jegliche Logik von Daten-Objekten entfernen und die Verarbeitung entsprechend den Business- und/oder Präsentationsschicht-Modulen überlassen. Diese Möglichkeit sehe ich deshalb, da deine Datenobjekte für mich so aussehen, als wären sie quais Model-Informationen innerhalb deiner Applikation.

Ich würde in den Controllern gerne nur die Prozesse definiert haben, die für die Benutzeranfrage direkt relevant sind. Also in Pseudocode:

page.remove:

page = pages.getByName(Request.pagename)

if isNull(page)
  return badRequest

if not(user.hasRight(page, 'remove'))
  return noRights

parent = page.getParentPage
page.remove()

return redirect(parent, message('pageRemoveSuccess'))

Im Moment werden an der Stelle dann noch alle Komponenten gebaut und gelöscht. Wenn ich jetzt alle Funktionalität aus den Datenobjekten nehme, dann müsste ich hier zusätzlich noch die Seite aus dem Seitenbaum entfernen, aus der Tabelle, die speichert, welche Seiten umbenannt wurden, müsste alle Daten löschen, die an der Seite registriert oder mit ihr assoziiert sind etc.

Den ganzen Schlonz will ich natürlich nicht im Controller haben.

Ich machs mal konkret. Ein Controller-Baum könnte z.B. so aussehen:

+ "page" => PageController
|
+-+ "page_version" => PageVersionController
| |
| +-+ "panels" => ContainerController
|   |
|   +-+ "contents" => PanelController
|   | |
|   | +-+ "0" => SectionController
|   | | |
|   | | +-+ "0" => PageNodeController
|   | |   |
|   | |   +-- "component" => Component_Heading
|   | | 
|   | +-+ "1" => SectionController
|   | | |
|   | | +-+ "0" => PageNodeController
|   | |   |
|   | |   +-- "component" => Component_MlText
|   | | |
|   | | +-+ "1" => PageNodeController
|   | |   |
|   | |   +-- "component" => Component_Image
|   | | |
|   | | +-+ "2" => PageNodeController
|   | |   |
|   | |   +-- "component" => Component_MlText
|   | | 
|   | +-+ "2" => SectionController
|   |   |
|   |   +-+ "0" => PageNodeController
|   |     |
|   |     +-- "component" => Component_InstituteAddress
|   | 
|   +-+ "layout" => PanelController
|     |
|     +-+ "1" => SectionController
|       |
|       +-+ "0" => PageNodeController
|         |
|         +-- "component" => Component_PageImage
|
+-- breadcrumbs BreadcrumbMenuController
|
+-- submenu SubMenuController

Jetzt könnte ich natürlich diesen Baum Stück für Stück quasi sich selbst aufbauen lassen: Die Seite baut eine version, diese baut die Panels, die bauen die Sektionen, die bauen die enthaltenen Knoten und die die jeweils dort eingehängte Komponente in der entsprechenden Version. Nun hab ich aber all dies Daten, die es braucht, diesen Baum zu bauen in einer Abfrage erledigt und daher baut der Seiten-Controller diesen Baum eben komplett.

Beim Löschen wär das ähnlich ungeschickt, das jedem Controller selbst zu überlassen. Der Ablauf ist der:

- Entferne alle Seiten-Knoten aus der Seitenversion xyz
- Für alle Komponenten, die in keine Seite eingebunden sind:
--- Baue die Komponente
--- Component->remove()

Basti

[dr.e.]

Ich hab halt nicht genau ein Datenobjekt je Controller. Das hatte ich anfangs so, hat sich aber für mich nicht bewährt. also meistens hauts schon hin, aber eben nicht immer.

Das meinte ich auch nicht. Ich sehe die Beziehung genau anderes herum: es kann einen Controller pro Datenobjekt (eigentlich Model-Objekt?) geben.

Nach deinem Beispiel bin ich der Meinung, dass man hier in Model der Anwendung und reiner GUI-Logik unterscheiden müsste. Das kann so aussehen:

* Business-Schicht baut das Model so auf, das es die GUI in einem bestimmten Zustand repräsentiert
* Die GUI wird gemäß Model aufgebaut

Damit sparst du dir theoretisch die Abbildung der Abhnängigkeit zwischen Datenobjekten und GUI-relevanten Objekten und kannst die GUI durch Zugriff auf das Model aufbauen und erzeugen lassen. In einfacher Form habe ich das letztens für eine Admin-GUI implementiert. Hier wird über eine FrontController-Action ein Model aufgebaut, das beschriebt, welche Views in welcher Form angezeigt werden sollen (View<->Content-Mapping). Anschließend wird die Präsentationsschicht erzeugt und die einzelnen Views ziehen aus dem Model die Info, welcher Content im View angezeigt werden soll. So bin ich absolut flexibel, spare mir jedoch die Vermischung von Datenobjekten und Model (die in der reinen Lehre IMHO auch nicht existiert).

In deinem Konkreten Anwendungsfall könnte die FrontController-Action einen definierten Zweig "löschen", sprich im Model mit NULL kennzeichnen und die Präsentationskomponente weiß genau, dass dieser Zweig (=View) nicht angezeigt werden darf/soll.

Hope this helps!

[Basti]

Hi Christian.

Termindruck hat mich zum Pfuschen getrieben (wenn man so will) in sofern suche ich gerade nicht mehr akut nach einer Lösung. Hab immer noch nicht klar, wie das wirklich außer gehen soll.

Zitat von dr.e.

Das meinte ich auch nicht. Ich sehe die Beziehung genau anderes herum: es kann einen Controller pro Datenobjekt (eigentlich Model-Objekt?) geben.

Naja, wenn der Controller sich nur auf das Datenobjekt/Model-Objekt bezieht, dann braucht es letztlich keinen Controller. Man würde die Methoden einfach dem Datenobjekt verpassen.

Die Controller sind ja aber viel viel mehr an die Benutzerschnittstelle gebunden und entscheiden anhand der Benutzereingaben, was weiter geschehen soll (vielleicht hier eben *was* anstatt *wie*).

Nach deinem Beispiel bin ich der Meinung, dass man hier in Model der Anwendung und reiner GUI-Logik unterscheiden müsste.

Eine Seite enthält Komponenten. Je nach Modus sind diese mal so und mal so eingebunden (mal in Panels mit Formularen, mal in „Containern“ (z.B. Bereiche in einem mehrspaltigen Layout), mal als einfach Liste, wenn es darum geht, ihnen ein Event durchzugeben). Was für eine Art von Logik ist das nun? Ich hab meine bestehende Misch-Lösung jetzt beibehalten, schiele aber dennoich immer mal wieder nach einer wirklich schlüssigen Lösung

Letztlich käme dann entweder sowas wie Prado raus oder eine Lösung, die extrem „unperformant“ ist:
Es wird grundsätzlich unterschieden zwischen einer Anfrage, die was verändern will und einer, die nur eine bestimmte Sicht fordert (wie GET und POST ja auch gemeint waren). Im ersten Schritt wird, falls es eine &#8222OST-Anfrage“ ist zunächst eine Kette von Controllern gebaut, die die Anfrage bearbeitet. Daraus entsteht intern oder extern ein „GET-Request“ und in diesem zweiten Durchlauf baut die Anwendung das GUI auf.

So ähnlich wollte ich das ursprünglich umsetzen, aber es ist nicht sehr effektiv.

In deinem Konkreten Anwendungsfall könnte die FrontController-Action einen definierten Zweig "löschen", sprich im Model mit NULL kennzeichnen und die Präsentationskomponente weiß genau, dass dieser Zweig (=View) nicht angezeigt werden darf/soll.

Nur verschindet er so ja nicht aus der Datenbank.

Kann mal einer bitte HTTP abschalten und … grrrr
Basti

[Dennis]

Zitat von Basti

Ich würde gerne, um eine Seite (oder Seitenversion) zu löschen aus dem Seiten-Controller einfach ein $this->Page->remove() ausführen. Nun hat $this->Page (also das Daten-Objekt) zwar natürlich diese Methode, kann aber die Komponenten nicht selbst bauen, um ihnen ein remove() zu schicken bzw. den Baum des Controllers manipulieren.

siehe http://en.wikipedia.org/wiki/Chain-o...bility_pattern

[Basti]

Ich glaub, du hast mein Problem nicht verstanden. CoR passt, wenn es nur um die Controller ginge oder nur um die Datenobjekte bzw. ist eh Grundlage.

Basti