Optimierung im Detail - Schreibweisen von Entitäten und Feldern im Modell

in  Zikula Apps , , ,

Optimierung im Detail - Schreibweisen von Entitäten und Feldern im Modell

In der modellgetriebenen Softwareentwicklung werden die fachlichen Anforderungen in der Regel sehr prägnant formuliert. Schließlich ist eines der Ziele einer domänenspezifischen Sprache eine lesbare und verständliche Beschreibung eines Softwaresystems, wozu auch die Vermeidung von Redundanzen und unnötigem Boilerplate-Code gehört.

Dies führt dazu, dass selbst kleine Veränderungen in einem Modell größere Unterschiede im generierten Quelltext zur Folge haben können. Ein Beispiel für solche, auf den ersten Blick unscheinbare Differenzierungen betrifft die Schreibweise von Modellelementen. Dieser Beitrag zeigt auf, was es bedeutet, ob der Name einer Entität oder eines Feldes so oder so geschrieben wird.

Zunächst einmal reagiert die Validierung von ModuleStudio mit einem Fehler, wenn man Bezeichnungen mit einem Großbuchstaben startet. Dies hat den einfachen Hintergrund, dass die Modellierung möglichst einfach bleiben soll (in dem Fall ohne unnötigerweise die Shift-Taste benutzen zu müssen). Wenn es erforderlich sein sollte, kann der Generator special selbstständig zu Special umwandeln.

Im Folgenden nehmen wir als Beispiel ein Modell an, welches eine Entität für Produkte enthält. Diese Entität soll ein neues Feld für etwaige zusätzliche Versandkosten erhalten.

Natürlich kann man das Feld einfach additionalshippingcosts nennen. Das wird ganz normal funktionieren und führt auch nicht zu einem Fehler. Es nimmt dem Generator aber die Möglichkeit, den Namen je nach Einsatzzweck unterschiedlich zu formatieren.

Mixed case to the rescue

Empfohlen für ModuleStudio wird die sogenannte mixed case Schreibweise: das obige Feld würde also additionalShippingCosts getauft. Dies ist erstens wesentlich lesbarer für Menschen, die sich mit dem Modell und/oder dem Quellcode auseinandersetzen. Zweitens kann der Generator mit dieser Bezeichnung etwas flexibler arbeiten - hier einige Beispiele:

  • Name des Feldes für Code und Doctrine: additionalShippingCosts
  • Lesbarer Name mit Großschreibung, z. B. für ein Form-Label: Additional shipping costs:
  • Lesbarer Name ohne Großschreibung, z. B. für einen Hilfetext: Please enter the additional shipping costs

Man erhält damit out of the box ansprechendere Oberflächen in den generierten Anwendungen, da die Oberflächen mit lesbaren Zeichenketten ausgestattet werden. Dies vereinfacht dann übrigens auch den Übersetzungsprozess mit Gettext, da der Übersetzer leichter versteht, wofür eine bestimmte Schreibweise gedacht ist.

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 …