UDS ist ein System. UDS besteht also nicht nur aus Software und ist damit nicht nur irgendein weiteres x-beliebges Redaktionssystem oder CMS sondern umfasst in seiner Gesamtheit auch Guidelines, Arbeitsanweisungen, Bewertungskriterien für Entscheidungsprozesse und andere Informationen, welche zwingend von Menschen erbracht werden müssen.

Wir haben nicht den Anspruch, dass Sie UDS komplett verstehen geschweige denn selbst mit UDS arbeiten und es als Verfahren einsetzen können. Uns geht es primär darum, dass Sie verstehen lernen, dass es einen Unterschied zwischen einem Systems, was mitunter eine Software enthalten kann, und der eigentlichen Software im Vergleich zu anderen Softwareprodukten einen Unterschied gibt.

Ein System umfasst stets auch den Menschen, und zwar in Bezug auf Informationssysteme nicht nur das Unternehmen, was irgendeine neue «Homepage» haben möchte sondern auch die Menschen, die das System, die Software, die Templates, die Funktionalität, IT-Sicherheit über die Jahre erhalten. Auch damit aber ist es noch nicht genug: Zu jedem System gehörten stets auch Schnittstellen zu denen, die es als Anwender oder Besucher oder Gäste nutzen.

Seien Sie sich bewusst, dass Informationssysteme nicht nur von Menschen oder irgendeinem Google Search Bot genutzt werden sondern auch über APIs durch andere Softwarelösungen sowie nicht zuletzt auch seit spätestens Herbst 2022 die KI verschiedener Anbieter, allen voran in 2022 ChatGPT.

Information, View, Control: In Anlehnung an das in der Software-Entwicklung bekannte und oft als MVC abgekürzte Model-View-Controller Paradigma besteht das idealisierte Ziel bei Informationssystemen darin, dass man jede Informationen nur ein einziges Mal erfasst und über einen Controller dann für verschiedene Nutzungsaspekte angepasste Ansichten als Views erzeugt.

Information: Jede Webseite, jeder Abschnitt, jeder Absatz, jede Überschrift, jeder Absatz, jeder Text, jedes Bild und auch jeder Link kann man als Information betrachten. Nur aber ein Teil dieser Informationen, die in einem System erfasst wird oder auch zwingend für bestimmte Nutzungsaspekte auch erforderlich sind, werden dem menschlichen Nutzer einer «Homepage» oder dem Download einer PDF-Version bereitgestellt.

View: Der Begriff „View“ bedeutet frei übersetzt „Ansicht“ und geht aber in der Informatik weit über das Prinzip der rein visuellen Darstellung hinaus: Ein sogenanntes „View“ ist im Datenbankdesign zuerst einmal ein Auszug an Informationen zum Zeitpunkt der Erstellung dieser Abfrage. Informationen in einem View können also längst 10 Minuten oder auch auch nur seit 100 Nanosekunden veraltet sein.

Ein gutes Informationssystem erzeugt nicht nur eine Variante von Views sondern bietet verschiedene Varianten von Views. So ist die sogenannte «Homepage» nur die mit HTML, CSS und JS für eine Darstellung im Browser zumeist für den Menschen gedachte Ausgabe von Informationen. Der Crawler einer Suchmaschine ließe sich auch nur mit Daten im LD+JSON Format beglücken. Softwarelösungen, welche über eine API kommunizieren, wollen wiederum über XML/SOAP, JSON oder über Sockets direkt über Byte-Streams im Binärformat kommunizieren.

UDS wurde nicht als x-beliebige weitere Alternative zu irgendeinem CMS oder Homepage-Baukasten sondern als Prototyp deshalb geschaffen, weil wir eigentlich parallel druckfähige Ansichten im DIN A4 Format, Folien als Alternative zu Powerpoint für Präsentationen und darüber hinaus noch eine webbasierte Ansicht wünschten, die sowohl im Browser für Desktop-Monitore als auch mit Smartphones funktioniert.

Object: Um über Zahlenwerte wie 1, 2, 3 oder Texte wie "Hallo Welt" sowie Listen wie [1,2,3,4] hinaus auch komplexere Werte als Daten erfassen zu können, gibt es in der Informatik sogenannte Objekte, englisch „Object“.

Ein Object hat üblicherweise einen Typ wie „Produkt“, v „Person“ oder eben auch in Bezug auf redaktionelle Daten dann „Aufzählungsliste“, „Bild“ oder „Menü einer Webseite.“. Alle Bezeichnungen werden üblicherweise mit englischen Begriffen formuliert, sind in einem Wort in CamelCase-Schreibweise zu schreiben und dürfen damit weder Sonderzeichen noch Leerzeichen umfassen. Eine Aufzählungsliste wird also z. B. je nach Nutzung und semantische Bedeutung eine „ItemList“ oder „UnorderedList“ oder ein „DataTree“.

Solche Objekte können diverse Eigenschaften haben; man bezeichnet diese in der Theorie der Objektorientierung als sogenannte „Attribute“ und in der eigentlichen Programmierung je nach Programmiersprache sowie auch bei Beschreibung von Datenstrukturen auch als „Properties“.

Für die Besserwisser unter uns: Bis 2020 führten viele Programmiersprachen nach dem Prinzip sogenannter „Decorators“ neue Features hinzu mit denen neben Annotations und Decorators auch Attributes ermöglicht wurden und in diesem Zusammenhang der Begriff „Attribute“ in der Programmierung auf einmal eine weitere Bedeutung bekam.

Wir sprechen in UDS, weil es fast immer um Daten- und Layout-Objekte geht deshalb von Objekten bestimmter Typen (statt Klassen in der Objektorientierung) und von Properties (statt von Attributen in der Objektorientierung).

Für eine Klassifizierung von Objekten eines gleichen oder zumindest ähnlichen Typs sprechen wir von Stereotype oder nur kurz Type im Sinne von Typen.

Mindestwissen: Maßgebend zum Verständnis ist zuerst einmal nur, dass man jederzeit Objekte definieren kann, ohne sich im Detail Gedanken über deren Klassifizierung oder die Ähnlichkeit oder Übereinstimmung mit anderen Objekten Gedanken machen zu müssen.

Ein Typ oder Stereotyp in UDS dient zuerst einmal semantisch und technisch dazu, einem Objekt überhaupt irgendeine Struktur und dieser einen Namen geben zu können. Ob es noch mehr Objekte dieses Typs geben wird spielt überhaupt keine Rolle, dh. wenn Sie unbedingt ein Objekt benötigen, was, die Geheimzahl 1234 und einen Namen wie „Mustermann“ kapseln soll, geben Sie dem Typ irgendeinen Namen wie „MeinTyp25“ und sorgen dafür, dass jeder Wert, den Sie speichern wollen, in diesem Objekt einen benannten Speicherplatz als Teil der Properties bekommt.

Der Unterschied zu einer klassischen Objektorientierung besteht darin, dass Type-Checks für Objekte nicht allein über Klassen und Interfaces sondern über Funktionen geprüft werden die man im Falle einer technischen Umsetzung in Java, C# oder PHP schlussendlich über Annotations als Decorators einer Klasse oder einem Interface zuordnet.

Wer es genauer wissen möchte: UDS ist nicht nur objektorientiert sondern in weiten Teilen auch semantisch objektorientiert.

Wir verwenden also durchaus für Stereotypes für die jeweiligen Proxies in PHP, JAVA, C# oder NodeJS je nach Sprache als durchaus auch Klassen einer auf Klassen, Interfaces, Enumerations und was diese Sprachen noch so zu bieten haben, aber man muss einfach eines wissen: Es gibt viele Varianten in Bezug auf die Theorie von Objektorientierung. Jede Programmiersprache setzt diese Konzepte etwas anders um. Das Primärziel von UDS aber ist kein Programm sondern ein Verfahren zu Formulierung von verteilten Dokumenten mit semantisch vernetzten Objekten.

In der objektorientierten Programmierung ist es üblich, dass jedes Objekt einen Typ hat. Man versucht also, Objekte zu klassifizieren und hat spätestens mit der Einführung C++ in 1986 sogenannte Klassen (engl. class) in die Programmierung eingeführt. Man spricht deshalb auch von einer sogenannten auf Klassen basierenden Objektorientierung und definiert in vielen Programmiersprachen Typen als class { }. Darüber hinaus kennt man auch in manchen Sprachen das interface, enumeration bzw. enum Typen, funktionale Interfaces, Annotations und vieles anderes mehr.

Wir wollen hier nicht in die Details gehen, denn das ist weder erforderlich noch ist es sinnvoll. So schön und praktisch diese klassenbasierte Objektorientierung auch sein mag: Sie ist eine Theorie und hat Ihre Stärken und auch Ihre Schwächen. Die Realität in der verbalen Kommunikation oder auch der Formulierung von semantischen Zusammenhängen lässt sich nicht immer in strikte Theorien pressen.

Als Serialisierung bezeichnet man die Umwandlung von Objekten und die von diesen kapselten Daten, die sich während das Programm läuft im Arbeitsspeicher RAM des Rechners befinden, in eine Serie und damit Abfolge von Bytes und damit Zeichen in eine Textform. Das Serialisierungsformat von Daten in solche Zeichenfolgen und damit ein Textformat, was von Maschinen und dem Menschenlesbar in Dateien gespeichert wird, ist im Falle von UDS der XML Webstandard.

