>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.
This
is true in the abstract, but in reality a bunch of things that have public
fields do wind up on the property sheet in one form or another. I'm
thinking of org.eclipse.swt.Point and org.eclipse.swt.Rectangle off the top of
my head.
So
the original idea with Sweet was to make it possible for the tool to be able
to deal with all of these things that need to be represented on the property
sheet uniformly as much as possible.
While I follow and agree with your argument from a pragmatic point of
view, my concern is that I don't want us to lose track of this from the big
picture perspective.
<snip/> 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.
I
agree here.
Can
you describe the issues with extending FeatureDescriptor more fully? The
intent underlying the original Sweet specification / implementation was that
individual BeanInfo classes would use java.beans.Introspector as-is, then
manually massage them into the state they needed to be. So, here's how
ButtonComponentInfo might look if the style bit property were added by
creating a new StylePropertyDescriptor that extends
FeatureDescriptor:
public class ButtonComponentInfo extends
OverrideComponentInfo // which extends
SimpleBeanInfo {
public ButtonComponentInfo() {
// Introspect
JavaBeans properties, etc,
using java.beans.Introspector
// This automatically
gets us all the standard java.beans-compliant properties and
events
super(Button.class);
BeanDescriptor
bd = getBeanDescriptor();
// Set the
icons
bd.setValue("iconURLs",
new
Object[] {
new Integer(BeanInfo.ICON_COLOR_16x16),
getClass().getResource("icons/Button.gif"),
new
Integer(BeanInfo.ICON_MONO_16x16),
getClass().getResource("icons/ButtonMono.gif")
}
);
// Set the
palette page
bd.setValue("categories",
"Basic");
//
StylePropertyDescriptor extends FeatureDescriptor
StylePropertyDescriptor stylePropertyDescriptor = new
StylePropertyDescriptor();
stylePropertyDescriptor.setValue("isStyleBit",
new Boolean(true));
// We'll use
the grouping structure you proposed...
styleValues
= new Object[][] {
"style" , new Object[]
{
"arrow" , "org.eclipse.swt.SWT.ARROW" , new Integer(SWT.ARROW)
,
"push" , "org.eclipse.swt.SWT.PUSH" , new
Integer(SWT.PUSH),
"toggle" , "org.eclipse.swt.SWT.TOGGLE" , new
Integer(SWT.TOGGLE) ,
"flat" , "org.eclipse.swt.SWT.FLAT" , new
Integer(SWT.FLAT) ,
"radio" , "org.eclipse.swt.SWT.RADIO" , new
Integer(SWT.RADIO) } ,
"alignment" , new Object[] {
"left" ,
"org.eclipse.swt.SWT.LEFT" , new Integer(SWT.LEFT) ,
"right" ,
"org.eclipse.swt.SWT.RIGHT" , new Integer(SWT.RIGHT) ,
"center" ,
"org.eclipse.swt.SWT.CENTER" , new Integer(SWT.CENTER) } ,
"arrowDirection",
new Object[] {
"up" ,
"org.eclipse.swt.SWT.UP" , new Integer(SWT.UP) ,
"left" ,
"org.eclipse.swt.SWT.LEFT" , new Integer(SWT.LEFT) ,
"right" , "org.eclipse.swt.SWT.RIGHT" , new Integer(SWT.RIGHT) }
,
} ;
stylePropertyDescriptor.setStyleValues(styleValues);
// Method added in
OverrideComponentInfo...
setStylePropertyDescriptor(stylePropertyDescriptor);
}
}
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 ?
Not
that I can think of right now. Does anyone else know of any?
However, I don't think this changes the fact that we need to find a suitable
way to represent these... I think we're still going to want to be able
to expand the fields of the Rectangle object contained in a Bounds property
and let the user edit the individual fields individually in the property
sheet.
Regards,
Dave