[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [ve-dev] RE: Sweet BeanInfo for SWT
|
Title: Message
>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