Get the MOST

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:

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 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. Der Controller muss das passende Template für die gewünschte Ausgabe auswählen. Je nach Ausgabeformat muss unter Umständen die Response angepasst werden: zum Beispiel ist oft ein spezieller Content-Type nötig, um RSS-Feeds oder JSON-Daten ordentlich auszuliefern.