• Thomas Pollinger
• 14.05.2018
• DE

Erweiterungen bei den Blockmarkierungen - Warum macht das Sinn?

Im letzten Artikel aus dieser Serie Blockmarkierungen vs. RenderTags - Warum braucht man noch beides? habe ich angekündigt, dass es Sinn machen würde die Blockmarkierungen auszubauen.

Der Grund für die Aussage liegt in der Einfachheit der Blockmarkierungen und der eleganten Handhabung im Content-Klassen/Template-Editor. Im Gegensatz zu den RenderTags, ist man mit Blockmarkierungen direkt in der Lage, durch markieren von HTML-(Markup)-Blöcken und dann einfügen von Blockmarkierungen, die Templates für Content-Klassen schnell zu erstellen.

Wenn RenderTags zum Einsatz kommen, wird es schon aufwändiger. Da die RenderTags schon mehr Programmierkenntnisse voraussetzen. Dazu kommen wir aber noch in einem späteren Artikel genauer.

Jetzt ersteinmal zu dem eigentlichen Thema dieses Artikels. Warum es Sinn macht, den aktuellen Bestand der Blockmarkierungen zu erweiteren.

---

Einfache Erweiterungen

Als erstes möchte ich ein paar Vorschläge für einfache Erweiterungen von bestehenden Blockmarkierungen aufzeigen. Dazu gehören auch teilweise eine neue Benennung, damit dies später ins Gesamtschema passt.

---

Hinweis: Eine sofortige Umbenennung bzw. Ersetzung des ursprünglichen Namens einer Blockmarkierung ist nicht mein primäres Anliegen. Daher sollte dies in Stufen passieren und über den Weg von s.g. Aliasnamen über eine bestimmte Zeitspanne, bis die Originalnamen verschwinden.

---

Ausführung von Code zur Laufzeit oder Publizierung

Hier erstmal eine ganz einfache Erweiterung:

