Scott Violet's Blog

Ease of Swing Development - Beans Binding

Beans Binding

  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());
      }
    }
  });

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");

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 here. The source for the first demo can be found here. Notice the source contains two variants, one implemented in terms of binding (BindingCaricatureController), the other with typical listeners (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

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?

    -Scott

Comments

• Why don't you just use javax.el w/ ValueExpressions and MethodExpressions for listeners and model backing under existing adaptors from Spring, etc?

  Posted by: jhook on May 23, 2006 at 04:08 PM

• jhook,

  The idea of using El has been raised, and would certainly simplify a handful of things. It would also nicely align with EE. Whether or not to use El is one of the things the eg will have to tackle. If we decide to use El we'll undoubtedly need to change a handful of things in El (listeners, ability to have incomplete paths ...). This needs more thorough investigation.

  Beans binding is for more than just models (selection for one), so that more than a model adaptor is needed. I don't know much about Spring though. Would you happen to have pointers to documentation, articles, white papers, whatever?

  Thanks for the comments!

      -Scott

  Posted by: zixle on May 23, 2006 at 04:17 PM

• I've come up against this problem many times over. The purported MVC architecture of Swing works well for it's internal design but falls over when you try to extend the concept for creating your own application models. For example, if you want to have a model for all the data in a dialog or form there is a lot of non-standard "wiring" that has to occur between the UI and your model class which contains the individual field models.

  Furthermore, and this really stumps me, using the existing implementation above you often need 3 references to wire in a component, e.g.:

  class myPanel extends JPanel
  {
  // ref 1 - instance variable
  JTextField textField = new JTextField();

  // ref 2 - add to swing container
  add(textField, /*constraints*/);

  // ref 3 - register property change listener or action listener
  textField.addPropertyChangeListener(/*listener*/);
  }

  
  That's an awful lot of references to maintain. I create GUI builder applications, so I need to be able to add and delete these UI and model pairs all the time. I wish there was a way to do it without the danger of leaving dangling references.

  Raj.

  Posted by: r_nagappan on May 23, 2006 at 05:17 PM

• http://weblogs.java.net/blog/jhook/archive/2006/03/the_unified_el.html
  http://java.sun.com/products/jsp/reference/techart/unifiedEL.html

  It also has support for basic structures like ResourceBundles, Beans, Maps, Arrays, etc, such that anyone can plug in their own handlers to either access specialized properties or provide additional scopes for variables, as Spring, Shale, and Seam have done for JSF. A lot of what's helped JSF's adoption is the ability for other frameworks or IoC containers to easily plug into the variable space.

  ValueExpressions do allow you to use them like pointers to other information for both getting, and setting. MethodExpressions can be provided with a specific signature that takes in a MouseEvent or ChangeEvent to nested structures that can be managed independently of the hard-references within the GUI (such is the web), but it would allow for models to have alternate lifecycles, independent of the UI.
  

  Posted by: jhook on May 23, 2006 at 05:23 PM

• It may be just me, but I can't seem to download the presentation.

  It doesn't seem to be there.

  Posted by: trcorbin on May 23, 2006 at 06:28 PM

• Scott,

  Good presentation. I liked the JTable example from Java One better than the one in this article. :-)

  
  What I've done is use POJO objects with simple collections that hold them. Having multiple JComponents that have references to the same object doesn't seem to be a problem. MVC is still a pretty thing even with an ugly POJO. :-)

  
  My renderers work great for showing state change information. So if the user does an edit I changed the foreground text to BLUE and the tooltip text to let them know it is NEW.

  
  Works for me and seems pretty simple. Not easy to test the GUI without a database connection though.

  
  Now if you put this in a GUI builder and allowed me to drag a SQL table onto a JTable. Then allow me to click which columns. Toss in a few renderers and add a custom editor like a JComboBox for a column.

  
  That would make me delete my old code in a heart beat. :-D

  Posted by: cupofjoe on May 23, 2006 at 07:25 PM

• trcorbin: There seems to be a problem with the web site. The hack is simple, in the URL look for "ip=no" and replace it by "ip=yes" after doing your search. You'll then see the links to download the PDF on the right part of the screen, as clipper icons.

  Posted by: gfx on May 23, 2006 at 11:09 PM

