Architekturzentrierte, modellgetriebene Softwareentwicklung für das Zikula Application Framework

PHP braucht keinen Code
Kommentare

Zikula Facts
Das Zikula Application Framework ist aus dem Content Management System PostNuke entstanden. Im Laufe der letzten Jahre wurde die komplette Architektur neu geschrieben und dabei mehreren Refaktorisierungen

Zikula Facts

Das Zikula Application Framework ist aus dem Content Management System PostNuke entstanden. Im Laufe der letzten Jahre wurde die komplette Architektur neu geschrieben und dabei mehreren Refaktorisierungen unterzogen. Dabei ist das ehemalige Portalsystem sukzessive zu einem flexiblen Framework gewachsen, dieser Entwicklung trägt der neue Name Rechnung. Der Zikula-Kern benötigt mindestens PHP 4.1 oder PHP 5 und eine Datenbank, wobei primär MySQL sowie darüber hinaus PostgreSQL, MS SQL und Oracle unterstützt werden. Die empfohlene Konfiguration ist PHP 5 mit MySQL 5.

Mithilfe eines ConnectionStacks können auch mehrere Datenquellen angebunden werden, so kann ein Modul zusätzliche, externe Daten beziehen. Eine einheitliche Persistenzschicht ersetzt das Schreiben von SQL-Anweisungen durch simple Methodenaufrufe, um die Portabilität weiter zu steigern. Zusätzliche Dienste wie etwa dynamische Attribute zur Speicherung erweiterter Objektinformationen ohne Änderung des Datenschemas oder integrierte Metadaten sorgen für eine komfortable Anwendung der Persistenzobjekte. Wesentlich für die Modellierbarkeit von Erweiterungen sind drei Technologien des Frameworks:

  • Erstens erlaubt ein Override-Mechanismus globales und Layout-spezifisches Überschreiben von Templates, Stylesheets, Funktionen und anderen Bestandteilen. Auf diese Weise können generierte Artefakte angepasst werden, ohne Gefahr zu laufen, diese Änderungen bei einer Aktualisierung versehentlich zu verlieren. Dank der Smarty-basierten Templating Engine können projektspezifische Erweiterungen auf Template-Ebene einfach über einen Plug-in-Mechanismus integriert werden.
  • Ein Event-gesteuertes Formular-Framework übernimmt die komplette Behandlung von Formularen, angefangen bei der Zustandsverwaltung bis hin zur Validierung. Die Ereignisbehandlung wird in Handler-Klassen implementiert, was die Abhängigkeiten des Controllers zu anderen Schichten minimiert.
  • Die dritte Komponente ist ein objektorientiertes Komponentenmodell, das durch die Kapselung der objekt-spezifischen Logik eine Trennung zwischen Systemanwendungsfällen und Geschäftsanwendungsfällen ermöglicht. Zusammengefasst bedeutet dies, dass beispielsweise eine Funktion view() oder delete() sowohl auf Kunden als auch auf Aufträge, Adressen oder Rezeptzutaten angewendet werden kann.

    Zikula bietet noch viele weitere Werkzeuge, wie zum Beispiel wiederverwendbare modulunabhängige Komponenten (Hooks) oder einen Workflow-Mechanismus. Die Object Library, das Herz des Systems, besteht aus einem Kompositum verschiedener Klassen, die dem Entwickler einfache Methoden zur Hand geben.

Frisch ans Werk

Im Folgenden wird anhand eines typischen Beispiels gezeigt, wie sich mit ModuleStudio ein kleines Modul für Zikula realisieren lässt. Das Modul AutoCustomer dient der Verwaltung von Kunden und deren Aufträgen, es kann ebenso wie andere Beispiele hier angeschaut und heruntergeladen werden. ModuleStudio speichert jedes Modell in zwei Dateien. Die semantischen Informationen werden im Domänenmodell mit der Endung *.msmodule gespeichert, die rein optischen Details der Diagramme in *.msmain. Nachdem die Applikation gestartet wurde, kann über den Menüpunkt File > New > Module Diagram ein Assistent gestartet werden, der nach Angabe von Dateinamen für Diagramm- und Domänenmodell entsprechende Dateien anlegt. Anschließend befindet sich der Benutzer im leeren Haupteditor (vgl. Abbildung 3).

Abb. 3: Aufbau der Applikation

Neben Hauptmenü und Toolbars ist die Umgebung in zwei Bereiche separierbar. Die Anordnung der Fenster kann beliebig verändert werden. Auf der linken Seite befindet sich das Editorfenster, das eine Zeichenfläche und eine Palette mit den verfügbaren Werkzeugen beinhaltet. Dort findet die eigentliche Modellierung statt. Die Palette des Haupteditors teilt Knoten und Kanten in die zwei Gruppen Container und Links auf. Die vier Containerarten repräsentieren die verschiedenen technischen Subdomänen des Modells wie oben beschrieben. Von jedem Containertyp können mehrere Elemente gleichzeitig in einem Modell existieren. Dies kann hilfreich sein, um die einzelnen Schichten nach fachlichen Kriterien aufzuteilen. Relevant ist dies aktuell jedoch nur bei der Datenschicht, um eine Anbindung externer Datenquellen zu realisieren.

Auf der rechten Seite befinden sich ein Vorschaufenster mit einer Miniaturansicht des Editorfensters und ein Eigenschaftenfenster zum Bearbeiten von verschiedenen Einstellungen. Bei diesen ist der Reiter Domain Model wichtig, in dessen Sektion View > Element die Attribute von Modellelementen bearbeitet werden können. Die Zeichenfläche selbst entspricht dem zu generierenden Modul, daher wird sie einmal angeklickt und anschließend können einige zentrale Einstellungen gesetzt werden. Das betrifft unter anderem den Namen des Moduls sowie des Autors oder die Option, ob das Modul über einen interaktiven Installationsprozess verfügen soll (vgl. Abbildung 4).

Abb. 4: Fenster mit Eigenschaften
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -