• Thomas Pollinger
• 24.05.2018
• DE

Weitere sinnvolle und hilfreiche Blockmarkierungen - gibt es die überhaupt?

Im letzten Artikel, dem dritten dieser Serie, hatte ich mich mit der Thematik Navigation mit RenderTags oder doch lieber mit Blockmarkierungen? auseinandergesetzt. Je mehr man sich mit dem Gedanken für neue Blockmarkierungen beschäftigt, desto besser und klarer wird das Bild der noch fehlenden bzw. sinnvollen weiteren Blockmarkierungen.

Daher möchte ich in diesem, dem vierten Artikel dieser Serie, noch weitere Blockmarkierungen vorstellen.
 

Zugriff auf die Session im EditMode

Gerade wenn man für den Editor eine sehr einfache und effiziente Pflegeoberfläche im SmartEdit bereitstellen möchte. Wird es immer wieder nötig auf Daten, welche im System (intern) verwaltet werden, zuzugreifen. Diese werden in der Regel in der s.g. Session gespeichert und stehen zu einem gewissen Teil im Management Server als s.g. Info-Elemente zur Verfügung.

Jedoch wäre es doch schön und einfacher, direkt mit der Session im EditMode zu kommunizieren:

<!IoRangeSession>
    ...
    Variablen (MetaElemente), welche nur innerhalb der aktuellen Session (EditGUI only)
    temporär zur Verfügung stehen. Diese können gesetzt oder abgefragt werden.
    ...
    <%lastAction%> = "..."  Aus Session
    ...
    "..." = <%lastAction%>  In Session
    ...
<!/IoRangeSession>

alternitve Bezeichnung:

<!IoRangeSessionEditMode>
    ...
    <%lastAction%> = "..."  Aus Session
    ...
    "..." = <%lastAction%>  In Session
    ...
<!/IoRangeSessionEditMode>

Damit könnte man sehr einfach im EditMode sich Werte, Objekte und andere Dinge für die aktive Session merken und an anderer Stelle wieder nutzen.
 

Temporäre Variablen bzw. Definitionen

Auch wäre es sehr schick, wenn nicht für alle Berechnungen, Definititionen ein Element anlegen müsste. Wenn man nun s.g. temporäre (bzw. vordefinierte) Variablen anlegen könnte, welche nur intern in der Content-Klasse z.b. für Berechnungen verwendet werden. Damit würden sich viele Anforderungen leichter umsetzen lassen:

<!IoRangePreDefinition>
    ...
    Variablen (MetaElemente), welche nur innerhalb der Content-Klasse temporär zur Verfügung stehen.
    ...
    <%tempVar%> = 3000
    ...
    <%valueIntA%> = 0
    ...
    <%ArrayElement%> = ("A","B","C","D","1")
    ...
<!/IoRangePreDefinition>

oder auch hier wieder alternativ:

<!IoRangeTemp>
    <%tempVar%> = 3000
    ...
    <%valueIntA%> = 0
    ...
    <%ArrayElement%> = ("A","B","C","D","1")
    ...
<!/IoRangeTemp>

Gerade ein temporärer Array, für eine Auswahlliste, welche man z.B. aus einem anderen Backend bekommt oder an Hand anderer Dinge berechnet, wäre ein sinnvolle Erweiterung.
 

Einfache Berechnungen

Auch Blöcke in denen man Dinge berechnen kann, sind sehr hilfreich. Folgendes Beispiel ist immer eine Herausforderung: Man hat einen Container mit drei oder vier Seiten und möchte je Anzahl im Container eine CSS-Klasse z.B. class="m-33" oder class="x-25" einfügen. Dazu müsste man aber die Anzahl haben und in der Content-Klasse eine Berechnung durchführen: 100 / Anzahl = CSS-Klassenwert.

operator + - / * ≈ auf Typ: FLOAT, INT oder DATE
 
<!IoRangeMath>
    ...
    <%valueIntA%> - 1
    ...
    <%valueIntA%> + <%tempVar%>
    ...
    <%valueIntA%> + <%valueIntB%>
    ...
    <%valueDateA%> - (1).asDate("day")
    ...
    <%valueDateA%> - (1).asDate("hour")
    ...
<!/IoRangeMath>

Auch in Kombination mit den zuvor erläuterten Definitions- oder temporären Variablen macht dies Sinn:

<!IoRangePreDefinition>
    ...
    <%tempVar%> = <!IoRangeMath><%valueIntA%> + 3000<!/IoRangeMath>
    ...
<!/IoRangePreDefinition>

bzw.

<!IoRangeTemp>
    ...
    <%tempVar%> = <!IoRangeMath><%valueIntA%> + 3000<!/IoRangeMath>
    ...
<!/IoRangeTemp>

Damit könnte man sehr viele Anforderungen bzw. aus heutiger Sicht "Herausforderungen" ohne Probleme einfach und schnell lösen.
 

Include vom Filesystem des Servers

Der nächste Punkt wird auch immer wieder angefordert und benötigt. Dateien bzw. Fragmente, welche aus anderen Systemen angeliefert werden, beim Publizieren in die Seite einfügen.

<!IoRangeInclude>
    ...
    <%FileRepositoryElement%>
    ...
<!/IoRangeInclude>

Ja, es ist bestimmt nicht so einfach im Management Server, dass ordentlich und korrekt einzubauen. Denn man muss das Rechte- und Dienstkonten-Thema betrachten und auch andere Dinge, welche im Zusammenspiel mit dem Betriebssystem stehen. Jedoch mit einem definierten Regelwerk, wo und wie mal solche Dateien für den Management Server bereitstellen muss, damit es funktioniert. Würde bestimmt eine Möglichkeit schaffen und somit wieder eine regelmäßig diskutierte Anforderung einfach lösen.
 

Image-Gallery

Hier nun noch ein Beispiel aus unserem Slack, was schon sehr lange und auch immer wieder anfordert wurden. Bildergallerien oder Bilderstrecken bzw. Teaser-Rotatioen usw. sind quasi auf jeder Webseite zu finden. Daher ein Vorschlag aus der Usergroup von Angelika Kusel und Christoph Straßer:

<!IoRedDot_ImageListMyGallery>
<!IoRangeImageList>
    <span class="xxx">
        <img src="<%ImageListMyGallery%>" alt="<%attributeDescription%> (Quelle: <%attributeSource%>)" />
    </span>
<!/IoRangeImageList>

Das ist aus meiner persönlichen Sicht eine extrem sinn- und sehr wertvolle Erweiterung bei den Blockmarkierungen.
 

Nützlicher Helfer

Zum Schluss nochmals kurz zusammengefasst, die bereits vorgestellten Blockmarkierungen für Entwickler-Kommentare. Und auch die Dokumentationsblöcke in Templates, sowie die definierten Bereiche, welche für eine korrekte Arbeitsweise der Blockmarkierungen nötig ist, aber nicht in der publizierten Seite ausgespielt werden sollen. Jetzt aber mal in einer dafür definierten Kategoriefarbe:

Kommentare

<!IoRangeComment>
    ...
    Hier steht Text, welcher beim Publizieren nicht ausgegeben wird (removed)
    ...
<!/IoRangeComment>
 
= Ersatz für <!IoRangeNoRedDotMode><!IoRangeRedDotMode> ... <!/IoRangeRedDotMode><!/IoRangeNoRedDotMode>

Dokumentation

<!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

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

Beispiel vorher:

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

Beispiel nachher:

<!IoRangeDynLink><a id="<%infoPageID%>"><%headlinePage%></a>
    <!IoRangeNoOutput><%anchorDynamic%><!/IoRangeNoOutput>
<!/IoRangeDynLink>

Rendermodes

= Modus 0
<!IoRangePreviewMode> ... <!/IoRangePreviewMode>
statt:
<!IoRangeNoRedDotMode> ... <!/IoRangeNoRedDotMode>
 
= Modus 1
<!IoRangeEditMode> ... <!/IoRangeEditMode>
<!IoRangeEditModeOn> ... <!/IoRangeEditModeOn>
<!IoRangeEditModeOff> ... <!/IoRangeEditModeOff>
statt:
<!IoRangeRedDotMode> ... <!/IoRangeRedDotMode>
<!IoRangeRedDotEditOnly> ... <!/IoRangeRedDotEditOnly>
<!IoRangeNoEditMode> ... <!/IoRangeNoEditMode>
 
= Modus 2
<!IoRangePublishMode> ... <!/IoRangePublishMode>

Active Templating

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

<!IoRangePreExecute>
    ...
    Dieser Block wird nur innerhalb des CMS zur Laufzeit (Preview/Publish)
    ausgeführt und nicht im SmartEdit. Er muss entsprechenden Code
    (z.B. C#, VBScript, PHP etc. enthalten) => PreExecute-Regeln via
    extra AppPool.
    ...
<!/IoRangePreExecute>

---

Fazit

Auch weitere neue Blockmarkierungen gepaart mit einer erweiterten Farbwelt, sieht erstmal bunt aus. Jedoch beim zweiten Blick wird die lesbarkeit beschleunigt und die Komplextität für den Content-Klassen-Ersteller reduziert.

Auch kann man, mit den aktuell bis jetzt vorgestellten Blockmarkierungen, komplett auf die derzeit vorhandenen RenderTags komplett verzichten. Jedoch muss aber noch deutlich angemerkt werden, die Custom-RenderTag-API (etc.) macht nach wie vor Sinn und sollte auch dauerhaft erhalten bleiben. Denn diese ist dann, was absolut logisch ist, für sehr spezielle Kundenwünsche als Schnittstelle oder Integrationsmöglichkeit für Drittsysteme bzw. Inhalte.

Wer nun meint, es wäre Schluss und es gibt nichts mehr zu zeigen was sinnvoll wäre. Der wird sich über nächsten Artikel noch mehr freuen, welcher das Thema hat: Highend Blockmarkierungen für die ganz speziellen Fälle - wäre sowas überhaupt denkbar?

---

Über den Autor: