[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [ve-dev] Example BeanInfo classes for SWT
|
Yup -- that's part of the idea.
I haven't had the chance to really think through it this
weekend, but here's some unfinished thoughts to get folks thinking... I started
writing this up last week but wanted to chew on it some more. My thoughts have
changed a bit, but here are some concepts to chew on... Note that it just kinda
ends -- didn't have time to do more with it yet.
A friend and I at work were also chatting about the concept
of Sun's BeanInfo and the metadata spec (JSR 175). We're both very scared about
what things will get represented by the metadata spec, and we think that there
needs to be a more flexible approach to metadata. (In short, adding metadata to
the code is very often a bad thing -- it only allows one value for metadata,
regardless of the context in which the metadata is needed. BeanInfo was pretty
good here, as it defined one set of "design-time visualization" data without
locking a class to it. Basically the class creator doesn't lock us into one
specific metadata impl - we can replace the default beanInfo with our
own.
My friend and I are looking into an alternate scheme that
allows class-based metadata (like beanInfo) on a per-context basis, as well
as instance-based metadata. Muihahahaha!
We're going to chat some more this week to firm things up.
I think it could be very valuable to implement per-context metadata for SWT, for
flexibility and as an example of what JSR 175 really should have been. We need to
spec a few things out more, then I'll post the
details.
-- Scott
There should be some way to "group"
properties.
I was thinking of changed to a single
property named "style" with some kind of property editor setup to provide the
bits. The editor might look like a bunch of checkboxes or a list with selectable
items.
Then it hit me -- what I'm really thinking
about is a grouping of related properties. If we think of the bit masks as
properties themselves (which I was pitching today), what would happen if we
introduced the concept of a "property group" into bean info?
The problem I see with all the individual
properties for the bits is that they'll get scattered across the property sheet.
We need some way to relate them. This could also carry through to other related
properties, like "size and position", "colors and fonts", "style" (we need to
pick the names better...) and such. The concept would allow us to easily group
related properties and place them on the property sheet as a tree:
- Size and Position
- Colors and Fonts
- foreground
- background
- font style
- font size
- Style (a better name might help here...)
- Maximizeable
- Minimizeable
- Resizeable
- ...
For some of these, they might be represented as a set of
checkboxes instead of true/false text
Get the idea?
So how does this work?
CONCEPT
-------
Properties are defined as normal (and as I proposed today --
I've got the "no method" stuff pretty much working; a weensey bit hackish, but
I'm working to clean it up)
A Property Group or the equivalent concept would hold details
about:
- properties it contains and their ordering
- is this group a real property,
or a "pseudo-property", just for containment?
- exclusivity of the properties
- one can be set/selected
- multiple can be set/selected
- target
- is there a single property all contained properties
contribute to?
- Or, are all of the contained properties
independent?
By "grouping" ,
do you refer to things like TRIM where it maps into a set of properties?
This is an area that may need more iteration.
------------
Dr. Gili
Mendel
IBM
Software Development
RTP Raleigh, NC
(919)543 6408,
tie: 441 6408
"Scott Stanchfield"
<scott@xxxxxxxxxxxx> Sent by: ve-dev-admin@xxxxxxxxxxx
03/12/2004 11:02 AM
|
To
| <ve-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| RE: [ve-dev] Example
BeanInfo classes for SWT |
|
Thanks much. I'll bang on the concepts I've been working a
bit this weekend.
I'm playing with some "grouping" concepts which might make
much of this easier as well as provide some nice additional support on top of
standard beans. Details soon...
Later!
-- Scott
From: ve-dev-admin@xxxxxxxxxxx
[mailto:ve-dev-admin@xxxxxxxxxxx] On Behalf Of Joe
Winchester
Sent: Friday, March 12, 2004 10:19 AM
To:
ve-dev@xxxxxxxxxxx
Subject: [ve-dev] Example BeanInfo classes for
SWT
Folks,
Following Wednesday's discussion on BeanInfo this is the design
that I believe we agreed upon to proceed with for the near term. All of
these examples are released into the CVS repository.
Style bits are defined on the
BeanDescriptor by a two dimensional value with a key of
"org.eclipse.ve.sweet". The array elements are the order:
String internalName,
String
displayName,
Boolean isExpert,
Object[] values.
The values is an Object[] that contains repeating
entries of
String displayName
String initializationString
Integer
value
The
following is an example of the BeanInfo class for Button.
public BeanDescriptor
getBeanDescriptor() {
BeanDescriptor descriptor = new BeanDescriptor(Button.class);
descriptor.setValue(
org.eclipse.ve.sweet.stylebits",
new
Object[] [] {
{ "style" , "style" , Boolean.FALSE , new Object[]
{
"PUSH" , "org.eclipse.swt.SWT.PUSH" ,
new Integer(SWT.PUSH) ,
"CHECK" , "org.eclipse.swt.SWT.CHECK" ,
new Integer(SWT.CHECK),
"RADIO" , "org.eclipse.swt.SWT.RADIO" ,
new Integer(SWT.RADIO) ,
"ARROW" , "org.eclipse.swt.SWT.ARROW" ,
new Integer(SWT.ARROW) ,
"TOGGLE" , "org.eclipse.swt.SWT.TOGGLE" ,
new Integer(SWT.TOGGLE)
}
} ,
{
"textAlignment" , "textAlignment", Boolean.FALSE , 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)
}
},
{
"arrowStyle" , "arrowStyle", Boolean.FALSE ,
new Object[] {
"UP" , "org.eclipse.swt.SWT.UP" ,
new Integer(SWT.UP) ,
"DOWN" , "org.eclipse.swt.SWT.DOWN" ,
new Integer(SWT.DOWN) ,
"LEFT" , "org.eclipse.swt.SWT.LEFT" ,
new Integer(SWT.LEFT) ,
"RIGHT" , "org.eclipse.swt.SWT.RIGHT" ,
new Integer(SWT.RIGHT)
} }
}
);
// Get any other inherited style bits
and merge them in
return descriptor;
}
For the merging there is a help called in
org.eclipse.swt.beaninfo.SweetHelper with a static method
/**
* Combine all of the style bits from the descriptor's classes superclass into the descriptor
*/
public static void
mergeSuperclassStyleBits(BeanDescriptor descriptor)
No implicit inheritance is done by
the tool using the style bits, although if no style bits are found then the
inheritance chain is walked to find the first BeanInfo whose BeanDescriptor
does have style bits.
For single value'd style bits they are defined with just a single
entry.
descriptor.setValue(
SweetHelper.STYLE_BITS_ID,
new Object[] [] {
{ "horizontalScroll"
, "horizontalScroll" ,
Boolean.FALSE , new Object[]
{
"H_SCROLL" , "org.eclipse.swt.SWT.H_SCROLL" ,
new Integer(SWT.H_SCROLL)
}
} ,
{
"verticalScroll" , "verticalScroll" , Boolean.FALSE , new
Object[] {
"V_SCROLL" , "org.eclipse.swt.SWT.V_SCROLL" ,
new Integer(SWT.V_SCROLL)
}
}
}
);
For the VE BeanInfo
classes the Composite will not include the bits NO_MERGE_PAINTS,
NO_BACKGROUND, NO_FOCUS, NO_DEFER_REDRAW. These are introduced on
CanvasBeanInfo. That way all custom controls and subclasses of
Composite by default will not include these style bits.
Best regards,
Joe Winchester