Stylistic consistency questions about GBean framework.

[David Jencks <da...@coredevelopers.net>]

A few things I noticed while working with the new GBeans framework...

1. Some parts use Class parameters (e.g. GConstructorInfo), others 
String for class name.

2. some GAttributeInfo constructors have one boolean and two Boolean 
parameters.

3. (an actual question, not a niggle) We tended to use data objects in 
constructors when the number of parameters got really large (ejb 
containers, web application, etc).  What's the recommended style when 
using persistent attributes?  should these be spread out again into 
zillions of little parameters or should we write a PropertyEditor that 
can edit the data object encapsulating them?  I'd guess the zillions of 
little parameters would be simpler.

4.  I'd think a constructor for GConstructorInfo taking String[], 
Class[] would be useful as it indicates the types.

thanks
david jencks

Re: Stylistic consistency questions about GBean framework.

[Dain Sundstrom <da...@coredevelopers.net>]

On Jan 15, 2004, at 11:16 AM, David Jencks wrote:

> A few things I noticed while working with the new GBeans framework...
>
> 1. Some parts use Class parameters (e.g. GConstructorInfo), others 
> String for class name.

Thought I had fixed all of those.  All of the info stuff needs to be 
strings so we can easily serialize.

> 2. some GAttributeInfo constructors have one boolean and two Boolean 
> parameters.

The Boolean parameters are there so we can have true, false, and don't 
care.  These are specifically use for readable and writable.  When they 
are null it means that they are only readable if there is a getter 
method, and writable if there is a setter method.  Normally, you leave 
then null.

> 3. (an actual question, not a niggle) We tended to use data objects in 
> constructors when the number of parameters got really large (ejb 
> containers, web application, etc).  What's the recommended style when 
> using persistent attributes?  should these be spread out again into 
> zillions of little parameters or should we write a PropertyEditor that 
> can edit the data object encapsulating them?  I'd guess the zillions 
> of little parameters would be simpler.

Lots (not zillions ;) of parameters is easier.  The end user will not 
interact with these classes, so it is only us that get punished.

> 4.  I'd think a constructor for GConstructorInfo taking String[], 
> Class[] would be useful as it indicates the types.

We can do that, but it will be (String[] names, String[] types) when I 
fix the Class issue (1 above).

-dain