RoutingDefinition

Die RoutingDefinition.xml Files

Damit der Server weiß, wie er auf HTTP Requests nach bestimmten Adressen mit/ohne Parameter oder auch Cookies reagieren kann, darf, sollte oder zwingend muss, sind Routing-Definitionen erforderlich.

Overview

Mit Hilfe von RoutingDefinition.xml Files lässt sich in UDS XML konfigurieren, wie der Server URIS auf Dokumente abbilden soll welche der Server im Anschluss als HTML-Seite zu rendern versucht. Eine besondere Bedeutung haben hierbei Canonical-Links: Dieses sind diejenigen Adressen welche schlussendlich von Suchmaschinen erfasst werden sollen.

HINWEIS: Die Konfiguration von RoutingDefinition.xml Files erfordert bietet verschiedene Varianten. Darüber hinaus ist für UDS v.1.6.x eine Überarbeitung in Planung.

RoutingDefinition XML Structure

RoutingDefinition XML Files stammen noch aus einer Zeit vor UDS v.1.5.2.x und beinhalten dahingehend weder Namespaces noch eine klare ce:config Ordnung für Konfigurationen.

UDS RoutingDefinition XML hat darüber hinaus in Version 1.5.2.x eine weitere Reihe von Besonderheiten welche die Struktur von üblichen XML Dokumenten abweichen lässt: Beim Lesen von UDS Routen ist es möglich, über XML Code Variablen anzulegen deren Werte aber aber im Verlauf der Verarbeitung von Routen-Deklarationen überschrieben werden können. UDS RoutingDefinition XML Code entspricht dahingehend einer einem Skripting als einer klassischen Dokumentstruktur.

Struktur einer RoutingDefinition

Der grundlegende Aufbau beinhaltet ein doc-Element welchem anschließend entweder route-Elemente oder aber route-keys Elemente hinzugefügt werden. Auch in RoutingDefinition Files können comment-Elemente verwendet werden.



<?xml version="1.0" encoding="UTF-8"?>
<index>
  <comment>
    /@uio3
  </comment>
  <route-keys>
    <SiteContextFILESegmentKey>@uio3</SiteContextFILESegmentKey>
    <SiteContextFILESegmentIndex>100</SiteContextFILESegmentIndex>
    <SiteContextCanonicalURISegmentKey>@uio3</SiteContextCanonicalURISegmentKey>
    <SiteContextAlternativeURISegmentKey>@uio3</SiteContextAlternativeURISegmentKey>
    <registerContextNode/>
  </route-keys>

  <comment>
    @uio3
  </comment>
  <route-keys>
    <SiteRealmFILESegmentKey>uio3.com</SiteRealmFILESegmentKey>
    <SiteRealmFILESegmentIndex>R120</SiteRealmFILESegmentIndex>
    <SiteRealmCanonicalURISegmentKey>uio3.com</SiteRealmCanonicalURISegmentKey>
    <SiteRealmAlternativeURISegmentKey>uio3.com</SiteRealmAlternativeURISegmentKey>
    <registerRealmNode isAlsoHTTP404="false"/>
  </route-keys>

  <route>
    <canonical>@uio3</canonical>
    <uri>^@uio3(?:\/$|$)</uri>
    <file>Realm/uio3.com/RealmNode.xml</file>
  </route>

  <comment>
    ============================================================================
    ===== CONTEXT 'de'
    ============================================================================
  </comment>

  <route-keys>
    <SiteContextFILESegmentKey>de</SiteContextFILESegmentKey>
    <SiteContextFILESegmentIndex>100</SiteContextFILESegmentIndex>
    <SiteContextCanonicalURISegmentKey>de</SiteContextCanonicalURISegmentKey>
    <SiteContextAlternativeURISegmentKey>de</SiteContextAlternativeURISegmentKey>
    <registerContextNode/>
  </route-keys>

  <comment>
    ============================================================================
    ===== REALM 'uio3.com'
    ============================================================================
  </comment>

  <comment></comment>
  <route-keys>
    <SiteRealmFILESegmentKey>uio3.com</SiteRealmFILESegmentKey>
    <SiteRealmFILESegmentIndex>R120</SiteRealmFILESegmentIndex>
    <SiteRealmCanonicalURISegmentKey>uio3.com</SiteRealmCanonicalURISegmentKey>
    <SiteRealmAlternativeURISegmentKey>uio3.com</SiteRealmAlternativeURISegmentKey>
    <registerRealmNode isAlsoHTTP404="false"/>
  </route-keys>

  <comment>
    ==========================================================================
    === Main-Root
    ==========================================================================
  </comment>

  <comment>
    ===== /uio3.com/de/@uio3/(RootNode)
  </comment>
  <route-keys>
    <SiteRootFILESegmentKey>@uio3__PUBLIC__DE</SiteRootFILESegmentKey>
    <SiteRootFILESegmentIndex>A010</SiteRootFILESegmentIndex>
    <SiteRootCanonicalURISegmentKey>@uio3</SiteRootCanonicalURISegmentKey>
    <SiteRootAlternativeURISegmentKey>@uio3</SiteRootAlternativeURISegmentKey>
    <registerRootNode/>
  </route-keys>

  <route-keys>
    <SiteBranchFILESegmentKey>portal__DE</SiteBranchFILESegmentKey>
    <SiteBranchFILESegmentIndex>A100</SiteBranchFILESegmentIndex>
    <SiteBranchCanonicalURISegmentKey>portal</SiteBranchCanonicalURISegmentKey>
    <SiteBranchAlternativeURISegmentKey>portal</SiteBranchAlternativeURISegmentKey>
    <registerBranchNode/>
  </route-keys>
  ...
