Version: GSB 7Site-Konfiguration

Der allgemeine Aufbau eines Webauftritts wird mithilfe von Konfigurationsdokumenten festgelegt. Zu den Themenstellungen, die mithilfe von Konfigurationen festgelegt werden, zählen der Aufbau, die Struktur und das Defaultverhalten des Webauftritts. Darüber hinaus werden im Rahmen der Site Konfigurationen auch Entscheidungen hinsichtlich der Mehrsprachigkeit, Metadaten oder Zielgruppen getroffen.

Konfigurationsdokumente

Die Site-Konfiguration eines Mandanten kann mithilfe von Dokumenttypen gepflegt werden. Die Konfigurationsdokumente können mit einem CoreMedia-Editor bearbeitet werden, um die Konfiguration der Site anzupassen.

Die Konfigurationseinstellungen werden in den Konfigurationsdokumenten als Key/Value-Paare modelliert. Als Schlüssel/Key dient der Name des Konfigurationsdokuments, die Werte werden im Attribut Value abgelegt.

Die Konfigurationsdokumente selbst müssen im Verzeichnisbaum in Verzeichnissen mit dem Namen _config abgelegt werden, wo sie mithilfe des sogenannten ConfigReaders ausgewertet werden.

Mithilfe der Konfigurationsdokumente können lokale und globale Konfigurationseinstellungen bearbeitet werden.

Lokale Konfigurationseinstellungen sind ordnerspezifische Konfigurations-angaben. Zur Auswertung lokaler Konfigurationseinstellungen existiert ein spezieller, rekursiver ConfigReader. Dieser ConfigReader erhält einen Schlüssel (bzw. Namen eines Konfigurationsdokuments) und beginnt seine Suche normalerweise im _config Unterverzeichnis des Verzeichnisses des aktuellen Kontexts, d.h. im Verzeichnis des Dokuments, das gerade im Template bearbeitet wird (Alternativ kann im Konstruktor auch ein anderer Pfad angegeben werden, bei dem die Suche beginnen soll.). Wenn der ConfigReader an der Ausgangsposition das gesuchte Konfigurationsdokument findet, wird die Suche abgebrochen und das Dokument ausgewertet. Andernfalls wird die Suche fortgesetzt und es werden rekursiv die jeweiligen _config Unterverzeichnisse der im Verzeichnisbaum übergeordneten Verzeichnisse durchsucht, bis das angeforderte Dokument gefunden wird.

Für globale bzw. mandantenweit festgelegte Konfigurationen, d.h. für Konfigurationsangaben, die nicht abhängig vom aktuellen Kontext sind, kann zur Beschleunigung der vordefinierte und in allen Templates bereits verfügbare nicht-rekursive ConfigReader mit dem Namen siteGlobalsReader verwendet werden. Dieser sucht seine Daten ausschließlich im Verzeichnis:

/<mandant>/SiteGlobals/_config

Weiterführende Informationen

Weiterführende Informationen zum Thema finden sich in den folgenden Dokumenten:

• GSB_CMShort, Paket: Configuration.
• GSB_CMDetails, Paket: Configuration.
• GSB7/Basiskonfiguration_Mandant behandelt Konfigurationsangaben für einen Mandanten
• GSB7/SL_Handbuch_Site_Manager beschreibt diverse lokale Konfigurationsangaben beispielsweise für die Standardnavigationsknoten, Standardnavigationsziele, oder Katalog-Konfigurationen.
• Technische Details zum ConfigReader finden sich in der JavaDoc Dokumentation des Packages de.bundonline.basis.web in der Klasse configReader).

Mehrsprachigkeit

Die Umsetzung der Mehrsprachigkeit erfolgt komplett mit GSB-Mitteln. Der Webauftritt eines Mandanten kann mehrsprachig sein. Zur Umsetzung der Mehrsprachigkeit sind die beiden folgenden Alternativen realisiert worden:

Parallel mehrsprachiger Webauftritt

