Applikation "Pager" – Technische Design-Elemente I

Ein wichtiger der zuletzt angekündigten Schritte für die ixCMF Version 5 befindet sich in der Umsetzung. Ich entwickle z.Z. die generelle CM-Applikation "Pager" und erweitere dabei die Klassenbibliotheken der bisherigen Version ixCMF v4.

"Pager" beinhaltet den kompletten Apparat an bereits bekannten ixCMF-Pflege-Tools und die erforderlichen Web-Generatoren für eine neue besondere ixCMF-Objekt-Klasse "Page". Diese neue Objektklasse repräsentiert im ixCMF-Framework künftig eine bzgl. ihres Contents und ihres Layouts pflegbare allgemeine Webseite.

Wie schon früher für komplexe ixCMF-basierte Master-Detail-Applikationen soll der End-Anwender zur Content-Pflege und zur Layout-Gestaltung einer Webseite keine HTML-oder CSS-Kenntnisse benötigen. Auf der technischen Seite werden Klassenbibliotheken des Frameworks für die Objektpflege einerseits und für die Web-Seitengenerierung andererseits genutzt. Im Web-Generator-Bereich interagieren Methoden von Template-Steuer-Klassen mit PEAR ITX-Templates.

Ein kurzer technischer Rückblick zum besseren Verständnis

Fachliche Objekte eines bestimmten Typus werden in ixCMF über sogenannte "ixCMF-Objektkategorien" und zugehörige Klassen repräsentiert. Wir sprechen von "ixCMF-Objekt-Klassen".

Aber Vorsicht: Das Wörtchen "Objekt" bezieht sich dabei auf die fachliche Ausprägung und nicht (!) auf eine programmtechnische Objektinstanz. Es handelt sich hierbei um einen Meta-Ansatz! Als Framework will es ixCMF ja ermöglichen, jede Art von zu repräsentierendem Fach-Objekt bestimmten gleichartigen Spiel-Regeln für die Pflege und vor allem bzgl. der Web-Präsentation zu unterwerfen.

Hierzu wird einerseits Vererbung und andererseits eine Art "Factory-Pattern" eingesetzt: Eine ixCMF-Objektkategorie wird durch eine spezielle Objektklasse realisiert,

  • die von komplexen, abstrakten und allgemeingültigen Basisklassen zur Repräsentation fachlicher Objekte in einem ixCMF-Applikationsprogramm abgeleitet wird und
  • deren spezielle, fachlich motivierte Attribute auf der Basis von "Schema-Informationen" erzeugt werden.

Jede ixCMF-Objekt-Klasse ist also u.a. durch spezifische Attribute definiert, die seine fachlichen Eigenschaften kennzeichnen. Hinzu kommen Attribute, die seine Beziehungen zu anderen Objekten anderer ixCMF-Objekt-Klassen betreffen, und natürlich viele grundlegende Methoden, die von Basisklassen des Frameworks geerbt werden.

Ein "Schema" ist selbst wieder ein Objekt, das die Attribute und bestimmte funktionale Eigenschaften der Objekte einer bestimmten ixCMF-Objekt-Klasse und damit fachlichen Objekt-Kategorie in normierter Weise definiert. Die Attribut-Definition erfolgt also pro ixCMF-Objekt-Klasse in Schema-Objekten. Letztlich ermöglicht ein Schema die "fabrikmäßige" Erzeugung und Pflege konkreter Objekte eines fachlichen Objekts aufgrund bestimmter Spielregeln.

Ein Schema legt auch immer auf die Hinterlegung der Attribute in einer Datenbank-Tabelle oder in Relationstabellen fest. Zudem eröffnet ein Schema einen Namensraum für bestimmte ixCMF-Objekt-Klassen, zugehörigen kategorie- und applikationspezifischen Template-Steuer-Klassen, Applikationsprogramme als auch ggf. für spezielle Klassen, die den Ablauf einer Applikation steuern. Applikationsspezifische Template-Steuer-Klassen wie auch applikationsspezifische Ablauf-Klassen werden natürlich von entsprechenden Basisklassen abgeleitet.

