• Thomas Pollinger
• 10.05.2018
• DE

Blockmarkierungen vs. RenderTags - Warum braucht man noch beides?

Seit einiger Zeit geistern bei mir im Kopf, was ich auch schon bei uns im Slack andiskutiert habe, Ideen rum. Dabei geht es um Dinge, wie man bei Web Site Management - in meinem Fall insbesodere beim Management Server - wieder vereinfachen kann.

Denn wir bei uns im Unternehmen beobachten immer wieder Fälle, bei denen sich die Anwender, Projekt-Admins oder Template-Enabler schwer tun. Vor allem wenn man bestimmte Tätigkeiten nicht so häufig oder intensiv durchführt.

Daher möchte ich mich - und als Vorbereitung für die anstehende Usergroup in München - mit einer Artikelserie erstmal um diese Themenblöcke visionär widmen:

• Blockmarkieren
• Elementsystem und Custom Content Element
• RenderTags und Custom RenderTags bzw. Navigations-Manager

Im ersten Artikel geht es primär um den Bereich "Templating", welche wir bereits im aktuellen Release haben.

Ich würde mich freuen, wenn man zu den einzelnen Artikel in unserem Slack auch intensiv diskutieren würde, damit man auch die anderen Blickwinkel auf diese Themenblöcke mitbekommt.

---

Blockmarkierungen

Die s.g. Blockmarkierungen werden in der Online-Hilfe von Release 16 wie folgt beschrieben:

Über Blockmarkierungen können bestimmten Abschnitten im Code eines Templates bestimmte Funktionen zugeordnet werden. Beispielsweise steuern Sie über Blockmarkierungen, welcher Code in welcher bestimmten Ansicht sichtbar ist oder welche Bereiche bei dynamischen Elementen berücksichtigt werden sollen.

Über die Liste Blockmarkierungen setzen Sie eine Blockmarkierung in Ihren Code. Wenn Sie zu einem Bereich des Codes eine Blockmarkierung wählen, wird der Code des gewählten Bereichs von einem Anfangs- und einem End-Tag der jeweiligen Blockmarkierung eingerahmt. Die eingefügten Tags sind grün hinterlegt.

Blockmarkierungen sind in den Content-Klassen bzw. deren Templates wie folgt gekennzeichnet:

<!IoRangeBlocktyp>
  ...
<!/IoRangeBlocktyp>

Es gibt folgende Blocktypen im Management Server:

• Rückverweis
  Mit diesem Blocktyp bestimmen Sie Beginn und Ende eines Rückverweises. Mit einem Rückverweis erzeugen Sie auf einer Seite Links zu allen Seiten, die diese Seite aufrufen.

<!IoRangeBack>
  ...
  <%Anchor%>
  ...
<!/IoRangeBack>

• Breadcrumb
  Mit dieser Blockmarkierung umrahmen Sie den Code, der für die Breadcrumb-Navigation verwendet werden soll.

<!IoRangeBreadCrumb>
  <%Breadcrumb%>
<!/IoRangeBreadCrumb>

• Konditional
  Diesen Blocktyp verwenden Sie, damit der damit umrahmte Templatecode nur dargestellt bzw. generiert wird, wenn alle Elemente innerhalb dieser Markierung mit Inhalten gefüllt sind.

<!IoRangeConditional>
  ...
  <%Image%>
  ...
<!/IoRangeConditional>

• Datenbankabfrage
  Mit diesem Blocktyp setzen Sie Beginn und Ende einer Datenbankabfrage fest. Der umrahmte Textblock muss mindestens ein Element vom Typ Datenbankinhalt enthalten.

<!IoRangeData>
  ...
  <ÚtenbankElement%>
  ...
<!/IoRangeData>

• Drag & Drop
  Mit diesen Blockmarkierungen können Sie Drop-Bereiche für Struktur-Elemente festlegen.

<!IoRangeDragDrop>
  ...
  <%Container%>
  ...
<!/IoRangeDragDrop>

• Dynamisch
  Der von diesem Blocktyp umrahmte Bereich ist dynamisch erweiterbar, das heißt, alle Tags und Elemente, die in diesem Abschnitt enthalten sind, werden wiederholt, wenn Sie den als dynamisch gekennzeichneten Bereich unter Projektstruktur verwalten erweitern. Über die Blockmarkierung ist die dynamische Erweiterung eines Link-Elements nur in SmartEdit sichtbar. Um die dynamische Erweiterung in der Projektstruktur des SmartTree sichtbar zu machen, weisen Sie dem Link-Element zusätzlich die Eigenschaft Dynamisches Element zu. Diese Funktion kann nur für die Link-Elemente Anchor, Container und Liste verwendet werden.

<!IoRangeDynLink>
  ...
  <%AnchorDynamisch%>
  ...
<!/IoRangeDynLink>

• Trefferliste
  Mit dieser Blockmarkierung bestimmen Sie Beginn und Ende einer Trefferliste. Der umrahmte Textblock muss ein Element vom Typ Trefferliste enthalten.