Wer es genauer wissen möchte: Übliche Serialisierungsformate und damit die Textform zum Speichern objektorientierter Daten in Textdateien oder eben auch der Übertragung dieser Tagen durch simples Kopieren dieser Zeichenfolgen in Emails sind JSON (MIME Type text/json, JavaScript Object Notation, W3C Standard) sowie XML (MIME Type text/xml, Extensible Markup Language, W3C Standard). W3C Standard bedeutet, dass es sich um eine von allen Herstellern von Browsern sowie Programmiersprachen und nicht zuletzt Software akzeptierte Empfehlungen des World Wide Web Consortiums, W3C, handelt.

Der Begriff "Extensible Markup Language" bedeutet, dass es sich um eine erweitertbare Programmiersprache mit einer Syntax handelt, welche auf dem Prinzip von Markern basiert.

Das Prinzip in XML ist schnell zu versehen und noch schneller, wenn man schon HTML oder SVG kennt: Jedes (fiktive) Element mit dem Namen «Alpha» muss als <Alpha> begonnen und mit </Alpha> geschlossen werden. Wenn Elemente kein schließendes Element haben so wird das öffnende Element mit einem / am Ende wie in <Alpha/> direkt wieder geschlossen.

XML ist case-sensitiv, dh. Groß- und Kleinschreibung ist von Bedeutung.

Um gleichnamige Bezeichner für Elemente von verschiedenen Firmen verwenden zu können, nutzt man in XML wie in Programmiersprachen Namespaces, dh. zur Vermeidung von Verwechselungen könnte es also für „anton“ und „berta“ als Kurzbezeichnung für einen Namensraum die mit einem Namespace versehenden Elemente <anton:Alpha> und <berta:Alpha> geben.

Die meisten Elemente in UDS haben das Prefix <ce:*> als Abkürzung für UDS ContentElement oder <user:Alpha> und <custom:Alpha> für User- und Custom-Tags.

Egal, ob Sie sich im Code Notizen schreiben oder Code-Beispiele auskommentieren wollen: Das <comment> ist eine der ersten und wichtigsten UDS Code Komponente welche Sie kennen sollten.

Die Struktur von UDS Dokumenten und Komponenten wird in XML 1.0 Syntax formuliert. XML ist ein W3C Standard wie HTML, CSS, SVG und andere mehr. Wenn eine Komponente also beispielsweise eine Aufzählungsliste beschreiben soll so könnte das zugehörige UDS XML Element quasi <ce:Aufzählungsliste> heißen, wobei alle Komponenten englische Bezeichnungen haben wie in diesem Fall <ce:UnorderedList> oder <ce:OrderedList>.

Bei Layout-Elementen handelt es sich um Komponenten mit denen redaktionell Einfluss auf die Anordnung von Inhalten in einer Ansicht genommen wird. Die vermutlich bekanntesten Layout-Komponenten sind der Container <CEContainer>, die Zeile <CERow> und die Spalte <CECol> in Anlehnung an Bootstrap UI und andere UI Frameworks.

Übrigens: Diesen Komponenten fehlt bislang die Schreibweise mit dem ce: Namespace als Prefix da diese Elemente aus einer Zeit stammten, als UDS noch keine Namespaces verwendete.

Es gibt allerdings keine Vielzahl weiterer Layout-Elemente sowie auch wiederum Variationen, so könnten nicht nur mehrspaltige Layouts realisiert werden sondern auch auf- und zuklappbare Elemente wie zum Beispiel das <ce:Accordeon> oder verschiedene Listen wie <ce:UnorderedList> verwendet werden.

Manche Layout-Elemente stellen selbst ein Block-Element dar, dh. wenn mehrere Layout-Elemente nacheinander definiert werden so ordnen sich diese nicht nebeneinander sondern untereinander an, weil jedes Block-Element die volle sich ihm bietende Breite verwendet.

Andere Layout-Elemente orientieren sich bei der Anordnung wie im Falle von Spalten <CECol> am übergeordneten Zeilen-Objekt <CERow> und können mitunter, je nach Layout-Variation, auch nebeneinander dargestellt werden.

Bei Absatzelementen handelt es ich um UDS Komponenten als Container für mehrere Inline-Elemente dienen, selbst aber bei mehreren solchen Absatzelementen immer jede für sich die volle Breite des Layouts nutzen und damit untereinander dargestellt werden.

Die am häufigsten in der Redaktion eingesetzten Blockelemente sind Absatzformate wie <ce:Paragraph-02> und <ce:Paragraph-01>, Überschriften wie <ce:FluidHeading-04>.

Bevor Sie sich eingehender mit Components befassen beachten Sie bitte, dass diese Komponenten ein paar Voraussetzungen haben welche mitunter vorab oder ergänzend in anderen Sektionen dieser Webseite erläutert wurden.

Components Overview Components Overview

Ein Sonderfall in der Redaktion sind mitunter Bilder, Videos, Audiofiles und andere Medien.

Im Gegensatz zu normalem Text, der redaktionell in UDS XML Syntax in XML Files erstellt oder auch durch andere Skripts automatisch erzeugt wird, werden Bilder als mitunter ImageObject Elemente zwar ebenso als XML formuliert, doch die eigentlichen Daten für JPG- und PNG-Files oder auch SVG-Grafiken und dergleichen befinden sich in anderen Dateien deren Adresse über eine Eigenschaft der Komponente angegeben wird.

Hinweis: Bilder werden werden vom UDS Server im Rendering automatisiert geschnitten, komprimiert, um Wasserzeichen und Logos versehen oder auch sonst irgendwie bearbietet.

Eine Besonderheit von UDS XML besteht darin, dass es möglich ist, redaktionelle Inhalte nebst zugehöriger Layouts und Metadaten einmal als sogenannte Instanz zu erzeugen und diese eine Instanz an anderen Stellen zu referenzieren, um sich quasi eine Kopie dieser Inhalte zu beschaffen.

Dieses Prinzip kennt man mitunter in der Textverarbeitung als sogenannten Textbaustein. Beinhaltet die Formulierung von Informationen aber auch eine Sequenz von automatisiert ablaufenden Arbeitsschritten so spricht man bei Textverarbeitung auch von Makros.

Die Bezeichnungen in UDS XML orientieren sich an Begriffen in der Softwareentwicklung.

Objekte sind quasi Container für eine Gruppe von Schlüssel-Wert-Paaren, auch als Key-Value-Pair bezeichnet. Ein WebPage-Objekt kann beispielsweise als Eigenschaften name, title oder auch url, dh. auch wenn eine WebPage letztendlich ein Layout, einen WebPageHeader, eine Navigation, redaktionelle Inhalte und anderes mehr hat, so basiert das Prinzip grundsätzlich darauf, dass jede zu speichernde Information entweder ein Text (String) oder aber ein komplexer Wert und damit wieder ein Objekt ist.

Wenn man nur den Titel einer WebPage erfassen will so könnte dieser Beispielsweise Impressum lauten, dh. diese Zeichenfolge bezeichen wir in der Programmierung als String und in UDS als TEXT, zuweilen als <text lang="de">Impressum</text> angegeben. In diesem Fall ist der Wert also ein SimpleType und damit das, was die meisten Menschen schnell verstehen.

Bereits eine Aufzählung ist in der Redaktion aber der erste komplexte Wert, den viele von Ihnen längst kennen: Eine Liste ist hierbei ein Container für Listeneinträge welche wiederum der Container für einen Absatz sind, wobei ein Absatz wiederum schlussendlich ein Container für TEXT ist.

Immer dann, wenn etwas nicht nur einen einzigen Text umschließt sondern mehrere Key-Value-Paare so sprechen wir von ComplexTypes und damit auch von Objekten, auch zumeist als Instance bezeichnet.

Wenn etwas aber nur einen einzigen Wert als TEXT beinhalten kann, wie beispielsweise die Zuordnung der Zahl zu einer Variablern a im Mathematik-Unterricht oder "Maria" als Zuordnung zu einem Feld "Vorname", dann sprechen wir von einem SimpleType.

Die Realität in UDS XML sieht so aus, dass fast jede Informationen mehr also nur den TEXT-Wert umfasst, denn bereits das Datum der Erfassung, eine Zuordnung einer Farbe für Text, die semantische Auszeichnung eines Worts als Fachbegriff, <ce:DefinedTerm>Objekt</ce:DefinedTerm>, führt dazu, dass faktisch die gesamte redaktionelle Erfassung und Formulierung von Zusammenhängen in UDS XML objektorientiert ist.

Jede Information wird in UDS XML immer in einem Element erfasst, also z. B. <ce:Paragraph-02>Hallo</ce:Paragraph-02>. Besteht des Containers ausschließlich aus Text wie hier Hallo so könnte man beim ce:Paragraph-02 von der Eigenschaft, in welcher das in einem Paragraph-02-Objekt gespeichert wird, von einem SimpleType sprechen.

Will man das Wort Hallo aber stärker auszeichnen innerhalb des Absatzes, kann man die Werte im auf Text basierten XML-Markup verschachteln: <ce:Paragraph-02><ce:InlineStrong>Hallo</ce:InlineStrong></ce:Paragraph-02>.

Wer bereits mal altes HTML 3.2 gelernt hat wird sich hierbei an <p><b>Hallo</b></p> erinnern: Ein Absatz ist der Container für ein b-Element (bold=fett) welches dann den eigentlichen Text also sogenannten TextNode umschließt.

Nun besagt aber <b>Hallo</b> nur, dass etwas damals bold geschrieben werden sollte, nicht aber warum. Die Redaktion hat sich über die Jahre im mehr und mehr in Richtung Semantik verschoben, so dass man die semantische Auszeichnung für eine Betonung eines Begriffs mit HTML5 als <strong>Hallo</strong> zu bezeichnen begann, die eigentliche Gestaltung mit einer fetten Darstellung der Schrift aber an CSS auszulagern begann.

Das Problem: Will man nun Informationen erfassen, die sowohl ins Web gehen sollen als auch gedruckt oder als Grafik dargestellt werden können sollen, benötigt man für das eigentliche Rendering als Berechnung einer Darstellung plötzlich 3 verschiedene Ausgabeformate. Hierbei kommt hinzu, dass das Prinzip, einfach irgendetwas mit <strong>Hallo</strong> zu betonen, noch immer keinen wirklichen Grund angegeben hat, warum es denn betont werden soll.

In UDS XML werden Informationen als vom Redakteur also nicht visuell nach belieben irgendwie fett geschrieben oder angehübscht sondern semantisch korrekt ausgezeichnet, damit die Themes und Templates und Skins nebst Logik für eine visuelle Darstellung sorgt.

In UDS XML gibt es <ce:InlineStrong>Hallo</ce:InlineStrong> deshalb, damit man im Textg Hallo betonen kann. Ein <ce:DefinedTerm>Hallo</ce:DefinedTerm> bedeutet nun aber, dass es sich bei „Hallo“ um einen Fachbegriff handelt der im Text verwendet wird und damit für die Erfassung für die wiederum <ce:keywords>Hallo</ce:keywords> einer WebPage Bedeutung haben kann.

Wer schon einmal in einem Text-Verarbeitungsprogramm Briefe geschrieben hat, wird wissen, dass manche Redakteure wissen, wie man Felder für das Datum, die Seitenzahl und anderes mehr nutzen kann. Auch für UDS haben wir eine Reihe solcher Textbausteine, Felder und Funktionen.

Mit <ce:fn-getdate-year-actual/> kann man beispielsweise die zum Zeitpunkt des Renderns des Dokuments bzw. der Webseite aktuelle Jahreszahl ausgeben, also heute wäre der Wert hierfür dann 2026, und nächstes Jahr wäre der Wert 2027.

Solche Felder und Textbausteine, welche direkt mit UDS bereitgestellt werden, beginnen bislang mit dem ce:fn- und damit dem XML Namespace-Prefix ce: wie fast alle ContentElement Instanzen sowie dem fn- Prefix.

Das Prefix fn- für Die Bezeichner von UDS Komponenten ist die Abkürzung für „Function“.

Die Bezeichnung getdate orientiert sich an der typischen Bezeichnung von get- und set-Funktionen zum Abfragen und Setzen von Werten in der Programmierung, wobei es eigentlich dann getDate hätte heißen müssen. Um das Tippen von ce:fn- Feldern und Funktionen nicht noch komplizierter zu machen haben die gängigen Felder in UML XSL eine Kleinschreibung bekommen.

Elemente mit dem ce:fn- Prefix werden beim Rendern des Dokuments einer WebPage hier in das in das eigentliche aktuelle Datum des aktuellen Jahres übersetzt. Will man allerdings andere Jahreszahlen oder auch z. B. das Datum der letzten Änderung redaktioneller Inhalte haben, benötigt man andere Felder.

Und genau hier wird es nun auch spannend, denn die redaktionellen Inhalte, welche im Browser für eine WebPage angezeigt werden, sind eben nicht alle in einem einzigen Dokument für diese Seite geschrieben oder getippt worden sondern können über die Verknüpfung von Elementen und damit Daten- und Informationsknoten im Dokument auch aus anderen Dokumenten und auch anderen Servern geladen werden.

Eine eigentlich einfache Fragestellung, wann der File für eine WebPage zuletzt geändert wurde, ist gar nicht nicht so leicht zu beantworten, denn über die semantischen Verknüpfungen kann es passieren, dass der Code der eigentlichen Seite zuletzt vor 2 Jahren aktualisiert wurde, die aber beim Rendern zusätzlich automatisch eingefügten Änderungen können gerade erst vor 2 Sekunden aktualisiert worden sein.

Eine Webseite besteht bekanntlich nicht nur aus Texten: Man wünscht hier auch mal mehrspaltige Layouts, Tabellen, Links, Icons, Bilder oder auch komplere interaktive Elemente. Um hier das Rad nicht ständig neu erfinden zu müssen oder auch bestimmte Zusammenstellungen von Informationen gleich mit dem Layout dazu mehrfach wiederverwenden zu können, hat der Redakteur im UDS XML Format einige Möglichkeiten.

Das mitunter am häufigste Verfahren für die Wiederverwendung von Texten und deren Layout besteht in der Verwendung von <ce:ContentReference ref=".."/> Elementen welche auf Dokumente verweisen in welchen sich ein <ce:ContentInstance id=".."/> Element befindet.

Basierend auf diesem Prinzip bekommt der Redakteur die Möglichkeit, sich quasi Text- und Layout-Bausteine in einem Ordner innerhalb seiner Realm-Struktur als XML-File abzulegen und später für die Nutzung über dieses Verfahren zu referenzieren.

Wichtiger Hinweis: Wir empfehlen Ihnen dringend einen Three-Strikes-Out-Ansatz für identisch wiederkehrende Inhalte zu verwenden: Immer dann, wenn Sie redaktionelle Inhalte mit/ohne Layout nicht nur einmal oder zweimal sondern dreimal mit identischem Text und Layout verwenden, sollten Sie mit ContentReference und ContentInstance Elementen arbeiten.

Das gilt auch dann, wenn Sie erfahren, dass wir die Syntax dieser Elemente oder Parameter noch verändern werden. Basierend auf diesem Prinzip ist es sehr leicht, dass 1 Original zu finden/zu ändern und über die ID oder REF Adresse alle Referenzierungen zu finden.

NOCH NICHT IMPLEMENTIERT!

Der Blueprint-Ansatz, dt. Blaupause, basiert auf dem Prinzip von Konstruktionspläne und damit wiederum sogenannten constructor-Funktionen, wie man dies in der objektorientierten Programmierung kennt.

NOCH NICHT IMPLEMENTIERT! Beim Include-Ansatz gilt es zu differenzieren, zu welchem Zeitpunkt in der Verarbeitung das Einfügen erfolgt. Include-Anweisungen müssten also eigentlich als Teil eines PreProcessing erfolgen vor der eigentlichen Verarbeitung von Dokumenten. Da hierbei aber Rekursionen, Probleme mit Zugriffsberechtigungen, Latenzen und anderes mehr auftreten könnten, werden einige UDS XML Features hin Hinblick auf Include, Annotation, Decorators und weitere Aspekte noch diskutiert.

Die Anregung, dieses Prinzip über ein neues <ce:Include file=""/> vereinfachen zu können, ist naheliegend und wurde möglicherweise auch längst schon sinngemäß umgesetzt. Das Prinzip von include(..) aus PHP oder auch <xsl:include ../> bedeutet zuerst einmal, dass es für den Programmverlauf eigentlich egal sein müsste, ob der Quellcode oder redaktionelle Daten nun direkt in einer Datei geschrieben wurden oder aber über ein Include-Verfahren eingebunden wird.

In der Praxis im Rendering von Dokumenten zu Ansichten ist das aber ein himmelweiter Unterschied, denn zum Zeitpunkt des Lesens eines <ce:ContentReference ref=".."/> oder <ce:Include ref=".."/> Elements befinden sich deren XML Elemente dieser Dokumente noch gar nicht in dem Dokument, welches wir aktuell verarbeiten.

Würden wir also über Templates alle Fachbegriffe <ce:DefinedTerm>..</..> erfassten wollen, stehen wir vor einem Problem: Das Durchlaufen der Datenstruktur des Dokuments müsste auch auf die eingebundenen Dokumente bezogen werden, nur können die sich auf einem Server in Chile oder Australien befinden.

Ein INCLUDE-Vorgang müsste also am besten tatsächlich den entfernten UDS XML Code in Ihr WebPage Dokument eingefügt haben, bevor die Rendering-Engine das Dokument zu verarbeiten beginnt.

Zusammengefasst: Ja, wir wollen, dass Sie mit einer Art Text- und Layout-Baustein oder auch Blueprints arbeiten können, aber wegen des Unterschieds zwischen DeepClone-Kopien quasi für Zwillinge auf der einen Seite und aber ein Einfügen einer Referenz auf ein Originaldokument haben Sie bitte Verständnis dafür, dass wir für UDS XML für verschiedene Zwecke verschiedene Ansätze haben und vor einer Implementierung eines neuen Features dieses zuerst mal durchdenken, welche Folgen das Feature haben wird.

Die Besonderheit von UDS besteht darin, dass UDS XML Dokumente in der Formulierung von Dokumenten eben nicht nur die Formulierung von Layouts, Absätzen, Texte oder Referenzen auf Bilder beinhalten können sondern auch serverseitige und clientseitige Skripts sowie damit sinngemäß Makros.

Es ist also im UDS Design System möglich, redaktionelle Inhalte mit zugehörigem Layout über Skripts zu erzeugen oder aber auch den erzeugten oder geschriebenen XML Code zu verarbeiten.

Das von uns empfohlende Verfahren ist grundsätzlich die Verwendung von UML Komponenten welche von uns bereits programmiert wurden.

Die zweite Variante besteht darin, dass Sie User-XSL-Templates schreiben und über die CONF Ihrer Webseite im Realm speichern.

Die dritte Variante sind clientseitige Verfahren mit JavaScript mit den Sie den JavaScript Code für Komponenten als Teil der Redaktion programmieren. Nachdem Rendern des HTML Codes und darstellen im Browser wird hierbei auch Ihr redaktionell ergänzter JavaScript ausgeführt.

Eine Installation des UDS Core und damit der Software wird üblicherweise von einem Dienstleister administrativ erbracht. Wir befassen uns in diesem Abschnitt aber nicht mit UDS an sich sondern nur der Konfiguration, wie Sie einen neuen Realm, eine Webseite, die erste WebPage und eine RoutingDefinition anlegen könnten, falls Ihr Dienstleister mal ausfallen sollte.

Die erste Maßnahme, die Sie ergreifen müssen, ist das Anlegen eines Realm. Das Realm beinhaltet im Regelfall auch eine eigene RoutingDefinition für eine Adressierung relativ zum Root-URI-Pfad.

Bezogen auf den einfachsten Fall einer Webseite im Single-Pager Ansatz, wo Sie alle Inhalte und Bilder auf einer Seite anzeigen wollen, benötigen Sie einem Realm-Ordner, indem Sie Ihre Daten für die Seite speichern. Sie benötigen mindestens eine WebSite-Definition, um dann Ihre eine WebPage-Seite dieser WebSite zuordnen zu können. Und damit man diese Seite auch später über z. B. /willkommen adressieren kann, benötigen Sie mindestens einen Eintrag in der RoutingDefinition, damit im Zweifelsfall jedes Request bei Ihrer Startseite ankommt.

Wenn Sie in UDS XML allerdings die Informationsstruktur eines Internet- oder Informationsportals formulieren, haben Sie mehrere Hundert oder Tausende von Files. Wirkt komplex, aber keine Sorge: Rom wurde auch nicht an einem Tag gebaut.

Der englischsprachige Begriff Realm bedeutet Königreich und hat innerhalb von UDS auch in etwa eine ähnliche Bedeutung, wenn es um digitale Daten geht: Das Realm ist der Container für die verschiedensten Daten welche der Besitzer als quasi Regent seiner Besitztümer innerhalb des Realms deklariert hat und verwaltet.

<ce:Realm> Objekte lassen sich (Stand UDS v.1.5.2.90) noch NICHT als Teil der normalen XML-Dokument-Struktur wie andere Komponenten erfassen sondern stammen sind älter als diese Standards. Auch Realms können durchaus mit XML Files konfiguriert werden, aber deren Struktur und Verarbeitung weicht vom Rendering von WebPages etwas ab.

Eine entsprechende Änderung der Konfiguration von Realms über Realm-Dokumente ist aber in Planung, um kommende Konfigurationsparameter dort speichern zu können.

ce:Realm ce:Realm Syntax

Das <ce:WebSite> Element ist semantisch betrachtet dazu da, um einer WebPage als Einzelseite mitteilen zu können, ob diese mit anderen WebPages zur selben Webseite gehört. WebSite Elemente werden im Regelfall in eigenen Dateien zentral definiert und konfiguriert, um diese aus WebPage Dokumenten referenzieren zu können.

Das Dokument für eine WebSite definiert mitunter beispielsweise welches 'Theme' für das Webdesign verwendet wird oder welches Menü für die Navigation geladen werden soll. Im Kern geht es darum, dass man Informationen, welche bei einer WebSite schon deklariert worden sind, für die WebPage nicht mehr definieren muss.

Bislang werden WebSite Element über die Adressierung des zugehörigen Files referenziert. Damit ist es prinzipiell möglich und bedingt auch gewollt, den Speicherort von WebSite-Dokumenten flexibler wählen zu können.

ce:WebSite ce:WebSite Syntax

Das <ce:WebPage> Element ist eines der wichtigsten und am häufigsten in UDS verwendeten Elemente. Jedes <ce:WebPage> Element wird im Regelfall in einem eigenen XML Dokument formuliert. Dieser Ansatz dient dazu, dieses Dokument und seine Daten auch von anderen Seiten der Webseite adressieren und bestimmte Informationen über Templates auslesen zu können.

So ist es für Template Programmierer beispielsweise möglich, ein neues Content Element zu schaffen, welches die Überschriften einer anderen WebPage ausliest, um diese Liste dann z. B. visuell als Auszählungsliste darzustellen. Für so etwas sind eigentlich Menüs da, aber mit dem selben Ansatz ist es möglich, neue Teaser-Komponenten zu programmieren, welche bei Verlinkung von Seite /was/auch/immer sich eine Zusammenfassung oder auch ein Bild aus dieser verlinkten Seite zu laden, wenn denn der Redakteur dieser Seite das dort definiert hat.

ce:WebPage ce:WebPage

Die RoutingDefinition.xml Datei in einem Realm dient der Deklaration und Definition von Routen in Anlehnung an beispielsweise .htaccess oder Nginx Routen, wenn auch in anderer Syntax und anderem Konzept.

Die Voraussetzung dafür, dass ein Realm überhaupt geladen wird, ist eine Erfassung des Realm in der Konfiguration wie z. B. routing_config_REALMS.

RoutingDefinition Deklarationen können also vom Prinzip her auf mehrere Files aufgeteilt werden, indem man schlichtweg weitere Realm(s) anlegt.

Eine RoutingDefinition dient dazu, dass der UDS Core als Service in der Lage ist, eine Anfrage an de/uio3-docs/uds/components zu verstehen und dann wissen zu können, welches Dokument mit dessen Daten oder auch zusätzlich verknüpften Dokumenten und deren Daten herangezogen werden muss, um eine Ansicht im HTML Code zu erzeugen welchen dann der Browser dem Besucher der Homepage anzeigt.

Eine Webseite, die als SinglePager geplant und redaktionell gepflegt wird, hat oft nur zwei Einträge in dieser Definition. Ein Portal wie unsere Webseite kann aber auch Hunderte solcher Routen haben.

RoutingDefinition RoutingDefinition

FAQ Häufige Fragen und Antworten zu diesem Thema gehören zwar eigentlich auf die FAQ Seite, aber die folgenden Fragen beantworten wir gleich hier.

Das <ce:WebPageHeader> Element dient der Definition der Seitenkopfs eines <ce:WebPage> Elements und damit bezogen auf das Dokument, welche man im Browser dann als einzelne Seite einer Webseite sehen kann, den Bestandteil der Seite, wo sich zuweilen ein großformatiges Bild oder auch ein Carousel-Element befinden könnte. Viele bezeichnen das auch als Slideshow.

Die Konfiguration eines <ce:WebPageHeader> selbst ist eher einfach: Es wird schlichtweg innerhalb des ce:contents Element des ce:WebPage Elements angeordnet. Wie die meisten UDS XML Elemente verfügt auch das dieses Element über ein ce:contents Element in welchem Sie dann das ce:HeaderCarousel Modul mit der erwähnen Slideshow anordnen könnten.

Hinweis: Sie können ein großformatiges Bild auch auf anderem Wege in den Kopf einer WebPage integrieren, denn eigentlich reicht hierfür ein ce:ImageObject schon völlig aus. Der Sinn und Zweck von <ce:WebPageHeader> Elementen besteht aber in der semantischen Auszeichnung als HTML5 <header> Element im HTML Code: Suchmaschinen verstehen dann besser, dass die Inhalte dort Teil des Header und nicht der eigentlichen redaktionellen Inhalte dieser Seite sind.

Das <ce:WebPageMain> Element eines <ce:WebPage> Elements ist der Container für alle redaktionellen Inhalt und deren Layouts, genauer gesagt werden die Sections, Überschriften, Texte und dergleichen innerhalb des ce:contents Element von <ce:WebPageMain> erstellt.

Das <ce:WebPageMain> Element ist in erster Linie nur ein Container welcher bei HTML Code als Ausgabeformat beispielsweise als HTML5 <main> gerendert werden wird.

Es gibt redaktionell für dieses Element nicht viel zu tun: Man muss nur sicherstellen, dass man dieses Element und sein ce:contents Element hat, weil dort die eigentliche Redaktion der Sections dann erfolgen wird.

Wenn Sie also einen DEMO-File für ein WebPage Dokument als Grundlage für eine neue Seite kopieren, sollte dieses Element bereits vorhanden sein.

Das <ce:WebPageFooter> Element eines <ce:WebPage> Elements beinhaltet, wie man sich denken kann, dem Seitenfuß einer Seite. Dieser Seitenfuß beinhaltet oftmals Kontaktdaten, ein paar nützliche Links, möglicherweise Hinweise auf die neuesten Meldungen eines Blogs oder auch eine Fußzeile mit Link zum Impressum.

In den meisten Fällen ist es so, dass dieser Footer von allen WebPage(s) einer WebSite referenziert wird. Die Redaktion des Seitenfußes einer Seite erfolgt also in 99% der Fälle NICHT über jede einzelne WebPage sondern zentral über einen ContentInstance-File, der als Dokumment die Definition des eigentlichen Footers beinhaltet.

Der Footer von Webseiten und dmait auch das <ce:WebPageFooter> wird im Regelfall nicht vom Redakteur der redaktionellen Inhalte erstellt oder geändert sondern von dem Anbieter oder Service-Partner, der Ihren den UDS Core, Themes, Styles etc. konfiguriert, angepasst oder explizit für Sie programmiert hat.

Das <ce:HeaderNavigationModuler> Element wird in UDS v.1.5.2.x in separaten Files konfiguriert und dann bei den WebSite(s), in welchen das Menü angezeigt werden soll, über die Konfiguration des <ce:WebSite> Element konfiguriert. Da wiederum ein <ce:WebPage> Element einer WebSite zugeordnet wird, wird also das Kopfmenü allen WebPages dieser WebSite zugeordnet.

Es ist möglich, dass mehrere WebSite(s) in einem WebSite-Cluster das selbe <ce:HeaderNavigationModule> Element referenzieren und damit das selbe Kopfmenü haben werden.

Für den Fall, dass die Seitenstruktur für einen Themenbereich einer WebSite zu komplex und umfangreich wird oder auch quasi Kapitel von Themen nicht zusammenpassen, teilt man diese WebPages eben auf zwei WebSites (innerhalb der selben Domain) einfach auf, weist jeder WebSite im Cluster ein eigenes HeaderNavigationModule zu uns verknüpft für den User diese WebSites und deren WebPage(s) anschließend über ein <ce:HeaderNavigationCluster> Menü, zumeist ist es der vorletzte Menüeintrag mit einem Dropdown.

Hinweis: Der Begriff „WebSite“ bedeutet hierbei eine Gruppierung von WebPage-Elementen und damit WebPage-Dokumenten die als Einzelseiten einer WebSite gerendert werden.

Normalerweise geht man davon aus, dass jede WebSite eine eigene (andere) Domain hat oder zumnindest eine Subdomain gekommt. UDS arbeitet aber basierend auf URI-Pfad-Segmenten, kann also mehrere WebSites über URIs als Adresse differenzieren, auch wenn diese alle über die selbe Domain adressiert werden.

Beispiel: Statt www.example-fisch.com oder fisch.example.com setzt das UDS als System auf example.com/de/fisch und example.com/en/fish. Das gilt auch für Kombinationen von Leistungen und Orten wie wie Fisch+Hamburg zu example.com/de/fisch-hamburg, example.com/de/fisch/hamburg oder example.com/de/hamburg/fisch mit dem Ansatz von Root- und Branch-Keys im URI-Segment-Pfad.

HeaderNavigationModule Syntax HeaderNavigationModule Syntax

Als HeaderNavigationCluster Menü bezeichnen wir im UDS bislang einen Menüeintrag 1. Ordnung im Seitenkopf mit dessen Hilfe ein Panel mit 4 Spalten mit Menüeinträgen geöffnet werden können, welche auf die jeweiligen Abteilungen oder Leistungsbereiche des Seitenbetreibers verlinken.

Hierzu muss man wissen, dass manche Themen- und Leistungsbereiche oder auch Abteilungen dermaßen viele Informationen anbieten können, dass diese eigene WebSite-Strukturen innerhalb einer WebSite haben können.

Eine Abteilung, ein Themenblock oder auch ein Standort eines Unternehmens kann also eine WebSite in einem Cluster von Webseiten haben, welche ein eigenes Menü mit einer eigenen Menüstruktur hat.

Damit ein Besucher dieser Webseite innerhalb des Clusters aber auch sich zur Hauptseite des eigentlichen Unternehmens oder auch alternativen Themenblöcken oder Standorten bewegen kann, sollte ein solches Cluster-Menü geschaffen werden.

Ein Cluster-Menü wird einem HeaderNavigationModule dann hinzugefügt, wenn man mit UDS für eine Domain nicht nur eine WebSite realisieren möchte sondern einen WebSite-Cluster bestehend aus mehreren WebSites.

Beispiel: Die Beschreibung des UDS Uniform Design Systems innerhalb dieser Webseite hat ein eigenes Menü im Seitenkopf. Um auch auf andere Themenbereiche innerhalb des Clusters von WebSites zugreifen zu können, kann man über den zumeisten vorletzten Menüeintrag im Kopfmenü ein Dropdown öffnen, mit welchem man zu anderen Themenbereichen verzweigen kann.

Hinweis: Ein Cluster-Menü ist nicht zwingend erforderlich und kann auch reaktiviert werden für den Fall, dass man für eine WebSite so etwas nicht haben möchte.

HINWEIS: Die Zuweisung von Cluster- und Switcher-Menüs erfolgt als Nav-L2-NavMenu Eintrag wie andere Menüeinträge im Kopfmenü auch. Die Konfiguration des zugehörigen Dokuments mit der eigentlichen Definition der Menüeinträge von Cluster- und Switcher-Menü erfolgt aber in der ce:config der ce:WebSite.

Als HeaderNavigationSwitcher Menü bezeichnen wir, wie der Name schon erkennen können, ein Menü als optionaler Teil des Kopfmenü und damit des HeaderNavigationModule(s) über welches man eigentlich zu anderen WebSites umschalten (engl. to switch) können soll.

Das Switcher-Menü ist im Regelfall der letzte Menüeintrag im Kopfmenü, sofern es aktiviert wurde, und soll in der Praxis eigentlich dazu dienen, aus einem Cluster von WebSites auf einen anderen Cluster und/oder auch z. B. zu Sponsoren oder dem eigentlichen Betreiber von Webseiten, Portalen und dergleichen wechseln zu können.

Hinweis: Ein Switcher-Menü ist nicht zwingend erforderlich und kann auch reaktiviert werden für den Fall, dass man für eine WebSite so etwas nicht haben möchte.

HINWEIS: Die Zuweisung von Cluster- und Switcher-Menüs erfolgt als Nav-L2-NavMenu Eintrag wie andere Menüeinträge im Kopfmenü auch. Die Konfiguration des zugehörigen Dokuments mit der eigentlichen Definition der Menüeinträge von Cluster- und Switcher-Menü erfolgt aber in der ce:config der ce:WebSite.

Die Verlinkung des Logo erfolgt NICHT über das HeaderNavigationModule sondern über die ce:config der ce:WebSite. Das ist auch nicht weiter verwunderlich, denn das Logo ist Bestandteil der WebSite und/oder in der Hierarchie einer übergeordneten WebSite in einem Cluster von WebSites.

Dieses gilt auch für Style-Varianten und Theme-Varianten wie die Farbgebung im Farbenschema.

MenuItem(s): Die XML Struktur und damit auch die Objekt-Struktur von Menüeinträgen, welche einen Link beinhalten und damit nicht selbst ein Menü als Container für Links sind, ist bei allen solchen *-MenuItem Elementen identisch.

Ein ce:Nav-L2-MenuItem Element ist also ein Navigationselement auf Level 2 in der Menüstruktur welches in diesem Fall als MenuItem einen Link beinhaltet.

Da Menüs eine verschachelte Struktur mit 1. Ordnung, 2. Ordnung, 3. Ordnung, 4. Ordnung, 5. Ordnung haben können, können Dokumente mit Menüstrukturen für Einsteiger eine gewisse Komplexität annehmen, basieren aber im Grunde genommen immer auf dem selben Schema.

Fügt man einem L1 Element MenuItem(s) hinzu, müssen diese folglich den Level L2 haben. Da die Navigation allerdings ein Layout, Varianten von Farben je nach Themenbereich und dergleichen mehr haben wird, verfügt jedes Element, welches als Container für andere Elemente dienen kann, über ein ce:contents Element mit einem ce:items Element.

doc/SiteNavigationElement/properties/content/ce:HeaderNavigationModule/ce:content /ce:Nav-L1-MainNavigation/ce:content/ce:items/ce:Nav-L2-MenuItem.style="1"

Für einen Menüeintrag im Kopfmenü, welcher also kein Dropdown ist, definiert man das Element mit ce:label (Text der angezeigt wird) und ce:uri (absoluter oder relativer Link bezogen auf den Base-Pfad der Seite) wie folgt:

Tipp: Wenn Sie das XML Dokument zur Sicherheit einmal in einer IDE automatisch formatieren, werden Sie anhand der Einrückung die korrekte Verschachtelung und Struktur erkennen.

ce:NavMenu sind Elemente welche als Container für MenuItem Elemente des nächsten Levels dienen und sich deshalb von einem MenuItem als Link darin unterscheiden, dass ce:NavMenu Elemente über ein ce:toggle Element mit einer Label verfügen und vor dem ersten Link im Untermenü die Option bieten, hier eine Überschrift anzuordnen.

Um also z. B. für das Thema A nicht direkt einen Link zu erstellen sondern ein Untermenü zu bauen, über welches auch Sprungmarken auf einer Seite adressiert werden können, kann man statt eines MenuItem mit Level 3 auch ein NavMenu mit Level 3 anlegen und diesem in seine ce:item Elemente dann eine Headline der Stufe 4 und einen MenuItem der Stufe 4 plazieren.

UDS ermöglicht es also, dass ein Menü nicht nur Links auf Seiten umfasst sondern auch diese Struktur von Links in Menüs mit Überschriften, vertikalen Trennern (sogenannten Devidern) oder auch mit Absatzformaten erweitern kann.

Planung und häufige Fragen: Die Anforderungen an das UDS Uniform Design System stehen und fallen letztendlich ständig mit dem, was wir oder unsere Partner mit diesem Ansatz umsetzen. Ein One-Size-fits-all-Prinzip, was wir mit UDS und UDS XML Dokumenten verfolgen, hat also immer Vorteile sowie aber auch Nachteile.

Wenn jemand hört, dass wir in UDS auch 5 Menü-Ebenen abbilden, schütteln die einen den Kopf: „Unsere Homepage hat nur 1 Menü mit 5 Einträgen, wozu braucht jemand 5 Gliederungsebenen?“.

Wer es aber gewohnt ist, Fachbücher zu schreiben, der jammert dann, dass ihm oder ihr 5 Gliederungsebenen nicht ausreichend sind.

Die Anzahl von Gliederungsebenen mit Level L1 (Kopfmenü) bis L5 ist nur eine Option. Wer nur Links im Kopfmenü braucht hat eben nur MenuItem L1 Einträge.

Wer nun feststellt, dass er 6 Menü-Ebenen zur Abbildung benötigt, sollte sich daran erinnern, dass es Menschen sind, welche diese Menüs noch benutzen können müssen. Die meisten Menschen verstehen Menüs mit 3 Gliederungsebenen, wollen am liebsten welche mit 2 Ebenen, verstehen aber auch 4 Ebenen, wenn es visuell mit Panels und Überschriften gruppiert ist.

Da Sie aber jederzeit ein Buch einer Buchreihe, einen Themenbereich, Themenblock oder auch die FAQ und dergleichen in eine einzelne WebSite im Cluster mit eigenem Menü auslagern können, sind Sie faktisch in der Verschachtelungsstruktur in der Informationsarchitektur NICHT begrenzt.

