Best practice for escaping?

[Ahmed Mohombe <am...@yahoo.com>]

Hi,

Is there a best practice on how to escape a velocity template.
(so in order to generate another velocity template?).

The escaping rules are clear however it seems a nightmare to me
to apply them because of the fact that 'undefined' variables are threated
different by the escape rule.

The problem is that some variables exist both in the source and the target template.
At the moment I tried so many 'tweakings' and I never get what I expect.
I'm at the point to use another template engine to generate velocity templates,
just to avoid the escaping nightmare.

Thanks in advance,

Ahmed.


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

Re: Best practice for escaping?

[Ahmed Mohombe <am...@yahoo.com>]

> These two techniques are what I've used to write templates that
> generate other velocity templates.   As Ahmed says, it makes the code
> hard to read, but there aren't any better options in Velocity yet.
That's why the pragmatic(but ugly) solution at the moment is to use another
template language/engine(that won't interfere with the syntax from Velocity).

> In the Objective C templating engine I used before Velocity, it was
> handled by changing the starting and ending delimiters.   Ie, instead
> of #{if}, you'd change the delimiters to <*if*>.
Well that's an interesting approach.

> Velocity doesn't currently support changing delimiters (or even
> starting/ending delimiters for directives), 
Are there any plans for the future to support this type of 'changing' in Velocity?

> so you'll have to use
> something else if you aren't willing to live with escaping all # and $
> symbols.    
Well, personally I could live with them. Unfortunately, those escaping rules are too much for
'simple users'. As I mentioned, some of the templates will be maintained/created
by them.

> While maintaining such templates is a nightmare, creating
> them initially isn't a big deal since you can just do a global find
> and replace of both symbols.
Well, yes, but I'm not sure if simple users can do the same. Also a big problem
are the 'errors' in the templates: while a programmer can live with them by debugging or by 
searching very quickly the source of the problem, simple users just 'blame the system'.

Thanks in advance,

Ahmed.


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

Re: Best practice for escaping?

[Mike Kienenberger <mk...@gmail.com>]

These two techniques are what I've used to write templates that
generate other velocity templates.   As Ahmed says, it makes the code
hard to read, but there aren't any better options in Velocity yet.

In the Objective C templating engine I used before Velocity, it was
handled by changing the starting and ending delimiters.   Ie, instead
of #{if}, you'd change the delimiters to <*if*>.

Velocity doesn't currently support changing delimiters (or even
starting/ending delimiters for directives), so you'll have to use
something else if you aren't willing to live with escaping all # and $
symbols.    While maintaining such templates is a nightmare, creating
them initially isn't a big deal since you can just do a global find
and replace of both symbols.

On 10/27/05, Nathan Bubna <nb...@gmail.com> wrote:
> personally, my recommendation would be to ditch the escaping rules for
> variables and go with the following:
>
> #set( $D = '$' )
> ${D}myVar
>
> or you can add the new EscapeTool (in VelocityTools 1.2-rc1) to your
> context and do:
>
> ${esc.d}myVar
>
> escaping is really a pain if you aren't sure whether a variable will
> be there or not.  i haven't done it to generate another velocity
> template, but the thought is unpleasant. :)
>
> On 10/27/05, Ahmed Mohombe <am...@yahoo.com> wrote:
> > Hi,
> >
> > Is there a best practice on how to escape a velocity template.
> > (so in order to generate another velocity template?).
> >
> > The escaping rules are clear however it seems a nightmare to me
> > to apply them because of the fact that 'undefined' variables are threated
> > different by the escape rule.
> >
> > The problem is that some variables exist both in the source and the target template.
> > At the moment I tried so many 'tweakings' and I never get what I expect.
> > I'm at the point to use another template engine to generate velocity templates,
> > just to avoid the escaping nightmare.
> >
> > Thanks in advance,
> >
> > Ahmed.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-user-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>

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

Re: Best practice for escaping?