Bei einem parallel mehrsprachigen Webauftritt bzw. im Falle der symmetrischen Mehrsprachigkeit wird davon ausgegangen, dass nahezu jeder Inhalt, der abhängig von einer Sprache ist, auch vollständig in allen verfügbaren Sprachen des Webauftritts umgesetzt ist. Falls dies nicht der Fall ist, wird dieser Inhalt automatisch durch die Hauptsprache ersetzt. Das heißt, dass beispielsweise jeder Artikel in allen Sprachen „verfügbar“ ist, der Benutzer folglich zu jedem Zeitpunkt die Sprache wechseln kann. Es gibt keine strukturellen Unterschiede zwischen den Teilauftritten der verschiedensprachigen Inhalte.

Bei symmetrischer Mehrsprachigkeit muss die Konfigurationsdatei MultiLanguageMode unter „SiteGlobals/_config“ auf „0“ gesetzt werden. Um die Übersichtlichkeit innerhalb des CMS zu erhöhen, sollten alle redaktionellen Dokumente unterhalb des Ordners „Content“ um den Wert des isoLanguageCode der entsprechenden Sprache ergänzt werden, z.B. <dokumentname>_de oder <dokumentname>_en.

Unabhängiger mehrsprachiger Webauftritt

Bei einem unabhängigen mehrsprachigen Webauftritt bzw. der asymmetrischen Mehrsprachigkeit existieren große strukturelle Unterschiede zwischen den Teilauftritten der verschiedensprachigen Inhalte, wobei die überwiegende Anzahl von Dokumenten nur in einer der verschiedenen möglichen Sprachen verfasst ist. Damit kann der Nutzer nicht von einer beliebigen Position innerhalb der Site zur entsprechend übersetzten Seite in der gewünschten Sprache wechseln, sondern muss zu einem Einstiegspunkt für die jeweilige Sprache navigieren. Als Einstiegspunkt und damit auch Auswahlmöglichkeit für den Nutzer zwischen den unterschiedlichen Sprachversionen der Site bieten sich die Startseite oder die ggf. vorhandenen Zielgruppen-orientierten Themen-Einstiegsseiten an.

Bei einer Entscheidung für asymmetrische Mehrsprachigkeit, muss die Konfigurationsdatei MultiLanguageMode unter „SiteGlobals/_config“ auf „1“ gesetzt werden. Weil der Content der einzelnen Sprachen in verschiedenen Ordnern gespeichert wird, wird ein Ordner für jede verfügbare Sprache unter Content angelegt und nach dem Feld isoLanguageCode des entsprechenden Language-Dokuments benannt, z.B.:

• Content/EN
• Content/DE
• Content/FR
• Zudem werden die Startseiten jeder Sprache mittels ConfigLinkList-Dokumenten unter den Ordner „_config“ spezifiziert. Die Dokumente werden mit LangTarget_ benannt, wobei den isoLanguageCode-Wert der ausgewählten Sprache enthält.

Weiterführende Informationen

Der zentrale Dokumenttyp zur Modellierung der Mehrsprachigkeit ist LanguageEnt aus dem Paket Core.Content.BasicStructure. Weiterhin finden sich im gleichen Paket in der Dokumentation des Dokumenttyps LinkClassifier Hinweise zur Verwendung der Classifier bei den einzelnen Varianten der Mehrsprachigkeit.

Weiterführende Informationen zum Thema finden sich in den folgenden Dokumenten:

• GSB7/Mehrsprachigkeit stellt die allgemeinen Konzepte und Funktionalitäten der verschiedenen Varianten der Mehrsprachigkeit vor
• GSB7/Basiskonfiguration_Mandant skizziert die grundlegenden Konfigurationsmöglichkeiten der Mehrsprachigkeit
• GSB7/SL_Handbuch_Site_Manager definiert die Konfigurationsschritte der verschiedenen Varianten der Mehrsprachigkeit für die Standardlösung
• GSB7/Navigation erläutert den Zusammenhang von Navigation und Mehrsprachigkeit
• GSB7/ClassifiedLinks erläutert den Zusammenhang von klassifizierten Links und Mehrsprachigkeit
• GSB7/Suche erläutert den Zusammenhang von Haupt- / Nebensprachdokumenten und der Suche

Darüber hinaus können technische Informationen der JavaDoc Dokumentation der Dokumenttypen entnommen werden.

Metadaten

Bei der Erstellung des Metadatenkonzepts wird zwischen CoreMedia Standard-Metadaten, allgemeinen GSB-Metadaten sowie spezifischen Metadaten eines Mandanten unterschieden.

