So I looked into this some more and here is the deal. This bug was
introduced with VELOCITY-285. The solution to 285 was to make the
#foreach index variable forced to local scope, which introduced bug
VELOCITY-630. However, I assert that 285 was never a bug!
Given the following VTL:
#macro(dig $x)
x1: $x
#foreach($i in $x)
x2 $x
#dig($i)
#end
#end
#dig([[1,2],[3,4]])
The premiss of 285 is that reference $x at x1: and x2: should render
with the same value. However, in a pass by name world this is not
true. On at least the second recursion level to #dig the reference $x
is essentially an alias for $i. Since $i changes value between x1 and
x2, rendering $x will change.
I agree with the sentiment that this is surprising, but it is working
as it should.
On Oct 14, 2008, at 1:58 , Byron Foster wrote:
Actually I don't think it's all that odd, the error case is somewhat
general (it came up in my own usage of Velocity to generate HTML
lists). Any pass by name reference to the #foreach iteration
variable will fail, it doesn't need to be in a string literal, for
example:
#macro(test $x)#foreach($i in [1, 2])$x#end#end
#test($i)
Maybe a different disscussion, but somewhat related to how #foreach
is implemented with local scope. The macro localscope setting
(velocimacro.context.localscope) has the same behavior as above for
the #set directive. However, I'm not sure what Velocity's intended
behavior is with scoping rules and pass by name.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
