velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@optonline.net>
Subject quick note on recent changes
Date Mon, 04 Dec 2000 05:32:56 GMT
Tonight I commited a wide ranging set of changes to address a few issues
that we have been discussing for a while.  I want to give everyone a
heads-up because there is a fair chance I broke something :) (I don't
really believe that, of course...)

Visible and Trivial Changes 
---------------------------
1) version of the jar is 0.71 - so velocity-0.71.jar  - because the
changes are deep enough that they aren't simple bugfixes, but rather a
re-working of something critical.  So if there are problems, we know if
the user says '0.71' that they have the new introspection stuff.

2) Speed : alas, we took a small speed hit,  I estimate about 6%-7% or
so.  Not big, but not small either.  The upshot is that all
introspection is done at 'run time' rather than init time.  

3) #foreach will restore the pre-loop value of the loop reference.  If
you want to grab the last element in the loop, do it explicitly.
   
   #set $flargh = "hi"
   #foreach($flargh in $array)
   #end
   $flargh

will output
   
   hi


Characteristic Problems Addressed
---------------------------------
There were a few problems that you might have run across, or not. They
all were basically related to introspection.  They were subtle but could
be deadly :

1) the #set would invoke the RHS several times, which was problematic if
the invocation of the RHS changed the state of something.

2) references would invoke their 'referands' more than once.

3) the introspection information would be 'locked in' at init() time in
some cases, resulting in limitations on app behavior.  For example, if
you tried something like :

<get template with a #foreach($a in $datalist)>

<create a vector 'v' with some elements>
context.put("datalist", v);
template.merge(context, writer);

<create a Object [] 'objarr' with some elements>
context.put("datalist", objarr);
template.merge( context, writer);

resulted in ugliness (usually threw an exception, I think.)

Why do we care?  Well, suppose in a multithreaded environment, say a
servlet engine, it's possible that many servlets will be using the same
cached template, and we can't impose the requirement that they all have
data in the Context with the same 'shape'.  Well, we could, but we
won't. :)

For more info, see the new JUnit test, ContextSafetyTestCase.

There was plenty of other stuff, but I think that's the basics...

geir

-- 
Geir Magnusson Jr.                               geirm@optonline.com
Dakota tribal wisdom: "when you discover you are riding a dead horse,
the best strategy is to dismount."

Mime
View raw message