ixCMF V5: Entwicklung eines allgemeinen CMS

Eine berechtigte Frage meiner Kunden zur Weiterentwicklung von ixCMF ist die, wie ich denn das Thema einer allgemeinen Menüverwaltung angehen werde, das ja auch in anderen CM-Systemen seine Tücken aufweist. Interessiert sind manche Kunden auch an weiteren Layout-Möglichkeiten im Rahmen einer allgemeineren Seitenpflege.

Zwar ist es heute in den aktuellen ixCMF-Applikationen bereits möglich, die Webseiten von speziellen Applikationen wie etwa "Leistungsangebot", "Team", "Veranstaltungen", "Aktuelles" nicht nur inhaltlich, sondern auch bzgl. des Layouts kreativ zu pflegen. Aber all diese Applikationen sind in gewisser Weise gekapselt. So fehlt hier noch der Schritt hin zu einer allgemeinen Pflege beliebiger Webseiten.

Solch allgemeinen Seiten einer Web-Präsenz sind zudem mit viel allgemeineren hierarchischen Menüstrukturen zu verzahnen, als dies im Moment im Rahmen der Spezialapplikationen der Fall ist. Vor allem auf dem Weg zu einer allgemeinen Pflege und Generierung von Menühierarchien sind substanzielle Herausforderungen zu bewältigen. Dies gilt auch dann, wenn man in Betracht zieht, dass die Version 4.2 für einige zugehörige Applikationen bereits eine eigenständige (Sub-)-Menügenerierung und Steuerung anbietet bzw. im letzten Fall anbieten wird.

Realisiert ist dies z.B. für die Applikationen

  • "Leistungsgruppen/Einzelleistungen" (mit und ohne zentralem Katalog)
  • "Team",
  • "Stellenanzeigen 2"

Ja, wie gehen wir dieses komplexe Thema also an? Zunächst gilt es, einmal festzuhalten, dass ixCMF in der aktuellen Version 4.2 ganz gut auf die Herausforderungen vorbereitet ist:

Ausgangsbasis - Was geht denn alles schon in der Version 4.2 ?

Über ixCMF in der Version 4.2 sind wir in der Lage, folgende in diesem Zusammenhang relevante Dinge zu realisieren:

  • Wir können mehrfach verschachtelte Master-Detail-Applikationen ("MD-Applikationen") über eine konsistente Web-Oberfläche verwalten. Grundlage ist das MD-Schema-Objekt, das Arrays aus Schema-Objekten für die über MD-Beziehungen zusammenhängenden Applikationen bereitstellt.
  • Wir können den Core-Objekten der ixCMF-Applikationen pro Webseite mehrere Objekte von Bild-, PDF- oder Sound-Repositories zuordnen.
  • Wir können auf der Basis der erfassten Daten-Objekte passende Webseiten generieren und über diese Seiten jede Ebene der MD-Applkations-Hierarchie in eine vorhandene Menüstruktur einklinken. Oder die Seiten der Spezial-Applikatione steuern über Listen und Einzellinks ihre Seitenaufruf-Logik selbst und unabhängig von anderen Site-Menüs.
  • In bestimmten Applikationen kann die mehrstufige MD-Hierarchie bereits auch als Menüstruktur generiert und in entsprechende Seitenbereiche eingebunden werden.
  • Seit der Version 4.1 sind wir auch in der Lage, die Objekte zweier verschiedener MD-Hierarchien in einzelnen Applikationen über das sog. MDX-Objekt zusammenzubringen und zu kombinieren. Das MDX-Objekt repäsentiert dabei über Schema-Objekte die externe Master-Detail-Hierarchie im jeweiligen Programm zur Behandlung der Objekte einer aktuell gewählten MD-Hierarchie.
  • Webseiten einzelner oder auch mehrerer hierarchisch untereinander abhängiger Spezial-Applikationen können bereits heute sehr kreativ gestaltet werden. Es stehen Textblöcke auswählbarer Template-Grundstrukturen bereit, 3 Bilder können relativ frei skaliert und positioniert werden. 3 weitere Bilder sind in Textblöcken positionierbar.
  • Bestimmte Textformatierungen (bold, italic, Listen, Links, header) können in Form von BB-Codes vorgenommen werden. Ein Checker sorgt für die Überwachung der in ixCMF bislang zulässigen, pflegbaren BB-Tag-Hierarchien.

Damit sind viele Zutaten für die erforderlichen Schritte zu einem allgemeineren CMS vorhanden.

Was ist so vertrackt an Menüsteuerungen in CM-Systemen?

Betrachtet man Menüs naiv, so kann man sie als hierarchische Baumstrukturen begreifen, deren Zweige in eindeutiger Weise mit zu pflegenden Webseiten verbunden werden.

Ganz so einfach ist das aber leider nicht. Unsere Praxis zeigt:

  • Wir sprechen nicht über einen Menü-Hierarchiebaum. In realen Webseiten gibt es oft mehrere, voneinander unabhängige Menübäume.
  • In vielen Sites kommt es vor, dass eine einzelne Webseite mehreren Menü-Blöcken zugeordnet sein kann. Ein klassisches Beispiel ist die Seite Kontakt.
  • Einzelne Menü-Punkten müssen auch externen Adressen zugeordnet werden können.
  • Etliche Menü-Blöcke auf einer Webseite sind nach bestimmten Regeln mit Daten zu füllen, die von speziellen Web-Applikationen in Datenbanken verwaltet werden und nun in den Prozess der Seiten- und Menü-Generierung einzusteuern sind.
  • Manche Menüpunkte müssen auf interne und externe Applikationen verweisen können, die untergeordnete Sub-Menüs selbst (!) und nach eigenen Regeln erzeugen und mit Datenbankinhalten füllen.

Es ist also keineswegs so, dass Links einer Menü-Hierarchie nur eindeutig mit einzelnen pflegbaren Seiten verbunden sind. In einem breit angelegten CMS muss es vielmehr eine Vielzahl von Möglichkeiten zur Behandlung von hierarchischen Menüblöcken und deren Links geben:

  1. Eine spezielle Pflege-Applikation für Menüs muss mehrere Hauptmenüblöcke und deren Link-Hierarchie erfassen können. Dabei sind logisch unterschiedliche Typen von Links zu unterstützen.
  2. Man muss definierte Links eines Menü-Blocks auf frei definierbare Adressen lenken können und nicht nur auf die im CMS erfassten und dort pflegbaren Webseiten.
  3. Die Kontrolle über den Inhalt bestimmter Menüblöcke muss vollständig an Spezialapplikationen abgegeben werden können, die bestimmte Daten nach eigenen Regeln einsteuern.
  4. Und last but not least muss es natürlich auch möglich sein, einzelne im CMS pflegbare und hinterlegte Web-Seiten bestimmten einzelnen oder auch mehreren Menüpunkten zuzuordnen.

Was bedeuten diese Forderungen? Aus meiner Sicht ergeben sich folgende Schlussfolgerungen:

Forderung 1: Man muss unterschiedliche "Kategorien" an Links in einer Menü-Hierarchie verwalten können. Dies ist eine Anforderung an die Erfassungs- und Pflege-Applikation für Menüs.

Forderung 2:Webseiten zerfallen in zwei Klassen: Einerseits solche, die über Spezial-Applikationen gepflegt werden, wie sie ixCMF schon seit langem bereitstellt. Andererseits in solche, die im CMS als unspezifische Einzelseiten erfasst werden und deren Inhalt frei definierbar ist.
Der Unterschied besteht vor allem darin, dass in speziellen Web-Applikationen auch spezielle Attribute von unterschiedlichen fachlich erforderlichen Objekten zu erfassen sind. Zudem werden in Web-Applikationen spezielle Beziehungen zwischen unterschiedlichen Objekten im Sinne einer Geschäftslogik behandelt.
Normale Webseiten bestehen dagegen im wesentlichen aus frei definierbaren Textelementen und Bildern. Solche Webseiten-Objekte stehen zunächst für sich selbst und sind höchsten lose und thematisch miteinander verflochten.
Aber beide Arten von pflegbaren Webseiten müssen mit der Menü-Hierarchie einer Site verbunden werden können

Forderung 3:Die Webseiten-Generatoren der allgemeinen Seitenpflege des CMS und die Seiten-Generatoren von Spezialapplikationen müssen mit Hilfe einer speziellen Funktional-Klasse zur allgemeinen Menübehandlung ausgestattet werden. Für bestimmte Menüblöcke muss dieser allgemeine Menügenerator die Menübeiträge aus anderen Pflegeapplikationen einsteuern können.

