PHP modular programmieren

Ein Produkt für eine Installation ist einfach zu verwalten. Aber ein Produkt für viele Installationen bringt den Programmierer regelmäßig in die Bredouille. (veröffentlicht in Internet Professionell 12/2004)

Oh, wenn ich das nur lese. Die „individuelle Konfigurierbarkeit“, das Versprechen der „völligen Anpassbarkeit“ eines Programms. Nicht nur, dass es sprachlich gruselige Ausdrücke sind. Nein, sie lassen auch erst richtig den Schweiß auf des Programmierers Stirn treten.

Da hat man eine wunderschöne Software. Schnell, hübsch und stabil. Sie läuft auf einer Seite und bringt ordentlich Seitenabrufe. Doch dann interessieren sich andere für das Programm und kaufen es.

Verstehen Sie mich nicht falsch: Das freut mich. Sehr sogar. Aber andererseits ist klar: Hier kommt einiges an Arbeit auf den Programmierer zu. Denn eine Software von der Stange ist für einen Web-Auftritt nur bedingt zu verkaufen.

Die Farben müssen angepasst werden. Kein Problem mit CSS. Auch Inhalte und Menüstruktur sind – wenn man sich entsprechend vorbereitet hat – kein Problem in der Umstellung. Selbst ein komplett anderes Layout ist kein Problem. Dazu gibt es schließlich Templates — sei es in Smarty oder auch mit PHP selbst.

Für Probleme, Kummer und Schweiß allerdings sorgen die Details. Diese fiesen kleinen Änderungen, die kommen, wenn einer sagt: „Wir nehmen das Grundlayout“, hätten aber gerne den Kasten hier raus und das Element noch drin.

Was dann? Komplett neue Templates für jede einzelne Installation basteln? Lästig. Dann muss ich diese Templates auch wieder verwalten. Und vor allem: Wenn sich irgendeine grundlegende Funktion ändert, muss ich dann jedes Template wieder einzeln anfassen und umbauen. Kommt nicht in Frage.

So komme ich auf ein Konzept, dass ich vor drei Jahren schon einmal ähnlich implementiert, aber dann verworfen hatte. Ich baue mir einen Kasten voller Module, aus denen ich dann die Templates zusammensetze. Der Vorteil: in den Modulen steckt die notwendige Anzeigelogik, und wenn sich etwas ändert, brauche ich nur das Modul anpassen und auf die einzelnen Installationen zu verteilen. Das eigentliche Template bleibt bis auf den Befehl zum Einbinden des Moduls sunangetastet.

Verworfen hatte ich das Konzept einst, weil ich für die Module Funktionen verwendet habe. Das hat sich nach einiger Zeit als zu starr erwiesen. Heute verwende ich für jedes Modul eine eigene kleine Datei, die in einem eigenen Ordner landet. Und diese Dateien hole ich mit einem include-Befehl in die Templates hinein.

Damit das Ganze rund wird, bekommt jedes Modul noch eine CSS-Klasse. Deren Name entspricht dem Dateinamen des Moduls. So kann ich einigermaßen die Übersicht behalten.

Aber so ein paar Fragen bleiben dann doch – Fragen, die sich aus all den Erfahrungen der letzten Jahre ergeben:

– Wie viel Intelligenz soll so ein Modul haben? Soll es alles selbst erledigen, seine Daten selbst holen? Oder soll es lieber möglichst dumm bleiben und auf die Daten von außerhalb warten, also auf die Daten vom aufrufenden Skript.

– Wie viel Layout soll so ein Modul haben? Soll es selbst zum Beispiel eine Tabelle sein oder wirklich nur blanke Textausgabe, unterstützt von CSS.

Im Moment habe ich beide Sorten: „dumme“ Module, die Daten aus dem aufrufenden Skript verwenden. Und „intelligente“, die sich selbst versorgen. Mittelfristig werde ich wohl komplett auf „intelligente“ Module umstellen. Denn alles andere ist eine potenzielle Fehlerquelle. Nur stellt sich dann die Frage, warum ich überhaupt noch ein Skript aufrufe, das ein Template aufruft, das wiederum Module einbindet… Manchmal verwirren mich diese Dinge.

Ähnliche Beiträge