Get the MOST

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.

Im Controller-Bereich der Modellierungssprache von ModuleStudio nimmt der Ajax-Controller eine besondere Rolle ein. Die Aktionen eines Ajax-Controllers werden im Gegensatz zu anderen Controllern nicht als Webseite durch den Anwender, sondern von mittels JavaScript initiierten Ajax-Requests aufgerufen.

Der Generator erzeugt unter Umständen einige zusätzliche Methoden im Ajax Controller, wenn diese für bestimmte generierte Funktionalitäten erforderlich sind. Dies betrifft unter anderem die im Folgenden aufgelisteten Methoden:

getCommonUsersList

Diese Methode sucht eine Liste von Benutzernamen, die zu einem gegebenen Suchausdruck passen, und liefert diese aufbereitet für AutoCompletion zurück. Wird nur generiert, falls in der Anwendung mindestens eine Entität mit einem Benutzerfeld existiert. Zusätzlich wird je Benutzerfeld eine weitere Methode generiert, zum Beispiel getArticleCreatorUsers, damit sich die Funktion einfach für bestimmte Felder überschreiben oder anpassen lässt.

getItemListFinder

Wird nur generiert, wenn auch der External-Controller und die Finder-Komponente generiert werden, was durch eine Generator-Einstellung gesteuert werden kann. Zweck der Methode ist es, eine Liste von Entitäten für den Finder aufzubereiten und zurückzuliefern. Mit der Finder-Komponente können Entitäten gefunden und ausgewählt werden, zum Beispiel bei der Verwendung der generierten Scribite-Plugins.

getItemListAutoCompletion

Sucht nach Entitäten, die zu einem gegebenen Suchausdruck passen, und liefert diese aufbereitet für AutoCompletion zurück. Wird nur generiert, wenn es mindestens eine Join-Relation im Modell gibt. Verwendet wird diese Methode von den AutoComplete-Feldern in den Änderungsformularen.

checkForDuplicate

Prüft, ob ein bestimmter Feldwert ein Duplikat ist oder nicht. Wird nur generiert, wenn unique-Felder oder unique Slugs im Anwendungsmodell verwendet werden.

toggleFlag

Diese Methode schaltet ein bestimmtes Flag einer gegebenen Entität um. Generiert wird sie nur, falls es Boolean-Felder mit aktiviertem Ajax-Toggle gibt. Auf Übersichts- und Detailseiten kann man dann per Mausklick die Werte einfach umschalten.

handleTreeOperations

Wird nur generiert, das Anwendungsmodell mindestens eine Entität mit aktivierter Baumstruktur enthält. Die Verwaltungsseite für Hierarchien benutzt diese Methoden für unterschiedliche Aktionen, die mit der Baumstruktur durchgeführt werden können: neuen Wurzelknoten anlegen, neuen Unterknoten anlegen, Knoten löschen, Knoten verschieben, Knoten verschieben nach X.

Wer seine Projekte regelmäßig mit einem Build-Server prüfen und testen lässt, erstellt oftmals auch eine API-Dokumentation. Dafür gibt es auch im PHP-Bereich eine Vielzahl unterschiedlicher Werkzeuge, beispielsweise PHPXref oder ApiGen. Dieser Beitrag stellt das Tool phpDox vor und gibt Einblick in das interessante Feature der Enricher.

Eine API-Dokumentation stellt in der Regel eine navigierbare Übersicht der in einem Projekt vorhandenen Klassen, Schnittstellen, Methoden usw. bereit. Damit können Entwickler, die diese Artefakte in ihrem eigenen Code nutzen wollen, Informationen über die benötigten Methoden einsehen und so beispielsweise herausfinden, welche Argumente eine bestimmte Funktion erfordert.

Bislang wurden in generierten Modulen selbstgeschriebene Validierungen verwendet. In den letzten Tagen wurden diese für die Zielversion Zikula 1.4.x abgelöst zu Gunsten der Symfony Validator Komponente.

In Symfony können Validierungen in mehreren Notationen definiert werden. Neben PHP und YAML sind auch XML und Annotationen möglich. Im ModuleStudio-Generator haben wir, wie auch im Ticket auf GitHub diskutiert wurde, Annotationen verwendet. Dabei werden Validierungsregeln (“Constraints”) durch @Assert-Annotationen direkt an der entsprechenden Entitätsklasse beziehungsweise den entsprechenden Feldern oder Methoden hinterlegt.

Wie im letzten Artikel bereits erwähnt, verfügt ModuleStudio seit Version 0.6.1 über eine Reihe von Generator-Einstellungen, mit denen sich unterschiedliche Features und Verhaltensaspekte beeinflussen lassen. Dieser Beitrag gibt einige Anregungen zu möglichen Anwendungsfällen dieser Optionen.

Zikula Core Version

Bereits von früheren Versionen bekannt ist eine Einstellung für die Version des Zikula Core, für die eine Anwendung generiert werden sollte. Dies ist also nicht neu.

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.

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.