Elegantes Modulsystem in PHP

[Peter Mairhofer]

Hallo!

Ich stehe vor der Frage, wie ich mein CMS System in PHP elegant modularisieren kann.
Also ich kann sagen, dass jede Seite/Bereich/Feature, was auch immer, auf der Homepage etliche Funktionen implementieren *kann* (aber nicht muss), um sich in die Homepage einzugliedern:

• Die Content-Seite selbst
• Ein kleines Popup/Übersichtsfenster etc für die Startseite (also z.B. bei einer Forumseite könnte das ein kleines Fenster sein, wo die letzten 5 Beiträge drinstehen, das dann auf die Hauptseite kommt. Nach einem Klick darauf bin ich dann dort).
• Eine Suchfunktion, kurz: es soll sich in eine gemeinsame Suchfunktion eingliedern lassen können.
• (...)

In C jedenfalls würde das perfekt gehen: Für jede Seite gibt es eine DLL, die bestimmte Callbackfunktionen exportieren muss. z.B. die Callback Funktion für die Suche: Das Hauptsystem ruft die Funktion "GetSearchParam" auf, um Suchparameter abzufragen und bei einer Suche "DoSearch" um alle Treffer auf dieser Seite zu erhalten unsw.

Jedoch ist das in PHP sicher nicht so einfach, da eine Funktion eindeutig sein muss.

Mein CMS-System ist bis jetzt so aufgebaut:

Es gibt eine "header.inc.php" und eine "footer.inc.php". Bei den verschiedenen Seiten wird nun am Anfang und am Ende jeweils der Header eingebunden. Vorteil ist, dass ich z.B. vor dem Einbinden ein $AddHeader definieren kann, das dem Header hinzugefügt wird. Mir ist dieses System irgendwie viel sympathischer als ein System, wo's nur eine index.php mit Parametern gibt (btw: WIe schaut eure Meinung dazu aus)?

Welche Tipps könnt ihr mir geben, wie man sowas "elegant" in PHP löst?

Peter

[Christian Kruse]

Hallo Peter,

[...]

Jedoch ist das in PHP sicher nicht so einfach,
da eine Funktion eindeutig sein muss.

Pack sie in eine Klasse. Das ist ein typischer
Fall von Objekt-Orientierung (Polymorphismus).
Du schreibst eine Klasse Plugin, von der alle
Plugins abgeleitet werden muessen. Zur weiteren
Information: in PHP ist etwas wie

$class = "Klassenname";
$obj = new $class("blahr","blub");

durchaus moeglich.

(btw: WIe schaut eure Meinung dazu aus)?

Hat beides Vor- und Nachteile. Deine Methode
verlangt halt viel mehr vom Plugin-Autor.

Gruesse,
 CK

[Andreas Korthaus]

Hallo Christian!

Du schreibst eine Klasse Plugin, von der alle

Plugins abgeleitet werden muessen. Zur weiteren
Information: in PHP ist etwas wie

$class = "Klassenname";
$obj = new $class("blahr","blub");

durchaus moeglich.

Wie würdedt Du denn einen Controller hierfür implementieren, also den Teil der Software der für das aufrufen einer Methode entsprechend dem Request zuständig ist, oder vielleicht auch nur include, oder man verwendet Apache als Controller in dem dieser entsprechend dem Pfad direkt das Script startet.

Angenommen man hat jetzt ein Plugin "kontakt", wo man so sachen wie irgendwelche Listen mit Ansprechpartnern, verschiedene Anfrageformulare... hat. Das heißt das Plugin hat verschiedene HTML-Templates die ausgegeben werden können.

• würdest Du alle Requests über ein zentrales Script laufen lassen

• wie würdest Du ausgehend vom Request des Clients die endgültige Funktionalität aufrufen, die z.B. das Kontakt-Formular laden soll?
  ?

• Woran würdest Du erkennen welches Plugin geladen werden soll?

würdest Du dann pro Plugin eine vererbte Plugin-Klasse haben, also z.B. "Kontakt extends Plugins", der die Request-Parameter übergeben und in der Konstruktor-Funktion dann entsprechend der gesendeten Parameter eine andere Methode laden, die dann z.B. das Template für das Kontakt-Formular läd?

So in etwa habe ich mir das nämlich überlegt, ich verwende ein Script "main.php", das per mod_rewrite alle Requests erhält.
Meine Requests sind so aufgebaut: /[pluginID]/[script]

Also z.B. /Kontakt/kontaktformular

So habe ich das bisher gemacht, und dann aus dem Plugins-Verzeichnis "Kontakt" das Script kontaktformular per include() eingebunden. Und das Script hat dann entsprechend entweder ein Template geladen, komplexere haben auch einen Switch der entsprechend weiterer Parameter das Vorgehen entscheidet, aber das war es im Prinzip.

Jetzt würde ich das ganze gerne besser abkapseln, also objektorientiert aufbauen.

Im Moment wüde ich es so machen:

Request: /[pluginID]/[action-methode]

und dann

include(APP_ROOT.$pluginID.'/main.class.php');
new $pluginID($action-methode,$_REQUEST,$_SESSION,$DB);

So prinzipiell, und dann in der Konstruktor-Methode vielleicht sowas wie

$this->$action-methode()

und darin dann machen was eigentlich gefordert ist, z.B. das Template für das Kontaktformular laden.

Aber das erscheint mir nochnicht wirklich rund, daher die Fragen hier ins Forum: Was haltet Ihr davon oder wie könnte man es besser machen?

Grüße
Andreas

[Tom]

Hello zusammen,

das ganze Konzept der Scripte ist bereits eine Form der Objektorientierung. Alle Scripte verfügen über ein gemeinsames Runtime und kennen ihre Methoden. Über Sessions hat man einen Shared Memory Bereich zur Verfügung.

Durch geschicktes Hinzuladen nur der benötigten Funktionen hält man das System schlank.

Nun kann man grundsätzlich alle Funktionen auslagern in include-Dateien und diese durch entprechende Prefixes kennzeichnen. Das ist zugegebenermaßen eine primitive Frühform der OOP, aber sie funktioniert bestens.

Man kann das Ganze auch bestens polymorphiefähig machen, indem man sich bei seinen HTML-Formularen an strikte Trennung von gebundenen Daten, ungebundenen Daten und Controls hält:

<input type="text" name="data[mahntext1]>

Wenn aber Entscheidungen im Script getroffen werden müssen, die nicht gespeichert werden:

<input type="checkbox" name="ctrl[mahntext][]>

usw.

Die gesamte Strukturierung eines CMS sitzt also eigentlich außerhalb der Scripte und HTML-Dateien....

Grüße

Tom