Zielgruppe BetriebVersion: GSB10.0Editor-Rollen

• Admin: Diese Rolle ermöglicht die Bearbeitung aller Dokumente und Dokumenttypen des Mandanten. Mit dieser Rolle werden insbesondere Site administrative und konfigurative Dokumente bearbeitet.
• Redakteur: Nutzer oder Nutzerin der Redakteursrolle pflegen redaktionelle Inhalte wie Standardartikel, Pressemitteilungen, Downloads, o.ä.. Konfigurative Dokumente wie Dokumentkategorien, Navigation, Seitenlayouts, Style-Sheets können durch die Redakteure oder Redakteurinnen nicht gepflegt werden.

D.h. einem Redakteur oder Redakteurin steht einerseits nur eine Teilmenge der Dokumenttypen des jeweiligen Mandanten und andererseits stehen in dieser Rolle auch nicht alle Dokumenteigenschaften (-properties) zur Verfügung.

Die Zuordnung einer Rolle zu einem Benutzer erfolgt über eine Editor-Benutzergruppe. Die Benutzergruppe editor_<CUSTOMERNAME>_<ROLENAME> entspricht der Editor-Rolle <ROLENAME> des Mandanten <CUSTOMER_NAME>. Die Standardlösung (GSB SL) definiert die folgenden Benutzergruppen:

• editor_stdlsg_redakteur entspricht der Editor-Rolle Redakteur
• editor_stdlsg_admin entspricht der Editor-Rolle Site-Admin

Rollenkonfiguration

Die Editor-Rollenkonfiguration wird im Mandanten im Ordner __EditorConfig/Roles jeweils in einem Unterordner mit dem Namen der zugehörigen Editor-Benutzergruppe. Die Rollenkonfiguration der Redakteursrolle wird bspw. in dem Ordner __EditorConfig/Roles/editor_stdlsg_redakteur definiert.

Rollenkonfiguration

Die Editor Rollenkonfiguration wird mit Dokumenten vom Dokumenttyp 'HTML-Baustein'erstellt.

Jede Rollenkonfiguration wird zentral über das Dokument __EditorConfig/Roles/editor_<CUSTOMERNAME>_<ROLENAME>/config/RoleConfiguration definiert und im Editor registriert. Die Rolenkonfiguration ist wie folgt aufgebaut: 

<RoleConfiguration name="editor_stdlsg_redakteur" parentRole="editor_stdlsg_admin">
 <Conventions>
   <DocumentName pattern="^[\wäüöÄÜÖß\\._-]{1,50}$" />
   <FolderName pattern="^[\wäüöÄÜÖß\\._-]{1,50}$" />
 </Conventions>
</RoleConfiguration>

• Das name-Attribut enthält den Namen der Benutzergruppe editor_<CUSTOMERNAME>_<ROLENAME>.
• Das parentRole-Attribut definiert eine übergeordnete Editor-Rolle. Der zentrale Aspekt einer Rollenkonfiguraiton besteht in der Konfiguration der einzelnen Dokumenttypen. Innerhalb der Rolle werden die mit dieser Rolle zu bearbeitetenden Dokumenttypen definiert. Darüber hinaus gibt es innerhalb eines Mandanten noch Dokumente, die zwar gelesen aber nicht bearbeitet werden können. Um diese Dokumenttypen ebenfalls im Editor anzeigen zu können werden die Konfigurationen der Parent-Role genutzt. So müssen bspw. für den Redakteur oder Redakteurin keine Dokumenttypkonfigurationen für Dokumentkategorien und Konfiguration-Strings angelegt werden, da diese aus der Admin-Rolle genutzt werden können.
• Der reguläre Ausdruck DocumentName-Pattern wird beim Anlegen neuer Dokumente zur Prüfung des Dokumentnamens genutzt. Der Ausdruck des Beispiels stellt sicher, dass der Dokumentname nur aus alphanumerischen Zeichen sowie den Sonderzeichen '.', '_', '-' besteht und maximal 50 Zeichen lang ist.
• Der reguläre Ausdruck FolderName-Pattern wird beim Anlegen neuer Ordner zur Prüfung des Ordnernamens genutzt.

Dokumenttypkonfiguration

Die Konfiguration der einzelnen Dokumenttypen erfolgt ebenfalls im Ordner __EditorConfig/Roles/editor_<CUSTOMERNAME>_<ROLENAME>.

Dokumenttypkonfiguration

