14 Jan
2011
14 Jan
'11
4:04 p.m.
On 01/14/2011 09:06 AM, Vincent Massol wrote:
Hi Sergiu,
I'd like to discuss this point that you've made in some other mail:
"Velocity 1.7, which brings many new features and improvements, but
breaks a lot of velocity macros (still working on fixing the broken
code)"
Does this mean users who have existing scripts will have things not
working anymore? (I guess so if we have broken stuff on our side)
If so, what can we do to make them suffer less when upgrading? Can we
start by listing broken stuff here and add them to the release
notes?
The key point is that Velocity 1.7 changed the way macro evaluations
work. While before it was more flexible with many possible outcomes
depending on what parameters were passed, and how they were used inside
the macro, the current version simplified a lot the internal logic of
variable assignments inside macros, which resulted in a critical
regression for us. The same change was introduced betwee 1.6.0 and
1.6.1, but was reverted in 1.6.2 when we notified them of the
regression, with the decision to go further with the change in 1.7.
To better understand the kind of code that doesn't work, take this example:
#macro(callBySharing $x)
#set($x = 'a')
#end
#set($y = 'y')
#callBySharing($y)
$y -> 'y' in 1.7
$y -> 'a' in 1.6.2, 1.6.0 and before)
But:
#set($x = 'x')
#callBySharing($x)
$x -> 'a' in all versions
This means that only macros that are supposed to change and return a
value in one of its formal parameters will stop working, and only when
the formal and actual parameters have different names. Macros with
signatures like:
#macro(computeSomething $fromValue1 $fromValue2 $putResultHere)
The only macro in macros.vm that was broken by this change was
#setVariableFromRequest, which I already fixed.
There are a lot of broken macros in the blog application, where I made
extensive use of this kind of macro behavior, which I'm going to fix. I
don't think that there are many other places in XE that were broken, and
I doubt that much user code makes use of this behavior.
Still, if we want to prevent any breakages, keep in mind that Velocity
will not change back to the old behavior. We can either stick to 1.6
till the end of time, keep patching 1.7 and any future release to keep
the behavior in place, or accept the change and document the breakage.
A simple solution for the moment is to patch Velocity 1.7 during the 3.x
cycle, but I'd rather not do it. 3.0 is the start of a new cycle, and
it's the right time to make major changes.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/