• In spring-richclient (alpha) we have databinding implementation (based on JGoodies binding). We should compare it with NetBeans implementation.
  I believe Jan and Larry are going to join the JSR :) Karsten of JGoodies also joined I hope?

  Posted by: ge0ffrey on May 24, 2006 at 12:56 AM

• First I want to thank you and the whole Swing team for a great JavaOne. Excellent Desktop presentations and BOF's (I should know - I attended them all ;)

  I also want to thank you for starting JSR 295. I have used JGoodies Binding extensively since Karsten released it and it's amazing how much cleaner and more structured your Swing code gets. What comes out of Beans Binding will lead to a much larger adoption and that is a Really Good Thing (TM).

  Be sure to get Karsten on the eg. He is a fairly unsung hero.

  Posted by: wass on May 24, 2006 at 01:59 AM

• Karsten a unsung hero? I can hardly spend a day without seeing JGoodies quoted on a web site on in a source code :)

  ge0ffrey: JSR 295 is, IMHO, much easier to use than JGoodies binding.

  Posted by: gfx on May 24, 2006 at 02:42 AM

• 
  Beans Binding is fundamental to easing Swing development via frameworks, so this JSR is hugely exciting!

  I read John O'Conners report on JSR296 before spotting this blog. As I said in a comment to that, I've been drafting a blog entry on bean binding for GUIs (with a JTable example) over the past few days, called "Beans Roti" which I will publish later. That presents how I've been doing beans binding in my project aptframework.dev.java.net.

  I look forward to a standard beans binding mechanism (with pluggable convertors, renderers, validators, et al) for Swing coming out of this JSR and going into Dolphin - we really need one "out the box" so that we are all banging on the same drum :)

  Posted by: evanx on May 24, 2006 at 03:26 AM

• gfx: Yeah, you and me know about Karsten, but there are gazillion Swing drones out there that haven't heard of him (and think that Romain is a country in Europe ;)

  Posted by: wass on May 24, 2006 at 03:36 AM

• All good. Does it handle converting between datatypes (e.g. your bean has a numeric property but it's entered in an alphanumeric text box)?

  Either way, it's somewhat sad that Java has in deep alpha/beta the type of basic feature that C#/.Net has had for the last 5 years and Visual Basic even earlier.

  I am glad Sun is finally paying some attention to the desktop.

  Posted by: jacek on May 24, 2006 at 05:05 AM

• 
  Yes i'm grimpy but JCaricature.java have some bugs :
  
  JCaricature is the view and the model of the MVC
  Inherits from JComponent instead of JPanel
  (use setOpaque instead).
  use paint immediatly instead of repaint.
  firePropertyChange and repaint() have not the same
  order for all methods
  getImage() should use JCaricature.class and not getClass,
  subclass will not work.
  The map could be created in a static block.
  

  
  please check codes that you drop in internet.
  because my students read it :)

  Rémi Forax

  Posted by: forax on May 24, 2006 at 07:04 AM

• Just out of interest, is there any scope at the other end of the problem for auto-generating property change events using annotations? Having to use PropertyChangeSupport manually sucks and is error prone.

  Posted by: pietschy on May 24, 2006 at 10:31 AM

• Sorry, the url in the article that I see is this:

  http://weblogs.java.net/blog/zixle/archive/2006.05.23/JavaOne.2006.binding.pdf

  I don't see an "ip=no" to replace. :(

  Oh well!

  Posted by: trcorbin on May 24, 2006 at 01:39 PM

• trcorbin: Go to the JavaOne web site to download the PDF and apply the trick :)

  Rémi: This is why we haven't released the code of other demos... Anyway, I don't see the problem of inheriting from JComponent instead of JPanel. Scott must have good reasons for that and paintImmediatly(). He's the Swing architect after all :p

  Posted by: gfx on May 24, 2006 at 01:57 PM

• wass: I thought Romain was a type of lettuce? ;)

  Great news!

  Posted by: evickroy on May 24, 2006 at 04:02 PM

• cupofjoe,

  Now if you put this in a GUI builder and allowed me to drag a SQL table onto a JTable. Then allow me to click which columns. Toss in a few renderers and add a custom editor like a JComboBox for a column.

  You missed the demo of just this at JavaOne:) We hope to have something like this in NetBeans 6 that integrates well with both beans binding and the Swing Application Framework (JSR 296).

      -Scott

  Posted by: zixle on May 25, 2006 at 07:24 AM