Forderung 4:Der letzte Punkt (Forderung 3) spricht dafür, spezielle "Menue-Contributor"-Kassen für alle ixCMF-Applikationen nach einem einheitlichen Schema aufzubauen. Diese steuern Listen an Daten/Objekten und zugehörige Links über ein definiertes Interface ein. Um das Nachladen vieler zusätzlicher Klassen für die Behandlung der Objekte und Daten vieler unterschiedlicher Spezial-Applikationen zu vermeiden, müssen diese Contributor-Klassen weitgehend autonom funktionieren und simpel gestrickt sein.

Forderung 5:Die Pflege der Haupt-Menüblöcke einer allgemeinen Web-Site und deren jeweiliger Linkhierarchie ist von der Pflege einzelner Webseiten und Business-Objekte zunächst logisch abzutrennen:
Die Menü-Pflege konzentriert sich auf die logische Navigation durch die Gliederung der Site. Spezial-Applikationen behandeln dagegen die Beziehungen und Verarbeitungslogik von bestimmten Business-Objekten und deren Präsentation auf speziellen Webseiten. Eine weitere generelle Applikation zur Pflege beliebiger Webseiten hat dagegen das Layout und die Texterfassung für solche allgemeinen Seiten im Auge.
 
Die Anbindung zwischen gepflegten Webseiten einerseits und Menü-Hierarchie andererseits muss über die gezielte Herstellung von Relationen durch den Anwender ermöglicht werden. Ganz nach dem Motto:
"Ich habe einen Menülink in einem Zweig der Menü-Hierarchie. Dieser Link ist vom Typus "Link auf pflegbare Standardseite" Zeige mir nun eine sinnvolle Auswahl an erfassten frei definierbaren Webseiten, von denen ich eine dem Link zuordnen kann. Soll der Link dagegen auf Applikationen oder externe URLs verweisen, muss ich die Applikations- oder Web-Adressen gezielt angeben können."
Letzteres stellt natürlich einen Anforderung an die Pflege-Applikation für die Menüblöcke und ggf. auch an die Applikation zur Pflege frei definierbarer Webseiten dar.

Hiermit ist bereits ein umfängliches Arbeitsprogramm definiert. Wie kann man das schrittweise umsetzen?

Schritt A: Pflegbare Webseiten als Hierarchie (Version 5)

Für ixCMF in der Version 5 ist eine neue autonome Applikation - "Pager" - geplant, die die bisherigen Arbeiten zur gestalterischen Pflege von einzelnen Webseiten fortsetzen wird. Diese Applikation wird zunächst als autonome 3-stufige Master-Detail-Applikation aufgesetzt. Sie besteht damit aus 3 über die Verwaltungs-GUI gekoppelten Applikationen, um Webseiten in einer Hierarchie

Hauptseite  >>  Subseiten  >>  Sub-Sub-Seiten

erfassen und gestalterisch pflegen zu können. Hierbei werden alle Layout-Möglichkeiten der aktuellen ixCMF Version 4.2 genutzt werden.

Warum wird "Pager" als MD-Applikations-Hierarchie ausgelegt?

Vergisst man mal Spezialapplikationen und betrachtet einfache Webpräsenzen, so liegt es nahe, Webseiten einer Site u.a. als eine thematisch sortierte Master-Detail-Hierarchie zu begreifen:

In der Regel gelangt man über Haupt-Menüpunkte zu einer Hauptseite für einen bestimmten thematischen Bereich. Unterhalb der Seite eröffnen Links in Sub-Menüs den Zugang zu weiteren Sub-Seiten. Viele Websites bestehen somit aus einer wohldefinierten Hierarchie von "Hauptseiten" und thematisch zugeordneten "Subseiten" bzw. auf einer zusätzlichen weiteren Ebene "Sub-Sub-Seiten". Mehr als 3 thematische Hierarchie-Ebenen strukturell im ixCMF-System abbilden zu wollen, erscheint mir praxisfern.

In ihrer MD-Struktur ähneln frei definierbare Webseiten durchaus den Webseiten mancher MD-Spezial-Applikationen, wie sie ixCMF seit langem ermöglicht. Aber:

"Frei definiert" meint im Falle allgemeiner Webseiten, dass es keine Spezial-Anforderungen an bestimmte Felder oder die Beziehung erfasster Datenobjekte zueinander außerhalb der angesprochenen Seiten-Hierarchie gibt. Texte werden einfach in vordefinierten Textblöcken erfasst. Diese werden auf der zu generierenden Webseite frei oder im Rahmen von vorstrukturierten Templates positioniert - ebenso wie zugeordnete Bilder. Hinzu kommen ein paar Standardfelder (Titel, Unter-Titel, Autor, etc.) sowie Relationen zu Bildern, PDFs in deren jeweiligen Repositories.

Man beachte, dass durch eine solche 3-stufige Pager-Applikation kein Widerspruch zu den obigen Anforderungen erzeugt wird, wenn man diese MD-Applikation mit eigenen speziellen "Menü-Contributor-Klassen" ausstattet:

Die zentrale CMS-Applikation zur Pflege von Seiten wird damit mit speziellen Web-Applikationen gleichgeschaltet ! Sie ist im ixCMF-Rahmen eine Web-Applikation wie jede andere spezielle Web-Applikationen auch. Und diese Applikation wird später (ixCMF v5.5) an eine umfassende Menüsteuerung angebunden.

Schritt B: Pflegbare Menü-Hierarchien und Menügeneratoren (Version 5.5)

Natürlich muss man in einem CMS in der Lage sein, Menü-Hierarchien zu verwalten und zu erweitern. Dazu gehört, im System festzulegen und in Datenbanken zu hinterlegen, welche Menüblöcke auf den Webseiten der zu pflegenden Site existieren und durch was sie wie zu belegen sind. Dies bedeutet für ixCMF dreierlei:

  • Erstens ist eine ixCMF Pflege-Applikation "Menue" zu schaffen, die es erlaubt, die Menühierarchie unter Beachtung der oben aufgelisteten Anforderungen zu definieren, zu pflegen und zu erweitern. Dies wird eine voraussichtlich 3-stufige MD-Applikationskombination werden.
  • Im Rahme der "Menue"-Applikation muss u.a. die Zuordnung von (Haupt-) Seiten der "Pager"-Seiten-Hierarchien zu Menüpunkten ermöglicht werden. Ggf. nicht nur im Rahmen der "Menue"-Applikation, sondern auch im Rahmen der "Pager"-Applikation selbst.
  • Ferner muss es möglich sein, Menüblöcke definierten externen und internen Links zuzuordnen.
  • Spezielle Menü-Blöcke müssen für die Behandlung durch Spezial-Applikationen freigegeben werden.

Es ist zudem zu definieren, in welcher Weise Menüs oder Menüblöcke künftig ihren Eingang in vorstrukturierte Templates finden. An dieser Stelle ist u.a. zu klären, ob die bisherige strenge Trennung zwischen HTML-Code und PHP-Code in der Zukunft noch aufrechterhalten werden kann. Zumindest theoretisch ist dies mit den erweiterten Funktionen für ITX-Templates möglich. Wir wollen eigentlich keinen Mix aus PHP und HTML-Code wie in WordPress und Konsorten! Aber mal sehen, ob wir mit diesem Ansatz durchkommen ...

In die bisherigen Webseitengeneratoren sind Menügeneratoren zu integrieren, die die im Menü-Pflegesystem hinterlegten Festlegungen in die Web-GUI umsetzen. Diese Generatoren nutzen die zu schreibenden "Menue-Contributor-Klassen" von "Pager" und künftig auch von anderen speziellen ixCMF-Applikationen.

Der Leser erkennt schon, dass Schritt B vermutlich selbst wieder in Unterschritte unterteilt werden muss.

Kann man in ixCMF Schritt A zunächst ohne Schritt B durchführen?

Ja, das kann man und das werden wir auch tun. Dass man das kann, hat mit den eingesetzten Template-Technologien zu tun. Insider wissen, dass wir ixCMF-Applikationen in zwei Phasen erzeugen:

  • In Phase 1 wird das HTML- und CSS-Layout der evtl. bereits bestehenden Kundensite erfasst und in Dreamweaver DWT-Templates hinterlegt. Diese DWTs steuern dann das Rahmenlayout von ITX-Templates. Letztere sind die Targets für die eigentlichen PHP-basierten ixCMF-Pflegeapplikationen.
  • In Phase II werden die von den PHP-basierten Seitengeneratoren benötigten Blockelemente in die ITX-Templates integriert. Die Seitengeneratoren beruhen auf den standardisierten Klassenbibliotheken von ixCMF und greifen auf die erforderlichen Klassen zum Zugriff auf diejenigen Objekte (und Datenbank-Records) zu, die durch die Spezialapplikationen verwaltet werden.

