Verbesserungen rund um Doctrine im Bundle-Generator

in  Generator , , , ,

Verbesserungen rund um Doctrine im Bundle-Generator

Es geht weiter mit den Aufräumarbeiten im Generator von ModuleStudio: nach den im letzten Beitrag beschriebenen Anpassungen rund um PHP 8 liegt aktuell der Fokus auf den Umgang mit Doctrine-Entitäten und -Repositories.

Was wurde gemacht?

Hier eine Auswahl der bereits umgesetzten Änderungen:

  • Repositories liegen nun im Namespace Repository anstatt Entity/Repository.
  • Sämtliche Referenzen zwischen Entitäten und Repositories verwenden nun keine Namespace-Strings mehr, sondern die Foo::class-Notation.
  • Es werden Interfaces für die Repositories generiert, was insbesondere dann wichtig wird, wenn es darum geht, abweichende Implementierungen für Tests zu verwenden.
  • Die Repositories erben von ServiceEntityRepository, um sie einfach via Dependency Injection verwenden zu können. Falls ein Repository von einer anderen Basisklasse erbt (z. B. im Falle der Tree- und Translatable-Extensions), wird statt dessen das dazugehörige ServiceEntityRepositoryInterface implementiert.
  • Auch für die Entitäten gibt es ein EntityInterface, welches hilfreich ist, wenn es darum geht, schnell herauszufinden, ob man gerade die Entität eines bestimmten Bundles hat oder nicht. Vorher musste hierzu der Namensraum untersucht werden. Im generierten Bundle wird dies beispielsweise in einigen Event-Subscribern/-Listenern genutzt.
  • Sämtliche beschriebenen Punkte werden nicht nur für die Repositories der modellierten Entitäten, sondern auch für etwaige Erweiterungen derselben (LogEntries, Translations, Attributes, Categories, usw.) angewendet.

Was wird noch gemacht?

Die Änderungen in diesem Bereich sind noch nicht abgeschlossen. Unter anderem sind hier noch folgende Dinge angedacht:

Der Bundle-Generator bekommt eine Verschlankungskur

in  Generator , , ,

Der Bundle-Generator bekommt eine Verschlankungskur

In den letzten Tagen sind die ersten Arbeitsschritte zur weiteren Modernisierung der von ModuleStudio generierten Symfony-Bundles bzw. Zikula-Module umgesetzt worden. Dieser Beitrag zeigt kurz die entsprechenden Änderungen auf:

Alte Zöpfe abgeschnitten

Die unterstützten Zikula Core-Versionen wurden auf die Zukunft ausgerichtet: so können die veralteten Versionslinien 1.5.x und 2.x nicht mehr ausgewählt werden. Hierdurch ist natürlich sehr viel alter Code entfernt worden. Die Version 3.0.x ist nun der neue Standard, außerdem wurden neue Optionen für 3.1.x und 4.x angelegt.

Vortrag zu Zikula und ModuleStudio bei der Symfony User Group in Köln

in  Verschiedenes , , , , ,

Vortrag zu Zikula und ModuleStudio bei der Symfony User Group in Köln

Schon seit einiger Zeit hatte ich den Wunsch, eine Symfony-Gruppe zu besuchen, um dort einmal kurz zu zeigen, wie wir mit Symfony arbeiten. Gestern hatte es schließlich geklappt. In einem sehr angenehmen und lockeren Ambiente durfte ich mit meinem Talk “Maßgeschneiderte Bundles vom Fließband” zunächst Zikula als ein auf Symfony, Doctrine und Twig aufsetzendes Application Framework vorstellen. Anschließend habe ich dann einen Einblick in die modellgetriebene Entwicklung mit ModuleStudio und die mit der Code-Generierung einhergehenden Besonderheiten gegeben.

Automatisierte Tests - ein Zwischenstand

in  Builds & Tests , , ,

Automatisierte Tests - ein Zwischenstand

Seit dem kürzlich angekündigten Start der Testautomatisierung von ModuleStudio ist bereits eine Menge geschehen. So gibt es knapp 1.000 Tests für die DSL, darunter vorwiegend für UI-unabhängige Komponenten, wie den Parser, den Serialisierer, den Formattierer und die Validierungsregeln. Hier haben wir eine Testabdeckung von etwa 95% erreicht und konnten einige Fehler in der Validierungsschicht beheben.

Auch der Generator wird bereits mit einer Abdeckung von über 90% getestet. Hier ging es bislang allerdings vorwiegend darum, möglichst viele Varianzen zu durchlaufen, um zum Beispiel Null Pointer Exceptions zu verhindern. Weitere Tests für einzelne inhaltliche Aspekte werden dann nach und nach auf der Basis von spezifischen Bug Reports ergänzt.

