Skip to main content

Ease of Swing Development - Beans Binding

Posted by zixle on May 23, 2006 at 3:25 PM PDT

With few exceptions (Web
Start
and Beans
Persistence
) there have been very few desktop related JSRs. Well,
we're going to change that. href="http://jcp.org/en/jsr/detail?id=295">Beans Binding, or JSR
295, has just passed inception ballot and the expert group is now
forming. Wahoo!

Beans Binding

A big part of what we, desktop developers, have to write every day is
component wiring code, or glue code. Glue code is the code that
connects components to your application model. For example, connecting
a slider's value propety to a property of the selected object in a
table requires glue code. Here's an example.

  slider.addValueListener(new ChangeListener() {
    public void stateChanged(ChangeEvent e) {
      selectedObject.setFoo(slider.getValue());
    }
  });

  selectedObject.addPropertyChangeListener(new PropertyChangeListener() {
    public void propertyChanged(PropertyChangeEvent e) {
      if (e.getPropertyName() == null || "foo".equals(e.getPropertyName())) {
        slider.setValue(selectedObject.getFoo());
      }
    }
  });

Anyone that's written this code, and we all have, knows it's painful,
tedious and error prone. YUCK!

Beans Binding aims to make it easy to bind two properties of
two objects together. Taking the slider example, you might be
able to bind the two together with the following code.

  bind(slider, "value", selectedObject, "foo");

This would bind the slider's value property to the selectedObject's
foo property, such that changes to the slider are reflected in the
selectedObject, and vice versa. Take this as just an example, the JSR
was just filed, so no API has been decided upon.

Of course this is a simplified view of things, beans binding will
likely accomodate converters, and possibly validators. To be
successful it will also need to accomodate renderers.

At this years JavaOne conference Hans and myself did a presentation on
beans binding with a handful of demos. You can view the presentation
href="http://weblogs.java.net/blog/zixle/archive/2006.05.23/JavaOne.2006.binding.pdf">here.
The source for the first demo can be found href="http://weblogs.java.net/blog/zixle/archive/2006.05.23/crazyFaces.src.zip">here.
Notice the source contains two variants, one implemented in terms of
binding ( href="http://weblogs.java.net/blog/zixle/archive/2006.05.23/BindingCaricatureController.java">BindingCaricatureController),
the other with typical listeners ( href="http://weblogs.java.net/blog/zixle/archive/2006.05.23/NoBindingCaricatureController.java">NoBindingCaricatureController).
You can run the demo by clicking on the launch button below.



We also demoed how beans binding addresses more traditional database
apps at JavaOne, but being a database app, it requires a bit
more setup so I'm holding off on publishing it now. I'll return to it
later on.

Data Binding

How does this relate to data binding, and specifically href="http://jcp.org/en/jsr/detail?id=227">JSR 227: A Standard Data Binding &
Data Access Facility for J2EE?

WARNING: I am not on the expert group for 227, and do not speak for
Mike De Groot, the spec lead for 227. Mike was gracious enough to meet
with me on various occasions to help me understand where he believes
227 is going. The following is based on those conversations, but as
227 is not finalized, it may change.

JSR 227 aims to make it easy to bind to any data, be it a ResultSet an
XML service, you name it. 227 will not care about the type of your
data, there will be an intermediary class used to access the data that
knows the specific of your data. In this manner, assuming you have the
intermediary layer, 227 will work with any data. Beans Binding is much
narrower than that, it assumes you have your data in a well known
type, a bean and possibly a Map. A big part of 227 includes
declaratively describing the bindings and data, Beans Binding will not
include a delcarative XML file describing the bindings and data.

So, why care about beans binding? If you're a good OO citizen you've
already created some mapping layer from your database (or other
backend) to real objects. Hibernate, Mustang's DataSet, and
EJB 3 all do this; they provide a way for you to get real object
graphs. Once you've done that, it'll just work with beans binding and
the world will be a happier place. Ok, perhaps that's a bit grand, but
at the least beans binding will simplify wiring your application
objects to components.

What can you do?

As I mentioned, beans binding will be done as a JSR. If you are
interested in helping shape the API, and have time to be on an expert
group, head over to the href="http://jcp.org/en/jsr/detail?id=295">home page for beans
binding and click on the href="http://jcp.org/en/jsr/egnom?id=295">I would like to join this
JSR link. For those that are interested, but can't commit the
time, watch the home
page for 295
for updates. Within the next month or so we'll settle
on a java.net project for the prototype including public forums and
what not.

    -Scott

Related Topics >>