Neben definierten Spielregeln zur Erzeugung von einzelnen Objekten im Rahmen einer Applikation existieren in ixCMF Regeln und vorgefertigte Basis-Applikationen zur Objektpflege, zur Kopplung von Objekten und zur Generierung von entsprechenden Webseiten. Die Methoden vieler Funktional-Klassen und spezieller Web-Generator-Klassen dienen als Ausgangspunkt für die Erzeugung spezieller Kunden-Applikationen. "Pager" wird als Content-Management-Applikation für allgemeine Webseiten "nur" nur einen Sonderfall darstellen, bei dem allerdings das gesamte Spektrum der bereits verfügbaren Pflege- und Generator-Möglichkeiten genutzt wird.

In vielen web-orientierten Anwendungen spielen baumartige Master-Detail-Beziehungen, die sich über mehrere Verzweigungs-Ebenen erstrecken können, eine Schlüsselrolle:

"MD-Hierarchien" sind in ixCMF Hierarchien von ixCMF-Objekt-Klassen, deren Objekte über (1:n)- oder (n:m)-Master-Detail-Relationen miteinander verknüpft werden. Der Aufbau und die Pflege solcher MD-Hierarchien ist in ixCMF vorstrukturiert! So gibt es ein spezifische Pflegetoolset für bis zu 4 MD-Ebenen.

Wir haben "Master-Detail" dabei mit "MD" abgekürzt. Unterstützt wird die Behandlung der Objekte einer MD-Hierarchie durch folgende Punkte:

  • Ein zentrales "MD-Schema-Objekt" bündelt die Schemata der hierarchisch abhängigen ixCMF-Objektklassen und steht den ixCMF-Objekt- und ixCMF-Web-Generator-Klassen zur Verfügung.
  • In den Einzelschemata wird einerseits die MD-Hierarchie-Ebene, der die Objekte zugeordnet sind, und andererseits auch die Beziehung zu den anderen Objektklassen der Hierarchie hinterlegt.
  • Die Pflegemasken zu MD-Applikationen bieten spezielle Bedien-Elemente zum nahtlosen Wechsel zwischen ixCMF-Objekten auf unterschiedlichen MD-Hierarchie-Ebenen, zur Erzeugung und Verknüpfung von Objekten auf den unterschiedlichen MD-Ebenen und natürlich zur Pflege der verkoppelten Objekte selbst.

In ixCMF-Applikation vor der Version 4 wurden die Webseiten über speziell designte Templates und zugehörige Template-Steuerklassen pro ixCMF-Objektklasse oder aber zu Objekten derselben MD-Hierarchie realisisert. Die TPL-Steuerklassen nutzten dabei normierte Methoden von Basisklassen, u.a. zur dynamischen Bildskalierung, zur Erzeugung von Listen - im speziellen von von Detaillisten zu Mastersätzen - etc.. Zurückgegriffen wurde bei der Seitengenerierung auch auf normierte Vorgaben im Schema-Objekt.

Der Einfluss des Users auf den grundsätzlichen Aufbau von Templates waren dabei relativ auf bestimmte variable Details beschränkt. Der User konnte sich nicht wirklich als Layout-Designer betätigen.

Page-Attribute - ein Basis-Set an Content- und Layout-Elementen sowie Geometrie-Parametern

"Pager" ist für die künftige ixCMF-Entwicklung insofern zentral, als diese spezielle Applikation zur Pflege von allgemeinen Webseiten auch einen allgemeinen Satz an grundlegenden Content- und Layout-Elementen sowie deren konkreter Ausgestaltung und Geometrie-Parametrierung durch den Anwender festlegt. Dieser Satz an Content- und Layout-Elementen soll in künftigen ixCMF-basierten Anwendungen für alle erfasste ixCMF-Objekte genutzt werden können. Also nicht nur für Page-Objekte!

Diese speziellen Content und Layout-Elemente machen ixCMF-Objekte in besonderer Weise für zu generierende Webseiten präsentationsfähig. Auf der Seite der ixCMF-Objektklassen, deren Instanzen die fachlichen Objekte verkörpern, entsprechen die genannten Elemente speziellen Attributen - wir nennen sie künftig "Page-Attribute".

Page-Attribute bleiben also nicht nur Objekten der Klasse "Page" vorbehalten, sondern werden in nachfolgenden ixCMF-Applikationen als ein Attribut-Grundstock in die Attributmenge aller pflegbaren ixCMF-Objekten eingehen. "Page-Attribute" unterstützen - neben weiteren applikations-spezifischen Attributen - die Einzeldarstellung eines ixCMF-Objektes auf einer Webseite. (Für die Insider: Page-Attribute entsprechen natürlich besonderen Attribut-Gruppen in den Schema-Dateien und korrespondieren auch zu definierten Gruppen von Datenbankfeldern.)

