Get the MOST

Nach dem Release von MOST 0.7.0 vor knapp drei Wochen steht nun das erste Service-Update bereit, welches sowohl Korrekturen als auch neue Funktionen bietet. Weitere Infos sowie den Download gibt es wie immer auf der Homepage des Projektes.

Nach fast zweieinhalb Jahren ist ModuleStudio 0.7.0 erschienen. Dies ist ein wichtiger Meilenstein für das Projekt und macht den Weg frei für weitere Schritte. Dieser Beitrag stellt die neue Version kurz vor und zeigt auf, wohin die Reise geht.

Neuigkeiten

ModuleStudio 0.7.0 bietet eine große Zahl an Neuerungen, unter anderem eine runderneuerte Benutzeroberfläche, Verbesserungen an der DSL sowie viele Änderungen im Generator. Die wichtigsten Infos können auf der Release-Seite nachgelesen werden.

Beim diesjährigen Camp Zikula haben wir unter anderem über die zukünftige Ausrichtung von ModuleStudio gesprochen. Dazu habe ich kurz die Bestandteile einer DSL sowie unterschiedliche Notationsformen und deren Kombinationen vorgestellt. Während wir über die Vor- und Nachteile einzelner Varianten und Editoren diskutiert haben, ist relativ schnell klar geworden, dass wir zunächst einmal den Umfang und Fokus der DSL korrigieren müssen. Die verschiedenen Gedanken und Impulse bilden eine Blaupause für die nächste Hauptversion von ModuleStudio. Aus diesem Grund wurde eben die Version 0.6.2 veröffentlicht, so dass nun der Weg frei steht für die ersten Arbeiten an 0.7.

In der modellgetriebenen Softwareentwicklung werden die fachlichen Anforderungen in der Regel sehr prägnant formuliert. Schließlich ist eines der Ziele einer domänenspezifischen Sprache eine lesbare und verständliche Beschreibung eines Softwaresystems, wozu auch die Vermeidung von Redundanzen und unnötigem Boilerplate-Code gehört.

Dies führt dazu, dass selbst kleine Veränderungen in einem Modell größere Unterschiede im generierten Quelltext zur Folge haben können. Ein Beispiel für solche, auf den ersten Blick unscheinbare Differenzierungen betrifft die Schreibweise von Modellelementen. Dieser Beitrag zeigt auf, was es bedeutet, ob der Name einer Entität oder eines Feldes so oder so geschrieben wird.

Im Controller-Bereich der Modellierungssprache von ModuleStudio nimmt der Ajax-Controller eine besondere Rolle ein. Die Aktionen eines Ajax-Controllers werden im Gegensatz zu anderen Controllern nicht als Webseite durch den Anwender, sondern von mittels JavaScript initiierten Ajax-Requests aufgerufen.

Der Generator erzeugt unter Umständen einige zusätzliche Methoden im Ajax Controller, wenn diese für bestimmte generierte Funktionalitäten erforderlich sind. Dies betrifft unter anderem die im Folgenden aufgelisteten Methoden:

getCommonUsersList

Diese Methode sucht eine Liste von Benutzernamen, die zu einem gegebenen Suchausdruck passen, und liefert diese aufbereitet für AutoCompletion zurück. Wird nur generiert, falls in der Anwendung mindestens eine Entität mit einem Benutzerfeld existiert. Zusätzlich wird je Benutzerfeld eine weitere Methode generiert, zum Beispiel getArticleCreatorUsers, damit sich die Funktion einfach für bestimmte Felder überschreiben oder anpassen lässt.

getItemListFinder

Wird nur generiert, wenn auch der External-Controller und die Finder-Komponente generiert werden, was durch eine Generator-Einstellung gesteuert werden kann. Zweck der Methode ist es, eine Liste von Entitäten für den Finder aufzubereiten und zurückzuliefern. Mit der Finder-Komponente können Entitäten gefunden und ausgewählt werden, zum Beispiel bei der Verwendung der generierten Scribite-Plugins.

getItemListAutoCompletion

Sucht nach Entitäten, die zu einem gegebenen Suchausdruck passen, und liefert diese aufbereitet für AutoCompletion zurück. Wird nur generiert, wenn es mindestens eine Join-Relation im Modell gibt. Verwendet wird diese Methode von den AutoComplete-Feldern in den Änderungsformularen.

checkForDuplicate

Prüft, ob ein bestimmter Feldwert ein Duplikat ist oder nicht. Wird nur generiert, wenn unique-Felder oder unique Slugs im Anwendungsmodell verwendet werden.

toggleFlag

Diese Methode schaltet ein bestimmtes Flag einer gegebenen Entität um. Generiert wird sie nur, falls es Boolean-Felder mit aktiviertem Ajax-Toggle gibt. Auf Übersichts- und Detailseiten kann man dann per Mausklick die Werte einfach umschalten.

handleTreeOperations

Wird nur generiert, das Anwendungsmodell mindestens eine Entität mit aktivierter Baumstruktur enthält. Die Verwaltungsseite für Hierarchien benutzt diese Methoden für unterschiedliche Aktionen, die mit der Baumstruktur durchgeführt werden können: neuen Wurzelknoten anlegen, neuen Unterknoten anlegen, Knoten löschen, Knoten verschieben, Knoten verschieben nach X.

Bislang wurden in generierten Modulen selbstgeschriebene Validierungen verwendet. In den letzten Tagen wurden diese für die Zielversion Zikula 1.4.x abgelöst zu Gunsten der Symfony Validator Komponente.

In Symfony können Validierungen in mehreren Notationen definiert werden. Neben PHP und YAML sind auch XML und Annotationen möglich. Im ModuleStudio-Generator haben wir, wie auch im Ticket auf GitHub diskutiert wurde, Annotationen verwendet. Dabei werden Validierungsregeln (“Constraints”) durch @Assert-Annotationen direkt an der entsprechenden Entitätsklasse beziehungsweise den entsprechenden Feldern oder Methoden hinterlegt.

Wie im letzten Artikel bereits erwähnt, verfügt ModuleStudio seit Version 0.6.1 über eine Reihe von Generator-Einstellungen, mit denen sich unterschiedliche Features und Verhaltensaspekte beeinflussen lassen. Dieser Beitrag gibt einige Anregungen zu möglichen Anwendungsfällen dieser Optionen.

Zikula Core Version

Bereits von früheren Versionen bekannt ist eine Einstellung für die Version des Zikula Core, für die eine Anwendung generiert werden sollte. Dies ist also nicht neu.

Wenn mehrere Zikula-Module zusammen arbeiten, wird dies in der Regel durch Modulabhängigkeiten ausgedrückt. Damit lässt sich festlegen, dass ein Modul A ein anderes Modul B entweder zwingenderweise voraussetzt oder optional empfiehlt. In größeren Systemen, die aus mehreren Modulen bestehen, reicht dies ab einem gewissen Punkt nicht mehr aus.

Austauschbarkeit von Modulen gewährleisten

Früher gab es in der Modultabelle von Zikula Flags für bestimmte Funktionen, zum Beispiel isProfile für Profilmodule und isMessaging für Module, die private Nachrichten verwalten können. In größeren Gesamtsystemen kommt es oft vor, dass man die Möglichkeit benötigt, so etwas allgemein für eigene Zwecke zu definieren.