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

[Joe Winchester <WINCHEST@xxxxxxxxxx>]

Scott,

Couple of quick snowballs.

>As for Introspector, that's just a tool to make the visual editor easier to use. You're free to use a custom introspector.

There are 1430 lines of code in java.beans.Introspector.  It does a shedload of stuff with inheritance, cloning stuff for additional BeanInfo descriptors.  At IBM we've had lots of subtle issues with it over the years and worked with Sun to file bugs and suggest enhancements.  I don't think it is trivial for anyone to create a new one.  

>It's really the concept of PropertyDescriptors that matters.

Yes, but I maintain that a PropertyDescriptor describes a JavaBeans property.  This, by definition, is a getter and/or setter.  A Property is not a thing shown on the property sheet - that is just a particular tool way of dealing with PropertyDescriptors.  As an analogy for SWT constructor bits someone might want a single property called style with sub properties for the individual families (as does SWTDesigner), while others might want to break the families (style, border, alignment, orientation, etc...) out into their own top level properties.  Does Sweet have a single PropertyDescriptor for style that breaks it down into families, or one for each family ?  Either way all that is important is that the information is captured in the BeanInfo.  A java.beans.PropertyDescriptor has no behavior at all - all it gives up is classes and MethodNames that the property sheet (and other parts of the tool) can use.

Regarding a new class such as StyledPropertyDescriptor this introduces problems because first Sun's introspector will hurt us.  I view java.beans.FeatureDescriptor as a Sun subclassable only thing right now.  Even if we did subclass it it'd be silly to put key value pairs on it, we might as well have proper getters and setters.  However all it is for us right now is a bag of data, so therefore why not just put the stuff on BeanDescriptor for construtor style bits ?

We do have other issues to deal with as well such as inheritance.  Table inherits from Composite but do you really want things like SWT.NO_RADIO_BEHAVIOR or SWT.NO_BACKGROUND on the property sheet ?.  You would for Group which subclasses from Composite, so in some cases inheritance is required and others not.  Maybe the inheritance for Table should not be there, but available as an advanced/expert setting for the property sheet.

The reason for the JSR is because BeanInfo needs an overhaul.  It should be XML and not class based, it needs to have a better way of dealing with inheritance, it should use 1.5 metadata tags to describe enumerated values, it should be easier to configure Introspector classpaths,  Customizers needs a rework to deal with defining the code delta better than just "change the object and figure it out".  Custom construction needs to also be there for regular JavaBeans, containment needs to be modeled properly, and so on.  

Best regards,

Joe Winchester