Ende März wurde das zweite Service-Release für die 1.4-Reihe von Zikula veröffentlicht. Neben diversen Bugfixes wurden einige Systemmodule auf Twig und Symfony Forms umgestellt, wie etwa die Theme-, die Modul- und die Blockverwaltung. Alle Änderungen im Detail können im Changelog unter https://github.com/zikula/core/blob/1.4/CHANGELOG-1.4.md nachgelesen werden.
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 Zikula Core wurde gestern in der Version 1.4.1 veröffentlicht. Neben einigen Korrekturen wurden alle Systemmodule auf PSR-4 umgestellt. Außerdem wurden die Modul- und Theme-Spezifikationen für 2.0.0 finalisiert.
Nachdem in Zikula 1.4.0 viele Änderungen am “Unterbau” des Frameworks vorgenommen wurden, von denen nur einige an der Oberfläche sichtbar sind (wie etwa die Nutzung der Symfony Routing Komponente oder der Einsatz von Font Awesome), kommen nun langsam auch andere Dinge an die Reihe, von denen das Zikula-Ökosystem mindestens ebenso stark profitieren kann.
In der Zikula Core-Version 1.4.1 wird das “Forward Compatibility Layer” für die Technologie in Zikula 2.0.0 festgeschnürt. Dies bedeutet, dass bisherige Module weiter funktionieren, aber auch Module für Zikula 2 bereits verwendet werden können.
In diesem Beitrag wird einmal grundlegend erklärt, wobei es sich um Zikula, Symfony und Doctrine handelt und wie diese Dinge zusammenspielen. Falls jemand diese Technologien nicht kennt, hilft dies vielleicht insbesondere beim Einstieg, sich unter der Masse von Begriffen zu orientieren.
Zikula Zikula ist ein Application Framework und dient somit als „Rahmen“ für beliebige Webanwendungen. Die wichtigste allgemeine Anlaufstelle für Zikula ist https://ziku.la/.
Seinen Ursprung hat Zikula in dem Vorgängerprojekt „PostNuke“, welches in den 90er Jahren sehr populär war und weltweit häufig verwendet wurde.
Der Zikula Core ist in zwei neuen Versionen veröffentlicht worden. Während Zikula 1.3.10 kleinere Dinge korrigiert und hinzufügt, wartet 1.4.0 mit einigen neuen Funktionen auf.
Das Zikula-Team hat den dritten Release-Kandidat für den Zikula Core 1.4.0 veröffentlicht. Sofern keine gravierenden Probleme mehr auftreten, wird dieser RC nach Feedback der Community vermutlich zum finalen Release erklärt. Gleichzeitig wurde auch der RC1 von Zikula 1.3.10 freigegeben.
Die Version 1.4 bringt einige neue Technologien und Werkzeuge mit sich. Im Frontend-Bereich werden beispielsweise nun jQuery und Bootstrap per Standard verwendet, Prototype nur noch aus Gründen der Abwärtskompatibilität mitgeführt. Aber auch unter der Haube hat sich sehr viel getan, da 1.
In ModuleStudio 0.6.2 liegt der Fokus auf die Anpassung des Generators auf Symfony und Bootstrap, was die Zielversion Zikula 1.4.0 anbelangt.
Einige Neuerungen betreffen das Zusammenspiel mehrerer Module, die miteinander interagieren. Erstens werden nun Factory-Klassen für Entitäten und Repositories in Verbindung mit Service-Parametern eingesetzt, mit denen man die Entität eines Moduls X von einem Modul Y heraus erweitern und anpassen kann. Zweitens werden in den Doctrine Lifecycle-Events der Entitäten eigene Symfony-Events verwendet, mit denen sich ein anderes Modul einhaken kann.
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.
In ModuleStudio-basierten Modulen werden je nach Einstellung und Eigenschaften des zu Grunde liegenden Modells unterschiedliche Ausgabeformate unterstützt. Dieser Artikel gibt Hinweise zur Verwendung und einen Ausblick auf kommende Veränderungen im Rahmen der Umstellung auf Symfony und Twig.
Ablauf im Hintergrund Um verschiedene Formate in einer Anwendung zu behandeln, sind mehrere Schritte nötig. Zunächst einmal ist festzuhalten, dass beim Einsatz von ShortURLs das sogenannte Routing dafür zuständig ist, die Parameter aus einer gegebenen URL auszulesen.