Die CoreMedia Standard-Metadaten (z.B. Ersteller eines Dokuments) sind bereits bei allen Dokumenten vorhanden und müssen nicht explizit modelliert werden. Diese werden mit Ausnahme des Dokumentnamens automatisch bei den entsprechenden Interaktionen mit dem System gesetzt.

Die allgemeinen GSB-Metadaten leiten sich aus den Metadaten der Anforderungsspezifikation unter Berücksichtigung der bereits vorhandenen CoreMedia-Metadaten ab. Die allgemeinen GSB-Metadaten müssen manuell gesetzt werden. Die manuelle Erfassung muss unter Umständen in separaten Dokumenten des Typs MetaEnts erfolgen.

Hinweis

Bei vielen Mandanten ist die Erstellung eines expliziten Meta-Dokuments zur Erfassung der Metainformationen nicht erforderlich, da die benötigten Metainformationen mithilfe von klassifizierten Links (cl2Categories) und entsprechenden Kategorie-Dokumenten direkt beim redaktionellen Dokument erfasst werden können. Statt eines expliziten Meta-Dokuments, das getrennt vom redaktionellen Dokument bearbeitet werden muss, kann so die Pflege von redaktionellen Informationen und Meta-Informationen in einem Dokument erfolgen.

Weiterführende Informationen

Im Dokument GSB_CMDetails befindet sich die Spezifikation des GSB Content Modells. Dort sind auch die relevanten Dokumenttypen zur Modellierung der Metadaten aufgeführt. Die zentralen Dokumenttypen zur Modellierung der Metadaten sind in der folgenden Aufzählung aufgeführt (zusammen mit den Paketen, in denen sie definiert sind):

• MetaEnt (Paket: Core.Content.BasicStructure)
• MetaData (Paket: Core.Content.BasicStructure)
• MetaTags (Paket: Core.Content.BasicStructure)
• MetaIndicator (Paket: Core.Content.MetaIndicators)
• HTMLMetaTags (Paket: Core.Content.BasicStructure)

Weiterführende Informationen zum Thema finden sich in den folgenden Dokumenten:

• GSB7/Metatags beschreibt die Verwaltung der HTML-Metatags und das allgemeine Zusammenspiel zwischen Metatags und Suchmaschinen.
• GSB7/Suche definiert das Zusammenspiel zwischen Metadaten und der Suchmaschine im Detail. An dieser Stelle wird insbesondere auf individuelle Konfigurationsmöglichkeiten der Metadaten und die Zuordnung zu Dokumenttypen eingegangen.
• GSB7/Workflows erläutert das Zusammenspiel zwischen Metadaten und Publikationsworkflows. An dieser Stelle wird insbesondere auf die Metadaten zur Kontrolle und Steuerung der Gültigkeit eines Dokuments eingegangen.
• GSB7/Mehrsprachigkeit skizziert das Zusammenspiel zwischen Dokumenten und Metadaten im Umfeld mehrsprachiger Websites.

Darüber hinaus können technische Informationen der JavaDoc Dokumentation der Dokumenttypen entnommen werden.

Zielgruppen

Die Kategorisierung und Aggregation der Inhalte nach Zielgruppen ist eine weit verbreitete Art der Personalisierung. Diese Art der Personalisierung ist ein mächtiger, effektiver und häufig auch dringend erforderlicher Mechanismus zur Fokussierung auf bestimmte Teilmengen der insgesamt bereitgestellten Inhalte. Sie gliedert die komplette Website nach Gruppen und ordnet die entsprechenden Inhalte den entsprechenden Gruppen zu. Generell muss jeder Redakteur definieren können, für welche Zielgruppen seine eingestellten Inhalte bestimmt sind. Diese Zuweisung erleichtert es dem Nutzer, schneller an die gewünschten Informationen zu gelangen.

Im Allgemeinen existieren Zielgruppen auf unterschiedlichen Ebenen. Generell können beispielsweise organisatorische, thematische und funktionale Kriterien zur Definition von Zielgruppen herangezogen werden.

Weiterführende Informationen

