Get the MOST

ModuleStudio 0.7 beinhaltet nun eine automatische Aktualisierung. Damit wird das Herunterladen neuer Versionen unnötig. Beim jeden Start der Anwendung werden verfügbare Updates gesucht und, sofern vorhanden, automatisch heruntergeladen und installiert.

Es gibt zwei Kanäle: stable und staging. Nach jeder erfolgreichen Erstellung eines Produktes durch den CI-Server werden die Dateien in das Staging-Repository kopiert. Release-Builds werden zusätzlich in das Stable-Repository kopiert.

In den Einstellungen von ModuleStudio lässt sich konfigurieren, ob lediglich stable Updates (Standard) oder auch staging Updates gewünscht sind. Falls die staging-Option aktiviert wird (was empfehlenswert ist, wenn man die neuesten Bugfixes und Neuerungen haben möchte), erhält man jedes mal ein Update, nachdem der CI-Server ein neues Produkt gebaut hat (was relativ häufig passiert, zum Beispiel nach einem Generator-Fix).

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.

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. Außerdem werden CSS- und JS-Dateien auf Grund der Modularität von Zikula-Systemen nicht einfach in einem Twig-Block eingebunden, sondern nach wie vor über PageVars zentral registriert. Beides zusammen sieht dann in etwa so aus:

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. Insbesondere ist damit die Nutzung der Twig Templating Engine und von Symfony Forms möglich, worauf viele Modulentwickler schon seit einiger Zeit gewartet haben.

Dieser Beitrag gibt einen Überblick über aus heutiger Sicht essenzielle Bibliotheken, mit denen das Frontend moderner Websites typischerweise realisiert werden. Diese sind weitgehend in Zikula enthalten, brauchen also nicht mehr dazu installiert zu werden.

Prototype & Script.aculo.us

Prototype ist eine JS-Bibliothek, die sich zum Ziel gesetzt hat, die JavaScript-Entwicklung zu vereinfachen. Script.aculo.us baut auf Prototype auf und bietet zusätzliche Effekte, Funktionen und Animationen. Aus Gründen der Abwärtskompatibilität sind beide Bibliotheken noch in Zikula 1.3.x enthalten, aus heutiger Sicht sind sie allerdings als obsolet zu betrachten. Ab Zikula 1.4.0 sind sie daher nicht mehr im System ver­fügbar, statt dessen wird nun primär auf jQuery gesetzt.

In Zikula wird eine „Templating-Engine“ verwendet, um Inhalt und Form voneinander getrennt zu halten. Dies bedeutet, dass der programmierte Quelltext, der eine bestimmte Funktion bereitstellt, woanders liegt als das Aussehen der entsprechenden Seite.

Dies ermöglicht es, dass sich Backend-Entwickler um die Implementierung kümmern, während Frontend-Entwickler die Oberfläche aufbauen und anpassen. Zum Frontend zählen im Wesentlichen das Markup (HTML), Client-seitige Skripte (JavaScript) sowie Stile (CSS).

Um eine Zikula-Seite zu gestalten oder zu verändern, muss kein Programmiercode angefasst werden. Jegliches Customising lässt sich in Templates durchführen. Ein Modul stellt Templates für jede Funktion bereit, die es zur Verfügung stellt. Ein Modul für Newsbeiträge verfügt beispielsweise über Templates für die Liste der Beiträge, die Detailansicht eines Beitrags, die Änderungsformulare, usw. Ferner stellt ein Modul allgemeine JavaScript- und CSS-Dateien bereit, die unabhängig von der Gestaltung einer konkreten Website für das Modul notwendig sind.

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. Im Jahre 2008 wurde das Projekt in Zikula umbenannt.

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.

Im Kern von Doctrine 2 wird Wert darauf gelegt, dass die Doctrine Query Language (DQL) möglichst portabel bleibt, damit Projekte einfach mit unterschiedlichen Datenquellen arbeiten können. Bei Webanwendungen kommt es immer wieder einmal vor, dass man eine bestimmte Funktion benötigt, die zwar in MySQL existiert, jedoch nicht von DQL unterstützt wird.

Man kann in solchen Fällen eigene DQL-Funktionen erstellen, dies ist aber in den meisten Fällen zum Glück nicht nötig. Denn in den DoctrineExtensions von Benjamin Eberlei befinden sich bereits eine ganze Reihe von MySQL-Funktionen. Dieses Paket ist idealerweise auch im Zikula Core enthalten, so dass man sie für die eigenen Module direkt nutzen kann.