Page-Attribute umfassen

  • normierte Textbox-Elemente,
  • deren formatierten Inhalt,
  • eine Layout-Variante für die Web-Präsentation des Objekts,
  • Geometriedaten zur Ausgestaltung etlicher Details einer Layout-Variante,
  • sowie Positionierungs- und Sizing-Daten von zugeordneten Bildern/Multimedia-Elementen.

Viele dieser Page-Attribute sind für ixCMF-Objekte mancher Applikationen der Version 4 bereits verfügbar. Beispiele liefern etwa die Applikationen "Leistungsgruppen/Einzelleistungn [LG/EL]" oder "Aktuelles".

Diese Attribute und korrespondierende Datenbank-Felder sollen in Zukunft aber allen ixCMF-Objekten als Basisausstattung zur Verfügung stehen. Dabei ist es egal, ob die Objekte einem oder unterschiedlichen Levels ein und derselben oder sogar unterschiedlichen Master-Detail-Hierarchien zugehörig sind oder nicht. Eine Beschränkung auf die Nutzung nur spezieller Page-Attribute ist in einer speziellen ixCMF-Objekt-Klasse natürlich per Schema-Vorgaben nach wie vor möglich!

Darstellung von Page-Attributen in Form mehrerer Layout-Varianten

Page-Attribute (wie Textblöcke mit Inhalt) erhalten ihre spezifische Ausprägung und Darstellung auf einer Webseite erst durch einen Layout-Rahmen und CSS-Style-Vorgaben hinsichtlich von Positionen, Dimensionen, Farben, etc. in diesem Rahmen.

Die Anordnung von Textblöcken und Bildern in einer bestimmten geometrischen Grundstruktur nennen wir "Layout-Variante".

Innerhalb einer geometrischen Grundstruktur kann es aber viele Detailausprägungen geben, die erst durch Geometrieparameter genauer fixiert werden. Solche Geometrie-Parameter können etwa die Breite und den Abstand von Textblöcken oder aber die Positionierung von Bildern innerhalb von Textblöcken oder frei im gestaltbaren Layout-Bereich betreffen. Die Auswahl einer Layout-Variante oder die Festlegung von Geometrie-Parametern erfolgt in ixCMF seit Version 4 durch den User und nicht den Template-Designer:

In der Version 4 von ixCMF wurde die programmtechnische Normierung der Web-Generierung für bestimmte Applikationstypen im Sinne von "Layout-Varianten" vorangetrieben. So bietet ixCMF v4 dem Anwender mehrere normierte Basis-Template-Varianten [A,B,C, ..] zur Web-Repräsentierung von ixCMF-Objekten an. Jede Template-Variante [TPL-Variante] bietet eine bestimmte geometrisch strukturierte Zusammenstellung von Textblöcken und einem Bildblock (besser Koord.punkt für frei positionierbare Bilder mit und ohne CSS-Overflow) als vordefinierte Layout-Varianten für die zu erzeugenden Webseiten an.

Der User kann in der Version 4 für jedes Objekt zwischen den angebotenen Layout-Varianten frei wählen und zugehörige Detail- und Geometrie-Parameter nach eigenem Gusto anpassen. Für den User bietet ixCMF daher in Applikationen die Möglichkeit, das Layout von zu generierenden Webseiten selbst in viel weitergehender Form zu beeinflussen als in den ixCMF-Vorgänger-Versionen.

Für jede dieser Layout -Varianten gab es in der Version 4 für Objekt-Einzeldarstellungen genau ein ITX-Template (oder bei Listen genau einen ITX-Block). Eine wählbare Layout-Variante war somit in den allermeisten Fällen gleichbedeutend mit einer Template-Variante. Durch verschiedene Tricks und pflegbare Geometrie-Parameter konnte der Anwender Details des vorstrukturierten Layouts zusätzlich beeinflussen.

