Very
nice analysis...
I'm
working on a visual builder right now that will be able to create AWT, Swing
(and eventually) SWT GUIs (as well as non-UI code). It's coming along nicely so
far, as GEF and I are finally talking the same language. (No offense to the GEF
folks intended: it's an incredible framework, but the docs need a lot
of help... When I'm further
along I'll write some tutorials...)
Anyway, my take on much of this is that the persistence of SWT
isn't really a major issue (though I did find this analysis really
interesting/enlightening). I think the main issue is simply represening SWT
components in a non-SWT model (for use in the builder) and
generating an SWT app from it.
If SWT were made persistable via the XML encoder/decoder, that
would give an alternate generation target. Rather than generating code for the
app, a LTP XML file could be created to store the
representation.
Of course, another possibility along those lines is to simply
modify/extend the LTP format to support SWT and create a custom XML
encoder/decoder for SWT. Personally, I think this is a better option due to the
non-bean nature of SWT components.
(Side
note: Personally, I don't find having SWT classes being non-beans an issue. It
just means you can't use current bean builder tools to create them. Of course,
due to other design concepts in SWT, I don't think you could really use
bean builders quite that directly anyway...)
--
Scott
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
