• Thomas Pollinger
• 28.05.2018
• DE

Highend Blockmarkierungen für die ganz speziellen Fälle - wäre sowas überhaupt denkbar?

Mit diesem und erstmal letztem Artikel aus dieser Serie, möchte noch weitere interessante Ergänzungen vorstellen. Wie schon zuvor in den Artikeln:

• Blockmarkierungen vs. RenderTags - Warum braucht man noch beides?
• Erweiterungen bei den Blockmarkierungen - Warum macht das Sinn?
• Navigation mit RenderTags oder doch lieber mit Blockmarkierungen?
• Weitere sinnvolle und hilfreiche Blockmarkierungen - gibt es die überhaupt?

geht es um die Erweiterung der Blockmarkierungen und den daraus resultierenden möglichen Rückbau der RenderTags. Angenommen, man kann jeden RenderTag durch eine Blockmarkierung ersetzen und bekommt alles zusammen lauffähig. Was würde dann noch fehlen, damit man in der heutigen Zeit die Anforderungen an ein Content Managament System (CMS) erfüllen kann?

Sprich, was müsste der Web Site Management Server (RedDot CMS) noch innerhalb der Blockmarkierungen bereitstellen?

Wenn man sich die RenderTags im Management Server und die Dynaments im Delivery Server anschaut. So kann man sich selbst die Frage sehr schnell und einfach beantworten...
 

Inline-Funktionen

Eine sehr mächtige und gleichzeitig flexible Möglichkeit, Inhalte zu beeinflussen, sind Inline-Funktionen. Diese werden sowohl bei den RenderTags, als auch bei den Dynaments bereitgestellt. Jedoch sind das keine neue Funktionalitäten, denn alle anderen Programmier- oder Script-Sprachen wie z.B. JavaScript, PowerShell, C#, Java usw. stellen derartige Funktionen ebenfalls bereit.

Also warum, wenn schon der Management Server auf C# basiert, diese nicht auch bei den Blockmarkierungen zum Einsatz bringen. Geht so was überhaupt? Ich behaupt ja und möchte nachfolgend einige Beispiele vorstellen.
 

Boolean

<%Element.StartsWidth()%>
<%Element.EndsWidth()%>
<%Element.Contains()%>
<%Element.Match()%>

Die hier gezeigten Inline-Funktionen sind in erster Linie interessant, wenn man Bedinungen innerhalb der Blockmarkierungen benutzen möchte.
 

String

<%Element.ToLower()%>
<%Element.ToUpper()%>
<%Element.SubString()%>
<%Element.Replace()%>
<%Element.RegExReplace()%>
<%Element.Trimm()%>
<%Element.Split()%>

Auch immer wieder gerne genutzt sind die String-Funktionen, welche es einem ermöglicht die Ausgabe noch zu optimieren - die Rückgabe erfolgt immer als String.
 

Int/32/64

<%Element.IndexOf()%>
<%Element.LastIndexOf()%>
<%Element.Length()%>
<%Element.Count()%>

Ebenfalls häufig genutzt sind Funktionen, welche die zuvor genannten String-Funktionen unterstützen - die Rückgabe erfolgt immer als Int.
 

Encoding

<%Element.HtmlEncode()%>
<%Element.HtmlDecode()%>

<%Element.UrlEncode()%>
<%Element.UrlDecode()%>

<%Element.HtmlAttributeEncode()%>

<%Element.JavaScriptEncode()%>
<%Element.JavaScriptDecode()%>

<%Element.JsonEncode()%>
<%Element.JsonDecode()%>

<%Element.MD5Encode()%>

<%Element.Base64Encode()%>
<%Element.Base64Decode()%>

Encoding ist gerade im Web eine wichtige Angelegenheit. Daher sollten auch diese Funktionen nicht fehlen und so gut wie möglich vollständig vorhanden sein - die Rückgabe erfolgt immer im entsprechenden Format.
 

Casting

<%Element.AsGuid()%>
<%Element.AsHtml()%>
<%Element.AsXml()%>
<%Element.AsJson()%>
<%Element.AsString()%>
<%Element.AsInt32()%>
<%Element.AsInt64()%>
<%Element.AsFloat()%>
<%Element.AsBoolean()%>
<%Element.AsDate()%>
<%Element.AsArray()%>
<%Element.AsObject()%>

Aber auch ein Typ-Casting bei der Ausgabe ist immer eine feine Sache. Vor allem wenn man aus einem String zum Beispiel eine Zahl extrahiert und diese dann echte Zahl z.B. Int32 weiter verarbeiten möchte. Oder einen Array als JSON bzw. XML direkt in die Seite ausgeben. Es gibt sehr viele Varianten wie man Datentypen korrekt ausgeben und dabei eine gewisse Typsicherheit sicherstellen möchte - die Rückgabe erfolgt immer im entsprechenden Format.
 

Navigation

<%Element.NavigationHasChildren()%>
<%Element.NavigationIsSelected()%>

<%Element.NavigationNextLevel()%>
<%Element.NavigationSubIndexes()%>

<%Element.NavigationCurrentIndex()%>
<%Element.NavigationFirstIndex()%>
<%Element.NavigationLastIndex()%>
<%Element.NavigationRootIndex()%>

<%Element.NavigationCurrentLevel()%>
<%Element.NavigationCurrentDepth()%>

<%Element.NavigationPath()%>
<%Element.NavigationPathArray()%>

Ob man noch alle aktuellen Rendetagtag-Navigation-Funktionen benötigt oder nicht, wird anhängig von der Implementierung der Blockmarkierungen in Kombination mit dem Navigation-Manager sein. Jedoch sollte es immer sinnvoll und funktionabel implementiert werden, statt einfach nur vorhanden zu sein.
 

Was ist damit?

<%Element.MainLink()%>
<%Element.OwnerPage()%>
<%Element.Id()%>
<%Element.Template()%>

und viele weitere...

Aktuell bin ich mir selbst nicht sicher ob man diese Abfrage dann noch benötigt oder man diese nicht einfach per Attribute oder Infoelemente lösen kann ;)

---

Fazit

Mit den insgesamt fünf Artikeln über das Thema "Erweiterung der Blockmarkierungen". Habe ich versucht auszuzeigen, dass es mehr als sinnvoll ist sich - voll und ganz - auf eine Rendering-Methode zu konzentrieren.

Die Blockmarkierungen haben das System groß, einfach und effizient gemacht. Jedoch mit Einzug der RenderTags stieg auch der Anspruch an die Administratoren bzw. Content-Klassen Entwickler und die Komplexität. Jedoch wurde damit keine Steigerung der Funktionalität erreicht, ganz im Gegenteil. Man hat über Jahre versucht die Funktionalität der Blockmarkierungen in den RenderTags abzubilden und hat dadurch eine parallele Welt geschaffen. 

Beide Render-Methoden sind nicht komplett und eine richtig gute Zusammenarbeit werden beiden Methoden nicht nachgesagt. Also nicht ohne sehr schräge und vergewaltigende Konstrukte, welche dann die Lesbarkeit und Pflege der Content-Klasse extrem erschweren.

Jedoch eine Sache ist wichtig, die Custom-RenderTag-API ist wichtig für das System. Gerade wenn man spezielle Drittsysteme integrieren möchte und diese Einbindung bei der Publizierung der Seite passieren soll. Dann sind die Custom-RenderTags eine sehr mächtige, elegante und zielsichere Methode.

Ebenso wichtig sind die Custom Content Elemente, welche die - sofern das seitens OpenText umgesetzt werden sollte - die Blockmarkierungen sehr stark unterstützen würden.

Wenn man sich die Technologien genau betrachtet, wäre ein 90/10 Verhältnis für die Blockmarkierungen wünschenswert. Denn wenn man bis zu 90% (oder sogar noch mehr) mit den Elementen und Blockmarkierungen abdecken könnte. Dazu noch spezielle Anforderungen mit Custom-Content-Elementen ( ca. 5%) ergänzt und Drittsysteme beim Rendering der Seiten über die Custom-RenderTags (ca. 5%) zusätzlich integrieren kann. Dann sehe ich eine sehr rosige Zukunft für den Management Server für die kommenden Jahre.

Denn damit sinkt für den Großteil der Projekt-Anforderungen die Komplexität und sorgt zeitlich dafür, dass die Umsetztungsgeschwindigkeit steigt. 

Doch eines muss allen bewußt sein, dies wird nicht ohne ein Umbau in den Projekten möglich sein. Denn wenn eine Technologie entfernt werden soll, muss man die darauf bestehenden Implementieren auch ersetzen bzw. migrieren.

Da dies jedoch ein einmaliger Aufwand ist, welchen man ggfs. durch eine gewisse Abwärtskompatibilität, über einen angemessenen Zeitraum vornehmen kann. Wäre das aus meiner Sicht verschmerzbar und ein schöne Gelegenheit, um Altlasten in den Projekten loszuwerden.

Daher hoffe ich auf ein wachsames Auge in Oldenburg, damit man sich dazu Gedanken macht bzw. die Ideen hier aus den Artikeln in der (Produkt-)Entwicklung durchspricht oder sogar direkt einfließen lässt.

---

Über den Autor: