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 7.1
- Derzeit werden die ersten Blog-Beiträge veröffentlicht, welche Einblicke in die neuen Features der nächsten Hauptversion Symfony 7.1 geben. Wie üblich werden die Neuerungen im Folgenden thematisch …
Kommende Neuerungen in Symfony 6.4
- Die Veröffentlichung der nächsten Symfony-Version 6.4 steht bevor. Wie immer gibt es regelmäßige Einblicke in die wichtigsten, zu erwartenden Features und Verbesserungen. Dieser Beitrag zeigt im …
Symfony vereinfacht zeitgesteuerte Aktionen mit neuer Scheduler-Komponente
- Mit Symfony 6.3 sind wieder allerhand neue Features hinzugekommen. In diesem Beitrag möchte ich kurz die neue Komponente Scheduler vorstellen, mit welcher der Symfony Messenger um zeitgesteuerte …
SSO mit Keycloak und Symfony
- Mit der Java-basierten Software Keycloak wird die Verwaltung und Authentifizierung von Nutzern zentral gelöst. Hierbei bleiben kaum Wünsche offen: egal ob nun ein Registrierungsprozess, die …
Symfony UX Translator bietet Mehrsprachigkeit in JavaScript
- Bereits seit einigen Jahren gibt es das BazingaJsTranslationBundle, welches es erlaubt, den Symfony Translator auch Client-seitig zu verwenden. Auch in Zikula kommt dieses Bundle zum Einsatz, …