SimpleFramework

Hast schon Recht mit den requires. Eigentlich sind die überflüssig, da es auch einen Autoloader gibt, der alle PHP-Dateien registriert. Das sie aber dennoch vorhanden sind, dient eigentlich nur der besseren Lesbarkeit des Codes. Man soll sehen, welche Klassen innerhalb des aktuellen Files benutzt werden. Ich finde sowas bei Java und auch C++ (wo es ja notwendig ist Referenzierte Bibliotheken und Dateien explizit anzugeben) sehr hilfreich, da gleich beim Lesen des Codes klar wird, welche weiteren Quellen genutzt werden und was man sich gg. noch anschauen muss, um den Code komplett zu begreifen.

Die Unterteilung in Haupt- und SubController ist doch eigentlich ganz praktisch, da du so innerhalb eines Controllers, der fachlich ein Thema abdeckt, anhand der aufgerufenen Methode unterschiedliche Logik ausführen kannst.

Beispiel: Man hat eine Seite gebaut, die Nachrichten anzeigt. Nun gibt es unterschiedliche Controller zum Laden von Nachrichten aus unterschiedlichen Themenbereichen (Sport, Politik, Börse, Wetter,...). Der Hauptcontroller lädt jeweils den Inhalt, der später in einem sehr großen, zentralen Bereich der gerenderten Seite angezeigt wird. Die Subcontroller laden "kleinen" Inhalt, der in kleineren Teilbereichen der Ergebnisseite angezeigt wird.

Hat man beispielsweise als Hauptcontroller den PolitikController, so lädt dieser die Megaschlagzeilen, dass sich der Wulff 500.000 € von wem auch immer geborgt hat und dass in China ein Sack Reis fliegen gelernt hat. Diese Meldungen werden dann riesengroß im Hauptbereich der Seite angezeigt.
Ganz oben links in der Ecke befindet sich dann aber noch ein kleiner Bereich, der anzeigt, dass es in Berlin gerade 3 Grad kalt ist und dass es regnet.
Diese Infos kommen vom Wettercontroller, der als SubController aufgerufen wurde.
Wäre er als Hauptcontroller aufgerufen worden, so hätten die Wetterdaten den Hauptteil der Seite ausgemacht und diese wären viel umfangreicher ausgefallen als eben beschrieben. Beispielsweise hätte man das Reisewetter für alle wichtigen Urlaubsländer, die aktuellen Schneehöhen, Unwetterwarnungen, das Regenradar und was weiß ich noch alles anzeigen können.

Um nun innerhalb des Wettercontrollers zu wissen, welche Daten man laden muss, wäre es doch ganz praktisch zu wissen, ob man nun gerade als Haupt- oder SubController arbeitet. Und genau dafür gibt es die beiden Methoden process() und subProcess(). Da ich in jeder der beiden Methoden weiß, was der Controller gerade für eine Rolle spielt, ist es auch einfach entsprechend zu reagieren.

Das Argument, dass es doppelten Code bei diesen beiden Methoden geben könne, kann ich nicht gelten lassen. Es kann natürlich gut sein, dass ein Controller immer den gleichen Code ausführt, egal ob er Haupt- oder SubController ist. Da sollte man sich die Frage stellen, ob dieser Controller denn überhaupt als SubController genutzt wird oder eben nicht. Wenn nicht, dann zwingt Simple Framework den Entwickler nicht, die subProcess() Methode zu implementieren. Man kann sie einfach weglassen.
Falls man sie aber doch implementieren will oder aus irgend einem Grund muss, es aber klar ist, dass dort der gleiche Code wie in der process() Methode ausgeführt werden muss, kommt dann halt einfach ein $this->process() als einziger Code in die subProcess() Methode und das Problem ist gelöst.

__________________
Beste Grüße
Andreas Ermrich
http://www.simple-framework.de

Mister Ad

dsentker