Es ist uns bewusst, dass viele Homepages im SinglePager-Ansatz aus nur 1 Seite mit vielleicht+ 5 Sections bestehen: Willkommen, Services, ... und Kontakt. Das UDS Uniform Design System wurde dient dazu, auch Kapitelstrukturen mit 5 Gliederungsebenen und damit Kapitel mit der Nummer 1.3.2.2.1 abbilden zu können.

In der Realität hat ein Branch als Kapitel 1 eine Section mit Kapitel 1.1, ein Topic mit 1.1.1 und einen Aspect mit 1.1.1.1.

Um nun aber eine Buchreihe mit 3 Teilen abbilden zu können, benötigt man eine 5. Ebene. Will man eine Buchreihe mit 3 Teilen zum Themenbereich A und eine zweite Buchreihe zum Themenbereich B abbilden, wird man erkennen, dass man ggf. wiederum einen übergeordneten Bereich benötigt, der alle Buchreihen umfasst.

Das Denken in Kapiteln ist also irreführend bzw. bei vielen Daten- und Informationsstrukturen nicht mehr ausreichend. Maßgebend ist nur, dass Menüs in der Lage sind, die Seitenstrukturen in Teilbereichen visualisieren und nutzbar zu machen.

Wenn Sie Fragen haben sollten, ob man mit UDS eine bestimmte Struktur abbilden kann, nehmen Sie im Zweifelsfall Kontakt auf.

Style, DefaultStyle, Styling: Als Styling bezeichnen wir alle Maßnahmen, mit denen ein Style geschaffen wird. Ein Style ist hierbei ein Datenobjekt welches eine Reihe von Key-Value-Paaren als Beziehungen zwischen einem Variablennamen und einem Wert, einem Selektor und einer Zusammenstellung von Formaten oder aber auch einem Selektor mit einer Sammlung von Skripts und damit Programmcode dient.

Ein Style lässt sich im Prinzip zuerst einmal daran erkennen, dass man eine Veränderung der Konfiguration gegenüber des Original-Style vergleicht.

Das bedeutet sinngemäß, dass jedes Objekt, jede Komponente, jeder Text, jeder Button und auch sonst jedes Element, was irgendwie eine visuelle Repräsentation in einer Ansicht hat, eine Standard-Ansicht hat. Diese bezeichnen wir als DefaultStyle.

Als Theme wird üblicherweise eine Variante sowohl von Layouts als auch der zugehörigen Typographie und anderen Aspekten mehr verstanden in deren Folge die redaktionellen Inhalte zwar vom Prinzip her noch identisch sind, die gesamte visuelle Darstellung beispielsweise einer Webseite aber so anders aussehen kann, dass Sie den Eindruck haben, dass Sie die Webseite eines anderen Unternehmens aufrufen.

Basierend auf dem Grundprinzip im UDS Uniform Design System ist es so, dass XML Dokumente über XSL Templates (oder Alternativen) in HTML-Dokumente umgerechnet werden.

Ein Redakteur oder Content Manager, welche redaktionelle Inhalte pflegt oder auch neue Seiten und dergleichen anlegt, benötigt KEINEN direkten Einfluss auf ein Theme.

Ein Theme wird in der ce:config Konfiguration eines ce:WebSite Elements angegeben. Eine weitere Konfiguration in dem Sinn gibt es an diesem Punkt deshalb nicht, um den gestalterischen Wildwuchs verschiedener Redakteure zu vermeiden.

Themes können durchaus Varianten und Variationen bieten, damit beispielsweise die WebSite für den Standort Wiesbaden eines Unternehmens eine andere Farbgebung im Cluster der Seiten bekommt als der Standort Hamburg.

Entsprechende Variationen werden aber redaktionell nicht über das Theme selbst gepflegt sondern über die Konfiguration eines Skins für eben dieses Theme.

Siehe: Skin, WebSite.

Als Skin wird in UDS eine Variation der Farbgebung eines Themes verstanden. Redakteure definieren also nicht eigene Skins sondern wählen einen Skin-Code passend zu einem Theme aus. Die eigentliche Konfiguration dieses Skins erfolgt im Regelfall durch einen Designer oder Entwickler.

Ein Skin wird (wie auch das Theme) über die ce:config Konfiguration eines ce:WebSite Elements konfiguriert. Jede WebPage, welche mit dieser WebSite verknüpft wurde, bekommt als beim Rendern der Darstellung das gleiche Theme und Skin dieser WebSite.

Es ist prinzipiell möglich, auch Einzelseiten abweichend zu gestalten, indem User-PostProcessing-Templates programmiert werden. Wir empfehlen aber dringend, auf diesen Ansatz zu verzichten, und immer für diesen Fall dann ein separates ce:WebSite Elemente zu schaffen.

Da Sie auch mehreren WebSite-Elementen die gleichen Footer und auch HeaderNavigationModule-Instanzen zuweisen können, wirkt es für den Besucher so, als wenn die zwei Seiten zur selben WebSite gehören, nur nun doch andere Farbgebung haben.

Da Sie mit diesem Ansatz aber in die grundlegende Gestaltungskonzeption des UDS Uniform Design Systems eingreifen, bei welcher man davon ausgeht, dass alle Seiten der selben WebSite und damit eines Themenbereichs das gleiche Stilkonzept und Farbkonzept haben, sollten Sie sich ergänzend mit Style- und Layout-Varianten befassen.

Als Layout-Variant bezeichen wir das Prinzip bei welchem ein Redakteur für die visuelle Darstellung einer Komponente mitunter die Option haben könnte, dass eine Komponente verschiedene Layout-Varianten bietet.

Ein typisches Beispiel für dieses Prinzip kennt jeder: In einem zweispaltigen Layout wird immer links ein Bild und rechts ein Link auf einer Seite angezeigt; man spricht oft von Teasern.

Eine Layout-Variante könnte z. B. darin bestehen, dass alle Bilder immer rechts stand links sind oder auch die Reihenfolge Bild/Text von Zeile zu Zeile im Layout wechselt.

Die Komponente und auch das Layout nimmt also den selben Platz ein und hat auch die selben Farben wie vorher, aber das Layout wurde eben doch variiert.

Damit eine Komponente eine Layout-Variante bekommt, muss ein Designer diese quasi planen und/oder ein Entwickler die Templates dafür so programmieren, dass Sie die Layout-Variante über die Konfiguration in UDS XML angeben können.

Für den Redakteur ist das oftmals einfach:

Mit layout-variant="ABC" ergänzt der Redakteur an einer Komponente einfach dieses XML-Attribut und beschafft sich dann den zugehörigen Key, mit welchem die Variante referenziert wird. Diese Infos bekommen Sie von Ihrem Entwickler/Designer.

Als Skin-Variante bezeichnen wir eine Variation der Farbgebung. Das eigentliche Farbkonzept ist also eigentlich das gleiche wie vorher, aber möglicherweise wird die Abfolge von Farben bei der Variante verändert.

Der Sinn und Zweck besteht darin, dass Redakteure nicht aus Lust und Laune anfangen, irgendwelche Farbwerte oder Farbabfolgen zu definieren.

Die Entscheidung, wie diese Varianten und Variationen aussehen, plant üblicherweise jemand, der oder die das nicht zum ersten Mal macht.

Für die Redaktion oder das Content Management wird diese Variante dann über ein XML Attribut ausgewählt.

Mit style-variant="ABC" ergänzt der Redakteur an einer Komponente einfach dieses XML-Attribut und beschafft sich dann den zugehörigen Key, mit welchem die Variante referenziert wird. Diese Infos bekommen Sie von Ihrem Entwickler/Designer.

Die Syntax für die Konfiguration von Theme und Skin für ein ce:WebSite Element und damit alle WebPage Elemente, welche mit dieser WebSite verknüpft sind, verwendet statt einer Referenzierung eines Theme-Objekts hier eine ce:use-Syntax.

Die Suche nach dem Dokument, in welchem das Theme oder auch das Skin definiert wurde, erfolgt über den UDS Core automatisch.

Dieser Unterschied gegenüber der Konfiguration der Beziehung zwischen WebPage und WebSite ist darauf zurückzuführen, dass die Theme- und Skin-Deklarationen bislang (im Gegensatz zu fast allen anderen Daten) kein XML sondern Teil des HTML-, CSS- und JS-Code ist, in welchem Designer und Entwickler das Frontend für das Theme programmiert haben.

Sie können die Theme- und Skin-ID, wenn Sie neue WebSite(s) im Cluster anlegen, von den bisher für Sie beim Launch der Seite angelegten ce:WebSite Elementen übernehmen.

Ein Ausprobieren weiterer Theme- und Skin-IDs ist wenig zielführend, denn die IDS haben derzeit zwischen 8 und 32 Zeichen und funktionieren auch nur, wenn diese auf Ihrem Server installiert wurden.

Neue Themes sind komplex, aber neue Skins stellen Farbvariationen dar und können von Ihrem Dienstleister für UDS Core und UDS XML basierte Seiten, recht schnell erstellt werden, wenn denn über die Farbwerte Einigkeit herrscht.

Wenn Sie mehr zu Design-Aspekten erfahren wollen: Dafür gibt es in der UDS Dokumentation einen eigenen Themenbereich.

WebPageSection Elemente sind logische Abschnitte welche als Container für semantische Section-Elemente dienen. Klingt kompliziert, ist es im Grunde genommen auch, aber man kann es auch vereinfacht wie folgt beschreiben:

