MVC in PHP-Projekt

[dedlfix]

Tach!

• Wo ist es sinnvoll in einem komplexeren php-projekt welche php Dateien wo im MVC-Modell reinzupacken. .lib.php, .inc.php in model?

Ich setze einmal den @INC-Pfad und dann werden Methoden, die ggf. weitere Klassen inkludieren, automatisch geladen (Factory).

Die Frage ist sehr allgemein gehalten. Man kann sie nicht vernünftig beantworten, ohne einen großen Roman zu schreiben. Das was du da antwortest, ist nur ein kleiner Aspekt, wenn es um das Laden geht. Wo "die Dateien" (ohne dass ansatzweise Inhalte erwähnt wurden - Versäumnis des Fragestellers) jedoch einsortiert werden sollten, darauf geht deine Antwort mit keiner Silbe ein. Wenn @INC in Perl dasselbe wie include_path in PHP ist, dann gibt man damit nur ein oder mehrere Basisverzeichnisse an, mit denen relative Verweise auf Code-Dateien ergänzt werden, um so den eigentlichen Dateinamen zu bekommen.

Per externer Konfiguration kann ich URLs ein beliebiges Interface zuweisen, sei es um Platzhalter zu beleben oder die ganze Seite interaktiv zu machen.

Was soll eine externe Konfiguration sein? In welcher Art und Weise befindet sie sich nicht in der Anwendung selbst, sondern außerhalb? Und wie kommt die Anwendung an die Konfigurationsinformation heran?

Welche Bedeutung gibst du hier dem Wort Interface? Soll das ein Interface sein, das bei OOP eine Vereinbarung über beispielsweise Variablen und Funktionen bescheibt, und welches in Klassen implementiert werden kann? Oder ist das ein spezieller Ausdruck, den man in Perl verwendet? Gefragt war nach dem MVC-Muster. Da wird üblicherweise ein Request auf einen konkreten Controller geroutet. Ob das eine Klasse ist, die ein Interface (im OOP-Sinne) implementiert, spielt für das generelle Verständnis keine Rolle.

Und was hat der Anfang des Satzes mit dem Rest zu tun? Was genau wolltest du eigentlich zum Ausdruck bringen?

• Wie ist HTML in einer PHP-Datei aufgeteilt? Strikt getrennt oder wie beim Eingabefomular beide zusammen in einer Datei?

Sowohl als auch, das regelt die View-Class, da kann ich festlegen aus welcher Quelle das Template geladen wird und das kann auch unterhalb eines Token innerhalb derselben Datei liegen. In Perlmodulen ist für sowas unterhalb __ DATA __ ein idealer Platz für Templates.

Sowas ähnliches gibt es auch in PHP. Das ist aber völlig unüblich, weil man in PHP mit <?php und ?> beliebig oft "rein und raus kann". Man ist im Gegensatz zu Perl bereits von Anfang an im Template. Dass es trotzdem noch extra Template-Systeme gibt, hat andere Gründe. Jedenfalls hilft diese Antwort nicht viel, wenn man mit seiner Lösung konform zur PHP-Philosophie bleiben möchte.

Mit Hilfe einer geeigneten Boundary unterteile ich ggf. ein Template in mehrere Templates und kann mir das für die jeweilige Anwendung entsprechend zusammenbauen wobei dafür nicht extra weitere Dateien geladen werden müssen sondern nur Eine.

Auch das braucht man in PHP nicht. Wenn man sowas ähnliches in PHP machen wollte, würde man das Template vielleicht in eine Funktion setzen.

function template_content() { ?>
<p>Template-Inhalt</p>
<?php }

function another_template_content() { ?>
<p>Noch ein Template-Inhalt</p>
<?php }

Ob das in der Form sinnvoll ist, oder es bessere Wege gibt, steht auf einem anderen Blatt.

Code mit HTML zu mischen ist keine gute Idee, da geht schnell die Übersicht flöten. So gab es auch in EmbPerl Versuche in diese Richtung, die sich jedoch nicht weiter verbreitet haben.

Welche Gründe gabs dafür? Liegt es vielleicht daran, dass Perl generell nicht (mehr) sehr häufig im Webumfeld zu finden ist und hauptsächlich für andere Einsatzgebiete verwendet wird?

Der erste Satz ist jedenfalls ein Allgemeinplatz, der stimmen kann, von dem aber auch das Gegenteil wahr sein kann. Übersicht kommt nicht automatisch zustande, wenn man ein System auseinandernimmt und dann vielleicht gar nicht weiß, wie die einzelnen Teile nun in welcher Situation zusammenspielen. Probleme mit der Übersicht liegen eher daran, dass ein Projekt aufgrund seiner Größe und Komplexität einen hohen Einarbeitungsaufwand erfordert. Natürlich gibt es auch Strukturen, die chaotisch gewachsen sind und deshalb schwer verständlich sind. Aber ich würde nicht behaupten, dass es per se übersichtlich ist, wenn Platzhalter im Template eingebaut werden und ihr Inhalt an anderer Stelle im Code ermittelt wird. Man könnte auch sagen, dass durch diese Trennung ein erhöhter Aufwand betrieben werden muss, damit beim Hinzufügen oder Entfernen von Platzhaltern im Template auch die andere Seite synchron gehalten wird. Am Ende bleibt es eine Entscheidung im konkreten Fall und Dogmen sind nicht die besten Ratgeber.

Eine einfache Template-Engine die Skalare und Arrays rendern kann, reicht vollkommen. Bilde die Progammlogik NICHT im Template ab.

View-Logik ist genauso Programmlogik wie Geschäftslogik. Du meinst mit Programmlogik vermutlich nur letzteres. Es spricht aber nichts generelles dagegen, View-Logik, wie das Verwenden einer Schleife zum Ausgeben von Daten aus einer iterierbaren Menge oder die Entscheidung, ob ein bestimmter Block oder ein anderer ausgegeben werden soll (if-else), in der View zu haben.

Natürlich kann man Templates auch völlig logikfrei gestalten. Das macht die Sache aber nicht generell besser, denn die Logik wird ja am Ende doch irgendwo gebraucht. Die Alternative ist, im Template nur Platzhalter zu haben und die Logik an anderer Stelle zu verwalten - auf dass man mindestens eine Stelle mehr hat, die man im Auge behalten muss.

Leider können die meisten mir bekannten Templateengines viel zu viel des Guten, bremsen am Ende alles aus und machen jegliche Performance-Optimierung zunichte.

Mehr Features, besonders solche, die man selbst gar nicht verwendet, machen eine Template-Engine oder ein System allgemein nicht zwangsläufig langsamer.

dedlfix.

P.s. zu Jörgs Missbrauchsverdacht. Ich wollte pls Antwort einfach nur unkommentiert stehen lassen und hab auch keine Bewertung vorgenommen. In der Vergangenheit habe ich mehrfach erlebt, dass Bemühungen den Aufwand nicht Wert waren und keinerlei Früchte zeigten. Ich will nicht sagen, dass ich die Wahrheit gepachtet hätte - ganz im Gegenteil. Nur habe ich den Eindruck, dass pls/hottis Antworten üblicherweise mehr Verwirrung stiften als aufklären. Begrifflichkeiten werden irgendwie verwendet, nur nicht so wie sie im Allgemeinen üblich sind. Auf konkrete Punkte angesprochen, kommt oft nur eine ausweichende Antwort, gern garniert mit einem "ist ja alles nicht so ernst gemeint"-Smiley ;) Ein fachlich beflügelnder Dialog kommt in der Regel nicht zustande. Ich kann es gut verstehen, dass sich aufgrund der wenig erkenntnisreichen Aussichten kaum einer mehr mehr Mühe machen möchte, als mit dem Minus zu signalisieren, dass da was nicht stimmen kann.