Re: upgrading from 1.5 to 1.7 compatibility issues
> Yes, compatibility was and is a goal, but with limited resources, > continuing support for implicit scoping in macros didn't make the cut. 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. >> * When scopes of the same type are nested make the parent Scope >> available through the child (e.g. $foreach.parent or >> $foreach.topmost). 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 wrote: > On Mon, Apr 30, 2012 at 1:06 PM, Boris Partensky > wrote: >> 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). > > Yes, compatibility was and is a goal, but with limited resources, > continuing support for implicit scoping in macros didn't make the cut. > >> * 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 > > "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 > >> * When scopes of the same type are nested make the parent Scope >> available through the child (e.g. $foreach.parent or >> $foreach.topmost). > > $.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 .provide.scope.control = true > >> * When a Scope reference overrides an existing reference that is not a >> Scope, make it available through the Scope (e.g. $foreach.replaced). > > $.replaced is not a parent scope, but is 'bar' in the example: > #set($foo='bar') #@foo $foo.replaced #end > > This is a workaround for incompatibilities/migrations/etc. It doesn't > provide any compatibility with the older implicit system of scoping. > >> On Mon, Apr 30, 2012 at 3:51 PM, Nathan Bubna wrote: >>> http://velocity.apache.org/engine/devel/changes-report.html#a1.7 >>> >>> On Mon, Apr 30, 2012 at 12:37 PM, Boris Partensky >>> 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 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 > wrote: >> Yep, I am afraid we do set globals from within macros... >> >> On Mon, Apr 30, 2012 at 2:05 PM, Nathan Bubna 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 >>> 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 str
Re: upgrading from 1.5 to 1.7 compatibility issues
On Tue, May 1, 2012 at 7:59 AM, Boris Partensky wrote: >> Yes, compatibility was and is a goal, but with limited resources, >> continuing support for implicit scoping in macros didn't make the cut. > > 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. Hmm. I think the #evaluate directive also lost its implicit scope, but i'd have to double check on that. >>> * When scopes of the same type are nested make the parent Scope >>> available through the child (e.g. $foreach.parent or >>> $foreach.topmost). > > 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? 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 (#@mymacroname() $mymacroname #end) and you set mymacroname.provide.scope.control = true and $mymacroname.parent would only exist if you are nesting calls to #@mymacroname :) > Thanks > Boris > > > > On Mon, Apr 30, 2012 at 5:08 PM, Nathan Bubna wrote: >> On Mon, Apr 30, 2012 at 1:06 PM, Boris Partensky >> wrote: >>> 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). >> >> Yes, compatibility was and is a goal, but with limited resources, >> continuing support for implicit scoping in macros didn't make the cut. >> >>> * 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 >> >> "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 >> >>> * When scopes of the same type are nested make the parent Scope >>> available through the child (e.g. $foreach.parent or >>> $foreach.topmost). >> >> $.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 .provide.scope.control = true >> >>> * When a Scope reference overrides an existing reference that is not a >>> Scope, make it available through the Scope (e.g. $foreach.replaced). >> >> $.replaced is not a parent scope, but is 'bar' in the example: >> #set($foo='bar') #@foo $foo.replaced #end >> >> This is a workaround for incompatibilities/migrations/etc. It doesn't >> provide any compatibility with the older implicit system of scoping. >> >>> On Mon, Apr 30, 2012 at 3:51 PM, Nathan Bubna wrote: http://velocity.apache.org/engine/devel/changes-report.html#a1.7 On Mon, Apr 30, 2012 at 12:37 PM, Boris Partensky 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 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 >> wrote: >>> Yep, I am afraid we do set globals from within macros... >>> >>> On Mon, Apr 30, 2012 at 2:05 PM, Nathan Bubna wrote: C