Hierbei sprechen wir hauptsächlich über Webseiten zur Darstellung von einem ixCMF-Objekt, das nach der Programmverarbeitung eine bestimmten Zustand hat (beispielsweise ein Produkt aus einer Produktgruppe). Es gibt aber bereits Anwendungen, in denen auch Listen mit Objekten auf Basis komplexer Layout-Varianten erzeugt werden: Jedes Listenelement entspricht dabei einer komplexen vom User beeinflussbaren Layout-Definition anstelle einer vordefinierten Aneinander-Reihung bestimmter Felder. (Die Darstellung vordefinierter Listen - u.a. MD-Listen beherrscht ixCMF ja schon lange.)

Gemeinsame Darstellung mehrerer Einzelobjekte oder Listen von Objekten aus unterschiedlichen MD-Hierarchien auf ein und derselben Webseite

Während Applikationen, die auf der ixCMF-Version 2 und 3 beruhen, bereits ixCMF-Objekte ein und derselben Master-Detail-Hierarchie in Applikationen und zugehörigen Webseiten miteinander verknüpft haben, wurde in den "Katalog"-Applikationen der Version 4 bereits ein wichtiger Schritt in die Richtung unternommen, logisch verbundene Objekte unterschiedlicher Master-Detail-Hierarchien nicht nur gemeinsam zu verarbeiten, sondern in bestimmten Pflegemasken und Webseiten auch gemeinsam darzustellen. Dies bedeutete auf der technischen Ebene, dass in vielen Methoden der ixCMF-Basisklassen das zu einem spezifischen ixCMF-Objekt gehörige Schema-Objekt sowie das MD-Objekt der eigenen Hierarchie und ggf. das MD-Schema-Objekt einer anderen Hierarchie zu Schlüsselparametern wurden.

Für künftige ixCMF-Applikationen wird die Kopplung von ixCMF-Objekten unterschiedlicher MD-Hierarchien absehbar wichtiger werden. Die Möglichkeit zur Pflege und Steuerung von Webseiten mit folgenden Freiheitsgraden wird daher wichtiger:

Die Webseite soll in unterschiedlichen Seitenbereichen vom User gepflegte ixCMF-Objekte nach verschiedenen durch den User flexibel wählbaren, gestaltbaren und jederzeit auch änderbaren Layout-Varianten darstellen.

Dies ist eine ungleich komplexere Anforderung als die, vom Kunden pflegbare MD-Objekte nach definierten Layout-Mustern in (vom Kunden) einmalig vordefinierten und somit relativ statischen Templates darzustellen.

Templates, Layout-Bereiche und Layout-Varianten

Eine Business-Logik zur gekoppelte Verarbeitung von Objekten ist in applikationsspezifischen Verarbeitungsobjekten zu hinterlegen. Jede Verarbeitung mündet aber irgendwann in die Präsentation von bestimmten Fach-Objekten als Teil einer Webseite. In Zukunft - und das gilt bereits für die Applikation "Pager" - wird zwischen "Templates" und "objektbezogenen Layout-Varianten" stärker zu unterscheiden sein:

Denn in absehbarer Zeit möchten wir auf einer Webseite ggf. mehrere Objekte aus unterschiedlichen MD-Hierarchien nicht nur gemeinsam zu präsentieren. Sondern wir möchten dabei für die Darstellung der jeweiligen "Page"-Attribute eines jeden ixCMF-Objekts Layouts nutzen, die der User in weiten Teilen nicht nur wählt, sondern selbst modifiziert: Jede Layout-Grundstruktur ist schon seit der Version 4 im Detail in vielerlei Weise flexibel und frei ausgestaltbar.

Ab einer Version 5.x wird es als Extremfall eine Layout-Variante geben, in der bis zu 8 Textblöcke und Bilder frei positionierbar sein werden. Hinzu kommt die Wahl von Hintergrundbildern mit dimmbaren Transparenzlayern. Pflege wird damit nicht nur zur Pflege definierter Content-Felder, sondern zum Spiel mit sehr vielen Layout-Freiheitsgraden, die pro ixCMF-Objekt festgelegt werden können. Diese Möglichkeiten sollen nun für mehrere Objekte auf ein und derselben Webseite genutzt werden.

Layout_Webseite_1_500

Komplexe ixCMF-Webseiten können in Zukunft daher mehrere separierte Bereiche beinhalten, in denen die Page-Attribute unterschiedlicher ixCMF-Objekte in jeweils unterschiedlichen Layout-Varianten präsentiert werden. Ein solcher Bereich heißt künftig "Layout-Bereich".
 
Ein Layout-Bereich entspricht in dieser Philosophie sozusagen einer kleinen Webseite innerhalb einer umfassenderen Webseite. Natürlich werden diese Bereiche das aber nicht über iFrames sondern über (komplexe) DIVs realisiert und gekapselt.

Innerhalb eines Layout-Bereichs entscheidet hinsichtlich der genauen Darstellung der Objektattribute die dem Objekt zugeordnete Layout-Variante mit den Geometrieparametern zu den zugehörigen, vom Anwender nutzbaren Freiheitsgraden der jeweiligen Layout-Variante.

Also:
Ein Template umfasst mehrere Layout-Bereiche. Einige dieser Layout-Bereiche werden im Detail gestaltet durch strukturell normierte "Layout-Varianten" A, B, C, .... Die Layout-Varianten selbst beinhalten jedoch viele Freiheitsgrade, die der Anwender durch die Vorgabe von Geometrieparametern, Bildauswahl, Skalierungsvorgaben, etc. auf individuelle Weise nutzen kann.

Natürlich wird es für spezielle Applikationen immer auch Layout-Bereiche geben, die in ihrem Struktur und ihrem Inhalt spezifisch festzulegen sind.

ixcMF-Objekte werden in dieser Logik durch Template-Steuer-Programme einem Layout-Bereich einer Webseite zugewiesen. Über die genaue Repräsentation von Page-Attributen entscheidet dann eine durch den Anwender ausgewählte und ausgestaltete Layout-Variante.

Hierbei stehen primär gestaltbare Einzeldarstellungen von Objekten auf Webseiten im Vordergrund. Im Kern schließen die obigen Definitionen aber auch die Behandlung von komplexen Listen ein, in denen die Page-Attribute jedes (!) aufgelisteten Objekts in komplexer Weise nach Layout-Varianten aufbereitet werden.

 

Die Content-Management-Applikation "Pager für gestaltbare Webseiten ist ein erster und relativ einfacher Sonderfall !

In der Version 5.0 geht es zunächst mal "nur" um die schrittweise Realisierung von "Pager". Pager soll die Pflege unspezifischer einfacher Webseiten leisten. Hierfür werden "Page"-Objekten als neuer Klasse von ixCMF-Objekten Page-Attribute zugeordnet, die Content- und Layout-Elementen entsprechen. Für Page-Templates gibt es aber nur einen Layout-Bereich:
Das ist der gesamte durch einen Anwender pflegbare und gestaltbare Bereich einer Webseite. (Wobei wir pflegbare Menüstrukturen in der Diskussion dieses Beitrags mal ausklammern).

"Pager" als Applikation beinhaltet bis auf eine zu definierende Menüsteuerung und Menü-Pflege eigentlich nur wenig "Applikationslogik": Die Aufgabe besteht in der Pflege von Objekten, deren Attribute die Elemente der darzustellenden Webseite selbst darstellen. Jedes Page-Objekt ist eine komplette Webseite. Die Attribute der Page-Objekte sind von einigen Ausnahmen mal abgesehen im wesentlichen die oben genannten Page-Attribute.

In Teil II der Diskussion von Design-Vorgaben für Pager werden wir allerdings auch noch eine MD-Hierarchie für Pager-Objekt definieren. Dies entspricht dann einer simplen Hierarchie von Webseiten, die nur thematisch, aber nicht durch andere spezielle logische Bezüge aneinander gekoppelt werden. Dann kommt die Logik der MD-Hierarchie-Pflege zur Content- und Layout-Pflege noch dazu - diese entspricht aber den vorhandenen iXCMF-MD_Standards.

Der Leser ahnt es schon: Die geplante Pager-MD-Hierarchie trägt natürlich zur pflegbaren Menüstruktur bei. Allerdings nicht allein und nicht ausschließlich: Es muus ja auch Links zu ixCMF-Spezialapplikationen geben, die spezielle Webseiten innerhalb einer Site bereitstellen - z.B. für Produktgruppen/Produkte, Seminare, Aktuelles, etc.. Die Zuordnung unterschiedlicher Typen von Links zu Pager-Seiten, Spezial-Applikationen, externen Seiten/Applikationen macht die Menüsteuerung letztlich komplex. Aber das ist Inhalt eines anderen Beitrags.

Pager und seine hierarchisch geordneten Page-Objekte stellen also einen Sonderfall der mit künftigen ixCMF Versionen zu behandelnden Aufgaben dar. Dennoch ist bei der Realisierung schon auf viele der oben genannten Aspekte mehrerer gestaltbarer Layoutbereiche zu unterschiedlichen Objekten Rücksicht zu nehmen.

Technische und logische Änderungen gegenüber der Version 4

Für die Interessierte hier ein paar Informationen zu technischen Änderungen gegenüber früheren Versionen:

Änderung 1: Ab Version 5 wird es deutlich mehr strukturelle Layout-Varianten, nämlich mindestens 7, geben. Eine spezielle TPL-Variante wird in einer späteren 5.x-Version eine solche sein, in der alle 8 verfügbaren Text-Blöcke (4 davon mit integrierten Bildern) plus 4 separate Bilder und ein Hintergrundsbild frei positionierbar und dimensionierbar sein werden - sozusagen für die Profi-Layouter. Hinzu kommen mehr Möglichkeiten zur Beeinflussung von Layout-Details im Rahmen der geometrisch logischen Grundstrukturen des jeweiligen Basis-Layouts.

Änderung 2:Technisch bedeuten die oben vorgegebenen Ziele, dass eine zentrale Stelle zur Steuerung und Generierung aller Layout-Varianten geschaffen werden muss. Auf der Frontend-Seite führen wir die verschiedenen grundlegenden Layout-Struktur-Varianten für die Seitengestaltung deshalb nun in einem gekapselten ITX-Template-Block mit mehreren (in sich weiter hierarchisch gegliederten) Sub-Blöcken zusammen. Dieser umfassende ITX-Haupt-Block für alle Layout-Grund-Varianten wird in Zukunft durch eine spezielle "TPL-Support-Klasse" namens "PageTool" gesteuert und mit Inhalten (Texte, Bilder) sowie bestimmten CSS-Anweisungen zur Geometrie versorgt. Wir nennen einen solchen, alle layout-varianten umfassenden ITX-Block künftig "Page-Super-Block".

Eine Layout-Variante korrespondiert zu einem Sub-Block eines Superblocks. Der ITX-Block für die Layout-Variante zerfällt natürlich selbst wieder in Unterblöcke für die beinhalteten Layout- und Content-Elemente. Also:

Ein Layout-Bereich eines allgmeinen ixCMF-ITX-Templates entspricht auf der HTML-Seite einem Page-Superblock und zugehörigen bestimmten CSS-Vorgaben. Auf der PHP-Seite korrespondiert der Superblock (mit seinen Platzhaltern) wiederum zu einer "PageTool"-Objekt-Instanz, die auf Basis der vom Anwender gepflegten Page-Attribute die jeweils gewählte Layout-Variante mit allen vom Anwender genutzten Gestaltungsmöglichkeiten umsetzt. Das PageTool-Objekt füllt dafür die Platzhalter (Content, CSS-basierte Styles) der vom User gewählten Layout-Variante als speziellem Sub-Block des Superblocks; natürlich zerfällt der Layout-Block selbst wieder in Sub-Blöcke. Im Fall von Pager mit nur einem Layout-Bereich ist die Webseite dann fertig und renderbar.

In der Version 5.0 ist dieser "Page-Super-Block" in die TPL-Dateien einer Applikation noch händisch einzusetzen. Ab einer kommenden Version 5.x wird er aber per ITX::addBlock() automatisch auf der Basis in Dateien geordneter Vorgaben in Templates hinein generiert werden. Dies zentralisiert und erleichtert die Pflege und Wartung von Page-Superblöcken für verschiedene Applikationen - ohne dass wir dabei unser Prinzip, HTML-Coding und PHP-Coduing zu trennen, verletzen würden.

Um ein ungewolltes mehrfaches Durchlaufen von IT(X)-Blöcken bei der PHP-basierten Generierung einer konkreten Webseite zu verhindern, müssen die Bezeichnungen der Sub-Blöcke und Platzhalter für die einzelnen Layout-Varianten (A, B, C, ...) innerhalb des "Page-Super-Blocks" spezifisch und eindeutig sein. Die Layout-Bereiche einer Webseite markieren ITX-Blöcke, denen einzelne Objekte - ggf. auch mehrere Objekte bei wiederholtem Parsen des Bereichs (Listen!) - gemäß der Logik der applikationsspezifischen Template-Steuerung zugewiesen werden können.