Ran an die Tests!

in  Builds & Tests , ,

Ran an die Tests!

Schon ewig geplant, aber lange schmählich vernachlässigt, habe ich bei ModuleStudio die automatisierten Tests. Zwar ist schon seit Längerem die Infrastruktur dahingehend ausgerichtet, was beispielsweise die Git-Struktur und die Jenkins-Pipelines anbelangt, allerdings bringt das relativ wenig, wenn es fast nur Dummy-Tests ohne jeglichen Inhalt gibt.

Da ModuleStudio 1.1.0 kürzlich veröffentlicht wurde, konnten danach in der Entwicklungsversion 1.2.0 einige Altlasten entfernt werden. Da hat es sich im Hinblick auf Timing und Ausgangslage angeboten, endlich zu starten.

Vereinfachung der DSL in Bezug auf Variablen

in  Metamodell , , ,

Vereinfachung der DSL in Bezug auf Variablen

Gegenwärtig arbeiten wir an der Konzeption einer Änderung in der Modellierungssprache von ModuleStudio, die uns schon seit Längerem umtreibt. Noch aus der Anfangsphase des Projektes gibt es neben den Feldern einer Entität auch Elemente für Variablen, die zentrale Konfigurationseinstellungen repräsentieren. Diese Variablen wurden bislang allerdings eher stiefmütterlich behandelt. Anstatt diese nun weiter aufzubohren, geht die Strategie eher in die Richtung, die normalen Feldtypen auch für Variablen wiederzuverwenden.

ModuleStudio kann anhand des Containers eines Feldes immer noch erkennen, ob es sich hierbei um ein Feld einer Entität oder um eine Konfigurationseinstellung handelt. Wenn also ein Variablen-Container auch normale Felder enthalten kann, können die zusätzlichen Variablen-Elemente entfallen. Diese würden übergangsweise in ModuleStudio 1.1.0 noch weiter unterstützt, jedoch eine Warnung oder einen Fehler verursachen. In ModuleStudio 1.2.0 werden sie dann komplett entfernt.

ModuleStudio-Releaseplan und Website-Design

in  Verschiedenes , , , ,

ModuleStudio-Releaseplan und Website-Design

In den nächsten Tagen werden Zikula 1.5.0 und 2.0.0 als Cross-Release erscheinen. Beide Versionen sind funktional identisch. Der Unterschied liegt darin, dass der Unterbau von Zikula 2 auf Symfony 3 basiert, wohingegen bei Zikula 1.5 weiterhin Symfony 2.8 zum Einsatz kommt. In Zikula 2 ist ferner jegliche Legacy-Unterstützung entfernt worden.

Aus Marketing-Gründen haben wir schon länger besprochen, dass zusammen mit Zikula 2.0 auch ModuleStudio 1.0 zur Verfügung stehen sollte. Daher geht meine Überlegung in die Richtung, dass zunächst ModuleStudio 0.7.5 veröffentlicht wird, welches alle aktuellen Generator-Fixes beinhaltet. Anschließend wird der Support für Zikula 1.4.x aus der DSL entfernt, welche aktuell noch als Standard eingestellt ist. Statt dessen wird per Standard für Zikula 2.0 generiert und weiter die Möglichkeit geboten, auf 1.5 umzustellen. Nach dieser kleinen Änderung wird dann ModuleStudio 1.0.0 direkt nach 0.7.5 das Licht der Welt erblicken.

ModuleStudio 0.7.4 macht Fortschritte

in  Generator , , , , ,

ModuleStudio 0.7.4 macht Fortschritte

Seit der Veröffentlichung von ModuleStudio 0.7.3 im Februar 2017 sind die Arbeiten an DSL und Generator kontinuierlich fortgeführt worden. Es wurden einige neue Optionen zur Modellierungssprache hinzugefügt und diverse Anpassungen im Hinblick auf eine optimale Kompatibilität der generierten Anwendungen mit Zikula 1.5 und 2.0 vorgenommen.

Es ist vorgesehen, dass ModuleStudio 0.7.4 noch im Mai erscheinen wird. Dieser Beitrag stellt einige der zahlreichen Neuerungen vor.

Die Repository-Klassen wurden aufgeräumt und von allen Dingen bereinigt, die nichts direkt mit der Erzeugung von Queries zu tun haben. In diesem Rahmen wurde ein CollectionFilterHelper eingeführt, der sich um die Anwendung der Parameter aus zum Beispiel den Quick Navigation Formularen kümmert.