RE: [platform-swt-dev] Re: FW: SWT History and Design Decisions ( WAS: [

[Scott Stanchfield <scott@xxxxxxxxxxxx>]

> [mailto:platform-swt-dev-admin@xxxxxxxxxxx]On Behalf Of Joe Winchester
>
> I agree with Scott here

Ahhhh... music to me ears...

> The problem should not be based around how a builder should
> construct an
> SWT control from its properties, but rather how the
> properties should be
> presented, rendered, edited and applied.  The existing
> analogy in Java is
> BeanInfo and JavaBeans - the BeanInfo describes how a JavaBean should
> behave in an editor tool but once it has been introspected and its
> descriptor classes retrieved it does not play any part in how the live
> instance is actually hosted - just how it is presented.

Couldn't have said it better meself. Or was that just didn't say it
better meself?

> The reason BeanInfo won't do the job right now is that
> java.beans.PropertyDescriptor assumes that the property is controlled
> through a get and set method,

Not completely true -- you can have the PropertyDescriptor send back
alternate read/write methods for a property, but they still expect to
have certain args. An extension on PropertyDescriptor could add info on
how to pass params.

> and also
> java.beans.ProperyEditor pre-reqs
> java.awt.Component for its editor.

There's a fun one... I must say I really like the PropertyEditor design
(I've got a tutorial at http://www.javadude.com/articles if anyone wants
detail), but it chould be abstracted a bit to use a "UI factory" for the
actual visualizations (which would allow AWT/Swing, SWT, or even JSPs to
be used to do the edit... gack -- a thin-client UI development tool --
well, it's just illustrative...)

> However, you could follow
> the BeanInfo
> pattern and have something such as
> org.eclipse.swt.info.PropertyDescriptor
> that had three subclasses - one for get and set method
> properties, one for
> public field access, and one for constructor style bits.  The
> PropertyDescriptor would contain the LabelProvider class name, the
> CellEditor class name.  As well as PropertyDescriptors you would need
> eventDescriptors that would be similar to BeanInfo ones,
> expect that they
> would need to deal with untyped listener pattern of SWT.

That's a start... We can hack out details on this. Maybe we should start
a Wiki or something on this? Or we could all get together in Hawaii for
a week or so. It's damn cold out here this week in Maryland...

> Bottom line - I love the idea of having a tools metadata
> layer for SWT,
> however I very strongly believe that it should be a
> descriptive layer than
> a component peer layer as proposed by Sweet.  The descriptive
> layer could
> either be explicit classes ( which BeanInfo is ) or else it
> should probably be declared in XML.

Or it could be a BeanInfo implementation that reads XML ;)

While we're at it, there are a few other BeanInfo like things that
really should have been in BeanInfo (like layout manager metadata...)

-- Scott