Overview
Wenn man einem Einsteiger in UDS den Begriff Begriff WebPage, deren Syntax und den Sinn und Zweck nahebringen möchte, beginnt mit manchen Kandidaten die Diskussion zuerst einmal bei der Schreibweise: Warum soll ich denn WebPage statt Webpage schreiben?
Nachdem Sie dann die CamelCase-Schreibweise der Komponente
überstanden haben werden Sie sich noch mit dem Namespace
in der XML Notation anfreunden müssen: Sie müssen
tatsächlich <ce:WebPage>
schreiben.
Übrigens: Die Formulierung von Daten und Strukturen
in Programmiersprachen (und damit auch in UDS XML Syntax)
ist case-sensitive, dh. Sie schreibeweise muss auch
exakt <ce:WebPage>
lauten. Regelkonform denkende und arbeitende Menschen
sind hier klar im Vorteil.
Das <ce:WebPage>
ist eines der wichtigsten CEs in UDS: Mit diesem
Content Element ist es möglich, eine Einzelseite einer
Webseite zu definieren.
Damit ein solche Seite allerdings anschließend auch
im Browser adressiert werden kann, muss diese
<ce:WebPage>
Instanz noch mit einer
<Route>
in der <RouteDefinition>
verlinkt werden.
WebPage XML Structure
WebPage Elemente entsprechend Einzelseiten einer Webseite
Die UDS XML Struktur von <ce:WebPage>
Elementen entspricht
dem Standard-Aufbau der Daten von Komponenten in UDS:
Der Name des Elements wird in Camel-Case-Schreibweise
geschrieben und bekommt vor dem Namen mit
ce: den XML Namespaces für Content Element(s)
zugewiesen. Konfigurationen schreiben Sie in der
<ce:config>, und danach kann es in
<ce:contents>
mit der Redaktion schon losgehen.
Eine neue Seite einer Webseite lässt sich am leichesten mit UDS XML Code anlegen, indem Sie sich den Quellcode einer Muster-Seite von Ihrem Entwickler und/oder Designer geben lassen.
Wir bezeichnen einen solchen UDS-XML Code als UDS Blueprint, also eine Blaupause.
Struktur einer WebPage
<?xml version="1.0" encoding="UTF-8"?>
<doc
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://snewmedia.com/snm/uio3/specs/ce ce.xsd"
xmlns:ce="http://snewmedia.com/snm/uio3/specs/ce"
xmlns="http://snewmedia.com/snm/uio3/specs/default"
>
<ce:WebPage>
<ce:config>
<!-- Configuration -->
</ce:config>
<ce:contents>
<!-- Contents -->
</ce:contents>
</ce:WebPage>
</doc>
Erläuterung
doc
Das <doc>
dient nur als Container für andere Elemente, darunter
in diesem Fall einem <ce:WebPage>
Element.
Die zugehörigen Namespaces basierend hier auf einem SNEWMEDIA Standard. Sie haben vom Prinzip die Option, eigene CEs zu definieren.
ce:WebPage
Ein <ce:WebPage>
gliedert sich primär in zwei Bereiche:
<ce:config>
Definitionen sowie dem
<ce:contents>
Element als Container für die eigentlichen Inhalte
einer Webseite.
Konfiguration
<ce:config> Element
Das <ce:config> Element beinhaltet
die Konfiguration von Properties und damit von Eigenschaften einer
<ce:WebPage> Instanz.
Auf übliche Eigenschaften der Konfiguration wird gesondert eingegangen.
<ce:contents> Element
Das <ce:contents> Element ist der
Container für alle Inhalte dieser WebPage, darunter mitunter
den WebPageHeader, WebPageMain und WebPageFooter.
Auf die Details wird gesondert eingegangen.
URIs und Distributed Documents
Domains mit URIs und das Routing zu Dokumenten und Services
Damit eine WebPage anschließend auch über einen URI und damit eine Adresse für Ihre Webseite adressiert und angezeigt werden kann, müssen Sie eine zugehörige URI-Adresse in der RoutingDefinition erstellen, um dort diese Webadresse mit Ihrer XML Datei zu verknüpfen.
https://example.com/testinstallation/de/service/tea besteht als URL aus https://example.com als Aufruf der Domain mit SSL Verschlüsselung und einem URI welcher aus zwei Teilen besteht: Einem Context wie /testinstallation für den Fall, dass Sie den UDS Core Server mehrfach für die Domnain installieren, und dem eigentlichen de/service/tea URI.
Damit der UDS Core Server weiß, wo er das zugehörige Dokument für die WebPage mit der relativen Adresse de/service/tea finden kann, muss dem Server dieses über eine XML formulierte RoutingDefinition mitgeteilt werden.
Hinweis: Zum Zeitpunkt der Redaktion dieser Doku gibt es zwei Verfahren für die Definition von Einträgen im Routing. Das Verfahren wird allerdings bereits um eine parallele dritte Variante ergänzt, um nicht Dokumente über URIS zu adressieren sondern tatsächlich REST-konforme Endpunkte für Webservices zu schaffen, welche basierend auf dem HTTP Request für den URI für eine Seite dann das Dokument beschaffenb und rendern lassen.
Entwickler und Administratoren kennen dieses Prinzip: Man kennt es vom sogenannten Mounten von Ressourcen wie Festplatten auf entfernten Rechnern, damit Sie diese Ressourcen genauso adressieren und verwenden können wie Dateien auf Ihrem lokalen Rechner auch.
Der Sinn und Zweck besteht hierbei darin, dass die in UDS v.1.5.x adressierten XML Documents für Ihre WebPage-Definitionen im Regelfall noch im Realm auf dem selben Server lagen, wo der UDS Core mit dem HTTP Server installiert wurde.
Ab UDS 1.6.x.x können die zugehörigen Dokumente aber auch über URL Connections über HTTP Requeste von anderen Rechnern geladen werden.
Das bedeutet sinngemäß, dass Sie bislang die Zuordnung zwischen URI und einem XML File in der RoutingDefinition schlichtweg relativ in Bezug auf Ihren Realm-Ordner formulieren.
/Realm/{IhreKennung}/service/tea/Branch.xml
Auf die Besonderheiten in Bezug auf die Namensgebung von XML-Files für WebPages gehen wir gesondert ein.
RoutingTable Mindestwissen
Zum Zeitpunkt der Planung es UDS Uniform Design System(s) hatten wir ein Primärziel vor Augen: Wir wollten schlichtweg die Datenstruktur und Seitenstruktur von Webseiten für die Redaktion von Seminarunterlagen formulieren und hierfür einen Renderer programmieren, der uns diese leidigen Updates für Open-Source-CMS immer dann erspannt, wenn man für den Mist keine Zeit hat.
Die Besonderheit in der Konzeption von Datenstrukturen begann dahingehend damit, dass wir den URIs eine klare Struktur geben wollten, um damit bestimmte Knoten in der Informationsstruktur möglichst leicht an URIs erkennen und aber auch nach einem klaren Schema in der Bezeichnung von Files und der Struktur der RoutingDefintion verwenden zu können.
ContextNode und RealmNode
ContextNode: Der ContextNode sollte sich hierbei auf die die Adressierung eines Webservices beziehen, also damit dem Programm auf dem Webserver, welches den URI als HTTP Request bei einem Aufruf einer Seite mitgeteilt bekommt.
Im Zuge der Programmierung, weil es mal wieder schneller gehen sollte, haben wir allerdings ab Version v.1.5.2.x den Sprach-Parameter wie /de oder /en oder auch /cn für Chinesisch mit eben diesem ContextNode abgebildet.
Der ContextNode ist seit v.1.5.2 immer das erste Segment einer Adresse und damit entweder die Sprachversion wie /de, /en, /cn oder aber ein Key für eine Landing-Page.
Der RealmNode ist in der Informationsstruktur damit das erste WebPage-Dokument dessen URI-Segment-Key sich an Position zwei befindet, dh. /de/services hat /de als ContentNode-URI-Segment und /services als RealmNode-URI-Segment.
In der RoutingDefinition in UDS v.1.5.2.x geben brauchen Sie aber den ContextNode-URI nur 1x angeben.
Damit aber der Server weiß, was eigentlich bei
/ oder /de zu adressieren, obwohl sonst noch kein
Dokument als WebPage adressiert wurde, muss dem
Server mitgeteilt werden, aus welchem Realm er
die Startseite laden soll. Diese wird als
ce:WebPage XML Struktur in einem RealmNode.xml
File formuliert. Wenn das Realm also z. B.
example heißen
würde befindet sich der Code für die Startseite
im Regelfall in /Realms/example/RealmNode.xml.
Für die Sprachversion selbst gibt es keine Webseite.
Das hat damit zu tun, dass die RealmNode Seite
nur adressiert wird, wenn der Nutzer keinen URI Parameter
hat, so dass die Startseite als RealmNode zumeist
die Sprachauswahl als Startseite liefert.
Man definiert in der RoutingDefinition also zuerst den ContextNode, damit der erste URI-Parameter wie /de, /en, /cn oder aber auch /wunschkonzert ohne einen Sprachenschalter erfasst werden kann.
Im Anschluss definiert man den zugehörigen RealmNode. Dieser dient primär dazu, den obersten Ordner Ihrer Dokumentstruktur für alle Seiten anzugeben.
RootNode
Ein RootNode ist in der Informationstruktur gewohnt das ce:WebPage Dokument in einem RootNode.xml File.
Ein RootNode ist der Wurzelknoten für einen kompletten Themenbereich oder auch ein Standort oder eine Abteilung+ eines Unternehmens. Eine Adresse wie /de/services führt also in der einfachsten Fassung zu folgender Position der Datei:
/Realms/example/services/RootNode.xml
ce:config
Inhalte der Konfiguration
<ce:config>
<ce:name>ce:WebPage</ce:name>
<ce:title>ce:WebPage</ce:title>
<ce:description>ce:WebPage</ce:description>
<ce:isPartOf>
<ce:WebSite
ref="/Realm/uio3.com/_nodes/WebSite__@uio3__UDS_V24A.xml">
</ce:WebSite>
</ce:isPartOf>
<ce:language_key>de</ce:language_key>
<ce:author>T2M</ce:author>
</ce:config>
Erläuterung
ce:config
Das <ce:config>
Element dient als Container für die Definition von
werden für eine Reihe von Eigenschaften, über die jede
Webseite als Einzelseite einer Website verfügen sollte.
Wichtige Eigenschaften
Eine sehr wichtige Konfiguration ist der
<ce:isPartOf>
Wert. Dieser gibt die semantische Verknüpfung zwischen
einer ce:WebPage Instanz und einer zugehörigen
ce:WebSite Instanz als Gruppierungselement
an.
Status: alpha
Geplante Änderungen
Die Verwendung von ce:config und ce:contents ist für die meisten Content Elements, kurz CE, ein Standard seit UDS v.1.5.2.x und wurde auch rückwirkend für ce:WebPage Elemente geschaffen.
Für die Berücksichtigung einer Vielzahl weiterer Properties aus dem Schema wird auch das ce:WebPage Element um ein ce:properties Element erweitert werden, um eine typisierte Erfassung weiterer Informationen für eine semantische Verknüpfung ermöglichen zu können.
title
ce:title: Der Titel entspricht dem HTML TITLE Element. Dieser wird später in einem Browserfenster oben im Reiter im Browser angezeigt.
Diese Property gibt es auch in schema.org für CreativeWorks Instanzen.
Status: alpha
Der ce:title wird bislang ohne Typisierung und ohne Auswertung der Sprache erfasst.
Mit Einführung von ce:properties wird der Titel einer WebPage demnach als text-Element typisiert werden.
ce:name
ce:name: Dieses Element dient für eine Kurzbezeichnung dieser WebPage Instanz. Es handelt sich zumeist um einen verkürzten Titel.
Diese Property wurde geschaffen für LinkedData in Anlehnung an SchemaOrg.
Status: alpha
ce:description
ValueType: xs:string
ce:description: Die ce:description entspricht dem HTML META Tag für die description, welche in Google verwendet wird.
Die Eingabe des Wertes entspricht einem normalen String bzw. XML TextNode.
Auch in schema.org gibt es eine entsprechende Property im Falle von Thing Instanzen.
Status: alpha
Die ce:description Eigenschaft ist sehr wichtig weil diese im Suchergebnis in Suchmaschinen wie bei Google die Kurzbeschreibung von ca. 90-120 Zeichen beinhaltet.
Diese Description ist allerdings eigentlich auch eine Property im Schema für Thing-Objekte und müsste dahingehend mit Einführung von ce:properties auch als text-Wert typisiert werden.
ce:keywords
ValueType: xs:string
ce:keywords: Die ce:keywords Definition entspricht dem HTML META Tag für die keywords, welche in Google verwendet werden.
Die Eingabe des Wertes entspricht einem normalen String bzw. XML TextNode.
Auch in schema.org gibt es eine entsprechende Property im Falle von CreativeWorks Instanzen.
Status: alpha
Für die Keywords wurde inzwischen ein KeywordsPermutationModule programmiert, um nicht ständig alle Stichworte von Hand schreiben zu müssen.
ce:isPartOf
ValueType: ce:WebSite.ref
ce:isPartOf: Eine WebPage-Instanz ist immer Teil einer WebSite-Instanz. Das hat damit zu tun, dass Einstellungen für Theme- und Style sowie das Menü im Seitenkopf, der Footer oder auch das Logo über die WebSite als Gruppierungsinstanz definiert wird.
Diese Eigenschaft ist SchemaOrg entlehnt worden und dient für die Definition eines semantischen Zusammenhangs zwischen WebPage und WebSite.
Status: alpha
Ein Wert für diese Eigenschaft ist wichtig.
ce:contents
ce:WebPageHeader
Das <ce:WebPageHeader>
Element ist optional. Wenn es verwendet wird so wird hier
zumeist eine Slideshow im Seitenkopf definiert.
<ce:WebPage>
<ce:contents>
<ce:WebPageHeader>
<ce:config></ce:config>
<ce:contents>
<!-- Hier Slideshow -->
</ce:contents>
</ce:WebPageHeader>
<ce:WebPageMain>
<ce:config></ce:config>
<ce:contents>
<HTMLBODY_HEADLINE_010_Section_Breadcrumb_Title>
<Headline><text lang="de">ce:WebPage</text></Headline>
<Paragraph>
<text lang="de">ce:WebPage</text>
</Paragraph>
<Navigation>
<Continue>
<Link>
<text lang="de">de/uio3-docs/uds/components/WebPage#contentBegin</text>
</Link>
</Continue>
<AncestorUp>
<Link>
<text lang="de">de/uio3-docs/uds/components</text>
</Link>
</AncestorUp>
<Previous>
<Link>
<text lang="de">de/@snm/docs/cs/cs-overview</text>
</Link>
</Previous>
<Next>
<Link>
<text lang="de">de/@snm/docs/cs/cs-basics/cs-programmstruktur</text>
</Link>
</Next>
</Navigation>
</HTMLBODY_HEADLINE_010_Section_Breadcrumb_Title>
<ce:JumpLanding id="contentBegin"></ce:JumpLanding>
<HTMLBODY_MAIN_CONTENT_010_Section_Overview>
<!-- .... -->
</HTMLBODY_MAIN_CONTENT_010_Section_Overview>
<ce:ContentReference
uri="/Realm/example.com/_ContentInstances/cblock-CallToActionFinally-@***-create.xml"/>
</ce:contents>
</ce:WebPageMain>
<ce:WebPageFooter>
</ce:WebPageFooter>
</ce:contents>
</ce:Webpage>
ce:WebPageHeader
Das ce:WebPageHeader Element ist ein Container für alle CEs welche der visuellen Gestaltung des Seitenkopfs dienen. Hierbei kann es sich beispielsweise um eine Slideshow handelt.
ce:WebPageMain
ce:WebPageMain Element beinhaltet die eigentlichen
Inhalte einer ce:WebPage Instanz. Dieses entspricht
sinngemäß dem <main>
Element in HTML.
In diesem Element werden WebPageMainElement artige
Elemente definiert welche wiederum der Container
für <ce:Section>
Elemente sind welche schlussendlich das eigentliche
Layout mit <CEContainer>
und dergleichen beinhalten können.
ce:WebPageFooter
Das ce:WebPageFooter Element beinhaltet den eigentlichen Seitenfuß einer ce:WebPage Instanz.
ce:isPartOf