Eine WebPage als Einzelseite benötigt für die Inhalte, die sich in UDS im WebPageMain Element befinden und als main Elemente auch in HTML gerendert werden, eine Möglichkeit, mehrere Kapitel, Artikel, Blogeinträge einerseits vom Layout klar trennen zu können, andererseits wünschen Suchmaschinen auch eine semantische Trennung von der Bedeutung her.

UDS hat also sowohl Components für die visuelle vertikale Gliederung von WebPage-Dokumenten innerhalb von WebPageMain sowie aber zusätzlich auch Komponenten für eine semantische Struktur.

Alle redaktionellen Inhalte befinden sich innerhalb von ce:WebPageMain/ce:contents. Das entspricht also dem Prinzip wie auch in HTML, wo alle Inhalte sich innerhalb des main-Elements von HTML5 befinden.

Die visuelle vertikale Gliederung erfolgt hierbei basierend auf HTMLBODY_MAIN_CONTENT~ Komponenten. Hierbei handelt es sich im Schema um WebPageContent Container.

Will man zusätzlich auch semantisch eine Section schaffen, die in HTML zumeist als section-Element seit HTML5 gerendert werden wird, kann man vor einer Fortsetzung mit der Definition eines Layout-Containers ein ce:Section Element bzw. in alter Syntax CESection Element anordnen.

Wenn Sie möchten, dass der HTML Code bei einem Rendering eines ce:WebPage Dokuments auch section-Elemente aus HTML5 beinhaltet, nutzen Sie ce:Section Elemente in der Datenstruktur.

Wenn Sie das nicht wünschen so lassen Sie diese einfach weg.

Hinweis: SEO und Sections sind so ein ganz eigenes Thema. Mit Sections kann man semantisch mehrere Kapitel und damit Überschriften und Texte auf einer Einzelseite zusammenfassen. In der Praxis kann das aber auch bedeuten, dass die Bedeutung einer z. B. H3 Überschrift außerhalb einer Section höher ist als die innerhalb einer Section.

Der Algorithmus von Suchmaschinen ändert sich über die Jahre ständig, und natürlich ist er geheim.

Die Layout-Struktur in UDS wird eigentlich zumeist über ce:Container, ce:Row, ce:Col für Container, Zeilen und Spalten definiert, aber wir sprechen hier über die grundlegende vertikale Gliederung einer Seite.

Wer also beispielsweise in einem Abschnitt auf der Einzelseite ein Bild über die volle Seitenbreite im Browserfenster darstellen will, braucht also genau genommen gar kein Layout-Element und auch gar kein semantisches Element sondern könnte direkt das Bild innerhalb von ce:WebPage/ce:contents plazieren und den Code stark verschlanken.

Die Realität aber sieht so aus, dass Sie bei responsiven Seiten die Layouts doch etwas raffinierter responsive definieren werden müssen.

Tipp: Sie sollten die vertikale Struktur einer Seite immer so planen, dass der Besucher zumindest am PC einen vertikalen Bereich entweder ganz auf dem Monitor sehen kann und/oder aber Sie sollte dafür sorgen, dass der Nutzer anhand der Gestaltung (z. B. der Hintergrundfarbe) erkennen kann, ob er noch im selben Bereich oder schon im nächsten ist.

Mit HTMLBODY_MAIN_CONTENT_** oder auch ce:WebPageContent öffnen Sie einen neuen vertikalen Bereich. Wenn Sie den beginnen muss der bisherige vorher geschlossen worden sein, wie es in XML und auch HTML üblich ist.

Mit einem ce:Section haben Sie nun die Option, den Bereich als HTML SECTION kapseln zu können, wenn Sie das möchten. Denken Sie daran, eine SECTION aber auch wieder zu schließen.

Wenn Sie mehrere vertikale Bereiche mit der selben SECTION umschließen wollen, vertauschen Sie die Reihenfolge in der Verschachtelung.

Das CEOuterContainer Element ermöglicht nun eine weitere visuelle vertikale Untergliederung des Layouts. Dieses Elemente wurde primär dafür geschaffen, um die Hintergrundfarbe variieren zu können.

Im Theme und Skin von UIO3 UDS ist es so, dass wir die Graufärbung etwas verändern. Das ließe sich aber gestalterisch auch komplett anders realisieren.

CallToActionFinally Elemente sind Sections welche einen Call-To-Action-Button beinhalten. Bei CTA Call-to-Action handelt es sich um Hinweise an den Nutzer einer Webseite, hier einem bestimmten Links zu folgen, um eine Aktion wie z. B. die Nutzun des Kontaktformulars ausführen.

Man kann es auch als visuelle Kommunikation einer Handlungsanweisung oder Handlungsempfehlung beschreiben.

CallToActionFinally sind Sections welche am Seitenfuß plaziert werden. Die Redaktion erfolgt aber nicht je Seite sondern oftmals über die Referenzierung eines Files, in welchem das Element definiert wurde. Näheres hierzu entnehmen Sie der Erläuterung von ContentReference- und ContentInstance-Elementen in UDS XML.

Das Prinzip der Verwendung von ContentReference-Elementen für Sections bedeutet, dass Sie den XML Code von ce:WebPage Dokumenten, wenn diese mehrere Sektionen als vertikale Abschnitte enthalten sollen, auf mehrere Dateien verteilen können, indem Sie dort ein ContentInstance Element anlegen, in welchem Sie die eigentliche Section dann formulieren.

Mit diesem Ansatz verkürzten Sie nicht nur den Code innerhalb der Dokumente für WebPage Elemente wie RootNode, RealmNode und dergleichen sondern haben damit auch die Option, eine Section, welche Sie auf mehreren Seiten benötigen werden, zentral an einer Stelle nur 1x zu erzeugen, um diese dann immer aus den zig WebPage Elementen zu referenzieren.

Hinweis: Bitte prüfen Sie vorher, ob das Rendering der WebPage alle von Ihnen genutzen Komponenten rendert. So werden zum Zeitpunkt der Redaktion dieser Doku für die Erstellung von Fußnoten-Zusammenstellungen sowie auch PageAnchorLinks im Kopf der Inhalte entsprechende Elemente aus referenzierten Dokumenten noch nicht berücksichtigt.

SectionBreadcrumbTitle ist eine Section deren sperriger Name darauf hinweist, dass hier eine Brotkrumenpfad und der Seitentitel angezeigt wird.

Für /de/was/auch/immer zeigt diese Sektion also die Links für den Zugriff auf die Seiten /de/was/auch/immer, /de/was/auch, und /de/was an.

Hinweis: Zum Zeitpunkt der Redaktion dieser Doku ist geplant, diesen Typ der Section zukünftig automatisch einer ce:WebPage zuzuordnen, da es sich im Grunde genommen um einen Teil der Navigation handelt und dessen Inhalte automatisiert ermittelt werden können. Eine manuelle Anordnung des Elements und dessen Konfiguration je Seite ist also zukünftig nicht mehr gewollt, um Redaktionsverfehler zu vermeiden.

Das SectionOverview Elemente war ursprünglich dafür gedacht, dass es es mit einer redaktionellen Formulierung den Überblick über die Inhalte der aktuellen Seite liefert. Das SectionOverview ist also üblicherweise nach dem BreadcrumbTitle die zweite Sektion.

Wenn das SectionBreadcrumbTitle Element zukünftig automatisch plaziert wird, wird das SectionOverview Elemente damit die erste Section auf einer WebPage im ce:WebPageMain Bereich sein.

Das HeaderCarousel ist eigentlich ein Element welches im ce:WebPageHeader plaziert wird. Es ist aber möglich, dieses Elemente auch für eine visuelle Trennung von Sections innerhalb von ce:WebPageMain/ce:contents zu verwenden.

Mit diesem Ansatz ist es möglich, mehrere einzelne WebPages, welche vorher eigene Header hatten, als SinglePager für diese Rubrik zusammenzufassen.

Dieser Ansatz ist dann zu empfehlen, wenn Sie die Anzahl der Seiten Ihrer Webseite reduzieren möchten.

Sie sollten aber berücksichtigen, dass Bilder für diese Elemente relativ groß sind und damit die Datenmenge, die zum Endgerät übertragen werden muss.

Das JumpLanding Element dient dazu,in einem ce:WebPageMain/ce:contents Bereich eine Sprungmarke definieren zu können, welche man über einen Hashtag # wie z. B. #sprungmarke adressieren kann.

Im Gegensatz zu PageAnchor-Definitionen werden die Sprungmarken bislang nicht automatisch für eine Menüerzeugung erfasst. Das hat damit zu tun, dass manche JumpLanding-Elemente von außen nicht zwingend zu erkennen sein sollen oder auch nicht müssen.

Der am häufigsten genutzte Marker in UDS ist der #contentBegin Marker. Dieser wird zumeist aus den HeaderCarousel-Elementen im Seitenkopf adressiert, damit der Nutzer aus dem Kopf der Seite direkt zu redaktionellen Inhalten springen kann.

Im Gegensatz zu PageAnchor-Links haben JumpLanding-Adressen kein anchorID- Prefix.

Das RawXML oder auch CERaw Element dient dazu, direkt HTML- und CSS- und JS-Code innerhalb von ce:WebPage/ce:contents realisieren zu können. Das ist dann sinnvoll, wenn man neue Komponenten erst einmal im Original-Code testen will, bevor man die tatsächlichen Templates dafür schreibt.

Die Verwendung von RawXML und CERaw Elementen sehen wir nicht gern, denn es besteht das grundlegende Problem, dass dieser Code nicht die üblichen Prüfungen von Entwicklern, Designern oder auch automatisierten Prüfverfahren durchlaufen hat und/oder diese manche Fehler nicht erkennen können.

Man kann also mit einem Fehler in einem RawXML und CERaw Element nicht nur das Layout der aktuellen Page zerschießen sondern auch das Lesen und Rendern des Dokuments komplett verhindern.