<!IoRangeRDExecute>
    ...
    Dieser Block wird nur innerhalb des CMS (MS) zur Laufzeit
    (im SmartEdit/Preview) ausgeführt und nicht bei der Publizierung.
    Es muss entsprechender Code (z.B. C#, VBScript, PHP etc.) vorhanden
    sein => Läuft innerhalb des CMS .NET AppPool und unterliegt diesen Regeln.
    ...
<!/IoRangeRDExecute>

und dieser Blocktyp bleibt unverändert:

<!IoRangePreExecute>
    ...
    Dieser Block wird nur innerhalb des CMS zur Laufzeit (im Preview/Publish)
    ausgeführt und nicht im SmartEdit.
    Es muss entsprechenden Code (z.B. C#, VBScript, PHP etc.) vorhanden
    sein => PreExecute-Regeln über einen eigenen .NET AppPool sind möglich.
    ...
<!/IoRangePreExecute>

Damit man einfacher und schneller erkennt, um welche Form des ActiveTemplating es sich handelt. Und man keine zwei unterschiedlichen Schreibweisen benötigt.
 

Rendermodes 2.0

Bei den RenderTag kann man schon zwischen 3+n Rendermodes unterscheiden. Die wichtigsten sind dabei:

• Modus 0: Wenn man die Seite im Seitenvorschau-Modus öffnet.
• Modus 1: Wenn man die Seite in SmartEdit-Modus öffnet.
• Modus 2: Wenn man die Seite veröffentlicht (publiziert).

Dies wäre mit unterschiedlichen Blockmarkierungen auch sehr einfach möglich:

 

Modus 0

Seitenvorschau:
<!IoRangePreviewMode>
  ...
<!/IoRangePreviewMode>


ein Alias für bestehenden Blocktyp:
<!IoRangeNoRedDotMode>
  ...
<!/IoRangeNoRedDotMode>

Dieser Blocktyp existiert bereits und gibt diese eingeschlossenen Bereiche nur in der Seitenvorschau aus. Jedoch ist die Empfehlung diesen eindeutiger zu benennen.

 

Modus 1

SmartEdit:
<!IoRangeEditMode>
  ...
<!/IoRangeEditMode>


ein Alias für bestehenden Blocktyp:
<!IoRangeRedDotMode>
  ...
<!/IoRangeRedDotMode>

Seite offen:
<!IoRangeEditModeOn>
  ...
<!/IoRangeEditModeOn>


ein Alias für bestehenden Blocktyp:
<!IoRangeRedDotEditOnly>
  ...
<!/IoRangeRedDotEditOnly>

Seite geschlossen:
<!IoRangeEditModeOff>
  ...
<!/IoRangeEditModeOff>


ein Alias für bestehenden Blocktyp:
<!IoRangeNoEditMode>
  ...
<!/IoRangeNoEditMode>

Diese drei Blocktypen sind ebenfalls nicht neu, jedoch eindeutiger benannt und arbeiten nur im Editiermodus (SmartEdit).

 

Modus 2

Publizierung:
<!IoRangePublishMode>
  ...
<!/IoRangePublishMode>

Dieser neue Blocktyp würde dann, die darin eingeschlossenen Beriche, nur bei der Publizierung in die Seite rendern.

 

Kommentare oder Notizen innerhalb der Templates

Auch Kommentare sind diese kleinen Dinge, welche einem das Content-Klassen/Template-Editor Leben erleichtert würden:

<!IoRangeComment>
    ...
    Hier steht Text, welcher beim Publizieren nicht ausgegeben wird (removed)
    ggfs. macht es Sinn diese Kommentarblöcke noch in der Seitenvorschau im
    s.g. Projektvarianten-Entwurfsmodus anzuzeigen.
    ...
<!/IoRangeComment>


ein Ersatz für den Workaround:
<!IoRangeNoRedDotMode><!IoRangeRedDotMode>
  ...
<!/IoRangeRedDotMode><!/IoRangeNoRedDotMode>

 

Dokumenation innerhalb der Content-Klassen bzw. Templates

Auch einen direkte Dokumentation innerhalb der Templates wäre eine sehr gute Erweiterung. Diese  Dokumentation könnte man dann in einem standardisierten Format (z.B. Markdown) auslesen, anzeigen oder exportieren z.B. in ein Git, in dem dann auch die Template-Exporte liegen:

<!IoRangeDocumentation>
    ...
   Hier steht Text, welcher als Documentation innerhalb der Content-Klassen dient.
   Diese Blöcke können später in einem noch zu definierenden Format
   (z.B. Markdown etc.) ausgegeben, abgefragt oder auf andere Art und Weise
   verwendent werden.
    ...
<!/IoRangeDocumentation>

 

Keine Ausgabe bei der Publizierung

Es gibt auch immer wieder den Fall, dass man z.B. bei einem Konditional-Block auf einige Elemente mit UND reagieren möchte, jedoch die Ausgabe aller oder einige Elemente einfach nicht an dieser Stelle brauchen kann (bei Listen oder dynamischen Anchor, wenn man Elemente hochreicht):

<!IoRangeNoOutput>
    ...
    Hier steht Element, welches z.B. für
 
        <!IoRangeConditional>
          ...
        <!/IoRangeConditional>
 
    oder
 
        <!IoRangeList>
          ...
        <!/IoRangeList>
 
    benötigt wird (z.B. Liste etc)
    ...
<!/IoRangeNoOutput>


ein Ersatz für den Workaround:
<!IoRangeNoRedDotMode><!IoRangeRedDotMode>
  ...
<!/IoRangeRedDotMode><!/IoRangeNoRedDotMode>

Beispiele:

Aktuell:
<!IoRangeDynLink>
  <a id="<%infoPageID%>"><%headlinePage%></a>
  <!IoRangeNoRedDotMode><!IoRangeRedDotMode>
    <%anchorDynamic%>
  <!/IoRangeRedDotMode><!/IoRangeNoRedDotMode>
<!/IoRangeDynLink>

Mit neuem Blocktyp:
<!IoRangeDynLink>
  <a id="<%infoPageID%>"><%headlinePage%></a>
  <!IoRangeNoOutput><%anchorDynamic%><!/IoRangeNoOutput>
<!/IoRangeDynLink>

oder bei dem besagten Konditional-Blocktyp:

Aktuell:
<!IoRangeConditional>
    <a id="<%infoPageID%>"><%headlinePage%></a>
    <!IoRangeNoRedDotMode><!IoRangeRedDotMode>
      <%anchorDynamic%>
    <!/IoRangeRedDotMode><!/IoRangeNoRedDotMode>
<!/IoRangeConditional>

Mit neuem Blocktyp:
<!IoRangeConditional>
    <a id="<%infoPageID%>"><%headlinePage%></a>
    <!IoRangeNoOutput><%anchorDynamic%><!/IoRangeNoOutput>
<!/IoRangeConditional>

oder in Kombination:

Aktuell:
<!IoRangeConditional>
  <!IoRangeDynLink>
    <a id="<%infoPageID%>"><%headlinePage%></a>
    <!IoRangeNoRedDotMode><!IoRangeRedDotMode>
      <%anchorDynamic%>
    <!/IoRangeRedDotMode><!/IoRangeNoRedDotMode>
  <!/IoRangeDynLink>
<!/IoRangeConditional>

Mit neuem Blocktyp:
<!IoRangeConditional>
  <!IoRangeDynLink>
    <a id="<%infoPageID%>"><%headlinePage%></a>
    <!IoRangeNoOutput><%anchorDynamic%><!/IoRangeNoOutput>
  <!/IoRangeDynLink>
<!/IoRangeConditional>

---

Komplexere Erweiterungen

Es gibt aber auch Blocktypen, wenn man auf RenderTags ganz verzichten möchte, die aktuell noch nicht komplett zur Verfügung stehen. Dazu gehören Bedingungen und auch Schleifen.

Bei den nachfolgenden Bedinungen, handelt es sich um sinnvolle Erweiterungen zum s.g. Kontitional-Blocktyp:

If/Else - Bedingung

<!IoRangeIf>
    <%ConditionElement%>
    <!IoRangeThen> ... <!/IoRangeThen>
    <!IoRangeElse> ... <!/IoRangeElse>
<!/IoRangeIf>

So eine If/Else Bedingung ist qausi selbst erklärend. Es wird eine zuvor definierte Abfrage auf "true" (then) oder "false" (else) geprüft. Und jeweils der damit umschlossene Block ausgegeben.

 

If Exists/Else - Bedingung

<!IoRangeIfExists>
    <%Element%>
    <!IoRangeThen> ... <!/IoRangeThen>
    <!IoRangeElse> ... <!/IoRangeElse>
<!/IoRangeIfExists>

Bei dieser Bediegung geht es darum, dass man z.B. an einer Liste, für eine Instanz einer Content-Klasse, prüfen möchte ob ein bestimmtes Inhaltselement vorhanden ist. Es wird eine zuvor definierte Abfrage auf "true" (then) oder "false" (else) geprüft. Und jeweils der damit umschlossene Block ausgegeben.

Man kann sich aber auch noch andere Varianten vorstellen, auf die möchte ich aber in einem späteren Artikel tiefer eingehen.

 

Switch/Case - Bedingung

<!IoRangeSwitch>
    <%ConditionElement%>
    <!IoRangeCase> <ÊseElementA%> ... <!/IoRangeCase>
    <!IoRangeCase> <ÊseElementB%> ... <!/IoRangeCase>
    <!IoRangeCase> <ÊseElementC%> ... <!/IoRangeCase>
    <!IoRangeCase> <ÊseElementD%> ... <!/IoRangeCase>
    <!IoRangeElse> ... <!/IoRangeElse>
<!/IoRangeSwitch>

Ein Switch/Case ist ein Klassiker und würde (wie auch jetzt schon mit RenderTags) komplexe If/Else Konstrukte verhindern. Es wird auf eine Abfrage reagiert, jedoch wie bei diesem Bedingungstyp üblich, mit mehreren Werten und einem Default.

 

Auch bei den Schleifen, welche sinnvolle Erweiterungen zum s.g. Listen-Blocktyp wären:

ForEach - Schleife

<!IoRangeForEach>
    ...
    <%ArrayElement%>
    <%Liste%>
    <%Container%>
    oder
    <%Optionsliste%>
    ... 
<!/IoRangeForEach>

wäre eine flexiblere Erweiterung zur:

<!IoRangeList>
    ...
    nur <%Liste%> möglich
    ... 
<!/IoRangeList>

Blockmarkierung, welche nur mit Listen funktioniert.

 

For Do - Schleife

<!IoRangeFor>
    <%ConditionElement%>
    <!IoRangeDo>
        ...
    <!/IoRangeDo>
<!/IoRangeFor>

Welche nur bei bestimmten Bedingungen auf z.B. alle Elemente einer Liste oder eines Arrays reagiert. Das wäre z.B. wenn man auf eine bestimmte Kombination von Inhaltselementen prüfen möchte usw. Und nicht nur, ob das Element gefüllt ist oder nicht, sondern auch auf bestimmte Inhalte.

---

Hinweis: Die in den Beispielen gezeigten <%ArrayElement%> und <%ConditionElement%> Elemente, werden in einem späteren Artikel auch noch genauer erläutert.

---

Zwischen-Fazit

Man sieht, es gäbe genug Potential sich von den RenderTags komplett zu trennen, wenn man bestimmte Funktionalitäten in Form von angepassten und neuen Blockmarkierungen zur Verfügung hätte.

Das ganze Thema kann man aber auch noch weiter denken und auch auf die Navigation ausweiten. Dazu mehr im nächsten Artikel: Navigation mit RenderTags oder doch lieber mit Blockmarkierungen?

---

Über den Autor: