velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Bubna <nbu...@gmail.com>
Subject Re: upgrading from 1.5 to 1.7 compatibility issues
Date Mon, 30 Apr 2012 19:51:56 GMT
http://velocity.apache.org/engine/devel/changes-report.html#a1.7

On Mon, Apr 30, 2012 at 12:37 PM, Boris Partensky
<boris.partensky@gmail.com> wrote:
> 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@gmail.com> wrote:
>> Congratulations, Boris.  You are the corner case we feared.  :-/  We
>> knew when we went ahead with this that providing a migration path
>> would be difficult.  We knew most users didn't have extreme numbers of
>> macros and hoped that those who didn't frequently nest them, in part
>> because of the complexities of heavy scoping in a language that often
>> treated scoping as a second-class feature, and in part because of the
>> performance issues macros had prior to 1.6.  #parse,
>> VelocityLayoutServlet and even custom tools, which lack the implicit
>> scoping support, tended to be more performant and encouraged for
>> simplifying complicated tools.  Considering those things and the
>> difficulty of implementing a BC switch for implicit scoping, we
>> decided to forego it and notify users of the non-BC change when we
>> released 1.7.
>>
>> Sorry.  It sounds like it's going to take some legwork to upgrade in
>> the cases where you nested your macros.
>>
>> On Mon, Apr 30, 2012 at 11:16 AM, Boris Partensky
>> <boris.partensky@gmail.com> wrote:
>>> Yep, I am afraid we do set globals from within macros...
>>>
>>> On Mon, Apr 30, 2012 at 2:05 PM, Nathan Bubna <nbubna@gmail.com> wrote:
>>>> Can you set velocimacro.context.localscope = true or is it important
>>>> for your system to be able to #set global stuff from within macros?
>>>>
>>>> On Mon, Apr 30, 2012 at 10:50 AM, Boris Partensky
>>>> <boris.partensky@gmail.com> wrote:
>>>>> Thanks Nathan, I think I do get the whole scoping idea, but my
>>>>> understanding was that one of the reasons to turn all scoping off by
>>>>> default (and have those properties to begin with) was to provide
>>>>> backward compatibility - as in: I upgrade to 1.7 and then I start
>>>>> turning on all those nice bells and whistles and use scopes and what
>>>>> not. Not so seems like? I also find somewhat strange that a a formal
>>>>> argument to a macro takes precedence and overwrites a global variable
>>>>> with the same name. How would one go about upgrading existing systems?
>>>>> We have roughly 1900 macros, big chunk of those are nested... Maybe I
>>>>> am misunderstanding something, but this issue makes it almost
>>>>> impossible to upgrade (at least for us).
>>>>>
>>>>>
>>>>> Thanks
>>>>> Boris
>>>>>
>>>>> On Mon, Apr 30, 2012 at 12:55 PM, Nathan Bubna <nbubna@gmail.com>
wrote:
>>>>>> Yeah, it was intended, and part of an overall move toward
>>>>>> fixing/simplifying Velocity's variable scoping, avoiding the
>>>>>> complexities and costs (performance, yes, but mostly time/brainpower
>>>>>> for users and devs alike) of more programming language type behavior.
>>>>>> Velocity has long aspired to be a straightfoward template engine
and
>>>>>> avoid being a complete scripting language.  (Implicit) variable
>>>>>> scoping, as seen in 1.5, was seen as a necessary compromise toward
the
>>>>>> latter; after all, one big fat namespace is always unmanageable,
>>>>>> right?  Well, there's ways to make that easy to manage. :)  Let's
call
>>>>>> it "optional, provided, explicit scoping", explicit because you don't
>>>>>> have to grok the contextual scope to understand a reference, optional
>>>>>> because you can ignore it, and provided because Velocity does the
work
>>>>>> of choosing "prefixes" and creating/destroying the scopes (as any
>>>>>> implicit scoping system does).  So everything is becoming globally
>>>>>> scoped, but it is now trivial to turn on automatic, explicit scopes
or
>>>>>> namespaces that you can use when you don't want things to live in
the
>>>>>> global scope.
>>>>>>
>>>>>> Here's an example...  Do you use $velocityCount to get an index
of
>>>>>> sorts inside of #foreach directives?  Well, that's an example of
mixed
>>>>>> implicit/explicit namespacing that gets messy when you nest
>>>>>> #foreach's, with no good way to get the parent's count and
>>>>>> unwieldiness when you want to add $velocityIndex, $velocityHasNext
and
>>>>>> so on.  Now, we automatically manage a $foreach var that not only
has
>>>>>> a 'count' property, but an 'index', 'hasNext', 'parent', and so on
>>>>>> (see http://velocity.apache.org/engine/devel/apidocs/org/apache/velocity/runtime/directive/ForeachScope.html).
>>>>>>  It also, of course, accepts any property you want to set on it
(like
>>>>>> any map).  This makes templates instantly understandable, making
>>>>>> debugging much better.  You always know exactly what you are referring
>>>>>> to, and so does anyone else reading the template.
>>>>>>
>>>>>> #foreach is the only 'content directive' that has its explicit scope
>>>>>> automatically turned on, but all content containing directives
>>>>>> (including custom body macros) can have their own explicit,
>>>>>> auto-managed scope, named after themselves.  for example, you can
flip
>>>>>> the macro scope on:
>>>>>>
>>>>>> macro.provide.scope.control = true
>>>>>>
>>>>>> and do:
>>>>>>
>>>>>> #macro( outer $arg )
>>>>>>  #set( $macro.arg = $arg )
>>>>>>  #inner( 'inner' )
>>>>>> #end
>>>>>> #macro( inner $arg )
>>>>>>  #set( $macro.arg = $arg)
>>>>>>  inner: $macro.arg
>>>>>>  #if( $macro.parent )outer: $macro.parent.arg#end
>>>>>> #end
>>>>>>
>>>>>> #outer( 'outer' )
>>>>>> #inner( 'just inner' )
>>>>>>
>>>>>> and get
>>>>>>
>>>>>>  inner: inner
>>>>>>  outer: outer
>>>>>>  inner: just inner
>>>>>>
>>>>>> Hope this helps...
>>>>>>
>>>>>> In any case, there was plenty of thought and discussion that went
into
>>>>>> this change.  Search http://velocity.markmail.org for 'scope' and
you
>>>>>> should find more on this.
>>>>>>
>>>>>> On Mon, Apr 30, 2012 at 8:49 AM, Boris Partensky
>>>>>> <boris.partensky@gmail.com> wrote:
>>>>>>> Hello, while going through the upgrade I noticed an incompatible
>>>>>>> behavior during nested macro evaluation. Looks like in 1.7 (all
>>>>>>> default properties) child macro has access to variables set in
parent
>>>>>>> macro scope (and those take precedence over globals), and 1.5
sees
>>>>>>> globals. In the following example, in 1.5 unit test the following
>>>>>>> template will evaluate to "globalvar", and in 1.7 - to
>>>>>>> "outermacroparam". Is this expected behavior?
>>>>>>>
>>>>>>>
>>>>>>> 1.5 test case
>>>>>>>
>>>>>>>
>>>>>>> public void testVelocityNestedMacroScope() throws Exception
>>>>>>>    {
>>>>>>>        VelocityEngine ve = new VelocityEngine();
>>>>>>>
>>>>>>>        ve.init();
>>>>>>>
>>>>>>>        String template = "#macro(outerMacro $arg1)"+
>>>>>>>                          "#innerMacro('blah')"+
>>>>>>>                          "#end"+
>>>>>>>                          "#macro(innerMacro $arg2)$arg1#end"+
>>>>>>>
>>>>>>> "#set($arg1='globalval')#outerMacro('outermacroparam')";
>>>>>>>        StringWriter eval = new StringWriter();
>>>>>>>        boolean b = ve.evaluate(new VelocityContext(), eval,
"foo", template);
>>>>>>>        assertEquals(eval.toString(), "globalval", eval.toString());
>>>>>>>
>>>>>>>    }
>>>>>>>
>>>>>>> 1.7 test case
>>>>>>>
>>>>>>>
>>>>>>>  public void testVelocityNestedMacroScope()
>>>>>>>    {
>>>>>>>        String template = "#macro(outerMacro $arg1)"+
>>>>>>>                          "#innerMacro('blah')"+
>>>>>>>                          "#end"+
>>>>>>>                          "#macro(innerMacro $arg2)$arg1#end"+
>>>>>>>
>>>>>>> "#set($arg1='globalvar')#outerMacro('outermacroparam')";
>>>>>>>        String eval = evaluate(template);
>>>>>>>        assertEquals(eval, "outermacroparam", eval);
>>>>>>>
>>>>>>>    }
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>>>>>>> For additional commands, e-mail: user-help@velocity.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>>>>>> For additional commands, e-mail: user-help@velocity.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>>>>> For additional commands, e-mail: user-help@velocity.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>>>> For additional commands, e-mail: user-help@velocity.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>>> For additional commands, e-mail: user-help@velocity.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: user-help@velocity.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>

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


Mime
View raw message