MyCoRe-Konventionen

Benennung der Properties

MyCoRe-Properties beginnen immer mit MCR, darauf folgt ein Punkt und dann der Komponentenname (z.B. ACL, IFS ...). Alle weiteren Bezeichner sind mit Punkt voneinander getrennt und beginnen mit einem Grossbuchstaben.

Beispiel:
MCR.IFS.FileMetadataStore.Class

Ausgenommen von diesem Namenskonzept sind Properties von konfigurierbaren Klasseninstanzen und solche von Drittanbietern (z.B. Log4j, Hibernate). Diese behalten jeweils ihre Konventionen bei.

Benennung von I18N Übersetzungen

Alle Übersetzungsvariablen erhalten ein einheitliches Namensschema. Alle Übersetzungen von Texten des Kerns und häufig benutzte Texte erhalten den Anfang common., Variablen der Module den Modulnamen und Teile der Anwendung den Anwendungsnamen.

Beispiel:

common.cancel = Abbrechen
mods.object.edit = Editieren Objekt
myapp.title.label = Titel

Stylesheets

Stylesheets in MyCoRe und DocPortal sind einheitlich zu benennen. Sie sollten (wenn möglich) komplett klein geschrieben werden. Die Verwendung eines Präfix wie mcr, MyCoRe oder mycore entfällt, auch werden keine Unterstriche genutzt.

Beispiele:

results.xsl
user.xsl
editor.xsl

Stylesheets für das Layout der Webseiten ...
[ToDo: Thomas] Namenskonvention bzgl. RootTag

Statische Factory-Methoden in Java

Statische Facory-Methoden sind als static markierte Methoden innerhalb einer Klasse, die eine Instanz dieser Klasse zurückliefern. Für derartige Methoden gibt es in MyCoRe die folgende Namenskonvention:

• getInstance() ausschlielich für echte Singeltons
• createInstance(…) für statische Methoden mit Garantie, dass bei jedem Aufruf eine neue Instanz erzeugt wird (wenn diese Garantie für die Semantik der API relevant ist)
• obtainInstance(…) für statische Methoden ohne Garantie, dass bei jedem Aufruf eine neue Instanz erzeugt wird (auch wenn die aktuelle Implementierung immer eine neue Instanz erzeugen sollte, dies aber für die Semantik der API nicht relevant ist und sich daher in Zukunft ändern darf)
• of(…) oder ofXXX(…) für Records und Value/Record-artige Klassen
• from(…) oder fromXXX(…) für Enums und Enum-artige Klassen
• Semantische Benennung (z.B. now(), parse(), parseXml()) wenn eine eindeutig passende Bennennung existiert

Verwendung des Maven-Datamodel-Plugin

Datenmodelle nach dem MyCoRe-Datenmodel-Schema 2 müssen im Maven-Modul unter src/main/datamodel/def stehen und den Namen {datenmodel}.xml haben. Dabei wird {datenmodel} dann in die Schemadatei {datenmodel}.xsd umgewandelt und so referenziert.

SOLR-Konfigurationen

Die SOLR-Konfiguration wurde mit Release 2018.06 modularisiert. Somit enthält jedes Modul nur noch die SOLR-Konfigurationsdefinitionen, die es benötigt. Um Namensdopplungen zu vermeiden, haben alle Typ- und Felddefinitionen einen Modulprefix in der Form {prefix}.{name}, Beispiel mods.identifier. Lediglich die MyCoRe-Basisfelder in mycore-base entsprechen nicht diese Konvention, da sie immer vorhanden sind.

Auch die RequestHandler sollten mit einem Präfix versehen sein. Ansonsten folgt die Benennung der RequestHandler entsprechend der Solr-Namenskonventionen in Kamelhöckerschreibweise: prefixMyRequestHandlerName, Beispiel uboExport.