Wenn man der Redaktion ermöglichen möchte die umfangreichen Features des Xperience by Kentico ↗ Page Builders mit seinen Templates, Sections und Widgets zu nutzen, dann sollten die entsprechenden Teile aus denen der Page Builder die Seiten zusammensetzt aufeinander abgestimmt sein und sich sinnvoll ergänzen.
Wie man die Page Builder Architektur dahingehend einrichten kann möchte ich in diesem Beitrag erläutern.
Schichten
Der Page Builder von Xperience arbeitet mit insgesamt 3 Schichten um Content darzustellen.
- Template (+ optional: Page View Component)
Enthält einstellbaren Inhalt + Editable Areas - Section
Enthält einstellbaren Inhalt + Widget Zones - Widget
Enthält einstellbaren Inhalt
Template
Ein Template definiert den statischen Teil einer jeden Seite und wo in diesen statischen Elementen eine oder mehrere Editable Area Platzhalter für die folgenden Sections liegen sollen und wird einmalig seitens der Entwicklung bereitgestellt.
Ich empfehle immer Templates einzurichten – auch wenn man sie evtl. erstmal nicht verwendet. Denn diese im späteren Projektverlauf nachträglich zu implementieren wird eine größere Herausforderung sein als dies direkt von Anfang an zu machen.
Das Template kann Eigenschaften nutzen, um die Darstellung der statischen Inhalte auf der Seite zu steuern.
In einem meiner Templates kann ich so z.B. einstellen, ob ich die Hauptnavigation ausblenden möchte (z.B. in E-Commerce Check-Outs) oder wie sich die Breadcrumb verhalten soll.
Diese Elemente sind statisch in jede meiner Seiten eingebaut und kommen nicht erst mit einer Section oder einem Widget hinzu.
Da man Templates natürlich später auch noch wechseln kann, könnte man auf diese Weise komplett unterschiedliche, statische Layouts anbieten. Gemeinsam haben sie dann lediglich die Editable Areas. Diese müssen identisch benannt sein, sonst kann der Page Builder nicht zuordnen wohin die bereits angelegten Inhalte kommen sollen falls man später einmal das Template wechseln möchte.
Der Rest des statischen Inhalts kann völlig frei gestalltet werden.
Der riesen Vorteil ist, dass man mit Templates seine Seite frei gestallten kann – quasi die Editable Areas mit Inhalten füllt – und die fertige Seite dann als Template Vorlage (Preset) speichern und wiederverwenden kann. Auf diese Weise kann man, und ohne jedesmal immer wieder einen Entwickler damit beauftragen zu müssen, komplexe Seiten Templates einfach redaktionell selber aufbauen.
Später kann man dann diese Vorlagen nehmen und einfach nur noch entsprechend anpassen.
Das ist extrem praktisch, wenn man z.B. News Artikel oder ähnlich stets gleiche Seiten anlegt. So kann ich einmal meine News Artikel Seite gestallten und dann als Vorlage speichern. Folgende nehmen dann meine Vorlage und tauschen dann lediglich den Inhalt aus, der für den neuen Artikel relevant ist.
Entwickler Tipp: Um die Darstellung des Templates bzw. der Page im .NetCore Backend vor dem rendern noch programmatisch anpassen zu können, kann man z.B. eine View Component in die Partial View des Templates legen, die dann wiederum das eigentliche Rendering enthält.
Auf diese Weise kann man in der View Component noch das ViewModel beeinflussen. Das ist ein recht schneller und unkomplizierter Weg, den ich gerne gehe.
Eine weitere Möglichkeit wäre ein eigenes Custom Routing einzurichten und einen Standard Template Controller zu implementieren. Dies ist etwas komplexer, enthält dann aber einen vollwertigen Controller mit noch mehr Möglichkeiten.
Beides wird in der Xperience Page Builder Dokumentation ↗ ausführlich beschrieben.
Entwickler Tipp: Es ist nicht schlecht eher seltener verwendete Komponenten in ein Template aufzunehmen. Da man die Templates ja einfach wechseln kann, kann man so etliche Inhalte, die oft nur ein einziges Mal gebraucht werden, statt in einem Widget in einem Template unterbringen. Sollte eine Einstellung notwendig sein kann man dies entweder direkt im Content Type mit abbilden oder in den Template Eigenschaften. Auf diese Weise hält man den Widget Katalog schlank und übersichtlich. Templates sind cool. Nutzt sie 😉
Ich habe in der Vergangenheit oft etliche Widgets gesehen, die nur ein einziges Mal in der ganzen Website verwendet wurden, wie z.B. ein Kunden Login, oder ein Newsletter Subscription Formular. Sowas würde ich heute als Kunden Login Page Template oder Newsletter Subscription Page Template anlegen.
Sections
Sections werden in die Editable Areas des verwendeten Templates von der Redaktion eingesetzt. Sie müssen einmalig von der Entwicklung bereitgestellt werden.
Welche Section in der entsprechenden Editable Area erlaubt sind kann eingestellt werden. So kann man ganz genau steuern welcher Inhalt wo eingesetzt werden darf.
Sections enthalten neben dem umschließenden HTML eine oder mehrere Widget Zones, in die dann wiederum passende Widgets eingesetzt werden können.
Somit bieten Sections eine gute Möglichkeit z.B. ein responsives Spalten System einzurichten wie man es aus verschiedenen Frontend Frameworks kennt. In diese Spalten kann man dann die Widgets einzetzen.
Sections haben ebenfalls eigene Eigenschaften, die das Verhalten der Section steuern können.
Auf diese Art kann man ganz hervoragend ein möglicherweise verwendetes Frontend Framework nutzen, und alle Einstellungen die hierdurch möglich werden direkt an die Redaktion weitergeben.
So bekommt sie ein sehr mächtiges Design Werkzeug um viele individuelle Darstellungen zu realisieren. Ganz ohne jedesmal Entwickler dafür beauftragen zu müssen.
Auch Sections können selbstverständlich später noch ausgetauscht werden ohne dass dabei die bereits eingesetzten Widgets verloren gehen.
So kann man sich auch später noch entscheiden statt einer Zwei-Spalten-Section doch noch eine Drei-Spalten-Section zu nutzen. Die Inhalte werden dabei dann einfach übernommen.
Widgets
Widgets werden als unterster Baustein in die Widget Zones der Sektions eingesetzt und enthalten die einzelnen Komponenten aus denen meine Seite besteht. Bilder, Texte, Buttons, koplexere und individuelle Komponenten. Sie werden einmalig von der Entwicklung bereitgestellt.
Welche Widgets in welchen Sections und Editable Areas erlaubt sind, kann sowohl in der Editable Area des Templates als auch in der Widget Zone der Sektion eingestellt werden.
So kann ganz genau eingestellt werden, welche Inhalte die Redaktion wo einbauen darf und wo nicht.
Widgets haben ebenfalls wieder die Möglichkeit eigene Eigenschaften einstellen zu können. Genau wie die Sektions kann man hier der Redaktion also auch sehr viele Möglichkeiten bieten, die angezeigte Komponente individuell einzustellen.
Ein Image Widget, welches ich nutze, hat z.B. folgende Eigenschaften:
Entwickler Tipp: Man sollte nach Möglichkeit Widgets so designen, dass sie zwar die Darstellung von Content übernehmen, diesen aber nicht direkt im Widget speichern, sondern besser in entsprechenden Content Types, die News Artikel, Slider Items oder Accordion Panels abbilden. In den Widgets stellt man dann lediglich die Referenz zu dem darzustellenden Inhalt ein.
Auf diese Weise kann der Content dann auch direkt mit dem Content Hub an andere Kanäle ausgeliefert werden und ist nicht nur Teil eines Widgets.
Gleichzeitig funktionieren mit diesem Widget Design auch viele Template Presets besser.
Section und Widget Editing Components
Xperience liefert von Haus aus einen ganzen Katalog an Editing Components für die unterschiedlichen Eigenschaftsdialoge. Dies kann unter Anderem dazu genutzt werden um z.B. Bilder aus der integrierten Media Library auszusuchen oder um eine Dropdown Liste mit Optionen darzustellen.
Hier ist keine aufwendige Individualentwicklung zu erwarten. Für fast jeden Bedarf steht eine passende Komponente zur Verfügung.
Die Implementierung ist in wenigen Zeilen Code erledigt:
//[...]
/// <summary>
/// The selected image media file
/// </summary>
[EditingComponent(
MediaFilesSelector.IDENTIFIER, Label = "Figure image", Order = 1)]
[EditingComponentProperty(
nameof(MediaFilesSelectorProperties.AllowedExtensions),
".gif;.png;.jpg;.jpeg;.svg;.webp")]
public IEnumerable<MediaFilesSelectorItem> ImageFiles { get; set; }
= Enumerable.Empty<MediaFilesSelectorItem>();
[EditingComponent(
IntInputComponent.IDENTIFIER, Label = "Max. width or height (px)", Order = 2)]
public int MaxWidthOrHeight { get; set; }
/// <summary>
/// Alt Tag to use
/// </summary>
[EditingComponent(
TextInputComponent.IDENTIFIER, Order = 3, Label = "Figure image alt")]
public string Alt { get; set; }
/// <summary>
/// Figure capture text
/// </summary>
[EditingComponent(
TextInputComponent.IDENTIFIER, Order = 4, Label = "Figure caption")]
public string Subtitle { get; set; }
//[...]
Was man nicht machen sollte
Um den Page Builder optimal zu nutzen, sollte man nicht einfach einen fertigen HTML Dummy nehmen und einfach so in eine oder mehrere passende Komponenten zerlegen.
Man sollte stets im Blick haben, welche Eigenschaften am Template, den Sections oder dem Widget einstellbar gemacht werden könnten.
Aus meiner Erfahrung kann ich sagen, dass oftmals der Web-Designer, der das HTML entwickelt, nicht zwingend berücksichtigt, wie das Markup hinterher in Kentico in einzelne Komponeten zerlegt werden könnte.
Idealerweise wird die HTML Entwicklung daher von Kentico Entwicklern unterstützt.
Weiterhin sollten die zu entwickelnden Komponenten, also Templates, Sections und Widgets auf jeden Fall voneinander weitestgehend unabhängig sein.
Andernfalls kann man die Komponenten später nicht uneingeschränkt überall benutzen.
Wenn sich Abhängigkeiten nicht vermeiden lassen, dann sollten die Komponenten durch entsprechende Konfiguration so eingeschränkt werden, dass man nur solche anlegen kann, die in dem entsprechenden Kontext auch funktionieren. Xperience by Kentico bietet dazu gleich mehrere Filtermöglichkeiten an.
Fazit
Der Page Builder von Xperience by Kentico ↗ hat eine sehr gut durchdachte, äußerst flexible, mehrschichtige, leicht zu erweiternde, komponentenbasierte Architektur um sehr schnell und ohne wiederkehrende Entwicklungsaufwände individuellen Content redaktionell aufzubauen.
Mit der richtigen Architektur kann die Redaktion damit schnell, selbstständig, unkompliziert und mit großem Funktionsumfang den Content der eigenen Seite intuitiv anlegen ohne jedesmal einen Entwickler damit beauftragen zu müssen.
Als Entwickler sollte man sich zum Projektanfang etwas Zeit nehmen und gemeinsam mit der Redaktion eine passende Page Builder Architektur für das neue Projekt festlegen, denn diese ist immer von individuellen Projektanforderungen abhängig.
Die Contentpflege ist oft eine wichtige Säule im ganzen System. Entsprechend hoch ist hier das Return on Investment.
Ich persönlich finde diesen Punkt sehr wichtig. Eine schlechte Architektur Entscheidung beim Projektstart führt später oft zu Frustrationen und schlechten Erlebnissen bei der täglichen redaktionellen Arbeit oder zu aufwendigen, nachträglichen Anpassungen. Beides lässt sich leicht vermeiden.
Schreibe einen Kommentar
Du musst angemeldet sein, um einen Kommentar abzugeben.