dr.e.

@dsentker:
Das ist nur notwendig, wenn du HMVC oder Template-Einbindung per Sub-Request realisierst. Dies ist beim APF beispielsweise nicht so gelöst und darum braucht es das auch garnicht.

Sofern er dynamisch gewählt werden soll: ja, ansonsten: nein. In einem APF-Projekt hast du stets ein statisches Haupt-Template, in dem du dann per FC-Action oder Input-Filter bestimmt einen dynamisch gewählten Knoten - mit eben einem dymnamisch evaluierten "obersten" Controller - anzeigst.
Insofern funktioniert HMVC in der Umsetzung des APF unterschiedlich zu deinem Gedankengang. Für meine Begriffe ist hierin genau das Quentchen Flexibilität versteckt, das andere Frameworks nicht haben, da das Url-Layout statisch hinsichtlich der Controller ist.

@Trainmaster:
So pauschal lässt sich das IMHO nicht formulieren. Der Unterschied ist für mich nicht nur Routing (sf2) vs. "Template-Mapping" (APF), sondern wie mit Url-Layouts umgegangen wird. sf2 und beispielsweise auch das ZF registrieren Routen in einem Router um eine Auflösung zu einem Controller bzw. einem Controller und einer entsprechenden Action durchzuführen. Unter http://symfony.com/doc/2.0/book/rout...under-the-hood ist exakt diese lineare Abbildung besprochen.

Das APF behandelt Urls auf eine andere Weise: die Url wird als Informationsquelle für alle zu einem Zeitpunkt notwendigen Daten gesehen, die zur Wiederherstellung eines Zustands zu exakt diesem Zeitpunkt genutzt werden kann. Ich lege mich also nicht fest, dass ich beispielsweise einen bestimmten Part auf eine Action und wiederum einen anderen auf einen Controller mappen muss - egal ob durch ein weiteres Mapping unterstützt oder nicht -, sondern die Url kann auch eine völlig andere semantische Struktur besitzten. Siehe hierzu auch die Diskussion unter http://www.php.de/software-design/60...-ansatz-2.html (URL-Design für PAC-Ansatz) und http://www.php.de/software-design/56...ing-mvc-5.html (erweitertes Controlling (MVC)).

Essenz der beiden Threads ist, dass ich (und damit die Implementierung im APF ) die Url als beliebige Struktur sehen, die eine äußere und eine innere Repräsentation besitzt und die je nach Applikation und Anwendungsfall auf eine andere Weise interpretiert wird. Weiter ist Bestandteil dieser Überlegungen, dass die Informationen zum Aufbau der internen Applikation-Informationen (im HMVC-Bereich: View-Model) nur zum Teil aus der Url "erreichnet" werden, zum anderen aus der Session oder aus der Datenbank, sofern dies im aktuellen Kontext notwendig ist. Bei einem CMS beispielsweise kannst du aus dem String /2011-the-year-at-a-glance weder den Controller noch andere Dinge erkennen. Das APF geht hierbei davon aus, dass du in einem eigenen Input-Filter die so gelieferte Url in die interne Struktur/Information übersetzt und diese z.B. über eine Front-Controller-Action im View-Model angereichert wird. Aus der obigen Url lässt sich beispielsweise

• die anzuzeigende Seite mit ihrem Inhalt
• die Sprache
• die Inhalte der Slots Header, Content, Footer

Ich hoffe der Unterschied ist nun klar geworden.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mister Ad

dsentker

Klingt interessant. Aber wenn es nicht die Uri ist, die einen Controller beschreibt, wer ist es dann? Wie lege ich fest, was beim Aufruf der Uri /foo/bar passiert? Wie kann ich als Entwickler zu einem späteren Zeitpunkt nachvollziehen, was genau bei /baz/qux/ passiert? Was genau ist der Einstiegspunkt einer APF-Anwendung unter Berücksichtigung der Uri?

__________________

dr.e.

Effektiv ist es eine Summe von Informationen. Um beim CMS-Beispiel zu bleiben ist es im "obersten" Knoten (Rahmen-Template) ein statischer Controller, der lediglich die Template-Basics füllt. Vielleicht ist es aber auch kein Controller, da das Rahmen-Template keinen Controller besitzt/braucht.

