Leon Messerschmidt [mailto:[EMAIL PROTECTED]]
> For what it is worth - I like this approach best. It gives
> you the power to
> escape everything that you would like to do, but in the
> exceptional cases
> you are still able to switch the escaping of in a template.
Since you now have to sprinkle Velocimacros around every single use of the
technique you want to use :
#macro(ident, $value)$xml.turnOff(true)$value$xml.turnOff(false)#end
Why not just do the escaping in the Velocimacro itself? Or use a
context-based tool directly?
I still don't get it. The example solution seems to be agreeing with my
contention that just having a listener isn't sufficient to solve the
problem, and you have to add somthing in the template for each instance of
the escaping function.
Now, if you have to surround each insertion with the 'switches', why not
just do the escaping directly, and avoid the overhead and complexity?
geir
> ~ Leon
>
> > The way I see it, from the point of view of velocity,
> whether the listener
> > is intelligent or not is irrelevant. It is upto the
> implementor of the
> > listener to decide how to proceed. The beauty here is that
> from velocity's
> > point of view you are just providing an entry point in which the
> application
> > can add its own processing logic.
> >
> > I could probably write a small listener and acompaning
> macro utilities to
> do
> > that.
> >
> > public class XMLEscape implements InsersionListener
> > {
> > private boolean off = false;
> > public String beforeInsert(String value)
> > {
> > if (off) return value;
> > return escape(value);
> > }
> >
> > public void turnOff(boolean v)
> > {
> > off = v;
> > }
> > ....
> > }
> >
> > #macro(ident, $value)$xml.turnOff(true)$value$xml.turnOff(false)#end
> >
> > Assume the same XMLEscape object is set as the listener and
> the putin the
> > context as "xml".
> >
>