Für jeden Dokumenttyp wird ein Dokument angelegt, in dem die entsprechende Konfiguration definiert wird. Als Dokumentname wird der technische Name des zugrundeliegenden Dokumenttyps genutzt. D.h. ein Standardartikel wird bspw. im Dokument Basepage konfiguriert. . Die Konfiguration besteht aus einem XML-Anteil im Feld HTML-Code und aus Dokumenten, die im Feld Parameter verlinkt werden und im XML referenziert werden können.

Der prinzipielle Aufbau einer Dokumenttypkonfiguration (HTML-Code) ist wie folgt: 

<DocumentType name='Basepage'>
  <Section name='tab_tabInhalt'>
     <Row>
        <Property name='title' ... />
     </Row>
     ...
  </Section>
  <Section name='tab_tabMetadaten'>
    ...
  </Section>
</DocumentType>

• Das DocumentType-Tag definiert als Root-Element den Dokumenttyp und enthält im Name-Attribut den Namen des jeweiligen Dokumenttyps.
• Die Dokumentproperties können im Editor über ein Akkordeon auf verschiedene Sektionen verteilt werden. Jede Sektion wird in einem Section-Tag definiert. Der Name der Section entspricht dem Label, mit dem das jeweilige Akkordeon im Editor bezeichnet wird.
• Einzelne Dokumenteigenschaft werden jeweils in einem Row-Tag gekapselt.
• Jede Dokumenteigenschaft/-property wird in einem Property-Tag definiert. Eine Property-Definition beschreibt den genauen Aufbau und das Verhalten der entsprechenden Dokumentproperty im Editor. Aufgrund der Komplexität der Propertykonfigurationen werden diese in dem Kapitel Propertykonfiguration

Referenzen auf Dokumente

In der Konfiguration einzelner Dokumenteigenschaften werden z.T. andere Dokumente referenziert, um

• Startordner für die Verlinkung von Dokumenten in (klassifizierten) Linklisten zu definieren sowie
• Vorbelegungen für Linkklassifizierer o.ä. umzusetzen.

Diese Referenzen werden ebenfalls in der Dokumenttypkonfiguration definiert. Hierzu wird das Feld Parameter der Dokumenttypkonfiguration genutzt.

Referenzen auf Dokumente

 

Propertykonfiguration

Jede Dokumentproperty basiert auf einem bestimmten Property-Typen, die jeweils über einen individuellen Satz von Konfigurationsoptionen verfügen. Der GSB unterstützt die folgenden Property-Typen:

• Classified Linklist
• Date
• Int
• Linklist
• Richtext
• String

Im Folgenden werden zunächst die übergreifenden und allgemeingültigen Propertykonfigurationen vorgestellt: 

<Property name='languageInd'
          type='Links'
          class='ComboBoxLinkListEditor'
          visible='true'
          mandatory='true'
          ... >
    <Initializer ... />
    <Validator ... />
</Property>

Eine Propertykonfiguration besteht aus der Definition der eigentlichen Property sowie optional vorhandenen Initialisierern und Validatoren.

• name enthält den technischen Namen der Property. Die Properties und -namen eines Dokumenttyps ergeben sich aus dem Dokumentmodell. Hierbei wird die Dokumenttyphierarchie berücksichtigt, d.h. es können für einen Dokumenttypen sowohl Properties des konkreten Dokumenttypen oder Properties von in der Vererbungshierarchie übergeordneten Dokumenttypen verwendet werden.
• type definiert den der Property zugrundeliegenden Property-Typen. Der GSB unterstützt die folgenden Property-Typen:
  • Blob ermöglicht die Speicherung von Binärdateien
  • ClassifiedLinkList stellt klassifizierte Linklisten zur Verfügung
  • Date ermöglicht die Speicherung von Datum und Uhrzeit
  • Int ermöglicht die Speicherung von Zahlenwerten
  • Links Referenzen auf Dokumente können in einer Linkliste gespeichert werden
  • Richtext unterstützt die Speicherung von Text inklusive Absatz- und Inline-Auszeichnungen
  • String speichert Zeichenketten (ohne Auszeichnungen)
• class definiert den Property-Editor mit dem die Property bearbeitet wird. Für die einzelnen Property-Typen steht jeweils ein Satz an individuellen -Property-Editoren zur Verfügung.
• visible definiert, ob die Property sichtbar (Wert true) oder unsichtbar (Wert false) ist
• mandatory legt fest ob die betreffende Property ein Pflichtfeld (Wert true) oder optional (Wert false) ist

Initialisierer werden benötigt, um den Wert der Property beim Anlegen eines Dokumentes mit einem Initialwert vorzubelegen. Validatoren ermöglichen beim Zurückgeben eines Dokumentes die Prüfung der Property auf erlaubte Werte.

Class Definitionen