Nein, sorry, das ist für mich kein Grund den Controller in zwei Teile zu splitten. Wie großflächig oder umfangreich bestimmte Bereiche auf einer Seite ausgegeben werden, ist Sache der View, nicht des Controllers. Wie gesagt, der Controller ist nur eine vermittelnde Instanz und schert sich nicht um die Präsentation.

Dafür gibt es Namespaces. Man sieht oben am Kopf gleich, wo die angeforderten Klassen herkommen (sofern, wie üblich, die Ordnerstruktur mit der Namespacestruktur einhergeht).

__________________

SimpleFramework

Das mit den Namespaces ist wohl richtig. Da gebe ich dir uneingeschränkt Recht. Bei den Controllern allerdings werden wir wohl nicht übereinkommen. Nur soviel. Das sich Controller nicht um die Views kümmern sollten ist korrekt. Das tun sie in meinem Fall auch nicht. Die View weiß nichts davon, dass es im vorgelagerten Controller eine process() und/oder subProcess() Methode gibt. Muss sie auch nicht wissen. Sie zeigt lediglich die ihr bereitgestellten Daten an. Woher diese kommen ist aber nebensächlich.

Stimmt. Aber was vermittelt er denn? Oder besser, wie macht er das? Er vermittelt über Programmlogik. In Abhängigkeit von bestimmten "äußeren" Bedingungen gilt es auf bestimmte Weise zu handeln. Und genau dass ist es, was die beiden von mir eingeführten Methoden machen. Sie erleichtern es dem Controller seinen vermittelnden Code in dem dem jeweiligen Kontext entsprechenden Rahmen auzuführen.

__________________
Beste Grüße
Andreas Ermrich
http://www.simple-framework.de

dr.e.

Hier stimme ich dsentker 1:1 zu. Eine Trennung ist hier nicht sinnig, denn eine Composite-Struktur von MVC-Elementen sollte sich durch die Struktur selbst und nicht durch unterschiedliche process-Methoden definieren. Ist ein Knoten ein Sub-Knoten, so ist er das, weil er im Baum ein Kind eines anderen ist und nicht dadurch dass du subProcess() aufrufst! Sollte das doch dein Ernst sein, implementierst du effektiv kein HMVC sondern eine zweistufige, begrenzte Struktur.

Mehrere Methoden pro Controller machen nur dann Sinn, wenn du unterschiedliche Zeitpunkte hast, zu denen ein Controller aufgerufen wird. Im Timing-Model des APF-Page-Controller könnte das beispielsweise eine Methode in der Analyse- und eine während der Transformations-Phase sein. In deinem Kontext kann ich so etwas nicht erkennen.

Auch hier gilt: ein Controller bzw. sein kompletter MVC-Knoten erhält durch seine Umwelt seine Bedeutung. Es verhält sich wie im täglichen Leben. Nur dadurch dass ich Mitmenschen um mich herum habe, unterscheide ich mich durch die ein oder andere Eigenschaft von diesen. Gäbe es nur mich, wäre "Unterschied" ein nicht definierbarer Begriff.

Ich bitte nikosch mit genauso viel Respekt zu begegnen, wie du dir das selbst wünschst!

Mit dieser Vorgehensweise bist du natürlich auf "programmatische Konfiguration" festgelegt.

Bin ich also doch abhängig von der Konfiguration?

Welchen Mehrwert bringt das ausser haufenweise Daten in der Session?

Als Hersteller eines Frameworks ist "Zumutbarkeit" IMHO anders zu bewerten und darf einer generisch einsetzbaren Lösung nicht im Weg stehen. Damit nimmst du dir beispielsweise komplett die Möglichkeit einer statischen Url eine konstante Repräsentation zuzuschreiben. Für Bookmarks und Suchmaschinen ist Zustandslosigkeit von Seiten enorm wichtig. Garantiert das deine Applikation nicht - in diesem Fall durch Session-Speicherung - kann der Aufruf einer Url mit frischer Session zu völlig unerwarteten Ergebnissen führen. Für mich ein NOGO.

__________________
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!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~