Jose Alberto Fernandez wrote:
> Geir :
> > Jose :
> > > The point is that within the template code you know, in
> > principle, the
> > > syntactic context in which you are expanding. Therefore you
> > could direct
> > > your custom listener to do different things at different points.
> >
> > Hm. So the listener would be fired at every insertion. How
> > do you know
> > syntactically where you are in the template if you have no information
> > other than the glob that Vel wants to insert into the stream?
> >
>
> You can control that from the context. No one says that the "custom"
> listener needs to be dum. The hooking mechanism for Velocity must be simple
> but not how the listener works.
Doesn't that mean you then have to put something in the template for
each reference to talk to the listener?
> > If you don't know, then processing the output stream at once with a
> > filter or tool is equivalent, right?
> >
> > Isn't doing it from strategic points in the template much better via a
> > context tool, or wrapping in a VM?
> >
>
> It is a question of percentages, I guess. If 95% of your insersions require
> escaping. Is it reasonable to provide a mechanism to reverse tell your
> listener to stop escaping and use that in the 5% of the cases when you do
> not require escaping.
>
> How can one achive that?
> Well you can provide access to your custom listener from the context. And
> control it. You can define macros and so on. But the point of all these is
> that you will need to use them much less than the other way around.
>
> The whole point of this is giving you choices on how to acomplish what you
> want.
Sure. Choice is great. But at some point the question becomes "given
the number of already available choices that appear to solve the
problem, does it make sense to add another special-purpose solution?"
That's all I'm trying to plumb here...
> > >
> > > That, and the fact that constant text in the template does
> > not get affected
> > > by the listener operation, I think are good reasons against
> > postprocessing.
> > >
> >
> > That's true, if your template is setup with the constant stuff
> > pre-escaped.
> >
> > But if the template is intended for XML-only output, meaning you have
> > stuff pre-escaped, then whats wrong with wrapping the dyanmic inserts
> > via context tool?
> >
> > I am not against a listener interface, per se. I have been thinking
> > hard about this for similar purposes, but didn't want to do anything
> > before 1.0. I guess what I don't understand, is why in-template
> > solutions aren't appropriate.
> >
>
> As I said, it is a question of percentages. What do you want the default to
> be given the problem space you are confronting.
Yes - true - in this case, this corner of the general Velocity problem
space is small based on my experience with Velocity and WM.
> And I am sure this is not only an XML issue. I am sure there will be other
> problem domains that can be approached the same way.
Sure. There are a bunch of things that a listener approach could
address...
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
