commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wannheden, Knut" <>
Subject [jelly] outputing unescaped xml
Date Wed, 02 Apr 2003 11:50:30 GMT
Hi all,

I recently posted this message to a thread in commons-user, but I didn't get
any response.  As the content seems more apropriate in this list and I'd be
really interested in comments I hereby pick the thread up again.

In summary the discussion is about how XMLOutput should consume text content
with characters like '<' and '&' in it -- XML escape it or not?

The following script demonstrates the "problem":

<j:jelly xmlns:j="jelly:core">

	<j:set var="foo">


I expected the output to be "<foo></foo>" but it is actually

It was suggested that setting the "encode" attribute of the <j:set/> tag to
false would fix the problem.  This does however for two resons not solve the

 1. The "encode" attribute controls whether body text passed to the
XMLOutput should be encoded using XML entities.  The keyword being _text_.
The body of the <j:set/> tag does however not contain any text, only an XML
element which Jelly parses into a tag (StaticTag).  So there is no text to
encode in the XMLOutput anyway.

 2. The value of the variable "foo" is the String "<foo></foo>".  When this
variable is dereferenced with "${foo}" in the script it is naturally written
as a String to the XMLOutput of the enclosing <j:jelly/> tag.  And now,
since an XMLOutput instance by default escapes body text, the variable value
gets consumed and as "&lt;foo&gt;&lt;/foo&gt;" in the XMLOutput.

Now the question is whether the current behaviour of Jelly in a case like
this is actually the desired behaviour.  If not, then the solution would be
to change the factory methods in XMLOutput to return an instance which
doesn't escape body text using XML entities, unless otherwise specified.

Of course, if this change was made, then the quesion of how to output XML in
escaped form comes up.  Should Jelly provide a tag (as <x:escape/>) for this
purpose?  Or should the "encode" attribute be available for all tags (like
"trim")?  IMHO the best solution would be to change the default behaviour of
XMLOutput so it doesn't escape body text and provide a tag for escaping.

What do you think?

I'd be happy to write patches for this as soon as a concensus is reached.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message