gmane.comp.jakarta.velocity.user

Re: Added Velocity language parser to CodeMirror

Nathan Bubna — 2012-05-19T14:16:49

Oh, one thing it does appear to be missing is body macros:

#< at >foo()
this is inner content for \#foo()
#end

On Sat, May 19, 2012 at 7:14 AM, Nathan Bubna <nbubna< at >gmail.com> wrote:

Re: Added Velocity language parser to CodeMirror

Nathan Bubna — 2012-05-19T14:14:56

That looks great!

On Sat, May 19, 2012 at 12:11 AM, Steve O'Hara
<sohara< at >pivotal-solutions.co.uk> wrote:

Added Velocity language parser to CodeMirror

Steve O'Hara — 2012-05-19T07:11:55

Just a note to say that I've contributed a language parser/colourizer mode for Velocity to the rather excellent free js package CodeMirror http://codemirror.net/
Looks good but if you spot something I've missed, let me know

Re: a programming exercise integrating velocity with spring ... for general interest of this list

Christopher Townson — 2012-05-11T17:17:13

as a follow up to this old thread on the spring-velocity glue library
I wrote some time back, I have picked up this project again after a
long break -- the first part of which is to move to github
https://github.com/corinthino/spring-velocity

the second part will probably be to update the licence ... and, of
course, anyone is now free to make the necessary changes for this,
should they wish :)

Cheers,

Chris

On 12 May 2011 01:05, Nathan Bubna <nbubna< at >gmail.com> wrote:

Re: More 1.7 BC issues (porting from 1.5)

Sergiu Dumitriu — 2012-05-04T02:49:14

Yep, me.

http://wiki.apache.org/velocity/MacroEvaluationStrategy lists the 
different ways that Velocity treats macro parameters, depending on how 
they're used, what their value is, and what kind of expressions are 
actually used when calling the macro.

I'd say that your example falls in the "call by macro expansion" 
example, which is how true "macros" are supposed to be evaluated, and 
this is what you'd get from a C #define macro as well. You're making the 
same mistake I often do, and think of Velocity as a kind of scripted 
Java, and of macros as a kind of Java functions. Under these 
assumptions, indeed one would expect "call by value" behavior.

Velocity 1.7 moved closer to the "call by macro expansion" model, since 
it is a templating engine, and not a real programming language, even if 
some of its users do use it like one.

Bottom line, I wouldn't call this a regression that needs to be fixed, 
but a bugfix that unfortunately broke compatibility for the few users 
that actually relied on the bu

Re: More 1.7 BC issues (porting from 1.5)

Nathan Bubna — 2012-05-03T20:28:24

I'm at a lost and out of time to look into this.  I'd consider opening
a JIRA issue so this doesn't get forgotten, or maybe someone else will
jump in on this...

On Thu, May 3, 2012 at 12:35 PM, Boris Partensky
<boris.partensky< at >gmail.com> wrote:

Re: More 1.7 BC issues (porting from 1.5)

Boris Partensky — 2012-05-03T19:35:35

Yep.


Not quite same. *With* nested macros  I get empty string in 1.7 and
foobaryokdar in 1.5. *Without* nested macros I get empty string in 1.5
and in 1.7. Below are the test cases for 1.5 and 1.7 that succeed.

1.5

 public void testVelocityForEachNestedMacroInvokeMacroScope() throws Exception
    {
        VelocityEngine ve = new VelocityEngine();

        ve.init();

        String template = "#set($global_types=['foo', 'bar', 'yok',
'dar'])#macro( showBox $input)#set($type = '')$input#end"+
                "#macro(showBoxes $types)#foreach($type in
$types)#showBox($type)#end#end#showBoxes($global_types)";

        StringWriter eval = new StringWriter();
        boolean b = ve.evaluate(new VelocityContext(), eval, "foo", template);
        assertEquals(eval.toString(), "foobaryokdar", eval.toString());

    }

    public void testVelocityForEachNestedMacroInvokeMacroScopeNathan()
throws Exception
    {
        VelocityEngine ve = new VelocityEngine();

        ve.init();

        String template = "#ma

Re: More 1.7 BC issues (porting from 1.5)

Nathan Bubna — 2012-05-03T19:20:25

Ah, it was Sergiu, not Byron.  Here's the relevant discussion:

https://issues.apache.org/jira/browse/VELOCITY-681

On Thu, May 3, 2012 at 12:16 PM, Nathan Bubna <nbubna< at >gmail.com> wrote:

Re: More 1.7 BC issues (porting from 1.5)

Nathan Bubna — 2012-05-03T19:16:37

Ok, for my sanity, is this an accurate rewrite?

#macro( inner $arg )
  #set($ref = '')$arg
#end
#macro( outer )
  #foreach( $ref in ['foo','bar','yok','dar'] )
    #inner( $ref )
  #end
#end
#outer()

Do you get the same behavior in both with this?

#macro( inner $arg )
  #set($ref = '')$arg
#end
#foreach( $ref in ['foo','bar','yok','dar'] )
  #inner( $ref )
#end

Or is it only when the macros are nested?
Also, do you have localscope on for the macros?

I know changes were made in the pass-by-name behavior between 1.5 and
the trunk (2.0-SNAPSHOT), but my memory is failing as to the
chronology of them.  What i do recall (possibly incorrectly), makes me
think this should have been reversed; blank in the older version,
instead of the newer.  I thought we stopped proxying #set calls on
macro args, because while that was arguably a correct way to do
pass-by-name, it was deemed surprising and not worth the
implementation/performance costs.  I seem to recall arguing with
someone about this, maybe Byron?  Well, i'm

Re: More 1.7 BC issues (porting from 1.5)

Boris Partensky — 2012-05-03T18:51:34

Not seeing any errors in log. Corrected to 2 single quotes. Same
behavior. I was hoping that $input in each iteration will not be empty
string, but rather 'foo', 'bar' etc (that's the way 1.5 behaves). Why
would setting a value of $type in parent (foreach) scope would affect
the value of the local $input argument?

String template = "#set($global_types=['foo', 'bar', 'yok',
'dar'])#macro( showBox $input)#set($type = '')$input#end"+
                "#macro(showBoxes $types)#foreach($type in
$types)#showBox($type)#end#end#showBoxes($global_types)";


On Thu, May 3, 2012 at 2:33 PM, Nathan Bubna <nbubna< at >gmail.com> wrote:

Re: More 1.7 BC issues (porting from 1.5)

Nathan Bubna — 2012-05-03T18:33:33

Anything in the log?  #set($type = \"\") is not valid syntax, i think.
 I'm not even sure what value you want $type to have.  Two double
quotes or an empty string?

On Thu, May 3, 2012 at 11:17 AM, Boris Partensky
<boris.partensky< at >gmail.com> wrote:

More 1.7 BC issues (porting from 1.5)

Boris Partensky — 2012-05-03T18:17:02

Hi, I have this use case which involves 2 nested macros and a foreach.
I am trying to understand why this template evaluates to empty string
on 1.7, and to "foobaryokdar" - on 1.5.


String template = "#set($global_types=['foo', 'bar', 'yok',
'dar'])#macro( showBox $input)#set($type = \"\")$input#end"+
                "#macro(showBoxes $types)#foreach($type in
$types)#showBox($type)#end#end#showBoxes($global_types)";

Re: upgrading from 1.5 to 1.7 compatibility issues

Nathan Bubna — 2012-05-01T15:55:09

On Tue, May 1, 2012 at 7:59 AM, Boris Partensky
<boris.partensky< at >gmail.com> wrote:

Hmm.  I think the #evaluate directive also lost its implicit scope,
but i'd have to double check on that.


Yep.  Explicit read/write is the name of the game.  And just to make
sure we're on the same page, $mymacroname scope control would only be
provided when using #macro( mymacroname ) as a macro with a body
(#< at >mymacroname() $mymacroname #end) and you set

mymacroname.provide.scope.control = true

and $mymacroname.parent would only exist if you are nesting calls to
#< at >mymacroname

:)

Re: upgrading from 1.5 to 1.7 compatibility issues

Boris Partensky — 2012-05-01T14:59:36

Ok. Are there any BC corner cases other than nested macros I should be
aware of? I could not really find the No-BC notification you had
mentioned.


Thanks. So, with macro.provide.scope.control =true scoping behavior
should stay the same, and I'd have to explicitly use scope handles to
reach different scopes, like $mymacroname.parent for example, or
$macro.parent. Is this correct?

Thanks
Boris



On Mon, Apr 30, 2012 at 5:08 PM, Nathan Bubna <nbubna< at >gmail.com> wrote:

Re: upgrading from 1.5 to 1.7 compatibility issues

Nathan Bubna — 2012-04-30T21:08:43

On Mon, Apr 30, 2012 at 1:06 PM, Boris Partensky
<boris.partensky< at >gmail.com> wrote:

Yes, compatibility was and is a goal, but with limited resources,
continuing support for implicit scoping in macros didn't make the cut.


"off for compatibility" here means reduced chance of squashing
someone's previous $macro or $template var, or more realistically $foo
when there is a body macro call #foo


$<scope>.parent is always and only made available when there actually
is an explicit parent scope provided. e.g.

#foreach( $a in $b )
   #foreach( $c in $d )
     $foreach.parent here == $foreach.topmost
   #end
  $foreach here == $foreach.topmost
#end

Think parent and topmost as ways to navigate the scope stack, which
only exists when <scope>.provide.scope.control = true


$<scope>.replaced is not a parent scope, but is 'bar' in the example:
#set($foo='bar') #< at >foo $foo.replaced #end

This is a workaround for incompatibilities/migrations/etc.  It doesn't
provide any compatibility with the older implicit system of sco

Re: upgrading from 1.5 to 1.7 compatibility issues

Boris Partensky — 2012-04-30T20:06:01

I am seeing 3 bullet points there pertinent to this issue and all 3
seem to indicate that being compatible was the intention there, or am
I wrong ? The way I read #2 and #3 is that the parent scope should
only be available if I explicitly specify the scope I want (parent or
topmost or replaced).

* For performance and compatibility these are all off by default,
*except* for $foreach. The others may be enabled by setting a velocity
property like:macro.provide.scope.control = true
* When scopes of the same type are nested make the parent Scope
available through the child (e.g. $foreach.parent or
$foreach.topmost).
* When a Scope reference overrides an existing reference that is not a
Scope, make it available through the Scope (e.g. $foreach.replaced).

On Mon, Apr 30, 2012 at 3:51 PM, Nathan Bubna <nbubna< at >gmail.com> wrote:

Re: upgrading from 1.5 to 1.7 compatibility issues

Nathan Bubna — 2012-04-30T19:54:55

This might be of use too:
http://velocity.apache.org/engine/releases/velocity-1.7/upgrading.html

On Mon, Apr 30, 2012 at 12:51 PM, Nathan Bubna <nbubna< at >gmail.com> wrote:

Re: upgrading from 1.5 to 1.7 compatibility issues

Nathan Bubna — 2012-04-30T19:51:56

http://velocity.apache.org/engine/devel/changes-report.html#a1.7

On Mon, Apr 30, 2012 at 12:37 PM, Boris Partensky
<boris.partensky< at >gmail.com> wrote:

Re: upgrading from 1.5 to 1.7 compatibility issues

Boris Partensky — 2012-04-30T19:37:40

No problem, thanks for making things clear.

<< we decided to forego it and notify users of the non-BC change when
we released 1.7.

which notification are you referring to? Wonder if there is something
else in there I am not aware of.


On Mon, Apr 30, 2012 at 2:34 PM, Nathan Bubna <nbubna< at >gmail.com> wrote:

RE: is it possible to maintain a foreach directive after a VelocityEngine.evaluate()?

John McNair — 2012-04-30T19:09:08

I'm not above faking it :)

-----Original Message-----
From: Nathan Bubna [mailto:nbubna< at >gmail.com] 
Sent: Monday, April 30, 2012 3:06 PM
To: Velocity Users List; jmcnair< at >enox.com
Subject: Re: is it possible to maintain a foreach directive after a
VelocityEngine.evaluate()?

No, i don't think there's a way to do that automatically without customizing
your velocity build.  But you can fake it:

#set( $h = '#')
#set( $d = '$' )
#foreach( $element in $object1.elements )

#end
#if( !$object1 )
${h}foreach( ${d}element in $object1.elements )

${h}end
#end

On Mon, Apr 30, 2012 at 11:44 AM, John McNair <jmcnair< at >enox.com> wrote:
evaluates.
evaluation:

Re: is it possible to maintain a foreach directive after a VelocityEngine.evaluate()?

Nathan Bubna — 2012-04-30T19:06:20

No, i don't think there's a way to do that automatically without
customizing your velocity build.  But you can fake it:

#set( $h = '#')
#set( $d = '$' )
#foreach( $element in $object1.elements )

#end
#if( !$object1 )
${h}foreach( ${d}element in $object1.elements )

${h}end
#end

On Mon, Apr 30, 2012 at 11:44 AM, John McNair <jmcnair< at >enox.com> wrote: