Generator Einstellungen in ModuleStudio 0.6.1 - Überblick und Anwendung

in  Zikula Apps , ,

Generator Einstellungen in ModuleStudio 0.6.1 - Überblick und Anwendung

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.

Features steuern

Ob Templates für unterschiedliche Ausgabeformate, Plugins für andere Module oder Blöcke: optionale Zusatzfunktionen können nun einfach ausgeschaltet werden. Falls man zum Beispiel bei einer Entität einen erweiterten Workflow benutzt, aber den Block zur Moderation nicht benötigt, muss lediglich die Eigenschaft generateModerationBlock auf false gesetzt werden. In der Folge sinkt der Anteil unnötigerweise generierter Dateien, was die Handhabung, Anpassung und Weiterentwicklung von Anwendungen vereinfacht.

Einfache Aktualisierung eines Moduls

Einige Generator Einstellungen dienen dazu, die Merge-Prozesse nach einem erneuten Generieren einer Anwendung zu vereinfachen. So kommt es zum Beispiel häufig vor, dass man ein Modul neu generieren möchte, in dem bereits einige Klassen implementiert wurden, um das Verhalten der generierten Basisklassen zu erweitern oder anzupassen. Normalerweise muss man hier in der neuen generierten Fassung die konkreten Klassen herauslöschen, bevor man die Dateien über die bestehende Fassung kopieren kann. In diesem Zusammenhang kann die Option generateOnlyBaseClasses nützlich sein: wird diese aktiviert, so werden nur noch die Basisklassen generiert. Bei Aktualisierungen ohne strukturelle Änderungen im Modell kann dies das Merging erheblich beschleunigen.

Mit der Einstellung skipFiles kann man eine Liste von Dateipfaden angeben, die bei der Generierung übersprungen werden sollen. Hat man zum Beispiel ein Template direkt im Modulordner verändert, kann man dafür sorgen, dass dies vom Generator nicht wieder erstellt wird, und so ein versehentliches Überschreiben vermeiden. Ein Beispielmodell, welches diese Eigenschaft verwendet, befindet sich hier. Mit der Zeit steigt hier allerdings die Gefahr, dass neue Änderungen im Generator nicht bemerkt werden.

Aus diesem Grund gibt es in ModuleStudio 0.6.2 noch eine weitere Eigenschaft namens markFiles: Dateipfade, die in dieser Liste angegeben werden, werden zwar generiert, aber mit einem speziellen Dateinamen markiert, in dem vor der Dateiendung ein .generated-Suffix eingefügt wird. Statt der Datei display.tpl würde also beispielsweise display.generated.tpl erzeugt, die mit der angepassten Version des Templates verglichen werden kann.

Die Einträge in beiden Listen können entweder durch Kommas oder durch Kommas mit Leerzeichen getrennt werden. Es ist vorgesehen, die Syntax der DSL an dieser Stelle noch etwas flexibler zu gestalten, damit auch Tabulatoren und Zeilenumbrüche eingefügt werden können.

Sonstige Aspekte

Es gibt noch weitere Optionen, die unterschiedliche kleine Dinge regeln:

  • timestampAllGeneratedFiles - Hier kann gesteuert werden, ob der Kommentar generiert durch ModuleStudio … entweder nur in der Version-Klasse der Anwendung oder aber in allen Dateien mit einem Zeitstempel versehen werden soll. Aktiviert man den Zeitstempel für alle Dateien, hat man mehr Kontrolle, aber auch mehr Noise in der Diff-Ansicht von Git.
  • generatePoweredByBacklinksIntoFooterTemplates - Mit dieser Einstellung lassen sich die Backlinks zur ModuleStudio-Homepage, welche per Standard in die Footer-Templates generiert werden, deaktivieren. Dies kann etwa nützlich sein für kommerzielle Module, bei denen solche Links den Kunden stören würden.
  • writeModelToDocs - Möchte man ein Modul für die Community freigeben, macht es Sinn, diese Option zu aktivieren. In dem Fall werden die Modelldateien in den docs-Ordner des Moduls geschrieben, ansonsten in einen separaten Ordner außerhalb des Moduls.

Weitere Beiträge in Kategorie Zikula Apps

Kommende Neuerungen in Symfony 6.2
- Gegenwärtig laufen die Arbeiten an der nächsten Symfony-Version 6.2. Wie immer gibt es regelmäßige Einblicke in die wichtigsten, zu erwartenden Features und Verbesserungen. Dieser Beitrag zeigt im …
Zikula 4 - Ansätze für ein leichtgewichtigeres User Management
- Im Rahmen der Schlankheitskur vom Zikula Core sind einige Altlasten bereits entfernt worden. Das Admin-Interface baut nun auf dem EasyAdminBundle auf. Ein größerer Knoten, den es noch zu entwirren …
Zikula 4 und ModuleStudio - Weitere Integration mit dem EasyAdminBundle
- Im letzten Beitrag wurde unter anderem dargestellt, dass Zikula 4 nun das EasyAdminBundle (EAB) integriert um das alte Admin-Interface abzulösen. Zwischenzeitlich sind die Arbeiten daran etwas …
Zikula 4 - Weiteres Ausmisten im Gange
- Getreu dem Motto Wer loslässt, hat die Hände frei wird der Zikula Core gegenwärtig ausgemistet: das Ziel ist es, wieder ein schlankes System zu schaffen, welches nicht jede Funktionalität selbst …
Zikula 4 - Fokus auf die eigenen Stärken
- Im Juli haben wir noch etwas zaghaft damit begonnen, historischen Ballast aus dem Zikula Core zu entfernen. Unter anderem wurden spezielle Themes und das Hook-System ausgesondert. Während der letzten …