On 9/26/01 9:34 AM, "Attila Szegedi" <[EMAIL PROTECTED]> wrote:
> An issue cropped up:
>
> - Right now, ASTReference supports setting of a property, and will look up
> the setter method based on the property name AND the class of the right-hand
> side value. So, in current Velocity design a single property can have
> multiple property writers (i.e. both setFoo(Foo f) and setFoo(Bar b)). If we
> switch to JavaBeans introspection, we will always have a SINGLE property
> write method per property. Is this an issue of concern, or is this just an
> artifact of the fact that ASTReference uses Introspector.getMethod(), and we
> can happily switch over to using the single property write method returned
> from JavaBeans introspection?
This is an issue of concern. Making all available is a really nice thing,
in my opinion. What problem are we trying to solve here, anyway?
> Fortunately, this is not issue for property
> read methods, as they have no arguments, so only one can exist for any given
> property name. I needn't say I favor the use of single property setter, the
> one returned from JavaBeans introspection.
>
> - BTW, is it any good having a template engine being able to call setXxx
> methods, thus potentially altering underlying data (or business) objects?
Yes - again, the idea that we offer such a transparent 'binding' to Java
objects is a great thing, in my opinion. It greatly extends the usefulness
of the API's offered to the template author.
For example, you can imagine all sorts of uses for this in a purely visual
context, such as
$rowcolorlaternator.setColors( ['red', 'blue', 'green'] )
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
"Whoever would overthrow the liberty of a nation must begin by subduing the
freeness of speech." - Benjamin Franklin
