velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@optonline.net>
Subject Re: ReferenceException
Date Tue, 03 Jul 2001 00:31:58 GMT
Lane Sharman wrote:
> 
> Piero,
> 
> The velocity introspection engine, as you've read from Geir's
> post, requires getter and setter methods for public instance
> members.

Actually, no, that's not 100% correct.

We restrict access to only the public methods of a class, not just
'getter/setter', and follow a slightly extended version of the standard
Java bean spec for finding methods for you.  These methods do not have
to be getter/setter methods in the spirit of

get<Property>()
set<Property>( value )

although using them is very common (many tools know how to introspect
and let you manipulate beans), and very convenient. They give you a
degree of freedom in your design as they don't make any 'statement'
about implementation.  For example, suppose you wanted to have an object
that can supply a name.  You could do something like

public class Foo
{
   private String name;

   public String getName()
   {
      return name;
   }
}

and then access in your template like

$myfoo.name

Velocity will intropect the object named 'myfoo' in the context, and
look for method signatures like

public getName()
public getname()

and even

public get( String )

So therefore, to take advantage of the latter, you could also use *any*
class that implements a Map interface, including Hashtable, HashMap,
TreeMap, etc, or any class of your creation, and your template wouldn't
have to change when your data model changed.  

The reason we do this is mainly to help enforce good OO design and
encapsulation.  It is something I believe you should do anyway.  It
means that your classes are reusable in tools, JSPs, etc.

I do a bit of professional consulting using Velocity, and I agree that
sometimes you just want to slap something together - if you need a quick
and dirty class to hold stuff, use a Hashmap.  It works great.  Do your
references in your template like

$foo.bar

and then later, if you have to evolve that data containing class into
something more substantial, you won't have to change your template.

> 
> For classes whose role is to represent data, not behavior, or
> for which there are other good reasons (performance, ease of
> use), I suggest that this model is overly restrictive. The
> WebMacro introspection engine allows you to set/get public
> members directly.

I would be interested to see what the performance result is in a
real-world test case (and then compare to the cost of change later :)
 
> A class with public instance members have a role to play in
> applications, especially when the instance containing them is
> referenced by a secure and debugged referent.

And when you can demonstrate a provably secure and debugged referent, 
let me publish the paper with you...

In all seriousness, Lane is from the WebMacro community, and we get into
this kind of good-natured crossposting between lists all the time.
Actually, not enough, in my opinion ;)

Give WebMacro a look if you aren't 100% convinced that Velocity is the
solution for you - don't take our word for it.  After all, you will have
to live with the choice.  That said, I used to be a WebMacro user :)

geir

-- 
Geir Magnusson Jr.                           geirm@optonline.net
System and Software Consulting
Developing for the web?  See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!

Mime
View raw message