> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
>
>
> From: Rafal Krzewski [mailto:[EMAIL PROTECTED]]
>
> > "Geir Magnusson Jr." wrote:
> >
> > > 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?
> >
> > As I understand, this macro is for the 5% of the cases when data is
> > placed in the template *unescaped*, hence ident=identity.
> > In the other 95% of the cases, no extra VTL markup is needed
> > to perform
> > the escaping, which makes the way more readable.
> >
> > For me, the Listener registered in the context sounds sensible and I
> > give my non-commiter +1 to it.
>
> I am actually +1 on the general idea myself, but the
> contextual issue is
> bothersome - if in reality the contextual problem arises
> sparingly, and it
> won't be an issue, than I think it's a good thing because it's a
> significantly superior solution to the 'diddle the template' approach.
> However, if thats not the case, and the majorty of use will have to be
> augmented with local/contextual template alteration, then we
> may be creating
> something that will, via performance or complexity, affect
> 99% of the users
> adversely to provide simply a more conceptually convenient
> but in practice
> not useable solution for 1% of the users. Then this
> discussion is worth it.
>
I think what we need to agree, is whether allowing people to alter output of
the insertion is a good idea or not. That is all what the Listener is doing.
So we abstract the issue away from XML escaping and so on.
It is upto the implementors of the Listeners to decide how they code it, how
they control its behavior and so forth. That is not for us to decide, it is
their thingy and they should decide how they want to use it.
I do not think, velocity should provide them, at least not in principle.
> There are a few things which I have been planning to solve
> this way, such as
> the whole 'log on null assignment' issue that is Christophs'
> favorite, the
> whole bit about weather or not to log when on a
> ReferenceException (a $<foo>
> isn't conditionally a reference but you know it and don't
> want it logged...)
> and there was another one (that got me playing with this a while ago),
> although I don't remember off the top of my head what it was.
>
This is more interesting, up to now we have been talking about being able to
alter the output of an insertion just before it will be inserted. What you
are talking here seem to be more ambitious than that since you may be acting
on some intermediate evaluation. Also, we were talking about having A (one)
listener, these looks like you may want to chain them? To be able to do
multiple processing? I would argue that is someone wants that one can write
a listener that delegates to others.
> Performance will be a big issue.
>
It seems that we are talking about an additional "if" statement:
return (listener != null ? listener.beforeInsertion(value) : value);
Do you think this will cause a big impact on the execution? I do not see
why? Now if you set a listener that computed PI everytime, well that is your
problem, not velocity's. :-)
> I'll whiteboard what I have so far if I can find it and some
> time tongiht.
>
Someone else mentioned having something already done, that we can use as a
base for discussion.
> geir
>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
