• Thomas Pollinger
• 23.11.2017
• DE/EN

RenderTags: Encode/Decode of strings or element values rendered by RenderTags

Seit Release 11.2 SP2 HF3 (11.2.2.725) gibt es eine Menge an neuen Escape RenderTags, die einen bei der Erstellung von Content-Klassen und Projekten unterstützen.

Hier ein Auszug aus den Release Notes:

Encode/Decode of strings or element values rendered by RenderTags

Element values and strings can be transformed via RenderTag. The following transformations are available:

• String HtmlEncode
  Converts a string into an HTML-encoded string. For example, the special characters < and > are encoded as < and >.
• String HtmlDecode
  Decodes an HTML-encoded string into a decoded string. For example, the special characters < and > are then decoded as < and >.
• String UrlEncode
  Encodes a string to meet the restrictions for an URL.
• String UrlDecode
  Decodes a string that has been encoded for transmission in an URL into a decoded string.
• String HtmlAttributeEncode
  Encodes a string to meet the restrictions for attributes in HTML.
• String JavaScriptEncode
  Encodes a string for use in JavaScript.

Example UrlEncode:
If the headline of the current page is "My homepage", the following expression results in the string "My homepage":

<%!! Context:CurrentPage.Headline.UrlEncode() !!%>

Please note that some elements have the option “Do not convert characters to HTML”. If this option is not checked, element values are converted to HTML. If using the HtmlEncode method as described above on those element values, the value will be encoded twice.

Jedoch es gibt auch noch ein paar Dinge zu beachten

Mein Kollege hat rausbekommen, dass wenn man diesen RenderTag nutzt:

<%!! Context.CurrentPage.GetElementByName(elementName).Value.JavaScriptEncode() !!%>

wird für JavaScript korrekt encodiert. Verwendet werden die Notationen \xHH (ASCII Hex) und \uHHHH (Unicode Hex) (H= hexadezimalers Zeichen). Für JSON allerdings nicht, da in JSON kein \x notiert werden darf. Nur \u ist ein gültig encodiertes Zeichen.

Man kann dies aber einfach ersetzen, da die ersten 255 Zeichen in der \u00HH Notation gleich sind. Somit muss für einen JSON kompatiblen String noch ein .Replace(Str:\x, Str:\u00) angefügt werden:

<%!! Context.CurrentPage.GetElementByName(elementName).Value.JavaScriptEncode().Replace(Str:\x,Str:\u00) !!%>

Hinweis: In der Online-Hilfe und den PDF-Unterlagen wird immer noch die alte Notation des Encodings verwendet z.B. <%!! Escape:HtmlEncode(...) !!%>. Diese bringt aber Risiken, vor allem wenn man z.B. mit Standardfeldern in Content-Klassen arbeitet, welche nicht immer befüllt werden müssen - sprich leer sind. Dann erzeugt die alte Notation des Escape-Providers im wsms.log Fehler. Da ein Encoding auf "NULL" nicht zulässig ist. Es empfiehlt sich auf jeden Fall, nur noch die neue Schreibweise zu verwenden. Da diese in den geschilderten Fehlerfall nicht reinlaufen kann.

Siehe dazu den Artikel: Root Cause Analysis: "EscapeLoader.OnGetObject ... Object reference not set to an instance of an object."

Fazit

Die neuen Ecoding-Funktion sind sehr hilfreich und ergänzen sich sehr gut. Jedoch sind diese noch nicht vollständig für die heutigen bzw. aktuellen Ansprüche. Ein z.B. Base64Encode/Decode, MD5Encode/Decode (also ein Encrypt/Decrypt, mit bekanntem SharedSecretKey oder ähnlichem) oder ein JSONEncode/Decode wären noch eine sinnvolle Ergänzung :)

Über den Autor: