Hallo,
in Featurelists von PHP-Scripten kann man häufig Dinge lesen wie "modular erweiterbar", "Zusatz-Module erhältlich!", "...".
Was mich interessiert: Modular scheint ja zu bedeuten, ich packe ein zusätzliches Script (eben das Modul) ein ein entsprechendes Verzeichnis z.B. modules/.
Wie genau lässt sich so etwas programmieren? Ich meine, wie wieß das Hauptscript, dass es da ein neues Modul gibt? Was gibt es zu beachten?
Hat jemand ein paar Links für mich?
Wäre echt cool. Danke
Sebastian
[PHP] Scripte modularisieren?
Hallo,
ich habe mal im Rahmen eines kleinen Projektes ein Modulares Script programmiert. Als ich fertig war konnte ich über ein Webinterface PHP Code schreiben (ging auch in einem Editor), welcher dann in eine Datenbank gespeichert wurde. Der "Webmaster" konnte dann *bestimmen* wann und wo und wie der Source Code ausgeführt wird. Er konnte sich also seine eigenen "Module" schreiben.
Ich persönlich bin der Meinung, dass "Module" nicht richtig definiert sind. Denn den Effekt, welchen ich erreicht habe könnte ich auch durch irgendwelche anderen Dinge erreichen.
Um auf deine eigentliche Frage zurückzukommen:
Du lässt dein PHP Script einfach die Dateien im Ordner /modules durchlaufen - dabei merkst du ja wenn eine neue Datei *da ist*.
Nun kanns du entweder dynamisch includieren oder dir irgendwelche anderen spielereien einfallen lassen.
Links kann ich dir nicht anbieten. Sorry.
Edit: Modular erweiterbar heisst zum Beispiel im CMS (Content Management System) Bereich, dass der Kunde zum Beispiel nur durch das Ausführen eines MySQL Befehles oder durch das abspeichern einer neuen Datei zb in das /Modules Verzeichnis ein neues "Modul" bekommt. Zum Beispiel eine Funktion, dass die Besucher der Seite nun auch in einem Forum diskutieren können. Module haben den Vorteil für den Kunden sich sein spezielles CMS zusammenstellen zu können -> er hat nur die features die er benötigt dh. er gibt nicht unnötig geld aus und im falle von kostenlosesen Scripten hat er weniger Bugs oder Sicherheitslöcher -> sprich weniger Aufwand das ganze zu pflegen. Module sind dazu da um Systeme besser skalieren zu können.
ich habe mal im Rahmen eines kleinen Projektes ein Modulares Script programmiert. Als ich fertig war konnte ich über ein Webinterface PHP Code schreiben (ging auch in einem Editor), welcher dann in eine Datenbank gespeichert wurde. Der "Webmaster" konnte dann *bestimmen* wann und wo und wie der Source Code ausgeführt wird. Er konnte sich also seine eigenen "Module" schreiben.
Ich persönlich bin der Meinung, dass "Module" nicht richtig definiert sind. Denn den Effekt, welchen ich erreicht habe könnte ich auch durch irgendwelche anderen Dinge erreichen.
Um auf deine eigentliche Frage zurückzukommen:
Du lässt dein PHP Script einfach die Dateien im Ordner /modules durchlaufen - dabei merkst du ja wenn eine neue Datei *da ist*.
Nun kanns du entweder dynamisch includieren oder dir irgendwelche anderen spielereien einfallen lassen.
Links kann ich dir nicht anbieten. Sorry.
Edit: Modular erweiterbar heisst zum Beispiel im CMS (Content Management System) Bereich, dass der Kunde zum Beispiel nur durch das Ausführen eines MySQL Befehles oder durch das abspeichern einer neuen Datei zb in das /Modules Verzeichnis ein neues "Modul" bekommt. Zum Beispiel eine Funktion, dass die Besucher der Seite nun auch in einem Forum diskutieren können. Module haben den Vorteil für den Kunden sich sein spezielles CMS zusammenstellen zu können -> er hat nur die features die er benötigt dh. er gibt nicht unnötig geld aus und im falle von kostenlosesen Scripten hat er weniger Bugs oder Sicherheitslöcher -> sprich weniger Aufwand das ganze zu pflegen. Module sind dazu da um Systeme besser skalieren zu können.
-
Sebastian.S
- Beiträge: 437
- Registriert: 13.04.2003 13:17:41
Ja genau so habe ich mir das auch vorgestellt.Christ|an hat geschrieben:Edit: Modular erweiterbar heisst zum Beispiel im CMS (Content Management System) Bereich, dass der Kunde zum Beispiel nur durch das Ausführen eines MySQL Befehles oder durch das abspeichern einer neuen Datei zb in das /Modules Verzeichnis ein neues "Modul" bekommt. Zum Beispiel eine Funktion
Und das machen auch größere Projekt einfach nur dadurch, dass Sie alle Dateien im modules/-Verzeichnis durchegehen und dann include()en? Oder gibt es da besondere Kniffe? (Vielleicht denke ich auch einfach nur zu kompliziert und es ist wirklich auch bei großen Projekten nur ein "Was-da-ist-wird-eingebunden-Algorithmus"?)
Hi
also ich habe es halt damals mit einer Datenbank gemacht und dann mit eval() ausgeführt (ja ich weiss is nicht die sicherste Varante).
Aber im Prinzip ist es so, wie du es dir vorgestellt hast. Es kommt halt auch auf de Stuktur deines Scriptes an. Und ob es "gut" ist einfach alle Modul Dateien zu includieren sei auch mal dahingestellt. Aber im prinzip kann es so funktionieren
Also ran an die Arbeit
Wenn du Hilfe beim coden brauchst - melden
Gruss
also ich habe es halt damals mit einer Datenbank gemacht und dann mit eval() ausgeführt (ja ich weiss is nicht die sicherste Varante).
Aber im Prinzip ist es so, wie du es dir vorgestellt hast. Es kommt halt auch auf de Stuktur deines Scriptes an. Und ob es "gut" ist einfach alle Modul Dateien zu includieren sei auch mal dahingestellt. Aber im prinzip kann es so funktionieren
Also ran an die Arbeit
Wenn du Hilfe beim coden brauchst - melden
Gruss
-
carstenBLN
- Beiträge: 20
- Registriert: 08.10.2003 20:39:35
Also, "modular programmieren" heißt ja noch was anderes. Es kann zum Beispiel heißen, dass Du ein großes PHP-Projekt mit Datenbank-Unterstützung hast, das der ursprüngliche Entwickler für MySQL geschrieben hat, aber schon so clever war, diese Datenbank-Anbindung nicht hart in den Code zu hacken, sondern sie zu shellen/wrappten/yielden, also in ein "Modul" zu stecken. Wenn Du das Projekt jetzt in eine Umgebung trägst, wo es Postgres oder Oracle oder ODBC oder sonstwas gibt, dann tauschst Du einfach das MySQL-Modul aus und kopierst ein Postgres-/...-Modul hinein, änderst vielleicht noch irgendwo eine Zeile, und das Ding läuft.
"Modular" programmieren heißt erstmal, dass es n "Baukastensystem" gibt. Einige Module sind notwendig für die Funktionalität (der "Kernel"), den Rest kann sich derjenige, der das Ding dann betreibt, nach seinen Wünschen einrichten. "phpNuke" ist ein Beispiel für so einen Ansatz, wenn auch ein denkbar schlecht umgesetztes. An der Oberfläche ist es allerdings schick. Du musst da ein Modul nur in ein Verzeichnis kopieren und findest dann in einer Admin-Oberfläche einen neuen Link, auf den Du nur noch klicken musst, um das Modul einzurichten und scharf zu schalten.
"Modular" programmieren heißt erstmal, dass es n "Baukastensystem" gibt. Einige Module sind notwendig für die Funktionalität (der "Kernel"), den Rest kann sich derjenige, der das Ding dann betreibt, nach seinen Wünschen einrichten. "phpNuke" ist ein Beispiel für so einen Ansatz, wenn auch ein denkbar schlecht umgesetztes. An der Oberfläche ist es allerdings schick. Du musst da ein Modul nur in ein Verzeichnis kopieren und findest dann in einer Admin-Oberfläche einen neuen Link, auf den Du nur noch klicken musst, um das Modul einzurichten und scharf zu schalten.
Und noch ein Link zum Thema, der dies recht einfach erklärt -> http://www.php-center.de/artikel/include.php3
cu
cu
Hi,
also es kommt wirklich ganz enorm darauf an, was du umsetzen möchtest. Und ich denke, es gibt hier verschiedene grundlegende Unterscheidungsebenen.
Zum einen ist die Frage, wie ein Modul in das System integriert wird (und umgekehrt).
Ich hab z.B. eine kleine Applikation geschrieben, in der es ein paar Module gibt (Daten importieren, Benutzer verwalten, Firmendaten ändern, Forum, Login, Logout usw.), die aber auf der Darstellungsebene fest eingepflanzt sind. Hier ein neues Modul einzubinden sähe je nach Modul ganz anders aus und wäre echte Handarbeit (aber durch den modularen Aufbau auch wiederum relativ schnell erledigt).
Im anderen Extremfall werden einfach alle eingebundenen Module in einer Navigationsliste aufgezählt (siehe diese unsäglichen Portalsysteme). Hier lässt sich sehr schnell ein Modul ein- oder ausbinden. Schon gar, wenn die Module unabhängig voneinander arbeiten.
Eine andere, oft angezeigte Variante ist die strikte Trennung von Seitenstruktur und Modulen, so dass über die gewöhnliche Seitennavigation lediglich bestimmte Ressourcen angefordert werden oder Aktionen gefordert werden und der Kern übergibt diese Aufträge dann den Modulen, die dafür gemacht sind. Hier hast du dann zumindest Abhängigkeiten zwischen den Inhalten (auch Navigationselementen) und den Modulen, denn alle verlinkten Ressourcen müssen ja auch angezeigt werden können.
Weiter macht es natürlich einen Unterschied, ob ein Modul z.B. nur aus einer Datei besteht, die man lediglich einschließen muss, oder ob das Modul erst entpackt und installiert werden muss.
Und dann ist die nächste Ebene eben die, der Einbindung zur Laufzeit. In aller Regel bindest du das Modul dann ein, wenn du es brauchst und nicht alle auf einmal. Das würde ja keinen Sinn ergeben. Und, mitunter bindest du Module eben mit einem einfachen @include("modules/$modul") or die "error: ..."; ein, mitunter besteht das Modul aus einer Klasse, die erst initialisiert werden will etc.pp.
Ich finde das Thema gerade recht interessant, da ich mir vor kurzem erst ein paar Gedanken über Modulabhängigkeiten gemacht habe (im Rahmen eines seit langem vor sich hinköchelndem Vorhaben, ein Scripting Framework zu basteln). Ich hab dabei die Vermutung aufgestellt, dass es geschickter ist, Modulabhängigkeiten nicht dergestalt abzubilden, dass bei Modul A abgegeben ist, dass es Modul X, Y und Z benötigt, um zu laufen, sondern, dass für Modul A angegeben ist, dass es die Funktionalitäten (oder Schnittstellen) k, l, m und n braucht, welche Module die dann auch immer bereitstellen.
Z.B. eine Session-Klasse, die die Session-Daten in eine MySQL-Datenbank speichern tut, die benötigt ja nur eine Möglichkeit, eine Query an eine Datenbank zu schicken. Ob das nun die MySQL-Klasse ABC, Version 1.3 oder die MySQL-Klasse DEF, Version 4.6.12 erledigt, kann der Session-Klasse ja gleich sein.
Die Schnittstelle, die die Session-Klasse benötigt bekommt also einen Namen und jede neu erschienene Klasse wird auf diese Funktionalität hin überprüft.
Auf diese Weise könnten Module flexibler gahandhabt werden.
Und, BTW noch eine praktische Frage, die mich schon lange wurmt:
Obiges beispiel einer Session-Klasse. Wie bindest ihr in einem solchen Fall die MySQL-Klasse ein? global $mysql_klassen_instanz; in jede Objektmethode? Oder nur in den Kostruktor, um die Instanz dann in eine Objektvariable zu speichern? Neue Instanz erzeugen? Vererbung?
Basti
also es kommt wirklich ganz enorm darauf an, was du umsetzen möchtest. Und ich denke, es gibt hier verschiedene grundlegende Unterscheidungsebenen.
Zum einen ist die Frage, wie ein Modul in das System integriert wird (und umgekehrt).
Ich hab z.B. eine kleine Applikation geschrieben, in der es ein paar Module gibt (Daten importieren, Benutzer verwalten, Firmendaten ändern, Forum, Login, Logout usw.), die aber auf der Darstellungsebene fest eingepflanzt sind. Hier ein neues Modul einzubinden sähe je nach Modul ganz anders aus und wäre echte Handarbeit (aber durch den modularen Aufbau auch wiederum relativ schnell erledigt).
Im anderen Extremfall werden einfach alle eingebundenen Module in einer Navigationsliste aufgezählt (siehe diese unsäglichen Portalsysteme). Hier lässt sich sehr schnell ein Modul ein- oder ausbinden. Schon gar, wenn die Module unabhängig voneinander arbeiten.
Eine andere, oft angezeigte Variante ist die strikte Trennung von Seitenstruktur und Modulen, so dass über die gewöhnliche Seitennavigation lediglich bestimmte Ressourcen angefordert werden oder Aktionen gefordert werden und der Kern übergibt diese Aufträge dann den Modulen, die dafür gemacht sind. Hier hast du dann zumindest Abhängigkeiten zwischen den Inhalten (auch Navigationselementen) und den Modulen, denn alle verlinkten Ressourcen müssen ja auch angezeigt werden können.
Weiter macht es natürlich einen Unterschied, ob ein Modul z.B. nur aus einer Datei besteht, die man lediglich einschließen muss, oder ob das Modul erst entpackt und installiert werden muss.
Und dann ist die nächste Ebene eben die, der Einbindung zur Laufzeit. In aller Regel bindest du das Modul dann ein, wenn du es brauchst und nicht alle auf einmal. Das würde ja keinen Sinn ergeben. Und, mitunter bindest du Module eben mit einem einfachen @include("modules/$modul") or die "error: ..."; ein, mitunter besteht das Modul aus einer Klasse, die erst initialisiert werden will etc.pp.
Ich finde das Thema gerade recht interessant, da ich mir vor kurzem erst ein paar Gedanken über Modulabhängigkeiten gemacht habe (im Rahmen eines seit langem vor sich hinköchelndem Vorhaben, ein Scripting Framework zu basteln). Ich hab dabei die Vermutung aufgestellt, dass es geschickter ist, Modulabhängigkeiten nicht dergestalt abzubilden, dass bei Modul A abgegeben ist, dass es Modul X, Y und Z benötigt, um zu laufen, sondern, dass für Modul A angegeben ist, dass es die Funktionalitäten (oder Schnittstellen) k, l, m und n braucht, welche Module die dann auch immer bereitstellen.
Z.B. eine Session-Klasse, die die Session-Daten in eine MySQL-Datenbank speichern tut, die benötigt ja nur eine Möglichkeit, eine Query an eine Datenbank zu schicken. Ob das nun die MySQL-Klasse ABC, Version 1.3 oder die MySQL-Klasse DEF, Version 4.6.12 erledigt, kann der Session-Klasse ja gleich sein.
Die Schnittstelle, die die Session-Klasse benötigt bekommt also einen Namen und jede neu erschienene Klasse wird auf diese Funktionalität hin überprüft.
Auf diese Weise könnten Module flexibler gahandhabt werden.
Und, BTW noch eine praktische Frage, die mich schon lange wurmt:
Obiges beispiel einer Session-Klasse. Wie bindest ihr in einem solchen Fall die MySQL-Klasse ein? global $mysql_klassen_instanz; in jede Objektmethode? Oder nur in den Kostruktor, um die Instanz dann in eine Objektvariable zu speichern? Neue Instanz erzeugen? Vererbung?
Basti