Die konkreten Controller in den einzelnen Komponenten - um auch hier beim CMS-Beispiel zu bleiben - werden dynamisch mit der Pflege des Redakteurs festgelegt. Es ist also weder die Entwicklung, noch die (statische) Konfiguration, die die Definition ausmacht. Die Url "/foo/bar" könnte demnach als CMS-Seite mit dem Url-Namen "/foo/bar" oder als "foo=bar" interpretiert werden. Deine konkrete Komponente selbst erfährt davon nichts, da das Layout per Input-Filter und FC-Action in eine interne Repräsentation übersetzt wird, die für alle Komponenten verständlich ist (meist Schlüssel=Wert).

Den Mechanismus muss du entweder selbst implementieren - dann kennst du ihn - oder du nutzt einen bereits vorgegebenen, dann gibt es dazu eine Doku. Im APF ist das das Timing-Modell des Front- und Page-Controllers.

Das ist nicht deterministisch definiert. Und zwar nicht etwa, weil das APF einen solchen nicht definieren könnte, sondern weil du die Freiheit hast, einen beliebigen Punkt zu wählen und auch so zu implementieren.

Im Auslieferungszustand ist der Einstiegspunkt einfach die Bootstrap-Datei. Wobei du hier genauer definieren musst, für welchen Bereich der Anwendung. Bezeichnest du als Anwendung eine Komponente News-Anzeige, die irgendwo auf der Seite eingebunden ist, dann ist der Einstiegspunkt der, der zur Anzeige des selben führt. Das kann ein Kenner einer CMS-Seite sein, auf der die Komponente redaktionell eingebunden ist oder ein einzelner Url-Parameter der die Anzeige steuert.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

dsentker

Okay, das heisst, es gibt keinen festen Ablauf der Komponente in einer APF-Applikation.

Aber irgendwo muss ja beschrieben sein, dass dieser Controller geladen wird. Ich habe die Doku überflogen, aber konnte keinen Hinweis darauf finden, wie ein solcher Einstiegspunkt definiert wird. Irgendwo muss es doch den "Stack-Ablauf" geben, sprich "mache erst dies, dann render das, dann ruf dies auf, dann mach das etc". Auch von der von verschiedenen Komponenten kommt - angestoßen werden muss er ja.

__________________

Trainmaster

Was soll das für eine andere Weise sein? Auch Symfony 2 behandelt die Url als Informationsquelle.

Nichts anderes erledigt der Routing-Mechanismus von SF2. Ich als Entwickler lege fest, welche Informationen aus der URL gewonnen werden können.

Hier möchte ich dir glatt widersprechen. Ich kann aus diesem String nicht direkt an einen Controller delegieren, jedoch aber ein Muster erkennen. Dieses Muster definiere ich als Route und der Router übernimmt die "Übersetzungsarbeit".

Wie gesagt, ich möchte weder die eine noch die andere Variante kritsieren. Lediglich geht es mir darum, dass ich mit beiden Vorgehensweisen gleichermaßen flexible und dynamische Anwendungen erstellen kann.

dsentker

Auch in meinem Framework ist die Url eine beliebige Struktur, die anhand von Routing-Definitionen aufgelöst wird. Trotzdem ist der Controller weiterhin Ziel und Dreh- und Angelpunkt einer solchen Uri-Auswertung. Wenn ich beim Aufruf einer Uri also das Model/View-Gedöns außen vor lassen möchte und nur eine Mail verschicken will, einen Webservice triggern möchte oder einen JSON-Response benötige, so muss ich hierfür eben trotzdem eine Controller-Action erstellen. Die Routedefinition könnte also lauten "Wenn Uri == 'quz/baz/' dann lade Controller "foo" mit der Methode "bar".

__________________

dr.e.

und

wiedersprechen jedoch "meinem" Ansatz und damit einer Abstraktion der Url im Sinne von HMVC. Wenn du das so haben möchtest, wiederspreche ich dir nicht. Ich möchte nur darauf hingewiesen haben, dass es hier einen kleinen aber wichtigen Unterschied gibt.

Sofern du plain-MVC und einen Front-Controller, der keine dynamischen und mehrfachen Actions ausführen kannst implementierst, ist das der einzige Weg. Schaltest du einen Front-Controller ein, der Actions basierend auf Url-Anweisungen (beim APF wiederum abstrahiert über einen Input-Filter) ausführen kann, kannst du ein und die selbe Seite bzw. Bootstrap einmal für den einen Anwendungsfall und einmal für den anderen verwenden ohne gedanklich einen Workaround schaffen zu müssen.

Der genannte Mechanismus ist beispielsweise unter http://wiki.adventure-php-framework....APF#Die_Praxis genutzt um sowohl eine einfache Webseite und leichzeitig AJAX-Resourcen über den Front-Controller bereitzustellen.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~