velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Colson" <>
Subject Hashes are cool (was:FieldMethodizer() question)
Date Mon, 11 Mar 2002 18:24:43 GMT
Geir wrote:
> We made a decision that we weren't going to expose fields 
> directly, but 'coax' people to use setters/getters.

FWIW: In order to provide 'safe and simple' objects to the view, I had
created several "view only" copies of objects. The getter/setters are a
pain to maintain/synchronize between this Generally, my need is to give
the TemplateAuthor access to the fields and keep them away from method

Borrowing from the FieldMethodizer thread for example : instead of
having the template call $TrxStatistics.getValue($PAST30DAYS,$CREATES,
$ALL) ...

I might give the template a collection of $AccountCreationStats which
have already called stat.getValue(const,const,const) in the controller.
More work for the Controller, but simplifies the View.

Perhaps it's my Perl background, but I've found it quite nice to use
hashes instead of full objects in many places - it's practically self
documenting for the Template author! :-)

HashMap h = new HashMap();
h.put("TODAY", stat.getValue(TODAY,CREATES);
h.put("PAST30DAYS", stat.getValue(PAST30DAYS,CREATES);
VelocityContext.put("CreateStats", h)
note: This is a trivial example, I might in a real app create a list of
hashes or a hash of hashes depending on the needs.
#if ($debug)
#foreach ($stat in $CreateStatsList.keySet() )
 KEY=$stat VALUE=$CreateStatsList.get($stat)
The template author will easily see in the debug output which keys are

I've even started adding a method getPublicFieldMap() to my business
objects which returns HashMap - nicely makes a read-only and easily
debuggable object for the template author, plus that reduces my object
maintenance (i.e. I maintain one method v.s. a new object with many
get/set methods and some mechanism to copy from the biz to the view

So instead of putting a "RegEmployee" object into the context, I do:
VelocityContext.put("Employee", employee.getPublicFieldMap() );

This way the method employee.setPayGrade(int grade) isn't exposed to the
template, and the template author doesn't have to sift through the
JavaDoc API figuring out which object she has in hand.  I just need to
tell her that "$Employee" will exist and empirically the fields can be


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message