Die Unterscheidung der entsprechenden ITX-Blöcke, ihrer Sub-Blöcke für Layout-Varianten und Ihrer Platzhalter geschieht in deren Bezeichnung daher über

  • ein variantenspezifisches Suffix (Layout-Basisvariante A (B, C, ....) + Textblock-Nummer
  • und ein spezifisches Prefix für den Objekttypus gemäß des Schemas (Namensraum!) sowie einer laufenden Layout-Bereichsnummer .

Warum so kompliziert?
Wichtig war ja, von vornherein anzunehmen, dass die gesamten Layout-Varianten für Textblöcke, Bilder etc. in späteren ixCMF-Anwendungen auf bestimmten Webseiten nicht nur für ein Objekt sondern für mehrere Objekte unabhängiger Schemata benötigt werden. Dies schließt potentiell Objekte, die verschiedenen Master-Detail- und Schema-Hierarchien zugeordnet sind, ein. Da der gesamte IT/ITX-Mechanismus allergisch auf gleichlautende Platzhalternamen oder Block-Namen in unterschiedlichen Block-Bereichen reagiert, ist die Kombination aus Prefix der Schema-Klasse des Objektes und einer laufenden Bereichsnummer sinnvoll.

Hierbei gehen wir davon aus, dass Objekte zu einem bestimmten Schema immer auch einen eigenen Layout-Bereich bekommen. Das erscheint uns im Moment praxisnah und erleichtert die Steuerung vieler Elemente im Programmcode der TPL-Steuerklassen doch erheblich.

Die nachfolgende Skizze gibt einen Überblick:

Layout_Steuerung_2_600

Die unterschiedlichen Layout-Bezeichnungen deuten an, dass der User für die Objektdarstellung unterschiedliche Layout-Varianten gewählt und im Detail gestaltet hat. Die entsprechenden Informationen erhält die objektspezifische TPL-Steuerklasse und die dort erzeugte Instanz eines PageTool-Objekts aus objektspezifischen Page-Attributen. Zur Wert-Ermittlung wird auf die in Arrays gebündelten Attribute der ixCMF-Objekt-Klassen zugegriffen.

Änderung 3:Die applikationsbezogenen Web-Generator-Klassen bedienen sich künftig in einheitlicher Weise und über einen (bzw. sehr wenige) Methodenaufruf(e) der PageTool-Klasse, um den erfassten Content- und Geometriedetails in die vom User gewählten Layout-Strukturen umzusetzen. Pro Objekt der Webseite muss der Generator jeweils eine eigene Objekt-Instanz "PageTool" der WEB-TPL-Support-Klasse erzeugen. Dadurch werden die Steuervariablen für die einzelnen zu präsentierenden Objekte der Webseite sauber separiert. Diesem Objekt werden bereits im Konstruktor das Schema des darzustellenden Objekts, sein Sgl-Objekt mit allen Objektattributen und die Objektnummer im Tempate der Webseite übergeben. (Ein Sgl-Objekt repräsentiert ein konkretes, spezielles ixCMF-Objekt.)

Änderung 4:Die WEB-TPL-Support-Klasse der ixCMF-Version 5 wird auch von Applikationen der Version 4 im Nachhinein nutzbar sein. Dann muss lediglich ein spezieller Parameter übergeben werden, um die früheren Block- und Platzhalterbezeichnungen zu bedienen. Immerhin wird so die Möglichkeit geschaffen, die applikationsbezogenen TPL-Steuerklassen der früheren Anwendungen im Nachhinein in einheitlicher Weise zu entschlacken.

Änderung 5:Um der Tatsache Rechnung zu tragen, dass auf Webseiten künftig Objekte unterschiedlicher Schemata beherbergen werden, ist weiteren Methoden der Basisklassen - insbesondere solchen zur Bildverarbeitung - das jeweilige Schema-Objekt per Referenz zu übergeben.

Änderung 6:Durch die Einführung standardisierter "Page-Attribute" deutet sich ein künftiger Split der datenbanktechnischen Organisation für

  • applikationsspezifische Attribute/Felder und
  • generelle Content-Attribute/Felder a la Pager

bereits an. Ich werde dies vermutlich in der ixCMF-Version 6 umsetzen. Für die CM-Applikation "Pager" selbst ist dieser Split noch nicht erforderlich, da diese Applikation ja gerade genau und ausschließlich das Basis-Set an Feldern für die Objektklasse "einfache pflegbare Webseiten" definiert.