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