Fwd: Integrating string escaping into the VTL proper

[Nathan Bubna <nb...@gmail.com>]

Hi Jochen,

Please feel free to send emails like this to
velocity-dev@jakarta.apache.org list.  It is the ideal place for such
discussions!  In fact, i hope you do not mind, but i am going to CC
the dev list in my reply, as i would like my response to be archived
for others with such questions to find.  Please forgive me if that is
not ok with you.

I agree (and i'm know Will would too) that easy and/or automatic
escaping of xml and html is a great feature.  In fact, we've been
adding and talking about such features a fair bit of late:

- the latest VelocityTools 1.2 release includes the EscapeTool for
escaping html, xml, sql, java, and javascript (among other misc
functions).  This is basically the corollary of the JSTL <c:out> tag
that JSP developers use for escaping html.  The syntax is quite simple
$esc.xml($foo).

- the upcoming Velocity 1.5 release includes some snazzy new
EventHandlers from Will that can provide totally automatic escaping
of--again--html, xml, sql, java, and javascript.  These are not
something that can be fully controlled from a template, but it does
provide the option of expression matching reference names to allow the
developer to give the template author some control over what is or is
not escaped.

- there is also talk of including a more fundamental "reference
interceptor" ability in a future version of Velocity to allow
contextual and more object-type based (rather than reference name
based) control over the rendering of references.  This overlaps the
ReferenceInsertionEventHandlers described above in ways, but i think
it will ultimately prove to be a more powerful, flexible, and simpler
way to do what you describe.  For instance, with the ability to
interrogate the context during rendering of a reference value, it
would be possible for the developer to give the template author the
#set( $default_escaping = 'html' ) ability that you described.  To my
knowledge, this cannot be done with EventHandlers.  Of course, there
is much left to be discussed before this feature is implemented and
released.

Thanks for the suggestions and opportunity to spread a little
knowledge about upcoming (and potentially upcoming) features! :)

-nathan

On 4/22/06, Jochen Eddelbüttel <jo...@eddelbuettel.net> wrote:
> Hi Nathan and Will,
>
> with HTML and XML being such important target formats for Velocity
> applications, the need for escaping seems to be pervasive. Even with the
> advent of a generic escaping tool the templates still suffer tremendously in
> their legibility.
>
> Could you consider a direct incoporation of escaping into VTL?
>
> I was thinking something like
>
>         $html@object.method(...)
>
> or
>
>         $!xml@object.Property
>
> or
>
>         $!{java@user.LocalMailAccount}@apache.org
>
> Even knowing the target format there is no way to tell whether a template
> author would need escaping. It may not be a frequent situation but the stuff
> being added from the Java Beans into the template may need to be HTML tags.
> So putting in &lt; and &gt; would ruin the show. But the template author
> could be handed a way to set the default escaping himself, with something
> like
>
> #set( $default_escaping = "html" )
>
> The default escaping would only be applied to the top level of nested
> refereces, i.e. the strings that actually end up being written out instead
> of being used as parameters.
>
> Not knowing much about the theory of MVC design while doing it, I've
> successfully powered a web frontend for an invoice verification and approval
> process with Velocity. I came across Velocity before having even the
> slightest idea of JSP. I don't know how JSP gurus tackle their woes with
> escaping (probably some tag libs), but I'm confident that Velocity could
> really outshine JSP in this area, if escaping could be included directly in
> VTL.
>
> So thanks for all your effort and keep up the good work!
>
> Regards,
>
> Dr. Jochen Eddelbüttel
> Sr. Document and Workflow Management Consultant
> Hamburg, Germany
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org