Sven Rautenberg: Web-Programme modular aufbauen

Beitrag lesen

Moin!

Ich bin dabei eine Softwre zu schreiben, die verschiedene Module enthalten soll. Das heißt ein Basis-Modul mit der eigentlichen Basissoftware, und dazu kann man evtl noch zusätzliche Erweiterungen(Module) installieren, so z.B. ein Modul Mehrsprachigkeit, oder ein Modul Fragebogengenerator. Programmiert wird das ganze in PHP/PERL und MySQL.
Wie man an den beiden Beispielen sieht, greifen die Module unterschiedlich weit in die gesamte Anwendung ein, gerade die Mehrsprachigkeit z.B. recht weit. Module sollen nicht von vornherein vorhanden sein, sondern sich auch nachträglich installieren lassen.

Mit anderen Worten: Du hast ein (geplantes) Gesamtpaket, aus dem du einzelne Elemente herausschneiden willst. Und wenn man etwas schneidet, dann ... blutet es? Nein, dann hat man Schnittstellen!

Du brauchst also vor allem Schnittstellen. Und am sinnvollsten sind welche, die nicht nur das erledigen, was du JETZT für die Module brauchst, die du planst, sondern was auch für andere Module, die du noch nicht planst, sinnvoll sein kann.

Das heißt es muß bei der "nachinstallation" z.B. in die Navigationsleise ein zusätzlicher Einrag erfolgen, oder es muss noch ein Extra Menü für die Konfigurierung des Moduls eingefügrt werden.

Plane voraus: Alle Dinge müssen sich dynamisch erledigen lassen. Menüs sind zum Beispiel nicht fest codiert, sondern werden durch deine Module definiert. Das bedeutet, dass beispielsweise jedes Modul eine Funktion besitzen könnte, die einen Menüeintrag zurückliefert, oder die Einträge werden einer entsprechenden Variablen hinzugefügt.

Merhsprachigkeit dagegenb müßte ja von vornherein vorgesehen werden, dazu habe ich auch schon einige Threads hier verfolgtm, weiß aber noch nicht so Recht welches jetzt der "goldene Weg" ist, dies zu implementieren. Mit dem Accept-Language Header des Browsers finde ich eher ungünstig, eher als Indiz für die Starteinstellung. Also muß ich alle Texte in Variabvlen speichenr und die wiederum in der Datenbank, und dann bei jedem Seitenaufruf erstmal alle Texte aus der Datenbank auslesen - auch nicht wirklich optimal. Oder wie könnte man das besser einarbeiten?

Mehrsprachige Seiten habe ich bislang so realisiert, dass es je Sprache ein Verzeichnis gibt (also /de/, /en/ und /fr/), in denen sich immer identische Dateien befinden. Will man von einer deutschen Seite auf die zugehörige englische Seite, dann könnte man im Pfad einfach das "de" durch "en" ersetzen und hätte so "umgeschaltet". Die einfache Variante ist natürlich, dass jede Sprache unabhängig von den anderen Sprachen ist, und die Links einfach zur Startseite führen.

Als Startseite im Hauptverzeichnis ist ein Skript aktiv, welches den Accept-Language-Header vom Browser auswertet und entsprechend auf eine der verfügbaren Sprachen weiterleitet. Auf diese Weise wird eine sinnvolle Vorauswahl getroffen, die der Benutzer jederzeit ändern kann - vorzugsweise wird er dies wohl gleich zu Beginn tun.

Was die Textausgabe angeht: Variablen, Variablen, Variablen. In allen Skripten ist die Angabe von festen Strings tabu - weil die logischerweise sonst dort übersetzt werden müßten. Alles, was irgendwie ausgegeben wird, muß flexibel bleiben: Menüpunkte, Tabellenbezeichnungen, Fehlermeldungen, Systemmeldungen... Alle diese Meldungen werden zentral definiert. Wenn du Mehrsprachigkeit hast, hast du noch die zusätzliche Schwierigkeit, dass du einerseits das Modul "Mehrsprachigkeit" unterbringen mußt, und zusätzlich müssen deine anderen Module natürlich ihre Textausgaben auch nur optional, dann aber eventuell mehrsprachig mitbringen. Das könnte knifflig werden.

Noch so eine Sache ist wie man bei einee WEB-Anwendung eine Update-Funktion implementiert. D.h. wenn die Anwendung stetig weiterentwickelt wird, das dann sehr problemlos auf eine neue Version upgedatet werden kann, so dass alle Einstellungen und Daten bestehen bleiben... problematisch ist auch das Updaten über mehrere Versionen hinweg.

Sowas funktioniert prima, wenn nur der Code ausgetauscht werden muß, aber nicht die Daten. Dann hält man den Server einfach für einen Moment an, kopiert die neuen Programmdateien aufs System, und fährt den Server wieder hoch.

Wenn sich auch Datenformate geändert haben, muss man eben eine Konvertierungsroutine mit einbauen, die vor dem Wiederhochfahren die notwendigen Dinge ändert. Allerdings: Daten werden üblicherweise in Datenbanken gespeichert, und es ist durchaus möglich, das Programm so zu gestalten, dass es sich dynamisch an das derzeit verwendete Datenformat anpaßt und gewisse Dinge dann eben nicht zur Verfügung stellt - bzw. erst nach und nach einpaßt.

Ein Beispiel: Wenn du eine Telefonliste programmierst, und in Version 1 Datenfelder für Name und Telefonnummer anlegst, in Version 2 dann aber noch Geburtsdatum hinzufügst, ist das für die Daten nicht so schlimm. Du fügst beim Update das neue Datenbankfeld hinzu, die bestehenden Einträge bleiben bestehen, haben aber logischerweise kein Geburtsdatum. Du könntest das Erkennen der Datenversion erleichtern, wenn du in der Datenbank grundsätzlich ein Feld "Datenformatversion" mitführst. Allerdings glaube ich, dass es mehr Sinn macht, beim Update die vorhandenen Daten komplett zu konvertieren - oder diese Notwendigkeit einfach nicht hineinzuprogrammieren. :)

Naja, leider habe ich mit solchen Dingen so gut wie gar keine Erfahrung. Hat da vielleicht jemand Tipps für mich, oder kennt jemand Projekte wo das ganze gut gelöst wurde?

Das Problem dürfte wohl die gedankliche Fassbarkeit der Dynamik sein. Die eierlegende Wollmilchsau wirst du nicht programmieren, aber gewisse Dinge sind fürs Funktionieren unbedingt erforderlich - alles weglassen geht also auch nicht. Aber irgendwie ist ja nichts greifbar fest, wenn alles dynamisch ist. Das kriegt man wahrscheinlich am besten hin, indem man erstmal irgendwas Festes programmiert, was dann dynamisiert wird. Mit Sicherheit dauert das ein Weilchen, bis es fertig ist.

- Sven Rautenberg

--
Diese Signatur gilt nur am Freitag.