• ge0ffrey,

  Karsten of JGoodies also joined I hope?

  Karsten has said he would join the expert group. He has concerns with some terms of the JSPA (license agreement you need to sign to be on the expert group). Assuming we can resolve this, he'll be on the eg.

     -Scott

  Posted by: zixle on May 25, 2006 at 07:26 AM

• jacek,

  Does it handle converting between datatypes

  Yes, that is planned.

      -Scott

  Posted by: zixle on May 25, 2006 at 07:28 AM

• Hi Remi,

  1. JCaricature is the view and the model of the MVC

  I suspect this will incite a flame war, but here goes. Not all components warrant a model/view separation - especially for a demo. If we did it again, we would NOT add models for buttons and a handful of other components. Adding a model most definitely complicates things, and gives little value.

  2. Inherits from JComponent instead of JPanel (use setOpaque instead).

  Why? JCaricature is meant to be a component, not an arbitrary container, therefor it extends JComponent.

  3. use paint immediatly instead of repaint.

  Huh? repaint is the preferred way to schedule a repaint. repaint allows you to change a bunch of properties without painting the results at each step.

  Consider if every time you changed a property on a component (like font, foreground, background ...) we did paintImmediately. It would mean code like this:

  button.setFont(xxx);
  button.setForeground(yyy);

  Would paint after each invocation. That is hardly expected, would look horrid, and would have serious performance implications.

  4. firePropertyChange and repaint() have not the same order for all methods

  While inconsistant it doesn't matter. repaint is a delayed operation.

  5. getImage() should use JCaricature.class and not getClass, subclass will not work.

  Why? The advantage of getClass is one less place to change if I rename the class.

  The map could be created in a static block.

  That is certainly true. Putting it in a static block would also mean I could make it final:)

      -Scott

  Posted by: zixle on May 25, 2006 at 07:42 AM

• My main concern is that none of this is statically type checked. And I can't just "search for references" in my IDE. If I want dynamic typing, I'll use a language other than Java.

  I understand that reflection is needed in the JVM (among other things, for dynamic language support), but there are ways to define binding without resorting to dynamic typing. Maybe official specs like this should keep static typing in mind, or maybe the spec should wait until the Java language can more conveniently express these things with static references.

  Just some thoughts.
  

  Posted by: tjpalmer on May 25, 2006 at 07:47 AM

• pietschy,

  Just out of interest, is there any scope at the other end of the problem for auto-generating property change events using annotations? Having to use PropertyChangeSupport manually sucks and is error prone.

  I completely agree with you!

  This is on my list of things to investigate. I can think of at least two approaches that would address this.

  Use annotations. This would definitely solve it and most definitely stream line our code. Depending upon what level the annotations are done, it might involve tools support, and might also involve a compiler annotation. This starts sounding very much like AOP. See Graham's blog on AOP.

  Have the ability for someone (perhaps the BindingContext) to track all changes. This way you don't need property changes in your model. On the down side it means an changes done to your model outside the UI would not be tracked. Another down side is that it couldn't track dependant properties (dependant properties being when you change the main property the dependant property also changes).

  The annotation certainly has a lot of benefits and is one I'll be looking into.

  Thanks!

      -Scott

  Posted by: zixle on May 25, 2006 at 08:01 AM