Falls nun jemand meint, hier einen eleganten Hacking-Ansatz gefunden zu haben: Nein, den haben Sie im Grunde genommen nicht gefunden, denn das fehlerhafte Rendering einer Seite wird vom System durchaus erkannt, dh. der Server liefert dann statt dessen eine 404 oder andere Fehlerseite aus.

Merken sollte man sich zu diesem Element nur, dass es ein Weg ist, wie man auch mit Unterstützung durch einen Entwickler oder Designer, der für UDS Komponenten bauen kann, auch mal kurzfristig Elemente in eine Seite plazieren kann, für die es keine Komponente gibt oder auch niemand geben wird.

Hierzu gehört mitunter SVG Code für Grafiken, Diagramme oder auch besondere Icons und Piktogramme.

Es funktioniert aber auch mit JavaScript Code.

PageAnchor sind Sprungmarken in einer Seite welche gegenüber JumpLanding Elementen die Option bieten, dass diese im Menü im Kopf der Inhalte erfasst und verlinkt werden.

PageAnchorLinks ist die Bezeichnung des Menüs, welches die PageAnchor Elemente anzeigt, wenn diese denn das Anzeigen eines Links über einen Parameter erlaubt haben.

Das Element wird üblicherweise nach der PageDescription, die zukünftig PageIntro heißen könnte, angeordnet. Will an ein Menü aber nicht haben, kann man es auch weglassen.

Die PageDescription ist ein Element mit welchem ein einführender Text im Seitenkopf plaziert wird.

Wir bezeichnen das inzwischen auch als PageIntro. In diesem Zusammenhang soll das Element in der bisherigen Verwendung auch umbenannt werden, damit die eigentliche ce:PageDescription dem Meta-Tag in HTML für die description für Suchmaschinen dienen kann.

Abstract, Intro, Description: Drei kurze Absätze mit Inhalte zur Seite, aber alle haben eine andere Bedeutung. Auch das ist Semantik.

Das ce:Accordeon Element dient als Container mehrerer Panels welche über jeweils einen zugeordneten Button bzw. eine Schaltfläche geöffnet sowie auch geschlossen werden können.

Der primäre Sinn des Accordeon-Elements besteht darin, den vollen Umfang von redaktionellen Inhalten mit einer Höhe von 1-2 Units im Layout jeweils in einem Panel kapseln zu können, damit die gesamte Höhe einer Sektion, auch wenn diese 3 bis 9 solche Panels mit einem Button, sich in der ersten Ansicht auf die Höhe der Buttons reduziert, um Leser nicht komplett mit Text zu erschlagen.

ce:Accordeon | Beispiele ce:Accordeon | Syntax

Mit Hilfe des Box Elements lassen sich mehrere Absatzformate mit einem Kasten oder auch Rahmen umschließen.

ce:Box | Beispiele ce:Box | Syntax

Die BlockQuote Komponente dient für die semantische Auszeichnung und visuelle Darstellung von Zitaten, englisch „quote“ genannt. Im Gegensatz zu einem Inline-Zitat, welches ein Zitat innerhalb eines Absatzes auszeichnen soll, dient das BlockQuote-Element dazu, einen Block zu bilden.

Beispiel:

Syntax in Kurzfassung:

ce:BlockQuote type="Quote", ce:content
ce:BlockQuote type="Quote", ce:author
ce:BlockQuote type="Quote", ce:source

Hinweis: Zum Zeitpunkt der Redaktion des obigen Beispiels gibt es für diese Komponente nur eine Layout-Variante. Es sind aber weitere Varianten in Planung welche über einen renderer-Parameter verändert werden können.

Für noch individuellere Varianten verweisen wir auf die Option, eine User-PostProcessing-Template zu schreiben. Damit können Sie die visuelle Darstellung noch serverseitig nach dem ersten Rendering-Prozess umrechnen lassen.

Im Sinne von home >chapter>page haben wir mit <ce:BreadcrumbList/> für UDS ein Element geschaffen, mit welchem Redakteure bei Bedarf auch redaktionell einen sogenannten Brotkrumenpfad anordnen können.

Wir möchten darum bitten, das <ce:BreadcrumbList/> Element spärlich oder gar nicht zu verwenden, denn Elemente, welche der Navigation dienen, sollten gem. UDS grundsätzlich über das Design- und Navigationskonzept von ce:WebPage Dokumenten zentral geplant, entworfen und automatisiert realisiert einer Ansicht zugeordnet werden.

Der Pfad ( > uio3-docs > uds > components) für diese aktuelle Seite lässt sich, wie Sie sehen, als Inline-Element direkt in diesem Absatz verwenden. Alternativ kann man auch das Element in einem ce:Paragraph-02 Absatz verpacken und jeweils eine horizontale Linie voran- und nachstellen. Das sähe dann wie folgt aus:

> uio3-docs > uds > components

Die Pfad-Segmente sind tatsächlich im den korrekten Zielseiten verlinkt, auch wenn man der Standard-Darstellung nicht ansehen kann, dass es sich um Links handelt.

Automatisierung bedeutet, dass der UDS Core beim Rendern eines WebPage Dokuments im Grunde genommen ein Breadcrumb-Pfad auch natürlich serverseitig über Programmlogik hinzufügen kann.

Das CardDeck ist ein Container für Card-Elemente. Damit realisiert man so genannte Card-Layouts.

In einem Card-Layout werden mehrere Cards nebeneinander dargestellt. Das Layout sorgt dafür, dass alle Karten in einer Reihe die gleiche Höhe aufweisen.

Das CollapsibleJS ist ein ce:Collapsible Element, welches allerdings im Browser JavaScript verwendet. Dieses Verfahren ist allgemein üblich in fast allen UI-Frameworks wie Vue, Bootstrap und anderen und damit auch in UDS. Die Besonderheit ist allerdings die, dass UDS auch ein Collapsible hat, welches ohne JS funktioniert.

Das HTabsPanelGroup ist ein Container welcher redaktionelle Inhalte sind Panels erfasst und anschließend dieser Gruppe an Panels entweder darüber oder darunter ein horizontales Menü mit Buttons hinzufügt, damit ein Nutzer Panels auswählen und anzeigen kann. H steht hierbei für Horizontal.

Hinweis: Diese Komponente befindet sich noch (wieder) in der Entwicklung. Diese Komponente führt im Rendering auf Smartphones zu einem Problem: Da die Labels der Buttons zur Auswahl von Panels nebeneinander angeordnet werden, lässt sich bei sehr langen deutschen Begriffen als Name für ein Panel zuweilen schon der 3. Button nicht mehr darstellen bzw. nur noch durch horizontales Scrollen.

Diese Komponente wird noch realisiert werden. In der Zwischenzeit empfehlen wir aber alternativ die Nutzung von VTabsPanelGroup Elementen.

HTabsPanelGroup CollapsibleJS

Das StyledBox Element ist ein Container, dessen Zweck darin besteht, das, was er beinhaltet, mit einem gestalteten Rahmen zu umranden.

StyledBox StyledBox

VTabsPanelGroup VTabsPanelGroup

UnorderedList

UnorderedList

DataTree

UnorderedList

OrderedList

CodeSample

Das CodeSample Element dient in UDS dazu, im Text einen Ausschnitt aus einem Programm wie eine Variable, einen Funktionsaufruf oder ähnliches darzustellen und zugleich auch als Code in einer HTML Darstellung für den Browser semantisch auszuzeichnen.

Mit <?php> beginnt in PHP der Teil in einem Dokument welcher vom PHP Interpreter reparst und als Programmcode ausgeführt werden wird.

Hinweis: Aus redaktionellen Gründen wird der CDATA Block derzeit im Code-Beispiel mit zusätzlichen Unterstrichen _ geschrieben.

InlineLink

Mit Hilfe des ce:InlineLink Elements können Links im Text deklariert werden. Das Beispiel zeigt sinngemäß mit falscher CDATA Syntax, dass man auch Labels mit Sonderzeichen verwenden kann.

KeyboardKey

Das KeyboardKey Element dient in UDS XML dazu, einzelne Zeichen wie beispielsweise den Schrägstrich /, den Backslash \, doppelte Anführungsstriche " und einfache Anführungstriche ' oder aber auch andere Tasten wie RETURN, TAB, STRG und dergleichen als Tasten einer Computerstatur oder auch eines anderen Bedienfelds visuell im Text dazustellen.

Das darzustellende Zeichen kann in den meisten Fällen direkt als TEXT eingegeben werden.

Für alle Zeichen, welche als Sonderzeichen in XML eine Bedeutung haben, sind die Zeichen wie z. B. das [& Zeichen allerdings als CDATA Block einzugeben:

[<![ CDATA[ & ]] >

InlineLink

Der ce:OtherActionButton funktioniert genauso wie der übliche ce:ViewActionButton, hat aber im Regelfall eine andere visuelle Darstellung und semantisch auch eine etwas andere Bedeutung.

Während der ce:ViewActionButton der primäre Button ist, den ein Nutzer auch nutzen sollte, wenn er bestimmte zusätzliche Texte oder Bilder sehen möchte, dient der ce:OtherActionButton zumeist als Ergänzung für weitere sinngemäße Links.

Beispiel: Link auf ein bestimmte Produkt und Link zu einer Seite für den Support für das Produkt.

Ein ce:ViewActionButton Element ist ein Button den man redaktionell üblicherweise für Links dann angibt, wenn dieser Link nicht ein ce:InlineLink innerhalb eines Textes ist sondern ein einzelner Button oder auch Button als Teil mehrere Buttons oder auch einer Gruppe von Buttons sein soll.