Re: SWT Bean Persistence [Was Re: [platform-swt-dev] SWT in borlands jbu

["Mike Wilson" <Mike_Wilson@xxxxxxx>]

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