Velocity: Vorsicht beim trimmen des Outputs

Velocity ist eine tolle Sache. Viel toller als der Internet Explorer jedenfalls. Der IE < 9 beispielsweise crasht, wenn ein Ajax-Response zu groß ist. Zugegeben: Der fragliche Response war auch wirklich groß, so 6 MB oder mehr. Er besteht aber zum Glück größtenteils aus Whitespaces, die daraus resultierten, dass zig Velocity-Templates (jedes mit zig Schleifen) zusammengemerged wurden – und Velocity erhält Whitespace. Man könnte “einfach” alle Whitespaces aus den Templates nehmen, und hätte vermutlich viel gewonnen. Allerdings könnte dann niemand mehr die Templates warten (weil lesen), und das wäre wiederrum nicht so toll.

Deshalb die Idee, den Velocity-Output zu “säubern” (zu trimmen, zu stripen, …). Gesagt getan: Eine Funktion, die die entsprechenden Chars löscht, könnte beispielsweise so aussehen:

Die Rekursion ist deshalb nötig, weil ␣␣␣␣ sonst nur zu ␣␣ statt zu ␣ werden.

Das funktionert auch ganz gut. Blöd, wenn man ein SAP hinter seiner Webseite hat, denn SAP kennt IDs, die zum Beispiel so aussehen: “01101NA50021435513400011␣␣2012081499991231␣␣␣␣␣␣␣␣␣␣000”. Die stehen bei uns in data-Attributen, und müssen so erhalten bleiben. Deshalb musste eine Lösung her, die Whitespaces filtert, aber NICHT in data-Attributen (genauer gesagt heißen die Attribute data-entry-json).

Die Velocity-Jungs empfehlen für das “Whitespace Gobbling” JTidy, aber das funktioniert nicht (out of the box); die Whitespaces in data-entry-json-Attributen bleiben erhalten.

Besser ist der HtmlCompressor, der das zwar auch nicht out of the box kann, der aber die Möglichkeit bietet, eigene Patterns zu definieren, die erhalten bleiben sollen. Laut Doku ist das für bestimmte Tags, aber man kann auch freiere Patterns angeben:

Das obige Pattern sucht nach Tags, die “data-entry-json” enthalten, und sagt dem HtmlCompressor, diese Tags zu erhalten.