> > If you are going to insert an raw xml blob then you would
> > probably be able
> > to assume that the blob of XML will be valid xml as generated
> > by the xml
> > source. Otherwise it can't be called an XML blob - just some
> > text with
> > random tags that looks like XML. You don't need to set the
> > listener for
> > these.
>
> Ah. So you *would* have to contextually switch the listener on and off?
If you forget to switch the listener off the page will just not work. It
won't seem to work and only bomb out when you enter a certain character or
combination of characters. You know from the start that there is a bug to
fix. This is something I can teach template designers - If the page is not
working from the start, you're doing something wrong. If it works most of
the time and breaks sometimes it is harder to teach.
> > 1. I have template designers that will forget to call
> > #escape(). I am
> > willing to bet money on that. The showstopper is that with
> > 99% of the cases
> > it'll work not to call #escape. Only when somebody actually enters an
> > entity will the bug show up. It is very hard to track
> > forgotten #escape's.
>
> But what if they forget to swtich the listener on and off? same deal,
> right?
Same as above.
> > 2. Because the XML parser stops with an exception it is not
> > an issue of
> > just an artefact on the screen. A customer will see an error
> > screen even a
> > possible java stack trace just because he entered a string
> > containing an
> > entity.
>
Same as above.
> And please understand that I am not just screwing around arguing with all
of
> you. What I can't seem to personally understand if how this would really
> work, in real life, w/o having to do all the things you are claiming you
> don't want to do.
In real live I would hardly ever need to switch the escaping off; there
isn't one example in my whole app that requires a switch off. I can however
switch it of in the template if I need to at some stage, but it will not
happen often (if ever). A Listener will clean up 99.9% of templates, plus
it would simplify debugging.
> If you have to switch the listener on and off each time, and that is
> acceptable, there is nothing that prevens you adding the listener to a
> wrapper for your stream, right?
Right, but I'm not going to switch on/off.
> To be transparent in what I am trying to do : I am trying to see if we can
> avoid adding complexity to the velocity core if numerous 'external'
> solutions already exist.
>
> This is a creative and talented bunch...
That's why I'm here - to soak up the creativity & talent :-) And I am
really grateful to you especially for all your hours.
~ Leon
