MVC in PHP-Projekt

[pl]

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.

Der Dateiname ergibt sich in Perl anhand des Modulnamen. Leider ist das in PHP u.a. PLs nicht so.

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?

Konfiguriert wird für einen URL title, descr u.a. Attribute. So kann z.B. dem URL /index.html das interface=date zugewisen werden, was in /index.html einen Platzhalter fürs aktuelle Datum ermöglicht.

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.

Ein einfaches IF beschreibt mehrere Methoden, die bei JEDEM Request durchlaufen werden um die Response zu erzeugen. In Perl wie in PHP machbar.

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.

Das ergibt wieder eine unheilvolle Mischung von Template mit Code, hat sich nach meiner Erfahrung immer wieder als unzweckmäßig erwiesen. Daher empfehle ich auch, für MVC-Patterns PHP eben nicht als Template-Engine zu verwenden.

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?

In Perl hats lange Zeit an einer TE gefehlt, erst mit 5.8 ist HTML::Template in den Core gekommen. Eigenbau einer TE war in Perl Tagesordnung. Habe ich auch hinter mir und das war eine sehr gute Entscheidung.

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.

Template vom Code zu trennen hat sich immer wieder als zweckmäßig erwiesen. Gerade fürn MVC.

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.

Nunja, if/else/endif sollte eine TE schon können.