|
I appreciate your thoughtful response. For lack of
time I must stay where the air is thin, but I'll make it brief (for
me).
Of course bean persistence (or any kind of
persistence) is orthogonal to the ability to make a GUI builder. Persistence
might facilitate making a GUI builder, but that depends on the GUI builder
builder. ;-}
I'm interested in this style of persistence because
it operates (almost) exclusively at the API level. Since SWT implementations are quite different underneath the API, the two
technologies seem a good match.
I think the word "bean" taints the discussion. The
1.4 persistence feature seems well-designed and well-written. The new
part is small and transparent, even a bit elegant. I've never much liked
beaninfo but I can see why the designers used an existing mechanism to identify
properties that should or should not participate in persistence rather than
re-inventing the wheel. Beaninfo is not used for streaming in, where performance
is an issue.
I have so far not encountered any example in SWT
that would trigger any of your issues. The job seems mostly adding accessors for
information that is already there or, in a very few cases, keeping around some
information that is currently discarded. If this is truly the case, a proof of
concept could be developed using only subclasses that do not change the behavior
of the parents.
But I'm far from an SWT expert. If one of the very
bright people on the SWT team has a quick counter-example, it would be good to
know.
Bob
----- Original Message -----
Sent: Wednesday, July 03, 2002 8:52
AM
Subject: Re: SWT Bean Persistence [Was
Re: [platform-swt-dev] SWT in borlands jbuilder]
Preface: The SWT team believes
that there is no correlation between bean persistance and the ability to build
a GUI builder for SWT. We have been trying to find the time to roll one
ourselves, to prove this for about a year now, but the workload has just been
too heavy to get around to it. If what people really want is just
"someday to be able to build SWT applications
graphically in Eclipse", then that is
where the energy should be focused.
---------------------------------------------
Having said that, obviously the SWT team has an
interest in anything which improves the quality of SWT. If we want SWT to
become pervasive (which is actually a whole other debate), it seems likely
that we would need work towards making SWT widgets bean-friendly, since like
'em or not, beans are important to the Java community.
Just so you know, the overriding historical context for
why SWT is the way it is a ferocious stubbornness about anything which would
add unnecessary layers between the API and the underlying native widgets. You
should have *seen* the fight that went on over the the typed event support(!)
and we're still not sure we did the right thing that time.
So it seems to me that, if we want this
to happen, we need somebody who actually understands beans (like yourself
<winks>) to work with us to incrementally move towards making the SWT
API more bean-friendly, but (and it's an important "but") we can only do this
under the following constraints:
1) For 2.1 at least, we can do nothing which breaks existing programs.
We can add API but not modify existing ones. This might mean that we would
need to do a phased strategy of some kind. For 3.0, we would have somewhat
more freedom in this regard.
2) We
absolutely will not make SWT slower for this [and will piss & moan about
making it larger too]. So if the requirement was, for example, that there be
an accessor in a place where there isn't one currently, that's doable; but if
the requirement was that you could *not* allow access via setting a field
which is currently the way it's done, that would be unnacceptable. Do you
see?
Another big issue I see is
that, SWT really isn't portable below the API it currently has. If you look at
the internal structure of the classes, you will see that the types of many of
the fields and the class hierarchy itself differ from platform to platform, so
any gui builder which relied on understanding the specific fields of a widget
would be problematic. I think it would be good if we had Steve Northover
discuss his vision for how to write a GUI builder on this list.
In any case, I'm not a big fan of
discussion in a vacuum. Your message has clearly got some interesting ideas.
If you're willing to take the time to be more specific about what the kinds of
changes would be (and yes, I know you've talked about some of them before), we
would be happy to discuss them with you.
McQ.
|
| "Bob Foster"
<bob@xxxxxxxxxx>
Sent
by: platform-swt-dev-admin@xxxxxxxxxxx
07/02/2002 12:24 AM
Please respond to platform-swt-dev
|
To:
<platform-swt-dev@xxxxxxxxxxx>
cc:
Subject: 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 -----
From: Jan Venema
To: platform-swt-dev@xxxxxxxxxxx
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
|
