Get the MOST

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:

Symfony und Doctrine bieten bereits Unterstützung für unterschiedliche native Attribute, welche seit in PHP 8 verwendet werden können. So lassen sich diese unter anderem für ORM-Definitionen (#[ORM\*]), Validierungsregeln (#[Assert\*]), Routen (#[Route]) oder zur Injektion von Service Tags (#[TaggedIterator]) einsetzen.

Das Attribut #[CurrentUser] erlaubt es, das Objekt mit dem aktuell angemeldeten Nutzer direkt als Controller-Argument zu übergeben; ein Beispiel hierfür lässt sich diesem Blog-Artikel entnehmen. Intern wird hierbei ein Argument Value Resolver benutzt.

Mit Hilfe der Metadaten von Doctrine lassen sich jegliche Daten zu einer Entität zur Laufzeit verändern. Allerdings kann das in manchen Anwendungsfällen fortwährend notwendig sein, zum Beispiel in Multi-Tenancy-Umgebungen. Wenn zudem Operationen mit dem Schema Manager in der Datenbank benötigt werden, kann es schnell unübersichtlich werden, da man sich nicht sicher sein kann, ob eine bestimmte Veränderung bereits durchgeführt worden ist oder noch nicht.

Der folgende Code-Ausschnitt zeigt ein Beispiel für eine Klasse, die eine Modifikation zentral für alle Entitäten, die für einen bestimmten EntityManager registriert sind, durchführt - hier wird etwa der Name der durch die Entität angesprochenen Datenbanktabelle verändert:

ModuleStudio erlaubt die Nutzung unterschiedlicher Doctrine-Erweiterungen, indem diese im jeweiligen Anwendungsmodell aktiviert und ggf. konfiguriert werden. Neben Baumstrukturen (tree / nested set), lesbaren Permalinks (sluggable) oder Übersetzungen zur Umsetzung mehrsprachiger Daten (translatable) sowie weiteren Funktionen steht hier auch die Möglichkeit zur Verfügung, die Änderungen an Datensätzen in Form einer Revisionierung aufzuzeichnen. Dieser Beitrag gibt einen Überblick über die damit einhergehenden Features. Als gemeinsame Basis der im Folgenden beschriebenen Funktionen kommt die Loggable-Extension für Doctrine zum Einsatz.

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.

In diesem Beitrag wird einmal grundlegend erklärt, wobei es sich um Zikula, Symfony und Doctrine handelt und wie diese Dinge zusammenspielen. Falls jemand diese Technologien nicht kennt, hilft dies vielleicht insbesondere beim Einstieg, sich unter der Masse von Begriffen zu orientieren.

Zikula

Zikula ist ein Application Framework und dient somit als „Rahmen“ für beliebige Webanwendungen. Die wichtigste allgemeine Anlaufstelle für Zikula ist https://ziku.la/.

Seinen Ursprung hat Zikula in dem Vorgängerprojekt „PostNuke“, welches in den 90er Jahren sehr populär war und weltweit häufig verwendet wurde. Im Jahre 2008 wurde das Projekt in Zikula umbenannt.

Im Kern von Doctrine 2 wird Wert darauf gelegt, dass die Doctrine Query Language (DQL) möglichst portabel bleibt, damit Projekte einfach mit unterschiedlichen Datenquellen arbeiten können. Bei Webanwendungen kommt es immer wieder einmal vor, dass man eine bestimmte Funktion benötigt, die zwar in MySQL existiert, jedoch nicht von DQL unterstützt wird.

Man kann in solchen Fällen eigene DQL-Funktionen erstellen, dies ist aber in den meisten Fällen zum Glück nicht nötig. Denn in den DoctrineExtensions von Benjamin Eberlei befinden sich bereits eine ganze Reihe von MySQL-Funktionen. Dieses Paket ist idealerweise auch im Zikula Core enthalten, so dass man sie für die eigenen Module direkt nutzen kann.