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.

Problem mit zirkulären Abhängigkeiten durch Dekoratoren in Symfony 5.3.7

in  Verschiedenes , , , ,

Problem mit zirkulären Abhängigkeiten durch Dekoratoren in Symfony 5.3.7

Symfony erlaubt das Dekorieren von Services: hierbei wird im Gegensatz zum Überschreiben bestehender Services eine Ummantelung derselben vorgenommen. Immer dann, wenn der ursprüngliche Service injiziert werden soll, wird statt dessen der ihn dekorierende Ersatz verwendet. Dies ist immer dann praktisch, wenn man zusätzliche Funktionalität hinzufügen möchte, jedoch keinen Zugriff auf den originalen Service hat - zum Beispiel aus Gründen der Entkopplung oder schlicht und ergreifend weil das zu erweiternde Bundle von Dritten entwickelt wird. In Zikula wird beispielsweise Twig mit einem Dekorator erweitert, um mit Hilfe zusätzlicher Events vor und/oder nach dem Rendern eines Templates reagieren zu können.

Symfony CurrentUser-Attribut kollidiert mit Doctrine Param Converter

in  Verschiedenes , , ,

Symfony CurrentUser-Attribut kollidiert mit Doctrine Param Converter

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.