http://velocity.apache.org/engine/devel/changes-report.html#a1.7
On Mon, Apr 30, 2012 at 12:37 PM, Boris Partensky <boris.parten...@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 <nbu...@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.parten...@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 <nbu...@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.parten...@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 <nbu...@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.parten...@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-unsubscr...@velocity.apache.org >>>>>>> For additional commands, e-mail: user-h...@velocity.apache.org >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org >>>>>> For additional commands, e-mail: user-h...@velocity.apache.org >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org >>>>> For additional commands, e-mail: user-h...@velocity.apache.org >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org >>>> For additional commands, e-mail: user-h...@velocity.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org >>> For additional commands, e-mail: user-h...@velocity.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org >> For additional commands, e-mail: user-h...@velocity.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org > For additional commands, e-mail: user-h...@velocity.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org For additional commands, e-mail: user-h...@velocity.apache.org
