Jose Alberto Fernandez wrote:
> 
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> >
> >
> > Jose Alberto Fernandez wrote:
> > >
> > > The point here is not how to escape but that the regular
> > way to do this,
> > > i.e., pass your value thru a function, or write a macro
> > that calls that
> > > function; they just polute the template and makes the whole
> > thing dificult
> > > to read.
> > >
> > > The need is for a mechanism that can perform this
> > transformations implicitly
> > > without having to call something everytime we type "${....}".
> > >
> >
> > What's the downside again for postprocessing the rendered stream?  I
> > don't remember...
> >
> 
> Not sure what you mean, but don't you usually need to know the syntactic
> context to decide what kind of processing to do?

I'm not sure.  Seems like if thats the case, then just using something
like

 $foo.escape( $blargh )

in the template would solve the problem.  Or a VM 

#escape($blargh)

and define the VM as appropriate.  Or...

Seems that Velocity has all the capability you need as is :

1) use a context tool in the template
2) use a Velocimacro in the template
3) Postprocess the rendered stream
4) Make your own writer to hand to velocity that will do the firing as
vel writes into it.
 
> 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?

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?

> 
> 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.

geir

-- 
Geir Magnusson Jr.                               [EMAIL PROTECTED]
Developing for the web?  See http://jakarta.apache.org/velocity/

Reply via email to