| SWT Bean Persistence [Was Re: [platform-swt-dev] SWT in borlands jbuilder] |
|
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 -----
|