Dies bedeutet aber nichts anderes als die Tatsache, dass man im ersten Schritt zur Version 5.0 die Haupt-Menüsteuerung auch noch vollständig über dynamische DWT-Template-Bedingungen steuern kann.

Aber unterhalb von bestimmten Hauptseiten und zugehörigen Haupt-Menüpunkten übernimmt für allgemeine nur thematisch gekoppelte Webseiten bereits "Pager" die vollständige Steuerung von Sub- und Sub-Sub-Menüs und nicht mehr DWT. Hier ist lediglich das Vorhandensein notwendiger Menüblöcke nach einem bestimmten Format in den ITX-Templates erforderlich. Wie im Fall bisheriger Spezialappliaktionen auch.

Damit kann man natürlich noch nicht alles machen, aber doch schon sehr viel. Der Kunde kann seine Menüs zwar noch nicht vollständig selbst verwalten. Aber er kann für gemeinsam vordefinierte Hauptmenüs und deren Menüpunkte bereits ganze Seitenhierarchien selbst kreativ pflegen.

In der Version 5.5 werden wir dann die Anlage und Pflege von Menüpunkten in erweiterbaren Hauptmenü-Blöcken unterstützen, indem wir die "Menue"-Pflege-Applikationen des Schrittes B und zugehörige Menü- und Seitengeneratoren realisieren.

Was kommt in der Version 5 im Gegensatz zur Version 4 an zusätzliche Pflegemöglichkeiten für das Seiten-Layout?

  • Es wird mehr vorstrukturierte Templates zur Auswahl geben. Diese werden dann auf 4 vorpositionierten Textblöcken aufbauen. Der vertikale Abstand zwischen benachbarten Blöcken wird durch den User gesteuert werden können.
  • Jedem dieser vorpositionierten Textblöcke kann man ein Bild zuordnen. Dieses kann nicht nur links/rechts im Textblock positioniert werden; auch die Vorgabe einer vertikalen Positionierung wird dem User ermöglicht.
  • Es wird zusätzlich zu den oben genannten Blöcken vier im Pflegebereich der Seiten frei positionierbare Textblöcke geben.
  • Statt bislang 3 wird es nun 4 frei im pflegbaren Bereich der Webseite positionierbare und skalierbare Bilder geben. Die Position kann dabei an der Top/Left-Ecke eines Bildblocks der vorstrukturierten Templates ausgerichtet werden oder an der linken, oberen Ecke des gesamten gestaltbaren Bereichs.
  • Ab einer bestimmten 5-er Subversion wird es auch die Möglichkeit geben, in die Textblöcke Bilder über ein BB-Code-Image-Tag aus einem wählbaren Repository einzubinden.

Soweit zumindest die hehren Ziele. Wie sich das auf die einzelnen Subversionen der 5-er Version verteilen wird, kann ich noch nicht genau absehen.

Was wird technisch ggf. noch verändert?

Der Kunde wird neben dem Upload einen weiteren Zugang zu den Repositories erhalten, um für ein Bild- oder PDF-Objekt das zugehörige elektronische Bild oder PDF austauschen zu können, ohne in die Pflege der betroffenen Webseiten einsteigen zu müssen.

Der Zugang auf die Bildrepositories, aus denen Bilder für Textblöcke oder zur freien Positionierung gewählt werden können, wird intern komplett umgebaut, da das bisherige Vorgehen in den Update- und Insert-Masken technisch an seine Grenzen stößt und von der Logik her suboptimal ist.

Die Darstellung der erfassten Geometrie-Informationen wird in der Maske "Feldanzeige" ähnlich komprimiert werden wie in der Update-Maske.

Die Vergleichsmaske für Katalog-basierte Pflege-Applikationen (Leistungen, Produkte) wird technisch überarbeitet werden.

Erneut gilt: Wie sich das auf die einzelnen Subversionen der 5-er Version verteilen wird, kann ich noch nicht genau absehen.