<!IoRangeHit>
  ...
  <%TrefferListe%>
  ...
<!/IoRangeHit>

• Liste
  Mit dieser Blockmarkierung bestimmen Sie Beginn und Ende einer Liste. Der umrahmte Code muss ein Element vom Typ Liste enthalten.

<!IoRangeList>
  ...
  <%Liste%>
  ...
<!/IoRangeList>

• Pre-Execute Bereich
  Mit dieser Blockmarkierung umrahmen Sie Skriptblöcke, die als Active Templates bereits in SmartEdit ausgeführt werden sollen.

<!IoRangePreExecute>
  ...
  ActiveTemplating Code
  ...
<!/IoRangePreExecute>

• SmartEdit-Modus
  Der von diesem Blocktyp umrahmte Bereich ist nur im SmartEdit-Modus sichtbar und steht nicht in der generierten Seite. In der publizierten Seite und in der Seitenvorschau ist der Bereich nicht zu sehen.

<!IoRangeRedDotMode>
  ...
<!/IoRangeRedDotMode>

• Nicht im SmartEdit-Modus
  Der von dieser Blockmarkierung umrahmte Bereich erscheint in der publizierten Seite und ist nicht im SmartEdit-Modus sichtbar.

<!IoRangeNoRedDotMode>
  ...
<!/IoRangeNoRedDotMode>

• SmartEdit-Modus Seite offen
  Der von dieser Blockmarkierung umrahmte Bereich ist im SmartEdit nur zu sehen, sobald der Redakteur die Seite über den OpenPage RedDot geöffnet hat. Der Abschnitt ist nicht in der publizierten Seite oder in der Seitenvorschau sichtbar.

<!IoRangeRedDotEditOnly>
  ...
<!/IoRangeRedDotEditOnly>

• SmartEdit-Modus Seite geschlossen
  Der von dieser Blockmarkierung umschlossene Bereich ist nur in der geschlossenen Seite in SmartEdit sichtbar. In der publizierten Seite und in der Seitenvorschau ist der Bereich nicht zu sehen.

<!IoRangeNoEditMode>
  ...
<!/IoRangeNoEditMode>

Diese Blockmarkierungen sind das Herzstück der Content-Klassen bzw. Templates im Management Server. Und der Vorteil, man kann diese Blockmarkierungen auch in Kombination verwenden. Dazu aber später noch mehr.

Reicht das aus?

Die o.g. Liste der Blockmarkierungen ist überschaubar und für das aktuelle Elementsystem sinvoll - jedoch auch ausreichend? Meiner Meinung nach reichen die aktuellen Blockmarkierungen nicht aus und daher werden diese immer wieder mit den folgenden RenderTag-Bedingungen vermischt:

• RenderMode
• If/Else
• ForEach
• Navigation
• Inline-Funktionen
• Berechnungen
• usw.

Wenn man sich die o.g. Blockmarkierungen ansieht fällt auf, dass man bei einigen Blocktypen nicht alle notwedigen Varianten implementiert hat. Wie z.B. bei

SmartEdit Modus:

<!IoRangeRedDotMode>
  ...
<!/IoRangeRedDotMode>

Seitenvorschau/Publizierungs Modus:

<!IoRangeNoRedDotMode>
  ...
<!/IoRangeNoRedDotMode>

denn hier fehlt noch der Modus, welcher klar zwischen Publizierung und Seitenvorschau trennt. Daher kommen immer wieder die RenderTags mit komplexen If/else Abfragen auf den CurrentRenderMode zum tragen.

Ebenso gibt es unterschiedliche Implementierungen für ähnliche Abläufe, wie bei Active-Templating...

...zur Laufzeit:

<!--RDExecute=[*]-->

und bei der Publizierung:

<!IoRangePreExecute>
  ...
<!/IoRangePreExecute>

---

Was könnte man ändern?

Die Blockmarkierungen sind eine feine Sache - noch lange nicht in die Jahre gekommen - und halten das Templating im Management Server einfach. Jedoch nur solange, wie man ausschließlich mit Blockmarkierungen und Elementen auskommt. Sobald etwas fehlt und man auf ActiveTemplating oder RenderTags - oder sogar beides in Kombination - zurückgreifen muss. Dann wird es komplex und man muss sich bestimmten Regeln unterwerfen, welche Stefan Buchali in seinem Artikel Die RedDot-Reihenfolge und C# im PreExecute: Tipps, Tricks und böse Fallen sehr gut aufgezeigt hat.

Daher möchte ich in nächsten Artikeln Beispiele aufzeigen, wie man das aktuelle Blockmarkierungssystem sinnvoll erweitern könnte und somit die Komplexität in den Templates deutlich für die Projekt-Admins reduziert.

Ebenso möchte ich etwas provokant andiskutieren, ob dann RenderTags überhaupt noch nötig sind bzw. ob man darauf nicht sogar komplett verzichten kann. Jedoch dazu mehr im nächsten Artikel: Erweiterungen bei den Blockmarkierungen - Warum macht das Sinn?

---

Über den Autor: