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

["Scott Stanchfield" <scott@xxxxxxxxxxxx>]

Scott,

Couple of quick snowballs.
[Scott Stanchfield: ]  <g> 

>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.  
[Scott Stanchfield: ]  Did I say create a new one? If so I didn't mean an entirely new one (though I still don't think it's that big of a deal) How about delegation? Use the base one to get the standard beans stuff, then add extra descriptors before returning. Delegation is your friend. 

>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.
[Scott Stanchfield: ]  Not true. The bean spec provides means to use non get/set methods.

Also, keep in mind we're extending the BeanInfo definitions to be able to include SWT. Style bits and public fields are "attributes" of an object, just like bean properties are "attributes". These attributes may or may not be changed (read/write via some mechanism), and could all be displayed to a user in the same way.

 

Bean "Properties" really refer to two things:

1) A conceptual attribute that an outside entity can manipulate (normally to change the state of the bean)

2) A mechanism by which introspection can magically determine what those attributes are

 

Conceptually, this also applies to constructor parameters, style bits, and public fields.

 

If we extend beaninfo to support SWT, we really have two choices:

1) Extend what things are called properties (add code or attribute values to PropertyDescriptors to indicate style bits, fields, constructor settings)

2) Add a new type of descriptor

 

What does a new type of descriptor buy us here, other than more divergence from the concept of beans?

 

The style bits, public fields, and constuctor settings could have been implemented as get/set in many cases -- the concept really fits properties.

 

A Property is not a thing shown on the property sheet - that is just a particular tool way of dealing with PropertyDescriptors.
[Scott Stanchfield: ]  Ahhh, but the intent of the bean spec is that a property could be displayed in a property sheet, which is why I use that as an example. Of course it could be used in other places (JSP getProperty tags, reporting tools, whatever), but here we're interested in tools that do display the properties on property sheets.

 

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.
[Scott Stanchfield: ] The bean spec did something very nice for extensibility -- they allow "attributes" to be set on any descriptor. These can be vendor-specific extensions (see http://www.javadude.com/articles/javabeanattributes.html for all of the common attributes I was able to find). Attribute values can be any object you want.

 

Are you familiar with how attributes work? Sun really did things right with attributes, allowing infinite vendor extension. If you think of SWT as a vendor extension to beans, it's simply a matter of adding whatever attributes we want to the existing descriptor structure.

 

This gives us a mechanism for adding any additional clues we need, such as

 

Is this a constructor-based property?

What are the possible values for this property? (a non-string enumeration)

What behaviors (strategy pattern instance objects) can I attach to this property?

What categories does this property belong to?

 

This gives us endless support for extending what a PropertyDescriptor tells us. The point of our earlier work on Sweet was to stick with the same concepts as beans (which I feel quite strongly apply equally well for bean properties and style bits) via simple extension.

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 ?
[Scott Stanchfield: ] because it breaks the concept of BeanDescriptor. Beandescriptor is for high level bean metadata, not for definition of user-changeable bean attributes.

 

As for Sun's introspector, no problem at all... We can decorate the introspector with our own introspector. When the app (VEP/Penumbra/other) asks the special introspector for property descriptors, it asks the real introspector, then adds new ones. No fuss, no muss. Great reuse with great flexibility.

 

(Did I mention I teach design patterns at Hopkins? I'm really into patterns like decorator and adapter when it comes to addition of functionality, rather than subclassing. I'm not a fan of static inheritance at all...)

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.
[Scott Stanchfield: ] heh heh heh. muihahahaha. cough cough (too much evil laughing)

Inheritance in beaninfo is pretty interesting stuff. (You likely know this already, but roll with me here). The introspector looks at the current beaninfo to see if it should include the superclass' beaninfo. It does this by calling getAdditionalBeanInfo, and the SimpleBeanInfo default implementation introspects on the superclass.

There are really two ways to omit superclass properties:

1) have your getAdditionalBeanInfo return null (skip all superclass beaninfo)

2) in your beaninfo return a property descriptor for the property that marks it "hidden" (this will override the superclass' provided property descriptor)

The reason for the JSR is because BeanInfo needs an overhaul.
[Scott Stanchfield: ]  Agreed, but really not too much...

It should be XML and not class based,
[Scott Stanchfield: ] Why? Classes are much more flexible. I don't understand the "everything must be XML" push...

 

it needs to have a better way of dealing with inheritance,
[Scott Stanchfield: ] Why? The current introspector works perfectly fine. You can override parts of superclass beaninfo or even tell it to ignore superclass beaninfo. Any particular problems you can point out?

 

it should use 1.5 metadata tags to describe enumerated values,
[Scott Stanchfield: ] <shudder> I'm very against the 1.5 metadata tags for use like this. The metadata tags should only be used to describe domain information, not presentation information or storage information. I've seen examples like (note I haven't really studied the syntax of the metadata entries, but I'm talking about the concept)

 

  @persistence table="people" column="name"

 

which is basically coupling domain objects to the way they're persisted (true, unadulterated EVIL!).

 

What I think you're saying here is that we should have things like

 

  @enumvalue {value="1" label="Elementary"}

  @enumvalue {value="2" label="Secondary"}

  @enumvalue {value="3" label="High School"}

  @enumvalue {value="4" label="College"}

 

The trouble with this is that it combines the presentation of the values with the model, giving no alternative. I'm a firm believer that presentation details should be separate, like in a co-class such as BeanInfo. The BeanInfo concept is really pretty well done, IMHO, as it says "here's the metadata for use when doing introspection". Other co-classes could be created for other types of presentation or metadata needs.

 

I'm really scared about what people will start doing with metadata...

 

  public class Person {

    @GuiComponent {TextField name="name" bound="true"}

    private String name

    ...

  }

 

It just begs people to couple layers like crazy (see http://javadude.com/articles for my definition of layers). People are already doing this with xdoclet, and in many cases they're creating a nasty binding between presentation, business logic, and data management.

 

it should be easier to configure Introspector classpaths
[Scott Stanchfield: ] I totally agree here... But that's a configuration/implementation detail of the introspector and not a problem with the metadata. It's almost good here, with the setBeanInfoSearchPath, but not quite. The problem IMHO is that you can only associate a BeanInfo by class name (in any package) or by specific package. There needs to be a way to link a.b.c.XXXBeanInfo to class x.y.z.Y -- better registration of the beainfo-to-class coupling.

 

Customizers needs a rework to deal with defining the code delta better than just "change the object and figure it out".
[Scott Stanchfield: ]  Agreed -- customizers are a bit too manual. They need to be more like property editors so you can ask "what's the java code for this". I don't think they quite put enough thought into customizers. They approached it more from the "everyone will use Serialization" point of view. Funny thing is that the only thing the bean spec requires is that beans be serializable, but for some reason everyone thinks the only thing they need to do is have a public no-arg constructor. The bean spec intended bean tools to modify real objects and serialize them, not generate code... Seems like the only place they really thought about code generation was in property editors with getJavaInitializationString()...

 

Custom construction needs to also be there for regular JavaBeans
[Scott Stanchfield: ] Why?

 

containment needs to be modeled properly
[Scott Stanchfield: ] How about BeanContext & runtime containment? And the isContainer and containerDelegate attributes? 

I've done a lot of work & research with BeanInfo over the years, and I think it's one of the few things that Sun did very right with Java. I'm happy to discuss this more, of course. I think there may be a few misunderstandings about how beaninfo and introspection works, and I think we should get these straightened out first.

 

At a basic level, what things are causing real problems with beaninfo for you? Some of the above comments lead me to believe you might have a few misconceptions. Don't take this the wrong way though -- very few folks have read the bean info spec and really "got it". Every bean builder I know of required public no-arg constructors -- the bean spec doesn't even have the word "constructor" in it ;) The only one I saw that required serialization was Asymetrix's Supercede (AFAIK it's dead now, but they mentioned one of my components wasn't serializable, which started by study of the bean spec...) 

 

The bean spec is just one of the most ambiguous docs ever...But after studying it and the implementations of beaninfo and introspector, I really understand and admire what it's doing and how it's doing it.

Thoughts?

--- Scott