• trcorbin,

  Sorry, the url in the article that I see is this: http://weblogs.java.net/blog/zixle/archive/2006.05.23/JavaOne.2006.binding.pdf I don't see an "ip=no" to replace. :( Oh well!

  There are two ways to get the pdf for the presentation. Use the URL I posted in this blog (http://weblogs.java.net/blog/zixle/archive/2006.05.23/JavaOne.2006.binding.pdf), or go to the javaone site and use the ip=no trick that Romain (gfx) mentioned. I uploaded the pdf to my blog so that you didn't have to go to the javaone site;)

      -Scott

  Posted by: zixle on May 25, 2006 at 08:04 AM

• tjpalmer,

  My main concern is that none of this is statically type checked.

  It's a good concern, and one I don't have a good answer for. If properties are made first class citizens of the JRE (one of the things being considered for dolphin) it might help. I have to think on this more...

  Thanks!

      -Scott

  Posted by: zixle on May 25, 2006 at 08:07 AM

• Hi,
  I think it is a great idea, the only problem that I see is that the "wiring" is done through strings. Isn't there a way to do it in a type-safe way?

  Maybe for the existing code is impossible, but I think that at least the new code writing after the JSR 295 is final, should have a way to do all this in a type safe way.

  Cheers
  JD
  

  Posted by: jdavi on May 25, 2006 at 08:37 AM

• Scott, thanks for the response and the willingness to consider the static/dynamic issue.

  Posted by: tjpalmer on May 25, 2006 at 09:12 AM

• Thanks Scott. I finally figured out what you meant (duh, silly me).

  Man, I wish I'd been there!

  I would love to see this type of thing, and it is exciting to see. I hope that there aren't too many binding projects out there, though as always competition does provide value.

  I'm using spring-rcp now, and it does quite a lot of nice things and has ramped up it's speed of improvement lately. Quite an exciting time for that project, too.

  Posted by: trcorbin on May 25, 2006 at 09:35 AM

• Some of what you talk about with lists and such sounds quite a bit like Glazedlists, which is one of my favorite projects out there.

  Posted by: trcorbin on May 25, 2006 at 09:55 AM

• trcorbin,

  Some of what you talk about with lists and such sounds quite a bit like Glazedlists, which is one of my favorite projects out there.

  Most definitely. Glazed lists has many elements of binding.

     -Scott

  Posted by: zixle on May 25, 2006 at 09:59 AM

• Is there any chance we could also get the source code for the BindingContext, BindingDescriptor, etc - basically the source code for the binding3.jar library? I know it's very early, but it would be helpful to see the concepts so far.
  Thanks
  Mazi

  Posted by: mazicato on May 25, 2006 at 07:10 PM

• mazicato,

  Is there any chance we could also get the source code for ...

  Definitely. I'm just sorting out the license to use. I hope to have a project up and running within the next couple of weeks with all the source.

     -Scott
  

  Posted by: zixle on May 26, 2006 at 08:06 AM

• How about putting the file back up on your blog? The link you gave and one linked in article give FNF.

  Going to the JavaOne site to find files is like a class on how NOT to build a site where people can find things. I wish some of the usability lessons we've learned in building Java GUIs would get passed on to the web team for that site. Searching for "javaone bean binding" from the search field in the JavaOne 2006 main page does not bring up your file that I can see. Please advise.

  Posted by: southc on June 05, 2006 at 11:46 AM

• southc,

  I'm not sure what happened to the pdf file. I've uploaded another version. You should be a able to see it again.

      -Scott

  Posted by: zixle on June 05, 2006 at 04:19 PM

• Has the plan to release the sources for the JavaOne demo been abandoned? I think last I read there was a delay due to the licensing issue. Then I thought I heard something mentioned on the Java Posse podcast about Swing Labs and the project being absorbed but I don't recall any details.

  I would like to see the code made available if it can be worked out.

  Thanks.

  Posted by: carljmosca on August 25, 2006 at 12:03 PM

• Getting legal approval is harder than one would think:( None-the-less I'm nearly there and hope to have an update soon.

      -Scott

  Posted by: zixle on August 25, 2006 at 01:23 PM

• Is it possible to bind JTree? And how (code snippet from javadoc does not work for me)?

  Posted by: filimono on May 15, 2007 at 04:04 AM

• My main concern is that none of this is statically type checked.
  '

  存倉
  辦公室搬運
  搬屋公司
  搬屋

  Posted by: xuefeng8 on August 02, 2007 at 03:23 AM

• Is there any chance we could also get the source code for ...

  
  存倉
  辦公室搬運
  搬屋公司
  搬屋

  Posted by: xuefeng8 on August 02, 2007 at 03:25 AM

• EF EF education,EF education,Education.com provides expert advice, features, columns, thousands of reference articles, and a community for parents of pre-school to high school students.

  Posted by: stillstayhere on November 30, 2007 at 01:53 AM

• EF EF education,EF education,Education.com provides expert advice, features, columns, thousands of reference articles, and a community for parents of pre-school to high school students.

  Posted by: stillstayhere on November 30, 2007 at 01:55 AM

This work is licensed under a Creative Commons License.