Jose Alberto Fernandez wrote:
>
> > 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.
I don't think it boils down to that, as I am not sure that it's
practical to talk about modifications outside of any use context if you
are concerned about simplicity and keeping things svelte. Otherwise,
you devolve to the 'Microsoft Office' design pattern...
The point of discussing is to get other people to offer solutions that
we may not have thought of, before reaching for the compiler. As
expected, for example, Christoph gave a bunch we thought of, and a bunch
we didn't. (At least I didn't.)
> 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.
Has anyone suggested we decide how people code a listener if we added
it? The question was 'do we add it?', or better put, 'do you really
need this?'
> > 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.
That's actually a separate issue - and yes, if we do it, we might as
well let them chain.
> 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.
Of course. As I would argue you can just use a context tool to escape
stuff. But then you argue "it's easier..." and so will I.
> > 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?
No, as written, that won't. We start doing goofy things like
'instanceof', and we're hosed.
We are in a speed race with our WebMacro bretheren, and we are *not*
going to lose! And to be a credible alternative to JSP in high volume
environments, speed speed speed.
> 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.
We can have multiple examples to look at. This has to be more than
dangling things off of the Context. You want a really short path to
decide if a handler is present, for example, and want to make sure that
new ones can be added in a transparent, backwards compatible way.
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
