Beans Binding
Hello folks,
as I have some spare time now (being on leave for two weeks), I would like to point your attention to the JSR-295 "Beans Binding" databinding framework for Swing, which seems to be near completion. Proper databinding support looks to me to become a big plus for rich client applications with Java.
The lead of the project has very recently been taken over by Shannon Hickey, who introduces himself in this forum post at java.net: http://forums.java.net/jive/thread.jspa?messageID=206602&tstart=0#206602 He writes, the project would be "almost ready" for an initial public release.
But how exactly does a databinding framework ease the development of rich client applications? For one part, it hides the tedious work of creating listeners, binding them to widgets and having them update your Java beans behind a convenient automatism. This obviously makes the development more easy. For another part, the automatism allows GUI editors like Netbeans to actually support databinding visually. Roman Strobl (Roumen) has put together an excellent demonstration using Flash, which shows how Netbeans 6 might do the job. This stuff looks very neat, it is exactly what I was missing in Java Swing.
The Beans Databinding project is not the only effort to provide databinding in rich client applications. Specifically, there is
as I have some spare time now (being on leave for two weeks), I would like to point your attention to the JSR-295 "Beans Binding" databinding framework for Swing, which seems to be near completion. Proper databinding support looks to me to become a big plus for rich client applications with Java.
The lead of the project has very recently been taken over by Shannon Hickey, who introduces himself in this forum post at java.net: http://forums.java.net/jive/thread.jspa?messageID=206602&tstart=0#206602 He writes, the project would be "almost ready" for an initial public release.
But how exactly does a databinding framework ease the development of rich client applications? For one part, it hides the tedious work of creating listeners, binding them to widgets and having them update your Java beans behind a convenient automatism. This obviously makes the development more easy. For another part, the automatism allows GUI editors like Netbeans to actually support databinding visually. Roman Strobl (Roumen) has put together an excellent demonstration using Flash, which shows how Netbeans 6 might do the job. This stuff looks very neat, it is exactly what I was missing in Java Swing.
The Beans Databinding project is not the only effort to provide databinding in rich client applications. Specifically, there is
- the JGoodies databinding framework, which is already on the market since 2005 (Version 1.0.3 is dated at Nov. 23, 2005).
- the JFace databinding framework, which is still being designed (a provisional API is included with Eclipse 3.2 though)
posted by effjay at 12:36 am
3 Comments:
Disclaimer: I'm a committer on JFace Data Binding.
In Elipse 3.2 the library was experimental but we will be releasing 1.0 with Eclipse 3.3. The API will be frozen for 1.0 as of this weekend and there are quite a few consumers of it already. JFace Data Binding has been in the works for a while and it wouldn't make sense to drop it just because there's a JSR. I'm not up to date on the progress of the JSR but we're pretty happy so far with our library as it satisfies our needs and from what we can tell it satisfies the needs of others as well.
>"As it is new and not yet fixed, the chance is still there to switch to the standard API (if possible)."
I'm not sure what this means as it's not needing to be fixed (it's not broken). It's not possible for us to drop what we have as I stated previously the 1.0 API freeze is this weekend with the 1.0 release to follow.
-brad
I just realized that you meant "fixed" as the API was not set in stone. It is or at least will be in a few days.
One difference though between the JSR and JFace Data Binding is that we're not just targeting the binding of beans. Our core API is bean agnostic to allow for other types of models (e.g. EMF) to be bound as well. But by default we provide bean implementation of our API.
Anyway it's going to be an interesting year. It's good that there's so much work being done on this front. In the end I think we'll all win as we'll have strong libraries for the binding of data.
-brad
"In the end I think we'll all win as we'll have strong libraries for the binding of data."
It's too bad that the Java world is split between IBM/Eclipse and Sun/JSR.
Instead of one data-binding API, we end up with 3, 4, or who knows how many...
In an ideal world, Sun and IBM would cooperate much more than they do. Sigh.
Post a Comment
<< Home