Der GSB Editor stellt folgende Property-Editoren (Interface zur Bearbeitung der jeweiligen Dokumenteigenschaft) zur Verfügung:

• Blob: Property-Editor für den Upload/Speicherung von Binärdateien
• CheckBoxIntegerEditor: Checkbox für Int-Properties
• ClassifiedLinkListEditor: Property-Editor für dynamische klassifizierte Linklisten
• CodeEditor: Property-Editor für die Bearbeitung von Sourcecode mit Hilfe des ACE-Editor (siehe auch https://ace.c9.io/)
• ComboBoxEditor: Dropdown-Menü mit einer fest definiert Wertemenge
• ComboBoxLinkListEditor: Dropdown-Menü mit Dokumenten aus einem Ordner
• ConfigurableClassifiedLinkListEditor: Property-Editor für statische klassifizierte Linklisten
• Date: Property-Editor für die Erfassung eines Datums
• DateTime: Property-Editor für die Erfassung von Datum und Uhrzeit
• HtmlEditor: Richtext-Editor
• ImageBlobEditor: Property-Editor für Upload/Speicherung von Bildern
• Int: Einfacher Property-Editor für Int-Properties (Zahlenwerte)
• KeywordsEditor: Property-Editor für die Erfassung von kommaseparierten Schlüsselworten
• PathAwareLinkListEditor: PropertyEditor für Linklisten
• String: Einfacher Property-Editor für String-Properties (Zeichenketten)

Damit ergibt sich folgende Zuordnung zwischen den Property-Typen (Type) und den möglichen Property-Editoren (Class):

• Blob: Blob, ImageBlobEditor
• ClassifiedLinkList: ClassifiedLinkListEditor, ConfigurableClassifiedLinkListEditor
• Date: Date, DateTime
• Int: Int, ComboBoxEditor, CheckBoxIntegerEditor
• Links: PathAwareLinkListEditor, ComboBoxLinkListEditor
• Richtext: CodeEditor, HtmlEditor
• String: String, KeywordsEditor, ComboBoxEditor

Initialisierer

Der GSB Editor unterstützt die Vorbelegung einzelner Properties beim Neuanlegen eines Dokumentes. Die zur Verfügung stehenden Initialisierungen der verschiedenen Property-Typen werden in entsprechenden Implementierungen gekapselt und über das Class-Attribut des Initialisiers definiert. 

Der prinzipielle Aufbau eines Initialsierers ist damit wie folgt: 

<Initializer class='DateInitializer' .../>

Es stehen folgende Initialisierer zur Verfügung:

DateInitializer

Die Initialisierung einer Date-Property wird mit dem DateInitializer durchgeführt. Das Datum für die Initialisierung wird über das Attribut offset definiert. Das Offset kann über DateMath-Syntax definiert werden (siehe auch https://lucene.apache.org/solr/guide/6_6/working-with-dates.html#WorkingwithDates-DateMath).

Beispiel:

• offset='' initialisiert die Property mit dem aktuellen Datum und Uhrzeit
• offset='NOW+2MONTH+3DAYS/DAY' initialisiert die Property mit einem Datum welches 2 Monate und 3 Tage in der Zukunft liegt

DynamicInitializer

Der DynamicInitializer initialisiert die LinkList-Property einer klassifizierten Linkliste mit einem Dokument.

Beispiel:

• path='$DefaultLanguage' initialisiert die Linkliste mit dem unter DefaultLanguage verlinkten Dokument (siehe auch Referenzen auf Dokumente)

IntInitializer

Der IntInitiazier initialisiert eine Int-Property mit einem definierten Zahlenwert. Der initiale Wert wird im Attribut initialValue definiert.

Beispiel:

• initialValue='10' initialisiert die Property mit dem Wert 10

LinkListInitializer

Der LinkListInitializer initialisiert eine LinkList-Property mit einem Dokument.

Beispiel:

• path='$DefaultLanguage' initialisiert die Linkliste mit dem unter DefaultLanguage verlinkten Dokument (siehe auch Referenzen auf Dokumente)

StringInitializer

Der StringInitializer initialisiert eine String-Property mit einer definierten Zeichenkette. Der initiale Wert wird im Attribut initialValue definiert.

Beispiel:

• initialValue='Mein String' initialisiert die Property mit der Zeichenkette "Mein String"

SubTypeInitializer

Der SubTypeInitializer wird für die Initialisierung der Property subType genutzt und wird ausschließlich für die Definition von Subtypen genutzt. Die GSB SL enthält mit dem Dokumenttyp Gästebuch eine exemplarische Dokumenttypkonfiguration eines SubTypes. Der Initialisier verfügt über keine Attribute, wird also wie folgt definiert:

• <Initializer class='SubTypeInitializer' />

Validatoren

Validatoren sind propertybezogene Validierungsregeln, die beim Zurückgeben eines Dokumentes im GSB Editor geprüft werden sollen.

Dokumente können nur dann erfolgreich zurückgegeben werden, wenn alle Validatoren erfolgreich durchlaufen worden sind, d.h. der Content gemäß der Validierungsregeln erfasst worden ist.

Die folgenden Validatoren stehen im GSB Editor zur Verfügung.

DateRangeValidator

Der Validator prüft, ob der Wert der Property innerhalb eines definierten Zeitintervalls liegt. Die untere Grenze wird im Attribut minDate und die obere Grenze im Attribut maxDate angegeben. Die beiden Werte werden über DateMath-Syntax definiert werden (siehe auch https://lucene.apache.org/solr/guide/6_6/working-with-dates.html#WorkingwithDates-DateMath).

Beispiel:

• minDate='NOW-2MONTH' maxDate='NOW+2MONTH' stellt sicher, dass das eingegebene Datum maximal 2 Monate in der Vergangenheit oder Zukunft liegen darf

 DocTypeValidator

Der Validator prüft die Dokumente der Link-Liste eines klassifizierten Link-Listeneintrags auf eine definierten Dokumenttypen. Das Attribut docType definiert den erlaubten Dokumenttypen. Mehrere Dokumenttypen werden durch Kommata getrennt aufgeführt.

Beispiel:

• docType='Basepage,PressRelease' erlaubt die Verlinkung von Standardartikeln (Basepage) und Pressemitteilungen (PressRelease)

LinkListValidator

Der Linklistvalidator prüft die Elemente einer Linkliste. Mögliche Prüfungen sind:

• docType prüft die Dokumente der Liste auf erlaubte Dokumentypen (siehe auch DocTypeValidator)
• minLength definiert die minimal benötigte Anzahl Dokumente in der Linkliste
• maxLength definiert die maximale Anzahl Dokumente der Linkliste
• path prüft, ob alle Dokumente unterhalb des definierten Pfades abgelegt sind

Beispiel:

• minLength='1' maxLength='5' prüft, ob die Linkliste wenigstens ein und höchstens fünf Dokumente enthält

MinMaxValidator

Der Validator prüft die Anzahl der Dokumente einer Linkliste. Mögliche Prüfungen sind:

• minLength definiert die minimal benötigte Anzahl Dokumente in der Linkliste
• maxLength definiert die maximale Anzahl Dokumente der Linkliste

Beispiel:

• minLength='1' maxLength='5' prüft, ob die Linkliste wenigstens ein und höchstens fünf Dokumente enthält

NotEmptyValidator

Der Validator überprüft, ob die betreffende Property nicht leer ist. Dass heißt, String-Properties dürfen keinen Leerstring (inkl. Whitespaces) und Linklisten müssen wenigstens ein Dokument enthalten. Dieser Validator kann bei Bedarf anstelle des Property-Attributs mandatory genutzt werden. Der Validator hat keine Parameter, so dass an dieser Stelle auf ein Beispiel verzichtet werden kann.

NumberRangeValidator

Der Validator überprüft den Wert einer Int-Property auf einen bestimmten Zahlenbereich:

Mögliche Prüfungen sind:

• min definiert den minimal erlaubten Zahlenwert
• max definiert den maximal erlaubten Zahlenwert

Beispiel:

• min='1' max='5' prüft, ob die eingegebene (natürliche) Zahl im Intervall zwischen eins und fünf liegt.

PathValidator

Der Validator prüft die Dokumente einer Linkliste. Alle Dokumente müssen unterhalb des im Attribut path definierten Ordners liegen.

• path prüft, ob alle Dokumente unterhalb des definierten Pfades abgelegt sind

Beispiel:

• path='/DE' stellt sicher, dass alle verlinkten Dokumente unterhalb des Ordners /DE liegen

RegexValidator

Prüft den Wert einer String-Property gegen einen im Attribut regex definierten regulären Ausdruck.

• regex enthält einen regulären Ausdruck gegen den die eingegebene Zeichenkette geprüft wird

Beispiel:

• regex='^START' prüft, ob der String am Anfang den Begriff START enthält.

StringLengthValidator

Überprüft die Länge eines Strings. Mögliche Prüfungen sind:

• minLength definiert die minimal benötigte Zeichenlänge des Strings
• maxLength definiert die maximal erlaubte Zeichenlänge des Strings

Beispiel:

• minLength='10' maxLength='50' prüft, ob String wenigstens 10 und höchstens 50 Zeichen lang ist

nach oben