aiticon plant, implementiert und betreut Ihr OpenText Web Site Management Projekt.

Gemeinsame Geschichte

Bereits seit ihrer Gründung im Jahr 2001 ist die aiticon GmbH eng mit diesem CMS verbunden – allerdings trug es damals noch den Namen RedDot CMS. Dieser war so einprägsam wie passend, schließlich sind es rote Punkte, die hier all jene Stellen kennzeichnen, an denen Redakteur*innen Inhalte pflegen können.

Damals geradezu revolutionär an RedDot: Erstmals fand die Inhaltspflege auf einer Oberfläche statt, die beinahe exakt so aussah wie die zu publizierende Website – nur eben angereichert mit den besagten roten Punkten. So hat sich dieser Name bis heute in vielen Köpfen erhalten.

Neue Namen

2005 kauft der kanadische Software-Hersteller Hummingbird RedDot auf, bereits ein Jahr später übernimmt der ebenfalls kanadische IT-Riese OpenText alle Hummingbird-Aktien und benennt das CMS zunächst um in OpenText Web Solutions. Seit OpenText mit Vignette ein weiteres CMS ins Boot holte, trägt das, was wir als RedDot kennen, den Namen OpenText Web Site Management.

Strukturprinzipien

Namensänderungen hin oder her, seinem strukturellen Prinzip ist unser CMS treu geblieben: der Trennung in den Management Server (früher RedDot CMS) und den Delivery Server (früher RedDot Live Server). Unter anderem in dieser Zweiteilung liegen die großen Möglichkeiten des Systems – gesetzt den Fall, man weiß, was man tut.

Im Management Server bauen die Redakteur*innen die Navigationsstruktur der Seite auf, entwickeln die Content-Klassen (Templates), also im Grunde die "Bausteine" des Systems, und pflegen die Inhalte. Der Management Server publiziert diese Inhalte dann in den Delivery Server. Dieser ist es, der die Seiten an die Nutzer, die Besucher im www, ausliefert.

Dynamik im Spiel

Der Management Server publiziert grundsätzlich statische Seiten, und das ist eine Einbahnstraße: der Delivery Server kann nicht "on demand" Inhalte aus dem Management Server abrufen – was unter Performance-Gesichtspunkten und aufgrund der eben beschriebenen Vorteile der Trennung ohnehin kontraproduktiv wäre.

Was nun aber, wenn der Betreiber einer Website dynamische Inhalte wie eine Volltextsuche, Datenbank-Inhalte oder auch Inhalte aus Dritt-Applikationen einbinden möchte? Und was, wenn er diese nativ in die Seite integrieren möchte und nicht über Umwege wie Iframe - und alle damit verbundenen Nachteile? Schließlich ist es absurd, dass der Management Server etwa Ergebnisse für jede denkbare Kombination an Suchbegriffen bereitstellt.

Die Lösung sind dynamische Steuerelemente namens Dynaments (im Falle des Delivery Servers) oder Taglets (so heißen sie bei appNG). Einmal eingebaut, teilen sie dem System mit, auf welche Art und Weise die Seiten zu dynamisieren sind. Kontaktformulare mit direkter Validierung, Newsletter-Anmeldungen inklusive automatisierter Bestätigungs-Mails, Integration von Datenbankinhalten mit Such- und Sortierfunktion – solche und auch weit komplexere Szenarien lassen sich dadurch abbilden.

Von Dynaments und Taglets

Dynaments und Taglets stellen die Dynamik nicht im Management Server her, sondern erst nach der Publizierung, also im Live-System. Sie sind wesentlich flexibler, da sie nicht den Beschränkungen des Management Servers (die, durchaus sinnvoll sind) unterliegen. So werden auch Funktionen wie nachträgliches, automatisches Beschneiden von Bildern für die jeweils gewünschte Ansicht möglich, aber auch Funktionalitäten wie Facetted Search, Suggested Search, integrierte Produkt-/Rezeptdatenbanken, in der Tat jede beliebige Art von Dynamik.

So können in eine vom Management Server publizierte Webseite komplexe Web-Anwendungen nativ integriert werden – und eben doch mit aus dem Management-Server publizierten Inhalten interagieren. Sämtliche Textinhalte einer zu integrierenden Drittanwendung werden im Management-Server gepflegt, während die eigentliche Geschäftslogigk nach wie vor durch diese Drittanwendung abgebildet wird.

Applikationen, welche Delivery Server- oder appNG-seitig in die publizierte Seite integriert werden, können also von Redakteur*innen im Management Server parametrisiert werden. Dadurch können sie Einfluss auf das Verhalten der Anwendung zur Laufzeit im Live-System nehmen.

Neue Funktionen

Natürlich geben Management Server und Delivery Server den großen Rahmen an Funktionalitäten vor, beide bieten jedoch über Schnittstellen die Möglichkeit für Erweiterungen – die wir auch intensiv nutzen.

Über die RQL (RedDot Query Language) haben wir den Management Server um zahlreiche Funktionen erweitert, zum Beispiel semi-automatische Migration von Inhalten aus bestehenden in neue CMS-Projekte oder auch die verschiedensten Assistenten, die den Redakteur*innen durch die Pflege der Inhalte führen und ihnen "überflüssige", das heißt automatisierbare Klicks abnehmen. Per RQL können auch Dritt-Applikationen wie z.B. appNG an den Management Server angebunden werden.

Die Delivery-Server-Schnittstelle OpenAPI (es handelt sich hierbei, anders als der Name glauben macht, um eine proprietäre Schnittstelle) hat uns beispielsweise unser eigenes Tool zum URL-Beautifying ermöglicht, ebenso wie ein umfangreiches Formular-Framework. Hier ermöglichen wir es den Redakteur*innen, Formulare im Management Server mit einfachen Mitteln zusammenzustellen, der Delivery Server übernimmt dann Validierung und Weiterverarbeitung der Formulareingaben.

Unsere Erfahrung, Ihr Nutzen

Umfangreiche Erfahrung in der Web-Entwicklung mit OpenText Web Site Management, gepaart mit unserem Know-How in der Software-Entwicklung sowie im IT-Betrieb, ermöglichen uns, diesem vielseitig nutzbarem System zur vollen Geltung zu verhelfen – zum maximalen Nutzen für unsere Kund*innen.

Das klingt interessant? Hier können Sie uns direkt kontaktieren: