ModuleStudio 0.7.5 und 1.0.0 veröffentlicht

in  Generator , , ,

ModuleStudio 0.7.5 und 1.0.0 veröffentlicht
Die Woche hat mit einem doppelten Paukenschlag begonnen! Was bereits angekündigt worden war, ist nun tatsächlich eingetreten: heute Morgen wurde zunächst ModuleStudio 0.7.5 veröffentlicht, mit Support für Zikula 1.4.x, 1.5 und 2.0. Anschließend kam direkt ModuleStudio 1.0.0 hinterher; das ist quasi identisch mit 0.7.5, allerdings ohne die Unterstützung für Zikula 1.4. Im Laufe der Woche erscheinen auch Zikula 1.5.0 und 2.0.0 final - dann ist der Weg frei für begleitende Marketing-Maßnahmen, um das Tandem “Zikula + MOST” zu pushen.

ModuleStudio 0.7.4 macht Fortschritte

in  Generator , , , , ,

ModuleStudio 0.7.4 macht Fortschritte
Seit der Veröffentlichung von ModuleStudio 0.7.3 im Februar 2017 sind die Arbeiten an DSL und Generator kontinuierlich fortgeführt worden. Es wurden einige neue Optionen zur Modellierungssprache hinzugefügt und diverse Anpassungen im Hinblick auf eine optimale Kompatibilität der generierten Anwendungen mit Zikula 1.5 und 2.0 vorgenommen. Es ist vorgesehen, dass ModuleStudio 0.7.4 noch im Mai erscheinen wird. Dieser Beitrag stellt einige der zahlreichen Neuerungen vor. Die Repository-Klassen wurden aufgeräumt und von allen Dingen bereinigt, die nichts direkt mit der Erzeugung von Queries zu tun haben.

Symfony Forms in Zikula und ModuleStudio

in  Generator , , ,

Symfony Forms in Zikula und ModuleStudio
Im Januar wurde der Generator auf Symfony Forms umgestellt. Mir war schon vorher klar, dass diese Komponente eine der mächtigsten Teile von Symfony darstellt. Wie nützlich sie aber in der Praxis ist, sieht man natürlich erst, wenn man sie tatsächlich nutzt. Auch der Zikula Core reimplementiert zunehmend Formulare mit Symfony Forms. Kürzlich wurde das Blocksystem komplett darauf umgestellt. In diesem Zuge wurden ein Block Handler Interface sowie ein dazu passender Abstract Block Handler eingeführt, mit denen Blöcke nun einfacher aufgebaut werden und einen Form Type zur Bearbeitung verwenden können.

Der Generator spricht Twig

in  Generator , , , , ,

Der Generator spricht Twig
Zwischen den Jahren konnte ich etwas Zeit erübrigen und in den ModuleStudio Generator investieren, um eine größere Umstellung durchzuführen: bei Anwendungen für Zikula 1.4.x wird nun Twig an Stelle von Smarty verwendet. Anwendungen für 1.3.x verwenden weiter Smarty wie bisher. Im Wesentlichen lief die Umstellung ziemlich geradlinig, da die meisten Konzepte aus Smarty analog auch mit Twig implementiert werden können. Eine Besonderheit betrifft die Behandlung von Assets, also CSS-, JS- und Bilddateien: statt direkt die Asset-Komponente von Symfony zu verwenden, wird in Zikula eine darauf aufbauende zasset-Funktion eingesetzt, welche einige Besonderheiten des Zikula-Frameworks beachtet.

Vorschau auf das Tooling für ModuleStudio 0.7.0

in  Generator

Vorschau auf das Tooling für ModuleStudio 0.7.0
Anfang August habe ich über die Ausrichtung von ModuleStudio 0.7.0 berichtet. In der Zwischenzeit haben wir einige Kernpunkte bereits umgesetzt. Dieser Beitrag soll einen kurzen Eindruck geben als Vorgeschmack auf die nächste Hauptversion. Alle grundsätzlichen DSL-Änderungen haben wir bereits vorgenommen und dabei eine ganze Reihe unnötiger Sprachelemente entfernt. In diesem Zuge wurden auch ein paar kleinere Funktionen hinzugefügt: so kann man nun bei Feldern direkt die Sichtbarkeit und die CSS-Klassen des jeweiligen Formularelemnetes im Modell beeinflussen.

Validierung im ModuleStudio-Generator auf Symfony umgestellt

in  Generator , , ,

Validierung im ModuleStudio-Generator auf Symfony umgestellt
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.