Get the MOST

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:

Das diesjährige Camp Zikula wird Mitte Juli stattfinden. Mittlerweile liegen die wesentlichen Programmpunkte vor. In diesem Beitrag werden kurz die Beiträge genannt, die voraussichtlich von meiner Seite vorgestellt werden.

Keynote / Core

Wie in jedem Jahr wird über die wichtigsten Neuerungen rund um den Zikula Core berichtet. Dies betrifft dieses mal die Versionen 1.4 und 2.0; die Keynote wird von mir zusammen mit Craig Heydenburg vorgetragen.

Multisites v2

Ein Einblick in die zahlreichen neuen Möglichkeiten, die sich mit der Version 2 des Multisites-Moduls bieten.

ModuleStudio 0.7.0: less is more

Was hat sich seit den wertvollen Anregungen vom letzten Camp bei ModuleStudio getan? Ein Statusbericht mit Demo und Ausblick auf die nächsten Schritte.

Showcases

Natürlich zeigen wir wieder einige spannende Projekte, die wir mit Zikula realisiert haben.

Im Dezember haben wir über eine Erweiterung des MUSeo-Moduls im Hinblick auf vielfältigere SEO-Konfigurierbarkeit berichtet. Mittlerweile liegt nun, dank intensiver Unterstützung durch Gabriel Freinbichler, eine Vorabversion von MUSeo 2.0.0 vor, welche wir erfolgreich bei einem Kunden integriert haben.

Wie bereits im ersten Artikel beschrieben, basiert diese Erweiterung im Wesentlichen auf einem SEO-Plugin für WordPress. Wir haben allerdings einige Funktionen weggelassen oder verändert, um die Funktionalität besser an Zikula anzupassen, da dort unterschiedliche Aspekte dynamischer gelöst oder bereits im Core gehandhabt werden.

Das Modul MUSeo von Michael Ueberschaer ist eine ModuleStudio-basierte Lösung zum Erfassen von suchmaschinenrelevanten Metatags für beliebige Einzelseiten einer Zikula-Präsenz. Aktuell laufen die ersten Schritte für die Version 2.0.0 mit erweitertem Funktionsumfang.

Neben einigen neuen Feldern und Angaben, z. B. für Social Media Funktionen, soll die kommende Hauptversion im Wesentlichen zwei neue Funktionen mitbringen:

Erstens soll es möglich sein, direkt eine Vorschau der voraussichtlichen Darstellung des Eintrags der Seite in Google-Ergebnislisten einzusehen. So kann man bereits während der Erfassung sehen, inwieweit die gewählten Kurzbeschreibungstexte und Keywords die gewünschte inhaltliche Optimierung abbilden. Als Vorlage dient hierzu ein SEO-Plugin für WordPress.

Im letzten Beitrag wurde die Weiterentwicklung des Multisites-Moduls beschrieben. Mittlerweile ist die neue Version im GitHub-Projekt verfügbar. Wer Multisites aktuell im Einsatz hat oder grundsätzlich an dem Modul interessiert ist, ist hiermit herzlich eingeladen, das neue Modul zu testen. Empfohlen wird dazu die Zikula-Version 1.3.9. Anmerkungen, Fehlermeldungen usw. bitte im Issue Tracker auf GitHub eintragen, vielen Dank für Euer Feedback!

Mit dem Multisites-Modul lassen sich beliebig viele Seiten mit einem einzigen Zikula-System betreiben. Mit Vorlagen, die im Prinzip SQL-Dumps repräsentieren, können neue Seiten auf Knopfdruck erstellt werden. Jede Seitenvorlage beinhaltet damit die vorab definierten Strukturen und -daten out of the box.

Jede Internetseite verfügt (aus Gründen der Architektur und der Skalierbarkeit) über eine eigene Datenbank. Es ist auch möglich, dass mehrere Internetseiten mit der gleichen Datenbank arbeiten. Dies erfordert jedoch entsprechende Anpassungen in den verwendeten Themes.

Beim diesjährigen Camp Zikula haben wir unter anderem über die zukünftige Ausrichtung von ModuleStudio gesprochen. Dazu habe ich kurz die Bestandteile einer DSL sowie unterschiedliche Notationsformen und deren Kombinationen vorgestellt. Während wir über die Vor- und Nachteile einzelner Varianten und Editoren diskutiert haben, ist relativ schnell klar geworden, dass wir zunächst einmal den Umfang und Fokus der DSL korrigieren müssen. Die verschiedenen Gedanken und Impulse bilden eine Blaupause für die nächste Hauptversion von ModuleStudio. Aus diesem Grund wurde eben die Version 0.6.2 veröffentlicht, so dass nun der Weg frei steht für die ersten Arbeiten an 0.7.

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.

In der modellgetriebenen Softwareentwicklung werden die fachlichen Anforderungen in der Regel sehr prägnant formuliert. Schließlich ist eines der Ziele einer domänenspezifischen Sprache eine lesbare und verständliche Beschreibung eines Softwaresystems, wozu auch die Vermeidung von Redundanzen und unnötigem Boilerplate-Code gehört.

Dies führt dazu, dass selbst kleine Veränderungen in einem Modell größere Unterschiede im generierten Quelltext zur Folge haben können. Ein Beispiel für solche, auf den ersten Blick unscheinbare Differenzierungen betrifft die Schreibweise von Modellelementen. Dieser Beitrag zeigt auf, was es bedeutet, ob der Name einer Entität oder eines Feldes so oder so geschrieben wird.