HMVC - Requests aus Templates

[dr.e.]

Hallo xm22,

beim Thema separation of concerns im Rahmen von HMVC geht es darum, die Abhängigkeiten eines Moduls innerhalb des Baumes zu abstrahieren. So sollst du nicht allgemeingültige Informationen und das Umfeld des Knotens diesem manuell zur Verfügung stellen müssen.

Fügst du an einer definierten Stelle ein Modul per PHP-Code ein, muss

a) PHP-Code im View erlaubt sein oder
b) ein Modul im Controller an einer definierten Stelle des Templates einfügen lassen (z.B. Platzhalter)

In beiden Fällen hast du aber die Notwendigkeit, das Modul auch in den Baum einzubetten. Du musst ihm Attribute des Baum-Zweiges mitgeben, seinen Vater, seine Nachbarn, ... Das alles ist dann händisch notwenig und eben nicht generisch durch eine umgebende Komponente wie der Page-Controller des APF.

Als Entwickler habe ich den Anspruch, dass ich mich um derartige Themen nicht kümmern muss, das sollte das Framework für mich schon übernehmen.

Sicher kann man nun argumentieren, dass ein Modul ja keine Informationen braucht. Nutz man diese Schnittstelle wirklich als Plugin- und Modul-Schnittstelle (was sehr wohl sinnvoll ist!) steht man vor den Problemen, die wir hier im Forum zu diesem Thema schon oft diskutiert hatten.

[Gast]

ein Modul im Controller an einer definierten Stelle des Templates einfügen lassen (z.B. Platzhalter)

Das entspricht doch dem Ansatz beim APF, oder nicht?

Du musst ihm Attribute des Baum-Zweiges mitgeben, seinen Vater, seine Nachbarn

Wieso? Die einzelnen HMVC-Knoten wissen weder was über Eltern, noch etwas über Geschwister. Wozu auch? Sie sollen ja weitgehend autonom arbeiten.

steht man vor den Problemen, die wir hier im Forum zu diesem Thema schon oft diskutiert hatten.

Das wollte ich jetzt auch nicht noch mal aufwärmen Es geht ja hier um den Unterschied zwischen dem Kohana-Ansatz und den des APF

In meinen Augen liegt der Unterschied ausschließlich darin, dass beim APF der Page-Controller die Taglibs parst und entsprechend umsetzt - eine zentrale Stelle also. Bie Kohana hingegen findet die Einbindung im _weitesten Sinne_ ebenso statt, nur dass die zentrale Instanz des Page-Controllers fehlt, die hier aber gar nicht notwendig ist.

[JohnT]

Dank für die Links dr.e. Ich hatte fast alle bereits durch und denke die theoretischen Grundlagen einer HMVC-Architektur sind verstanden.
Klar ist auch, wie es dein APF macht. Ich habe dem ähnlich erfolgreich einen Test erstellt, mit eigenem XML-Parser und Page Controller mit Composite, der den Seitenbaum verwaltet. Statt der XML-Syntax in den Templates würde ich aber gerne (aktiven) PHP-Code haben. Die Templates würden dann also selbst direkt den Seitenbaum erstellen/veralten, ohne dass dies der Page Controller über die geparsten Aufrufe macht.
Darüber finde ich jedoch keine Unterlagen, da deine Kommentare im Forum und Tutorials auf der APF-Webseite allesamt nur den APF-Weg über XML beschreiben. (Neben deinen Meldungen gibt's praktisch nichts anderes bezüglich PHP und HMVC.)

Konkrete Frage: ist nach deiner Erfahrung ein vernünftiges HMVC-Design also nur zu erreichen, wenn die Templates den passiven Code enthalten, der geparst, die Requests extrahiert und damit dann die Seite "zusammengesetzt" wird?

Edit: Sorry, habe erst jetzt deinen Beitrag von 14:43 gelesen. Beantwortet natürlich die vorausgehende Frage.

[dr.e.]

Das entspricht doch dem Ansatz beim APF, oder nicht?

Eben nicht ganz. Der Ansatz von Kohana ist manuell und der des APF automatisiert.

Wieso? Die einzelnen HMVC-Knoten wissen weder was über Eltern, noch etwas über Geschwister. Wozu auch? Sie sollen ja weitgehend autonom arbeiten.

Darum! Und du kennst die Antwort aus unseren Diskussionen auch.

In meinen Augen liegt der Unterschied ausschließlich darin, dass beim APF der Page-Controller die Taglibs parst und entsprechend umsetzt - eine zentrale Stelle also. Bei Kohana hingegen findet die Einbindung im _weitesten Sinne_ ebenso statt, nur dass die zentrale Instanz des Page-Controllers fehlt, die hier aber gar nicht notwendig ist.

Und da wäre noch das Environment, das der APF-Page-Controller zur Verfügung stellt. Es ist also kein Unterschied, ob du ein Template als Root-Node oder als "Modul" lädst. Bei Kohana ist es für mein Verständnis ein Unterschied.

[dr.e.]

Hallo JohnT,

Konkrete Frage: ist nach deiner Erfahrung ein vernünftiges HMVC-Design also nur zu erreichen, wenn die Templates den passiven Code enthalten, der geparst, die Requests extrahiert und damit dann die Seite "zusammengesetzt" wird?

Meiner Ansicht nach ja. Nur so wird eine Trennung von View und Controller erreicht und nur so kann einem Modul ein Umfeld geboten werden, das es erlaubt dieses an jedem beliebigen Platz im Baum einzuhängen.

Weiterhin verleitet PHP als Template-Sprache birgt potentiell Unsicherheit, es werden schnell Konstrukte wie ViewHelper genutzt, die im Grunde keine Wiederverwendbarkeit erzeugen und konzeptionell von MVC entfernen und ermöglicht keinen Aufbau eines generischen DOM-Baums nach immer dem selben Muster.

Ein gemeinsames Sprach-Konzept bringt zudem den Vorteil, dass Komponenten leichter implementiert werden können. Bestes Beispiel ist die Formular-Unterstützung des APF, die "auch nur" Taglibs sind, durch die Composite-Struktur jedoch auch in einem Controller als vollweriges Objekt genutzt werden können.

Nicht zu letzt wegen diesen Gründen gibt es die APF-HMVC-Implementierung nun mehr schon seit mehr als 6 Jahren.