[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[platform-swt-dev] Re: SWT Bean Persistence
|
Title: Re: SWT Bean Persistence
I agree with Randy. SWT support for JavaBeans is a chimera
- a bad mixture of disparate entities.
Existing GUI builders depend on the JavaBeans structure because
that's how Swing implements widgets. Eclipse GUI builders won't
use that structure because SWT doesn't provide it. And (IMHO)
there will be several GUI builders available long before Eclipse 3.0
sees the light of day.
Don Wills
At 10:49 AM -0400 7/3/02, hudsonr@xxxxxxxxxx wrote:
Any GUI builder will inevitably treat the widgets, whether they
be Swing or SWT, as more than just beans. You can't build a good GUI
builder by just manipulating JavaBeans. For example, a GUI builder
would have to know that a JTabPane only shows one of its children at a
time, and if the user want to visually drop widgets on the other tabs,
there has to be a design-time way to flip pages. Split panes have to
be treated specially, and so do *lots* of other things, like layout
managers, constraints, menus.
So, desigining a builder that has to understand constructor-time
attributes, or publicly-accessible fields, or public API that is
really internal are just some of the small steps in supporting a
useful SWT GUI builder.
Bean support is not all you need to create an AWT/Swing GUI builder,
so why should SWT conform to a spec that doesn't give you any real
benefit? (That's a rhetorical question, just my 2 cents)
Randy Hudson
