commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [clazz] Supported object model list
Date Sat, 26 Oct 2002 16:31:31 GMT
From: "Dmitri Plotnikov" <dmitri@apache.org>
> I agree that BeanInfo is a good model to build on. However, I would like
to
> emphasize a few fundamental difficiencies in BeanInfo:
>
> 1. Introspector is too class name centric: it uses the class name to
create
> other class names and look up information that way.  This produces two
types
> of problems:
>         a) what do you do if the class is automatically generated (e.g. by
> the EJB container)?
>         b) what if there is whole category of classes for which we want to
> generate BeanInfo in a certain way?  You cannot have a "generic" BeanInfo
> for multiple classes.

Agreed, both cases must be dealt with.

> 2. BeanInfo and PropertyDescriptors specifically give you some methods
> (readMethod, writeMethod etc) to call instead of calling those methods
> themselves.  What this does is that you cannot support models like maps,
> delegated accessors, collections etc, because for those there is no "get"
or
> "set" method to call at all.

Agreed, we must fix this

> 3. BeanInfo mixes apples and oranges a lot - you find there information
> about access to the property at run time as well as how to edit it inside
an
> IDE.  I am not opposed to centralized access to all kinds of information,
> but I think the information itself should be properly compartmentalized.
>
> That said, I agree with you that loose coupling with the target class has
> the disadvantages you mentioned.  So, I guess we need to find a solution
> that is well balanced simplicity and flexibility.


I was thinking along the lines of
ClazzUtils:
 IClass getMetaClazz(String className)
that uses pluggable implementations (reflection, BCEL, XML file, ...)

The IClass object has IMethod, IField, IProperty, IEvent, etc.

IClass has an instantiate method
 Object newInstance()
that uses pluggable implementations (reflection, BCEL, HashMap, ...)

IClass has the ability to store arbitrary meta data
 void setMetaData(Object key, Object value)
 Object getMetaData(Object key)
but this may be too weak a form of meta data?


Stephen


> ----- Original Message -----
> From: "Steve Downey" <steve.downey@netfolio.com>
> To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> Sent: Friday, October 25, 2002 8:15 PM
> Subject: Re: [clazz] Supported object model list
>
>
> On Friday 25 October 2002 07:07 pm, Stephen Colebourne wrote:
> > Other object models that could be considered:
> > JAXB
> > Swing
> > neither strike me as essential.
> >
> > However, providing base support for Map properties in beans seems
> essential
> > to me. We should support beans with simple (atomic) properties, array
> > properties, List properties and Map properties. The act of deciding what
> is
> > an SimpleArray/ListMap property (ie. what the methods are what etc. is
> > pluggable)
> >
> Perhaps we should take a view of eventually proposing a JSR for it. The
fact
> that the java bean spec doesn't address collection properties means that
> everyone creates their own, similar, workarounds.
>
> I think a good aproach for pluggability is the BeanInfo class. It's well
> defined how to create a BeanInfo that overides the default java bean
> behavior. In fact, that's one of the reasons you have to use Introspection
> to
> deal with javabeans correctly.
>
> There is a lot to critisise about the BeanInfo spec, though. The loose
> coupling between a BeanInfo and it's class has resulted in genuine java
> bugs,
> for example.
>
> Hejlsberg's approach of requiring an inner class has some advantages.
>
>
> --
> To unsubscribe, e-mail:
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
>
>
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message