Willkommen in der Webstatt Zum Webstatt Blog und Stories
Wasili am 07.02.07 19:01

Eine theoretische Frage zu einem Modulsystem... Ich kenne ein Browserspiel, das vollkommen Modular ist und bei dem sich fast alles per Modul lösen lässt.
Nun geht das aber auf Kosten der Geschwindigkeit... Seitenaufbau von ~2 Sekunden sind keine Seltenheit.
Nun will ich für ein Projekt auch ein Modulsystem bauen. Um aber nicht diese extreme Lahmheit zu erben, überlegte ich mir folgendes:

Die Module werden einer in XML-Sprache notiert. Beim installieren des Moduls arbeitet ein interner Interpreter die XML-Datei ab und schreibt den entsprechenden Code in die entsprechenden Stellen, anstatt den Code über eine Funktion dort aufzurufen...

Also sowas in der Art:
Vorher:
##### HOOK::VILLAGE #####
##### ENDHOOK::VILLAGE ####


Moduldatei:
<module>
<name>Blah</name>
<author>...</author>
<official_UID>x000000f1</official_UID>
<install>
<hook name="village">
<![#PCDATA]
output('Hier hat sich das Modul eingehakt.');
!>
</hook>
</install>
</module>


Nachher:
##### HOOK::VILLAGE #####
##### START::MODULE::x000000f1 ####
output('Hier hat sich das Modul eingehakt.');
##### END::MODULE::x000000f1 ####
##### ENDHOOK::VILLAGE ####


Bevor ich mich da nun euphorisch drauf stürze... Ist diese Idee überhaupt sinnvoll? Vorausgesetzt, Installation und Deinstallation klappen Reibungslos? ^^

netcup.de Warum gibt es hier Werbung?
crooked am 07.02.07 21:05

Wie wäre es mit nem Template System?

Wasili am 07.02.07 21:38

Ich will n' Modulsystem und kein Templatesystem Oo
Templatesystem hab ich ja. Ich will aber n' Modulsystem, um den Skriptcode erweitern zu können. Nicht das Template.

Snake am 07.02.07 21:49

es drängt sich nur die frage auf: warum xml, wenn du es nacher doch in php umwandelst. warum nicht gleich als php? und schon wärst du wieder beim modul system.

ein klever implentiertes modul system ist nicht wesentlich langsamer als wenn mans direkt rein coden würde

Michael Michael am 07.02.07 23:05

Ich kann Snake nur zustimmen. Wenn du einen eigenen Server hast, könntest du darüber nachdenken Module direkt inden Apache Speicher zu laden. Zumindest mit anderen Sprachen geht das.

Allgemein gilt: Je flexibler desto langsamer.

Man muss entsprechend der Anforderungen einen Mittelweg finden

Wasili am 08.02.07 17:06

Warum XML?
Naja. Dachte, es sei für andere einfacher, was in XML zu beschreiben, als was in PHP... ^^ Dat Ding soll ja später mal veröffentlicht werden, und damit der Core updatebar bleibt, mach ich n' Modulsystem.

Mh. Immerhin noch kein Argument, das klar gegen das "reinschreiben" in den Code spricht... Mit svn kombiniert wäre es vielleicht ganz bequem zu verwalten ^^

Michael Michael am 08.02.07 19:27

Wenn jemand Erweiterungen/Module für ein PHP System schreibt, sollte er auch in der Lage sein eine "Installations" Datei in PHP zu schreiben.

Ich würde das OOP aufbauen und alle Module von einer Basisklasse erben lassen, die den Aufbau vorgibt und sie zwingt gewissen Informations-Methoden zu implementieren.


// edit
Rechtschreibfehler

Johannes am 10.02.07 19:53

Das bringt mich auf eine Idee, die wiederum folgende Frage aufwirft:

Wäre es bei einem Skript, von dem ich jetzt schon weiß, dass es dafür Updates geben wird (bei denen auch die Ordnerstruktur geändert werden muss) sinnvoll, eine XML-Datei für jede Version rauszugeben, in der dann in XML-Syntax drin steht:

-Füge bei der Tabelle die und die Spalte ein. ( Automatisch )
-Zähle die Datensätze und speichere die wo auch immer. ( Automatisch )
-Frage ab, ob der Ordner umbenannt wurde ( Useraufgabe )
-Überprüfe, ob die und die Datei geändert wurde ( Useraufgabe )

Das würde dann je Update immer nur eventuell geänderte Dateien geben und die Installations-Datei wäre dabei immer dieselbe (und könnte auch mehrere Updates hintereinander (verschiedene xml-Dateien) ausführen)

Macht sowas sinn, oder sollte man vielleicht doch besser bei jeder Version eine neue Installationsdatei (PHP) rausgeben?

Michael Michael am 12.02.07 15:04

Ich sehe einfach den Vorteil nicht.

Bitte versteht mich nicht falsch, es gibt viele sinnvolle Anwendungsbereiche von XML, aber bei diesem Beispiel gibt es nur Nachteile gegenüber ausführbaren PHP Dateien - man müsste ja auch die XML Datei herunterladen, oder?

Johannes am 12.02.07 15:39

Nuja, aber ich könnte ja jetzt eine XML-Datei mit der Ordner- und Datenbankstruktur erstellen und das Installationsprogramm sucht alles, was anders ist und ändert das. -> Man könnte von jeder beliebigen Version aus ein Update machen und hat nur eine Datei

Michael Michael am 12.02.07 15:56

Das ist mir klar. Aber was ist der Vorteil gegenüber einer PHP Datei, die den Installationscode enthält.
So wie ich es verstehe, gibt es bei deiner Idee ein Update Script, das als Parameter eine XML Datei bekommt und dementsprechend Änderungen durchführt.
Das ist solange wirklich sehr einfach, wie es vorher definierte Änderungen sind. Datenbankabfragen, Ordnerstrukturen...
Probleme gibt es sobald nicht vorher gedachte Änderungen nötig sind, dann ist in jedem Fall ein neues Script für das Updaten nötig.

Wenn man nun das Updatescript zusammen mit den Parametern in eine PHP Datei macht, wird die Datei zwar ein wenig größer aber man ggf belibig variabel sein.

Ich kann gerade nicht vollkommen richtig denken, aber mein Punkt wurde glaube ich deutlich

Wasili am 12.02.07 17:08

Mh... Lol. Mir ist gerade eingefallen, dass Änderungen an den PHP-Dateien automatisch den Code auch unersetzbar machen Oo"

Vergesst das ganze.. xD Argh. Irgendwie is mir das entfallen *g*

Es war eine Idee. So flugs... Man hätte einfache Module schreiben könnte, ohne PHP zu können (Naja, dafür halt nen XML-Dialekt... Grm). Aber je länger ich das beachte, umso unsinniger wird das ganze :D

Creative Commons Lizenzvertrag
Alle Inhalte des Webstatt-Archivs stehen unter einer Creative Commons Namensnennung - Weitergabe unter gleichen Bedingungen 3.0 Unported Lizenz.

Impressum & Kontakt