[Ahmed Mohombe <am...@yahoo.com>]

>>>personally, my recommendation would be to ditch the escaping rules for
>>>variables and go with the following:
>>>
>>>#set( $D = '$' )
>>>${D}myVar
>>>
>>>or you can add the new EscapeTool (in VelocityTools 1.2-rc1) to your
>>>context and do:
>>>
>>>${esc.d}myVar
>>>
>>>escaping is really a pain if you aren't sure whether a variable will
>>>be there or not.  i haven't done it to generate another velocity
>>>template, but the thought is unpleasant. :)
>>
>>Thank you very much for the fast reply.
>>
>>Unfortunately if I 'obfuscate' the templates, the possibility for an error would
>>be even bigger.
> not sure how
> ${D}myVar
> is more of an obfuscation than
> #if( $myVar )\$myVar#else$myVar#end
Yes, you are right :), your example is convincing :).

>>It's seems to me much simpler at the moment to generate the velocity templates
>>with another template engine that has a totally different syntax, so that it won't
>>interfere with the velocity variables, defined or not or have the same name
>>in the source template with the destination template. Not to mention the escaped directive lines
>>that behave again different from at variable pespective.
> there's precious few directives.  it should be simple to escape those
> properly.  but still, you're right that it will probably be visually
> easier to use a different template engine.
Yes, this was my first thought, but this (with another template language) works only if
one makes only once the transformation :). To use a third language just because it might
be another level of transformation is not very practical :)(one might simply not find a
third one that is 'orthogonal' on the first two :). ).

>>I wonder why there isn't a more elegant solution for such situations :(.
> actually... there may be.  i forgot about the #literal() directive in
> my previous response.  it's a block directive used to prevent
> interpolation of its contents.  
This sounds very interesting. I found however no mention in the 1.4 documentation
about it.

>>Maybe it has nothing to do with the syntax, but the Velocity syntax is very easy and clean in a
>>direct form.
>>IMHO the escaped syntax should be as easy, and comprehensible, so that one understands from a simple
>>sight what's up there. 
> 
> well, it can be pretty simple.  if the variable is present, use
> \$variable  and if it's not, just use $variable.  but if you can't
> ensure the presence or absence of a variable, then it's a bit more
> difficult.
Well in most of the cases, I can't ensure the status of a variable, since
this may vary, depending on the many factors. Besides, some of the templates
must be edited by 'simpler users' - that have a little knowledge of HTML but not more.
The plain Velocity syntax looks for them however pretty simple :), but the escaping rules
look under some circumstances complicated even for programmers :).

>>Unfortunately I found no tool that handles the escaped template gracefully :(, so that at least with
>>syntax highlight to make it evident.
> yeah, i don't think i've ever seen syntax highlighting for Velocity
> that was advanced enough to handle this well.
This is also pretty strange, considering how many projects use Velocity, and how much time(and 
errors) could save a plug-in that would be a little more 'intelligent' than just simple editor :).

I suppose for the moment, I'll stick with another 'orthogonal' template language, to avoid escaping, 
and later I'll try to find a

Thank you very much for your help!.


Ahmed.


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

Re: Best practice for escaping?

[Nathan Bubna <nb...@gmail.com>]

On 10/27/05, Ahmed Mohombe <am...@yahoo.com> wrote:
> > personally, my recommendation would be to ditch the escaping rules for
> > variables and go with the following:
> >
> > #set( $D = '$' )
> > ${D}myVar
> >
> > or you can add the new EscapeTool (in VelocityTools 1.2-rc1) to your
> > context and do:
> >
> > ${esc.d}myVar
> >
> > escaping is really a pain if you aren't sure whether a variable will
> > be there or not.  i haven't done it to generate another velocity
> > template, but the thought is unpleasant. :)
> Thank you very much for the fast reply.
>
> Unfortunately if I 'obfuscate' the templates, the possibility for an error would
> be even bigger.

not sure how

${D}myVar

is more of an obfuscation than

#if( $myVar )\$myVar#else$myVar#end

> It's seems to me much simpler at the moment to generate the velocity templates
> with another template engine that has a totally different syntax, so that it won't
> interfere with the velocity variables, defined or not or have the same name
> in the source template with the destination template. Not to mention the escaped directive lines
> that behave again different from at variable pespective.

there's precious few directives.  it should be simple to escape those
properly.  but still, you're right that it will probably be visually
easier to use a different template engine.

> I wonder why there isn't a more elegant solution for such situations :(.

actually... there may be.  i forgot about the #literal() directive in
my previous response.  it's a block directive used to prevent
interpolation of its contents.  it's not well-documented, but that's
partly because it is dead-simple.

perhaps you'll find that more elegant.  i've never used it myself and
don't know the details of your situation, so i hesitate to say that it
is.

> Maybe it has nothing to do with the syntax, but the Velocity syntax is very easy and clean in a
> direct form.
> IMHO the escaped syntax should be as easy, and comprehensible, so that one understands from a simple
> sight what's up there.

well, it can be pretty simple.  if the variable is present, use
\$variable  and if it's not, just use $variable.  but if you can't
ensure the presence or absence of a variable, then it's a bit more
difficult.

> Unfortunately I found no tool that handles the escaped template gracefully :(, so that at least with
> syntax highlight to make it evident.

yeah, i don't think i've ever seen syntax highlighting for Velocity
that was advanced enough to handle this well.

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

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

Re: Best practice for escaping?

[Ahmed Mohombe <am...@yahoo.com>]

> personally, my recommendation would be to ditch the escaping rules for
> variables and go with the following:
> 
> #set( $D = '$' )
> ${D}myVar
> 
> or you can add the new EscapeTool (in VelocityTools 1.2-rc1) to your
> context and do:
> 
> ${esc.d}myVar
> 
> escaping is really a pain if you aren't sure whether a variable will
> be there or not.  i haven't done it to generate another velocity
> template, but the thought is unpleasant. :)
Thank you very much for the fast reply.

Unfortunately if I 'obfuscate' the templates, the possibility for an error would
be even bigger.

It's seems to me much simpler at the moment to generate the velocity templates
with another template engine that has a totally different syntax, so that it won't
interfere with the velocity variables, defined or not or have the same name
in the source template with the destination template. Not to mention the escaped directive lines 
that behave again different from at variable pespective.

I wonder why there isn't a more elegant solution for such situations :(.

Maybe it has nothing to do with the syntax, but the Velocity syntax is very easy and clean in a 
direct form.
IMHO the escaped syntax should be as easy, and comprehensible, so that one understands from a simple 
sight what's up there.
Unfortunately I found no tool that handles the escaped template gracefully :(, so that at least with 
syntax highlight to make it evident.

Ahmed.


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

Re: Best practice for escaping?

[Nathan Bubna <nb...@gmail.com>]

personally, my recommendation would be to ditch the escaping rules for
variables and go with the following:

#set( $D = '$' )
${D}myVar

or you can add the new EscapeTool (in VelocityTools 1.2-rc1) to your
context and do:

${esc.d}myVar

escaping is really a pain if you aren't sure whether a variable will
be there or not.  i haven't done it to generate another velocity
template, but the thought is unpleasant. :)

On 10/27/05, Ahmed Mohombe <am...@yahoo.com> wrote:
> Hi,
>
> Is there a best practice on how to escape a velocity template.
> (so in order to generate another velocity template?).
>
> The escaping rules are clear however it seems a nightmare to me
> to apply them because of the fact that 'undefined' variables are threated
> different by the escape rule.
>
> The problem is that some variables exist both in the source and the target template.
> At the moment I tried so many 'tweakings' and I never get what I expect.
> I'm at the point to use another template engine to generate velocity templates,
> just to avoid the escaping nightmare.
>
> Thanks in advance,
>
> Ahmed.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>

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