Get the MOST

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.

Worum geht es?

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.

In Zikula 1.3.x sind jQuery und jQuery UI bereits enthalten. Allerdings verwenden viele Module noch Prototype, was dazu führt, dass beide Skripte parallel nebeneinander verwendet werden. Dieser Artikel zeigt auf, welche Konsequenzen dies für die Nutzung mit sich bringt und wie man jetzt schon ohne Probleme mit jQuery arbeiten kann.

Skripte via PageVar laden

Statt mit Pfaden und Dateinamen hantieren zu müssen, können oft benötigte Skripte in Zikula einfach mittels PageVars geladen werden. Um beispielsweise jQuery und jQuery UI in einem Rutsch einzubinden, genügt die folgende Zeile im Template:

Dieser Beitrag gibt eine kurze Einführung in die Verwendung von Modulvariablen. Diese können dazu verwendet werden, bestimmte Parameter in einem Modul einstellbar zu machen. Typische Beispiel hierfür sind etwa Grenzwerte oder API-Keys für Drittdienste.

Nutzung im Code

Die wichtigsten Grundfunktionen werden von Zikula durch die ModUtil-Klasse bereitgestellt.

1
2
3
4
5

ModUtil::hasVar($modname, $name)
ModUtil::getVar($modname, $name = '', $default = false)
ModUtil::setVar($modname, $name, $value = '')
ModUtil::setVars($modname, array $vars)
ModUtil::delVar($modname, $name = '')

Innerhalb von Klassen, die von Zikula_AbstractBase erben, zum Beispiel in Controller- und API-Klassen, gibt es außerdem Convenience-Methoden, die auf die oben genannten ModUtil-Methoden verweisen.

Bei mit ModuleStudio generierten Modulen werden unter anderem auch Plugins für unterschiedliche WYSIWYG-Editoren erzeugt, die im Modul Scribite integriert sind. Wie diese Plugins eingerichtet werden und was sie können, zeigt dieser Beitrag.

Das Zikula-Modul Scribite bringt eine Reihe von Editoren mit, die flexibel konfiguriert und in anderen Modulen verwendet werden können. So könnte man etwa Summernote als Standardeditor nutzen, in einem bestimmten Modul jedoch TinyMCE, während in einem anderen Modul oder einer bestimmten Modulfunktion QuillJS zum Einsatz kommt.

Wenn mehrere Zikula-Module zusammen arbeiten, wird dies in der Regel durch Modulabhängigkeiten ausgedrückt. Damit lässt sich festlegen, dass ein Modul A ein anderes Modul B entweder zwingenderweise voraussetzt oder optional empfiehlt. In größeren Systemen, die aus mehreren Modulen bestehen, reicht dies ab einem gewissen Punkt nicht mehr aus.

Austauschbarkeit von Modulen gewährleisten

Früher gab es in der Modultabelle von Zikula Flags für bestimmte Funktionen, zum Beispiel isProfile für Profilmodule und isMessaging für Module, die private Nachrichten verwalten können. In größeren Gesamtsystemen kommt es oft vor, dass man die Möglichkeit benötigt, so etwas allgemein für eigene Zwecke zu definieren.

Dieser Blog wird hauptsächlich über die Anpassung von Modulen für das Zikula-Framework berichten. Dabei werden zahlreiche Technologien verwendet, unter anderem Symfony, Twig, Doctrine, Bootstrap und jQuery. Eine Besonderheit ist, dass die Zikula-Module auf modellgetriebenem Wege realisiert werden.

Modellieren – generieren – anpassen

Meistens wird es in diesem Blog um Zikula-Module gehen, die mit dem MDSD-Werkzeug ModuleStudio modelliert und generiert wurden. Manchmal werden kleinere Tipps und Tricks vorgestellt, manchmal vielleicht etwas längere Tutorials und HowTos, die zeigen, wie wir bestimmte Anforderungen umgesetzt haben. Auch von der Entwicklung des ModuleStudio-Generators werde ich berichten.