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.

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.