This runs a bit long, so be warned. It
helps if you are interested in bean persistence. ;-}
Personally, I have no interest in building SWT
applications in JBuilder. But it would be nice someday to be able to build SWT
applications graphically in Eclipse. This would be facilitated if SWT shells and
controls were readable and writeable using the JavaBeans long-term persistence
feature of JDK 1.4 (XMLEncoder/XMLDecoder). Awhile ago I spent a couple of days
investigating the issues with doing this. They fall into several
categories...
- Null constructors. This is NOT AN ISSUE.
XMLEncoder/XMLDecoder support constructors with arguments. They even support
constructors with arguments that must be read from fields. Color, RGB, Point,
etc. are no trouble to encode/decode. (These have parallels in AWT/Swing.)
XMLDecoder will even set fields accessible, so if it can get by the
Security Manager, it will be able to construct most SWT controls off-the-shelf.
If not, there is a workaround.
- Package-private fields. I'm not sure every field
in SWT is package-private, but every one I saw was. Since the SWT jar is not
sealed, it seems possible to write a field reader/writer class to work
in concert with PersistenceDelegates for the SWT classes. Unfortunately,
XMLDecoder will only read fields for constructor arguments, it won't treat them
as properties. So a special decoder owner is required for decoding which also
must be used with the encoder. This means that XMLEncoder/XMLDecoder cannot be
used off-the-shelf and IMHO the approach barely rises to the level of an ugly
hack, but it has the virtue of proving the concept. Any SWT class that works
like this would also work (and better) if the fields were exposed with
ordinary property getters and setters.
- Objects that cannot be reconstructed from their
contents. This is a big problem. An example is the Image class. I'm not talking
about access to the bits; it would be a bad idea to stream out
platform-dependent bits. It would probably be sufficient if images obtained from
files and resources were reconstructable (the remainder could be reconstructed
by user classes), but the origin of the image data is not saved in the image or
even, in some cases, available to it. Such classes need to be extended slightly
to allow a mode of use that creates decodeable objects. This should not affect
current APIs.
- Listeners. I think this is doable. (Once you get
past the fact that not only are the necessary data not stored in the objects,
but in package-private fields in other package-private classes. ;-} In some
cases, a single listener at one level of the API becomes multiple listeners at a
lower level, but it seemed to me the higher-level could be reconstructed.
Obviously, it would be better if there were explicit getters for properties in
the classes where they are added. (In case you are wondering, bean persistence
works only with listeners that are proxies or are themselves encodeable objects.
It does not support the common idiom of a listener object from an anonymous
inner class.)
I may have missed a gotcha in my pass through this,
but it seems to boil down to a need for a few cosmetic extensions of some SWT
classes to make them more bean-like. (The constructors, to repeat, are fine
just the way they are.)
So now the $64 question: Does the SWT team have an
interest in this? Is this something you would encourage as a project or
discourage?
Bob
----- Original Message -----
Sent: Monday, July 01, 2002 1:51 PM
Subject: Re: [platform-swt-dev] SWT in
borlands jbuilder
- Q: Will or can SWT be enhanced to include
support for JavaBeans?
- A: To the extent that it makes sense, given the constraints of operating
system compatibility, SWT already mirrors the beans behavior. An example of
this is the use of standard beans mechanisms for event dispatch
(EventListener, EventObject and adapter classes). Some aspects of the beans
paradigm, such as the ability to create beans with null constructors, run
counter to the constraints of the underlying operating systems that SWT runs
on. For example, operating systems do not typically support creating a
widget without specifying its parent. The essence of the problem is that if
you allow a widget to be created with a null constructor, then you can't
actually create the o/s resources at the time the constructor runs (you
would have to wait until later, after the parent has been set). We just can
not do this, since we always create the o/s resources in the
constructor, and for performance/efficiency/consistency reasons do not even
keep slots in the object to hold whatever state would be required so that
the object could be created later.
Holger.Schadeck
wrote:
Hello,
is there any possibility to convert the eclipse.org.swt into java beans
(with beaninfo?),
so that it is possible to load the SWT components onto a new tab panel
of the gui builder in borlands jbuilder?
Sorry, in eclipse I miss an easy to use gui builder.
Holger.
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
_______________________________________________
platform-swt-dev mailing list platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
|