</doc>

Erläuterung

doc

Für die Deklaration von Routen sind Segmente von URIs im URI-Segment-Pfad zu bestimmen: SiteContext, SiteRealm, SiteRoot sowie bei weiteren Segmenten dann SiteBranch, SiteSection, SiteTopic und SiteAspect.

Das erste Segment bei der Adressierung wird als 'SiteContext*URISegmentKey' bezeichnet, wobei wir zwischen Canonical- und Alternative-Keys unterscheiden.

Der Canonical-Key ist derjenige, welche diejenige Adresse spezifiziert, welche von Suchmaschinen erfasst werden soll.

Der Alternative-Key sind optionale weitere Alias-Angaben für URIs. Damit ist es möglich, eine WebPage in UDS mit durchaus 20 verschiedenen URIs zu definieren. Maßgebend hierbei ist zuerst einmal, dass nur genau einzige Adresse als Canonical-URI-Key bestimmt wurde.

Die in UDS v.1.5.2.x gängige Variante der Definition von Routen besteht darin, nicht vollständige URIs zu definieren sondern immer nur Route-Keys für den aktuellen Node. Damit wird es möglich, eine Konfiguration für das übergeordnete URI-Segment übernehmen zu können und z. B. für eine Verkettung von Context, Realm und Root anschließend mehrere Branches definieren zu können; die Konfiguration von Context, Realm und Root wird hierbei von darüber liegenden Deklarationen übernommen.

Wird allerdings ein RootNode überschrieben durch eine neue Deklaration eines Route-Key, gilt das anschließend für alle weiteren Deklarationen. Wird nun hierbei ein RealmNode neu definiert, wird auch der zugehörige bisherige RootNote gelöscht. Will man also nun für den neuen Realm auch einen Branch definieren, muss man zuerst einen zugehörigen RootNode definieren.

Zusammenfassend: Die Reihenfolge der Node-Typen muss immer eingehalten werden. Context, Realm, Root, Branch, Section, Topic, Aspect.

Code-Beispiel

Dsa nachfolgende Beispiel zeigt die Definition von Routen für das UIO3 Portal.

Ein Sonderfall ist die Verwendung von route-Elementen für die Adressierung Seiten wenn nur der Context-URI mit de oder en oder auch nur ein Realm-Key wie @uio3 angegeben wurde.

In diesem Fall werden URIs über die Definition eines regulären Ausdruck erkannt. Beispiel: ^@uio3(?:\/$|$)