Entwicklerblog für Zikula, Symfony, MDSD und mehr
Die Cascading Style Sheets zum Gestalten von Internetseiten und Webanwendungen gibt es schon eine ganze Ewigkeit. Elementare Dinge ändern sich hier vergleichsweise selten.
Mit der Umstellung von Bootstrap 3 auf Bootstrap 4 kommt man jedoch nicht umhin, sich mit dem Flexbox-Konzept auseinander zu setzen. Hier kommt man mit den alten Floats nicht mehr weit. Am Anfang ist das ein ungewohntes Umdenken. Aber sobald man Flex einmal verstanden hat, möchte man auch nicht mehr ohne.
Der folgende Tipp hilft dabei, den Code-Umfang häufiger Abfragen in Twig-Templates zu reduzieren. Dies verbessert die Lesbarkeit enorm und hilft dabei, die Logik in den Templates intuitiver zu formulieren. Diese Abkürzung kommt komplett ohne zusätzliche Funktionen und Filter aus.
Oft möchte man prüfen, ob eine Variable im Template existiert und einen gültigen Wert enthält. In dem Fall soll etwas mit der Variable getan werden, typischerweise erfolgt eine Ausgabe des Wertes. Ganz explizit formuliert sieht so eine Abfrage in etwa wie folgt aus:
Seit kurzem haben neue Funktionen in die Template-Engine Twig Einzug gehalten. Diese verändern die Art und Weise, wie mit mehrwertigen Daten umgegangen wird, fundamental. Aus diesem Grund soll dieser Artikel beleuchten, wie man mit den neuen Möglichkeiten umgehen kann.
Bei “filter, map und reduce” handelt es sich um ein Muster (Pattern) aus der funktionalen Programmierung. Es erlaubt die Veränderung von Sequenzen (Listen, Arrays, Vektoren, usw.) mittels mehrerer Operationen und Manipulationen, an deren Ende ein Ergebnis steht, welches entweder ausgegeben oder weiter verwendet werden kann. Der Vorteil liegt hier darin, dass diese Veränderungen deklarativ angegeben werden können. Dies führt zu einer sehr prägnanten und lesbaren Syntax.
Eine häufige Anforderung besteht darin, die Startseite eines Projektes individuell anzupassen. Zikula bietet zwar die Möglichkeit, eine Controller-Aktion sowie die zu übergebenden Argumente in der Grundkonfiguration einer Seite einzustellen, allerdings ist diese Funktionalität bislang doch eher eingeschränkt. Mit einigen Modulen, wie etwa Content, sind zwar unterschiedliche Inhalte je Sprache auf ein und derselben Seite möglich, aber auch das kann nicht alle Varianten abdecken. Also was für Möglichkeiten gibt es? 😕
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:
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.
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.
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.
Im Gegensatz zu älteren Versionen empfangen Controller-Aktionen ab Zikula 1.3.x keine Argumente mehr. Bei der Umstellung bestehender Module kann man darüber stolpern, zum Beispiel wenn Controller-Funktionen mit dem modfunc-Plugin in Smarty-Templates eingebettet wurden.
Früher wurde in Zikula nicht unterschieden zwischen Controller-Aktionen und API-Methoden. Beides konnte beliebig aufgerufen und integriert werden, sowohl in PHP als auch in Smarty-Templates. Seitdem Symfony unter der Haube die Behandlung von Requests steuert, erfolgt hier eine striktere Trennung: während API-Methoden immer noch mit Argumenten aufgerufen werden, werden bei Controller-Aufrufen ausschließlich die Request-Parameter injiziert. Dies folgt der Konvention, dass ein Controller immer eine Response für einen gegebenen Request zurückliefern sollte.
Bei vielen kleineren Modulen muss nichts oder nicht viel an der Logik verändert werden, welche die Bearbeitung von Datensätzen steuert. Häufig ist es aber wünschenswert, dass der Anwender nach dem Speichern seiner Änderungen zu einer bestimmten Stelle umgeleitet wird. In generierten ModuleStudio-Modulen gibt es dafür bereits eine nützliche Funktion.
Im Folgenden wird ein einfaches Modell als Beispiel verwendet: es gibt zwei Entitäten für Kunden und Adressen. Eine bidirektionale 1:n-Beziehung legt fest, dass jeder Kunde mehrere Adressen haben kann, wobei jede Adresse auch auf die Daten des zugeordneten Kunden zugreifen kann. Als Anwendungsfall erstellen beziehungsweise bearbeiten wir eine Adresse.