Get the MOST

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.

Vorhandene Formate in ModuleStudio

Die folgenden Ausgabeformate werden derzeit von ModuleStudio unterstützt. Viele davon sind in generierten Modulen nur für Administratoren zugänglich, damit Daten nicht per Standard automatisch für alle Besucher verfügbar sind.

• RSS- und Atom-Feeds: für view-Seiten (öffentlich)
• CSV: für view-Seiten (nur für Admins)
• XML: für view- und display-Seiten (nur für Admins)
• JSON: für view- und display-Seiten (nur für Admins)
• KML: für view- und display-Seiten (nur für Admins)
• PDF: für view- und display-Seiten (nur für Admins, per Standard inaktiv)

Seit ModuleStudio 0.6.1 ist es möglich, die Generierung der einzelnen Formate im Anwendungsmodell zu steuern. Wenn in einer Anwendung beispielsweise keine XML-Templates benötigt werden, kann dies einfach ausgeschaltet werden.

In ModuleStudio 0.6.2 wurde übrigens als neues Format für display-Seiten auch ics aufgenommen. Damit lassen sich Objekte, die ein Start- und ein Enddatum haben, als iCalendar-Events exportieren.

Nutzung und aktuelle Defizite

Sofern man ShortURLs aktiviert hat, ist die Verwendung unterschiedlicher Formate sehr intuitiv. Im Prinzip wird hier einfach die Endung in der URL ausgetauscht.

• Display-Seiten: aus kalender/event/mein-event.html wird z. B. kalender/event/mein-event.kml oder kalender/event/mein-event.xml
• View-Seiten: aus kalender/view/events/ wird z. B. kalender/view/events.atom oder kalender/view/events.json

Ohne ShortURLs muss ein zusätzlicher GET-Parameter mit übergeben werden, dessen Verwendung noch etwas verbesserungswürdig anmutet: &usefooext=1, wobei foo für die jeweilige Endung steht.

Die oben erwähnte Anpassung der Response läuft momentan ebenfalls noch etwas suboptimal. Dies läuft nicht zentral im Controller, sondern wird von der View aus mit Hilfe eines Template-Plugins gesteuert.

Nutzung individueller Templates

Neben dem Überschreiben der Standardtemplates gibt es bei den Standardaktionen (view, display, edit, delete) auch die Möglichkeit, abweichende Vorlagen mit Hilfe eines tpl-Parameters zu verwenden. Ist beispielsweise eine alternative view-Ansicht für die Entität person gewünscht und wird dann diese Seite mit &tpl=foo aufgerufen, so wird statt view.tpl erst einmal nach der Datei view_foo.tpl gesucht.

{modurl modname='MeinModul' type='user' func='view' ot='person' tpl='foo'} führt also zum Template modules/MeinModul/templates/user/person/view_foo.tpl

Was passiert in Zikula 1.4.0 ?

Beginnend mit ModuleStudio 0.6.2 wird das Prozedere bei der Ziel-Coreversion 1.4.0 auf Symfony2 und Twig umgestellt. Das bedeutet, dass auch das Routing komplett von Symfony gesteuert wird. Unterschiedliche Formate werden dabei mittels eines speziellen Parameters _format abgebildet (Beispiel). Symfony kennt bereits zahlreiche Ausgabeformate und stellt die Response automatisch passend dazu ein.

Wer diese Umstellung verfolgen möchte, kann das entsprechende Umbau-Ticket beobachten.