Re: [ve-dev] RE: Sweet BeanInfo for SWT

[Joe Winchester <WINCHEST@xxxxxxxxxx>]

Dave,

>>First - I don't think we should use a property descriptor.  It's not really a property per say, there is no getter or setter.  Right now you can create a java.beans.PropertyDescriptor with no get and set method, but this is not >>guaranteed to always be that way.  It's just internal code that doesn't enforce either at   least a read or write method.  Instead I think it should be a key value on the BeanDescriptor itself.  
>There are 3 kinds of "properties" you have to deal with in SWT:
 
>- Traditional JavaBeans properties
>- Style bit properties
>- Public fields
 
>The idea with the current spec is to define a way that lets the builder treat all 3 the same as much as possible.
 
>I'm not sure I see a good reason here to abandon this?

The thinking is that a java.beans.PropertyDescriptor assumes there is a get and/or set method associated.  With a field or constructor style bit there isn't.   What we're trying to do with BeanInfo is to describe things that the builder tool can use, so having a java.beans.PropertyDescriptor doesn't mean it belongs on the property sheet - it means there is a get and/or set method that the tool knows how to show and set values for.

With constructor style bits and public fields we need to describe these.  What the tool does with them is it's problem.  I think using java.beans.PropertyDescriptor is a fools gold - mainly because there is nothing to stop Sun making it impossible for us to create one with not at least one of the two methods.  The BEST solution, would be if we re-subclassed java.beans.FeatureDescriptor for things like
org.eclipse.ve.sweet.FieldDescriptor
and
org.eclipse.ve.sweet.ConstructorDescriptor

We looked at this and decided against it however because of the way the java.beans.Introspector works.  What you get back from the introspector are not the actual features the BeanInfo has, but instead wierd stuff happens like features get clones (using constructors that take other features), so I think the existing PropertyDescriptors are pretty much just that - property descriptors and as good as final until the Introspector gets changed by Sun.

Therefore - I still think that the features should be on the BeanDescriptor rather than overload the java.beans.PropertyDescriptor.  I'd hate to see a new release of java.beans.PropertyDescriptor kill us.

Also - you mention public fields.  The only ones I can think of off hand are things like RowData, GridData, FormData, Rectangle or Point.  These are basically data structures that SWT uses elsewhere (i.e. in layout managers or controls).  For actual subclasses of org.eclipse.swt.widgets.Widget are there any public fields that the VE has to be aware of in its model ?

Best regards,

Joe