Die Zielgruppenzuordnung in den einzelnen Dokumenten kann beispielsweise über klassifizierte Links erfolgen. Die Zielgruppenattribute können somit ebenso wie die Metaattribute Dokument- und mandanten-spezifisch ergänzt werden (siehe Abschnitt "Metadaten").

Personalisierung

Neben der vordefinierten Auswahl der Inhalte für bestimmte Zielgruppen spielt die benutzerdefinierte Personalisierung bei der Darstellung der Inhalte eine wichtige Rolle.

Die benutzerdefinierte Personalisierung verbindet in der Regel eine Funktion, die es dem Nutzer erlaubt, Websites sowohl inhaltlich als auch gestalterisch seinen Wünschen anzupassen. Der prinzipielle Ablauf von Personalisierung besteht darin, implizite und explizite Informationen über eine Person (Nutzer) zu sammeln, diese zu analysieren und so passende Inhalte für diese Person zu identifizieren und bereitzustellen. Als bekanntes Beispiel können hier die Finanzseiten der Online-Broker dienen. Nach der Abfrage eines Logins kann sich der Nutzer Daten in Watch Lists, Portfolios und dergleichen selbst zusammenstellen. Die Auswahl wird gespeichert und gilt auch bei den folgenden Aufrufen der Site (nach der Abfrage des Logins).

Funktionalitäten im Bereich der benutzerdefinierten Personalisierung können von einem CMS meistens nur unterstützt bzw. vorbereitet werden. Zur konkreten Umsetzung dieser Funktionalitäten sind in der Regel erhebliche Zusatzinvestitionen notwendig, um die dafür notwendigen Komponenten, beispielsweise einen Applikations-Server oder einen Personalisierungs-Server bereitzustellen.

Um die Integration derartiger Personalisierungskomponenten vorzubereiten, sind mögliche Personalisierungsszenarien bei der GSB-Erstellung soweit wie möglich berücksichtigt worden. Beispielsweise können Personalisierungsattribute – ebenso wie die Zielgruppen- oder Metaattribute – Dokument- und mandanten-spezifisch ergänzt werden (siehe Abschnitt 4.3). Zur Integration von Portalfunktionalitäten stehen Dokumente vom Typ GenericJSPEnt bereit.

Caching

Personalisierte Inhalte auf einer Seite verhindern ein effizientes Caching der gesamten HTML-Seite. Um sicherzustellen, dass die Session unabhängigen Seitenbestandteile gecached und nur die dynamischen/Session abhängigen Bestandteile bei Aufruf der Seite dynamisch erzeugt werden, müssen statische und dynamsiche Seitenbestandteile voneinander separiert werden.

Das Konzept welches eine Trennung zwischen statischen und dynamischen Inhallten ermöglicht sind die sogenannten Edge-Side-Include Statements. Durch Integration von ESI-Tags in eine HTML-Seite können die dynamischen Inhalte bei Seitenaufruf eines Nutzers dynamisch nachgeladen werden. Die HTML-Seite enthält nur Verweise auf die zu inkludierenden dynamischen Fragmente in Form von ESI-Statements, so dass die komplette Seite gecached werden können. Die dynamischen Bestandteile werden durch die im ESI-Statement referenzierte URL nachgeladen.

Die Standardlösung enthält eine exemplarische Konfiguration einer ESI-Einbindung. Die Startseite des geschützten Bereichs der Standardlösung bindet einen Session abhängigen Seitenbereich in die Marginalspalte ein.

Das Dokument esi_fragment_html enthält die Definiton des ESI-Tags im HTML-Code. Die im Attribut SRC definierte URL ist für die dynamische Ermittlung und Ausgabe der Login-Informationen zuständig.

Hinweis für Hostingplattformbetreiber

Die Auswertung der ESI-Tags in den HTML-Seiten erfolgt durch einen sogenannten ESI-Processor. Der GSB-Kern integriert einen ESI-Processor als Filter in die Filterchain des Tomcat-Servers. Dieser Processor ist allerdings nicht für Produktivumgebungen geeignet. In einer Produktivumgebung muss ein dedizierter ESI-Processor eingesetzt werden. Hierfür kann bspw. ein Squid-oder Varnish-Server eingesetzt werden. Installation und Konfiguration dieser Komponenten sind nicht Bestandteil des GSB und müssen gesondert in Betrieb genommen werden.