Schwerpunkte für ModuleStudio 0.7.0

in  Metamodell  , , ,

Schwerpunkte für ModuleStudio 0.7.0

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.

Zum Beispiel macht es bei einer DSL für Zikula-Anwendungen nicht viel Sinn, ein View Layer zu definieren. Das Modellieren einzelner Views ist hingegen eher hinderlich, da das Abstraktionsniveau dabei zu niedrig ist, um einen Mehrwert an Effizienz und Produktivität geltend machen zu können. Ein Template per Overriding in Zikula anpassen geht viel schneller und präziser.

Auch der Controller-Editor hat zu viele Details an Bord, die im Zikula-Umfeld ohnehin per Konvention geregelt sind. Somit können einige Elemente entfallen und durch reine Standardimplementierungen im Generator ersetzt werden - bei Bedarf lassen sich Anpassungen ja ohnehin einfach als Override einbinden.

Seit ein paar Wochen erzeugt der Generator eine Controller-Klasse je Entity. Die historischen User- und Admin-Controller sind ebenfalls noch vorhanden, dienen aber lediglich als Umleitung und können als veraltet betrachtet werden. Abstrahiert betrachtet bedeutet dies, dass man eine Entität auch als eine Spezialisierung eines Controllers auffassen kann. Dies bildet die Grundlage für einen weiteren Schritt zur Reduktion der DSL: die verbleibenden Elemente aus der Controller-Schicht werden mit den Elementen der Datenschicht verschmolzen. Natürlich wird es auch weiterhin eigene (Entity-unabhängige) Controller geben.

Die Datenstrukturen eines Modells finden sich in allen Ebenen der generierten Anwendung wieder. Ohne Editoren für Controller und View wird der Dateneditor passenderweise automatisch zum neuen Haupteditor. Dies führt dazu, dass statt vier Editoren nur noch ein einziger zu entwickeln und zu warten ist, was Raum für andere Erweiterungen öffnet. So können wir uns beispielsweise eher auch darauf konzentrieren, diesen Editor zu verschönern und die Nutzbarkeit zu verbessern. Falls es einmal einen Workflow-Editor geben wird (der dann z. B. durch Doppelklick auf eine Entität geöffnet werden könnte), so werden wir dazu einen bestehenden Editor auf Basis einer Standardnotation wie BPMN2 verwenden, um die Aufwände für einen eigenen Editor einzusparen.

Es sind noch einige weitere Punkte vorgesehen, zum Beispiel die Integration eines textuellen Editors, der kontextbasiert für eine Entität aufgerufen werden kann, um deren innere Struktur zu beschreiben. Dieser Beitrag zeigt aber die wichtigen und entscheidenden Punkte auf, die ModuleStudio 0.7.0 prägen werden. Schön finde ich, dass hiermit eine Perspektive aufgezeigt wird, die nicht nur Komplexität reduziert, sondern auch die Kernanliegen von ModuleStudio weiter heraushebt und die Effizienz der Modellierung sicherstellt.

Weitere Beiträge in Kategorie Metamodell

Vereinfachung der DSL in Bezug auf Variablen
- Gegenwärtig arbeiten wir an der Konzeption einer Änderung in der Modellierungssprache von ModuleStudio, die uns schon seit Längerem umtreibt. Noch aus der Anfangsphase des Projektes gibt es neben den …