You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Sebastian Lisken <li...@Mathematik.Uni-Bielefeld.DE> on 2004/08/05 17:33:39 UTC

request: new event handler to "hook" expression insertion

Hi, I'm a Velocity beginner, so please forgive me if I am overlooking
something obvious. But i think there is a gap in the Velocity API that
could easily be filled and, if it is, would make using Velocity much
easier, especially in environments where VLT expression results need
to conform to some kind of syntax prescribed by their environment,
such as XML. I came across

http://jakarta.apache.org/velocity/developer-guide.html#Velocity%20and%20XML

, where it says "One issue that arises with XML and Velocity is how
to deal with XML entities." That is my issue exactly. I want to make
sure the data written into my XML won't contain the special characters
<, >, ", & in unencoded form (&lt; and such is what I want instead).

The obvious solution is to put some object into your Context that
has an encoding method, and then call $obj.encode(VLTexpression) on
your results. The page I mentioned considers ways of making this
easier (shorten the sytax), three strategies are shown:

1. define a Velocimacro, shortening the call to #macro(VLTexpression)

2. put your results in a variable, provide a helper object with a
get(key) method which will, when called with that variable's name,
retrieve the value from the context, and mangle it - the syntax
now becomes #set( $var = VLTexpression ) / $helper.var (extends
across two lines actually, the slash is a line break)

3. Write your own context which can change the way variable values
are inserted; the syntax now is #set( $var = VLTexpression ) / $var
(two lines again).

It seems to me that another obvious strategy is

4. Use a ReferenceInsertionEventHandler instead of some context,
easier to code, but for the template writer nothing changes compared
to strategy 3.

I am unhappy with all of these solutions because I want to write
just the VLTexpression, still wanting it to be "mangled" (encoded,
in my example). I put the problem down to the fact that strategies
3 & 4 (and I don't see any other) can only "hook in" when variables
are inserted. Why not provide another "hook" that gets activated
whenever any expression result is inserted? I assume every expression
evaluates to some kind of object (possibly a wrapper such as Integer)
and toString() is then called on that object and the result inserted.
Why not hand this over to an event handler before inserting the
result? Something like

interface ExpressionInsertionEventHandler {
   String expressionInsert(expression, result);
}

, where in my situation I would only be interested in the result
and XML-encode it, but one could provide the original expression
for convenience. This would not exclude the possibility of a
ReferenceInsertionEventHandler being used beforehand to insert
parts of the expression (those that reference variables).

Comments, support, alternatives?

Sebastian

---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org


Re: request: new event handler to "hook" expression insertion

Posted by Sebastian Lisken <li...@Mathematik.Uni-Bielefeld.DE>.
I wrote:
> interface ExpressionInsertionEventHandler {
>   String expressionInsert(expression, result);
> }

I suppose it makes little sense to pass in the original expression
after it's been evaluate. Does one want to re-evaluate it? Maybe
there should be two events, before and after expression evaluation.
The "before" handler would get the original expression and could
stop Velocity from evaluating further. One way of doing this would
be to expose Velocity's own expression handling mechanism through
some method. It would be the event handler's responsibility to call
that, with the original expression or some modified version of it.
Post-processing would be another useful option (the one I'd use in
my example), but without inspecting the original expression perhaps.
That would give us something like

interface PostExpressionEvaluationHandler {
   public String expressionInsert(String velocityResult);
}

interface PreExpressionEvaluationHandler {
   public Object expressionInsert(String vltExpression);
}


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org