Scott Violet's Blog

Update on Beans Binding (JSR 295)

Try selecting multiple elements in the table, notice the label beneath the table updates to reflect how many elements are selected. Similarly notice that when multiple rows are selected changing one of the detail values (such as the slider) updates all. But I'm getting ahead of myself.

WARNING: beans binding is in no way done and will most likely change from what I'm going to detail here.

Quick refresher: beans binding is all about binding two properties of two objects together. Properties in this sense refers to the beans notions of properties, the "foo" property is identified because you have setFoo/getFoo. If the two objects are observable (support PropertyChangeListeners), then beans binding can track changes and keep the two sides in sync. Don't get hung on using "bean" here, nearly any Object is a bean and if you're following common design patterns, you're in good shape.

Before getting into how the UI is configured, let me describe the model for this app. The model consists of a List<Bug>, where Bug is a trivial bean with properties for id, priority, synopsis ... And of course Bug is observable, meaning it notifies listeners of changes by way of PropertyChangeListener.

For this example I'm going to use BindingContext. BindingContext isn't strictly necessary; it's useful for managing a set of bindings. I envision a BindingContext per form:

context = new BindingContext();

List<Bug> bugs = ...;
Binding tableBinding = context.addBinding(
    bugs,      // Source for the binding, the List of bugs in this case.
    null,      // Expression, relative to the source, used in obtaining the property.
               // For this example it's null, meaning use bugs as is.
    bugTable,  // Target of the binding, a JTable in this case.
    "elements"); // The property of the target to bind to.

While this example isn't showing it, you can also specify a converter, validator and a handful of other properties per binding.

The next step is to specify how the values for each column are obtained:

tableBinding.addBinding(
    "${ID}",    // Expression evaluated relative to each Bug.
                // In this case, it's treated as bug.getID().
    null,       // Target value (I'm not going to get into this parameter now)
    TableColumnParameter, 0); // Specifies the binding applies to the first column

The expression language for the source is nearly the same one used by JSF/JSP. The only changes are to support a handful of things needed for binding, none-the-less it's nearly the same. Do a search for JSF expression language if you're interested in the specifics. The language for the target is just a dot separated property syntax. I'm not going to get into why these are different now.

The second and third columns are similarly bound:

tableBinding.addBinding("${priority}", null, TableColumnParameter, 1);
tableBinding.addBinding("${synopsis}", null, TableColumnParameter, 2);

Each of the detail components (text fields, slider, combobox) are driven from the selection of the table. As such, they are bound to a property of the "selectedElements" property from the table. This means that any time the selection of the table changes, the text field is updated appropriately. The following shows the code for the first text field:

Binding textFieldBinding = context.addBinding(
    bugTable,                 // Source of the binding, the JTable in this case.
    "${selectedElements.ID}", // Expression relative to the source. Evaluates to the
                              // the id property of each of the selected elements
    idTF,                     // Target of the binding, a JTextField here.
    "text",                   // The target property to bind to.
    // The next line specifies the 'text' property should change as you type.
    // The default is to change the property on enter/focus leaving.
    TextChangeStrategyParameter, TextChangeStrategy.CHANGE_ON_TYPE);

textFieldBinding.setListCondenser(ListCondenser.concatenatingCondenser(
    "\"",   // The string placed before each element
    "\"",   // The string paced after each element
    ", ")); // The string that separates each element.

context.addBinding(
  bugTable,  // The source of the binding, the table in this case.
  // The expression evaluated relative to the source. Notice this makes use
  // of the function "listSize", that returns an size of the list supplied to it.
  "${bb:listSize(selectedElements)} of ${bb:listSize(elements)} are selected",
  summaryLabel, // The target of the binding, a JLabel here.
  "text");      // The target property to bind to

The last step is to realize the bindings, or install all the necessary listeners so that everything remains in sync:

context.bind();

There's a lot that I haven't gotten into, but this should give you a feel for where beans binding is headed.

Next question I know is going to be asked: where's the source? I'm working on it!

    -Scott

Comments

• Excellent, just recently I posted on why 2006 was an exciting year for swing app development, when Hans announced the availability of Spring Application Framework prototype, and now this... can't wait to see what the guys at Swinglabs post next ;-)

  Posted by: aalmiray on February 02, 2007 at 12:13 PM

• I would be even more excited about this if not for the fact MS Visual Studio.Net has had this for 5 years now. Guys, get moving with this!

  Posted by: jacek on February 02, 2007 at 12:49 PM

• Are you going to use strings as the binding to a property??

  Posted by: mikaelgrev on February 02, 2007 at 02:42 PM

• I think you recognized it above but obviously having a strong example of seeing model changes reflected in the GUI is essential. Of course it introduces a circular loop of updates which needs to be recognized.

  I am definitely a little worried at some strange looking syntax and IMHO anytime one moves from Java towards JSP its rarely in the right direction.
  

  Posted by: aronsmith on February 02, 2007 at 05:42 PM

• Cool stuff, hope you guys will follow the recent trend and open a JSR project on java.net so we can play with the code early ;-)
  In the example when I select multiple elements with different values e.g. a bug and an enhancement I always get one of the values in the controls (always bug for some reason). In most such UI's that allow multiple selection you would expect the value to be empty and the widget is usually grayed out, e.g. try to multiple select files with different attributes in windows and select properties the attributes that are different will be grayed out in the sheet to indicate the difference. I think something like this can be achieved in Swing although it is not trivial.
  I personally am not too crazy about the expression language, can we maybe have an "evaluator" interface version so people who choose not to use the expression language can just pass their own "evaluator function"? The EL code can be just a standard implementation of the evaluator used for people who don't like verbosity.

  Posted by: vprise on February 03, 2007 at 03:34 AM

• Swing binding is cool!

  However, I don't like the EL. I prefer the "evaluator" interface.
  In my swing app, I have something like that. I call this interface a 'Getter' and I have a custom table that can use it easily:

  class XTable extends JTable {
  ...
  void addColumn(String name, Getter getter) { ...}
  }

  For example:
  static final Getter BUG_ID_GETTER = new Getter() {
  String getFrom(Bug bug) { return bug.getID(); }
  }

  Of course if the langage could directly give a typed object from a method reference, it would be less verbose for simple cases like:
  myTable.add("Identifier", Bug.getID);
  I don't know if this is something that will possible in a future java release.

  
  

  Posted by: arnaudmasson on February 03, 2007 at 05:22 AM

• Hi Scott,

  I have to say I'm a little confused. It looks interesting, but it seems to move away from MVC. I guess I might be missing something but the model seems to have disappeared in this example in favor of binding a collection directly to a table. Now I have written a reflection based table model before. I use them for simple tables with low row counts. It's handy but the first thing other people want to do is add columns for data that is related to the object but not part of the object. It's really not a good idea to extend an object to handle every visual representation of that object. Is it possible to bind different columns to different collections of data? Also why EL? I don't see anything, at least in this example, that couldn't be done with classes and generics. Please don't take this the wrong way but if EL is the alternative to a real property syntax or closures. Then I vote for anything but EL. Having never written any JSP, EL just doesn't look or feel like Java. What if I misspell "selectedElements"? This is a runtime error, and not a compile time error right? I prefer compile time errors. I also prefer checked exceptions .. so how are exceptions handled in bindings? Anyway it does look like a lot of hard work went into this. Good luck.

  Posted by: aberrant on February 03, 2007 at 06:50 AM

• Thanks for that Scott, there seems to be a lot of interest in binding for some reason at the moment. I was wondering if buffering changes was in scope for this JSR? As you know when you're showing a dialog it a common pattern that changes aren't propagated to the backing beans unless the user commits the changes with OK or discards then with Cancel. As things stand it seems binding would make the changes immediately in the case of textfields as the user types.. which in the case of jdbc/remote backed sources would'nt be ideal either.

  Also.. With beansbinding who has the responsibility to provide these observable beans? are you expecting developers to implement the boilerplate code themselves with PropertyChangeSupport or SwingX AbstractBean? or have you got some reflection/proxy magic in mind?

  
  - Richard

  Posted by: osbald on February 03, 2007 at 07:05 AM

• Thanks for the preview. I am a hesitant about EL too. Would most of that be hidden e.g. in a form designer or default classes enveloping rowsets or tablemodels?
  Conversion and validation are a must, and I can't wait to find out how these will plug in. Any chance of a short blog on that?

  Posted by: jancarel on February 03, 2007 at 07:49 AM

• Two good news in one week, "Swing Application Framework" and "Beans Binding". Thanks for your efforts. I do not know this is the correct place to ask, but when will be a demo of "Beans Validation" will be available?

  Posted by: denizoguz on February 03, 2007 at 11:53 AM

• 
  I was wondering if buffering changes was in scope for this JSR? As you know when you're showing a dialog it a common pattern that changes aren't propagated to the backing beans unless the user commits the changes with OK or discards then with Cancel. As things stand it seems binding would make the changes immediately in the case of textfields as the user types.. which in the case of jdbc/remote backed sources would'nt be ideal either.
  - Richard

  
  I think another TextChangeStrategy value will be used for specifying this behavior. Just a guess.

  Posted by: denizoguz on February 03, 2007 at 12:15 PM

• Re: buffering changes. I sent Scott a binding framework developed at my company many months ago, I'm not sure if Sun's lawyers let him look at it though :(. In it we had "listening" and "non-listening" bindings, the non-listening bindings only exchanged data when you explicitly called a push() or pull() method on the binding. Bindings could be set up to be listening in one direction only, so changes in a model were reflected immediately in a dialog, but changes in the dialog would only be pulled back to the model when you pressed OK, for example.
  I too find the EL a little icky, but it is something I might be able to get used to. In our own binding framework we had "translators" that we could attach to the bindings that would handle a lot similar stuff.

  Posted by: swpalmer on February 05, 2007 at 07:51 AM

• aronsmith,

  I think you recognized it above but obviously having a strong example of seeing model changes reflected in the GUI is essential. Of course it introduces a circular loop of updates which needs to be recognized.

  To avoid a circular loop, beans binding ignores changes if beans binding triggered the change. For example, if beans binding invokes setFoo(xxx), it'll ignore the property change for 'foo'.

  I am definitely a little worried at some strange looking syntax and IMHO anytime one moves from Java towards JSP its rarely in the right direction.

  Until java has first class support for properties, some syntax will need to be adopted. EL was created for needs similar to beans binding and is a natural fit. No point in inventing a new duplicate syntax.

      -Scott

  Posted by: zixle on February 05, 2007 at 08:28 AM

• vprise,

  In the example when I select multiple elements with different values e.g. a bug and an enhancement I always get one of the values in the controls (always bug for some reason). In most such UI's that allow multiple selection you would expect the value to be empty and the widget is usually grayed out, e.g. try to multiple select files with different attributes in windows and select properties the attributes that are different will be grayed out in the sheet to indicate the difference. I think something like this can be achieved in Swing although it is not trivial.

  The behavior of multiple selection most definitely needs to be configurable. For the purposes of this demo, I've gone with what's possible with Swing now. To really support it will require changes to various components (tri-state buttons, comboboxs that can somehow render you've got multiple selection...).
  I personally am not too crazy about the expression language, can we maybe have an "evaluator" interface version so people who choose not to use the expression language can just pass their own "evaluator function"? The EL code can be just a standard implementation of the evaluator used for people who don't like verbosity.

  It's certainly possible to make the path syntax pluggable, it just requires another level of complexity I'm hoping to avoid. We'll see though.

      -Scott

  Posted by: zixle on February 05, 2007 at 08:32 AM

• Scott,

  Thanks for your work, and we're very interested to see the source.

  As per a previous note about a departure from MVC:

  We had developed a similar binding framework that went straight from the domain to the widget. In retrospect, I think that this was a mistake. We lost control where we needed it. As an example, we used Java Persistence annotations in the domain, and bound the domain to one or more widgets, and found that the two kept stomping on each other.

  We've since moved to jgoodies. There, they have a presentation model. That can be kind of a pain to create, in that you have to have to handle a PropertyChangeEvent in every setter, but we worked around that by creating said presentation model class with a proxy factory. Something like this:

  PresentationModel model = PresentationModelFactory.create(bugs);

  The good news of that approach is that the widgets never talk to the domain directly.

  Whaddya think?

  Steve
  

  Posted by: pupmonster on February 05, 2007 at 08:32 AM

• aberrant,

  I have to say I'm a little confused. It looks interesting, but it seems to move away from MVC. I guess I might be missing something but the model seems to have disappeared in this example in favor of binding a collection directly to a table. Now I have written a reflection based table model before. I use them for simple tables with low row counts. It's handy but the first thing other people want to do is add columns for data that is related to the object but not part of the object. It's really not a good idea to extend an object to handle every visual representation of that object.

  
  Think of beans binding as automating writing the model swing components talk to. You still have your application model, but you no longer need to write the model for Swing components. There may be cases where it's easier to write the Swing model directly, but I don't think that's the common case.

  Is it possible to bind different columns to different collections of data?

  That's a bit dicey, given the two collections need not be related. Currently, you can't.
  Also why EL?

  I answered that one earlier on.
  I don't see anything, at least in this example, that couldn't be done with classes and generics.

  That's true of any ease of use layer; you can always write directly to the lower layers. Beans binding is aiming to make it easier to bind common data types together. If you prefer to write a lot of code, then you could still write directly to Swing's model;)

  What if I misspell "selectedElements"? This is a runtime error, and not a compile time error right? I prefer compile time errors.

  As do I! If we change Java to make properties part of the language, then we could avoid the runtime problems.

      -Scott

  Posted by: zixle on February 05, 2007 at 08:41 AM

• osbald,

  Thanks for that Scott, there seems to be a lot of interest in binding for some reason at the moment. I was wondering if buffering changes was in scope for this JSR? As you know when you're showing a dialog it a common pattern that changes aren't propagated to the backing beans unless the user commits the changes with OK or discards then with Cancel. As things stand it seems binding would make the changes immediately in the case of textfields as the user types.. which in the case of jdbc/remote backed sources would'nt be ideal either.

  Currently there is no direct support for buffering. The best way to handle this, at the bean level, is to clone the object and then supply it to the dialog for editing. If the user clicks ok, then the edits are passed back to the real object.

  Also.. With beansbinding who has the responsibility to provide these observable beans? are you expecting developers to implement the boilerplate code themselves with PropertyChangeSupport or SwingX AbstractBean? or have you got some reflection/proxy magic in mind?

  Currently developers must do this. The current thinking is to make beans binding know about changes beans binding makes to an object, regardless of whether you implement PropertyChangeListener. That way, from the UI perspective, beans binding can keep everything in sync even if you don't implement PropertyChangeListener. On the down side, it would mean that if you change your object in code, beans binding wouldn't know about it and the UI wouldn't update.

  Observability is key to beans binding and I most definitely understand the pain involved in making objects observability. The right thing, in the long term, is to make it trivial for developers to have properties of their objects observable. I suspect the best way to accomplish that is at the language level.

      -Scott

  Posted by: zixle on February 05, 2007 at 08:48 AM

• jancarel,

  Would most of that be hidden e.g. in a form designer or default classes enveloping rowsets or tablemodels

  Most definitely. An IDE should keep you from having to know the particulars of the path syntax.

     -Scott

  Posted by: zixle on February 05, 2007 at 08:49 AM

• denizoguz,

  I do not know this is the correct place to ask, but when will be a demo of "Beans Validation" will be available?

  Do you mean JSR 303? I'm not the spec lead for that one, so I've no idea.

      -Scott

  Posted by: zixle on February 05, 2007 at 08:50 AM

• pupmonster,

  I'll have to read up a bit more on the presentation model before I can comment entirely on that. I want to say that can be handled by duplicating your application model and binding your objects to that, but I'm not positive. Will follow up later.

      -Scott

  Posted by: zixle on February 05, 2007 at 08:53 AM

• Excellent, I did same kind of binding using JGoodies binding but it require more code.

  I am looking for data navigation capability much like netframework.

  Is there any future possibility to develop such feature?

  I found that JTable API does not have method to move selected row.

  Posted by: mikeshimura on February 05, 2007 at 08:31 PM

• mikeshimura : Do you mean like click and drag the row to a new position, or do you mean change the selected item? I'm pretty sure the drag and drop API will let you do the first and the selection model of the table will allow you to do the second.

  Posted by: aberrant on February 06, 2007 at 03:54 AM

• aberrant,

  I am looking for data navigation capability much like netframework. Is there any future possibility to develop such feature?

  What do others think? Is a navigation control important?

  I found that JTable API does not have method to move selected row.

  There isn't an explicit method for this, but it's pretty trivial code. Get the current selection, (checking for -1), increment it, and reset the selection.

      -Scott

  Posted by: zixle on February 06, 2007 at 01:38 PM

• Scott,

  Allow me to explain how directly binding the domain messed us up and how a presentation layer fixed it:

  Hibernate (the implementation of Java Persistence we were using) would swap out the implementation of say the java.util.List we were using. In our home-grown binding framework, that stomped on our implementation of List to which we for instance added Property Change listening support.

  That caused us a fair amount of grief.

  By using a presentation layer, the UI never directly talks to the domain and we have the following neat little facilities:

  commit and rollback (from the presentation layer)

  Commit updates the domain layer from the presentation layer, rollback of course updates the presentation layer from the domain.

  The UI never swaps things out from under the covers of the domain and it just plain works better especially when you start binding the domain to other things, like the database.

  How that would work with bean-to-bean binding, I don't know. This is for your consideration of course. Karsten Lenz of course could explain this much better.

  Thanks for your work, and looking forward to hearing more from you.

  Steve

  Posted by: pupmonster on February 06, 2007 at 04:09 PM

• aberrant: Thank you for your advice to use selection Model to change current selection. I overlooked it.

  Based on this function, I can easily create navigator.

  Posted by: mikeshimura on February 06, 2007 at 04:33 PM

• I have experience trouble with JTabale data binding, because I am editing table field and I clicked other field such as JTextField but still JTable is editing mode and not commit automatically.

  Is there any method to fix this behavor?

  Posted by: mikeshimura on February 06, 2007 at 04:36 PM

• I liked the approach that JDNC/SwingLabs took in the early days with the DataModel interface. That made it easy bind existing beans who didn't have PCS, and provided a way to buffer agains the domain model. I know that approach has shortcomings, but I wonder if some sort of adapter/delegate like that would be helpful.

  Posted by: wsnyder6 on February 07, 2007 at 10:28 AM

• One thought that could help here is to make the endpoints of binding to be ValueModels in the spirit of jgoodies. Since a value model is really a generalized getter/setter protocol, you open yourself up to flexibility mentioned in some of the posts above. For example, since the entire jgoodies framework is around value models and if you can use these as end points, you get buffering through jgoodies and other features such as using the presentation model's getModel() call to bind to endpoints efficiently. Of course, the value models that would be used the most are the ones that do get/sets on java beans. A convienence interface could be provided to do addBinding(sourceBean,...,targetBean, ...) type calls. I stuck some code up on sf.net using this idea (and used commons beansutils to get nested property support). I think the EL language feels complicated in the first pass here. I would keep things simpler for now and get something out the door then iterate on it after real usage has occurred.

  One thing that pops up around gui data binding is that the java gui libraries such as swing and swt seem to have not been built with exposed properties in mind that would make binding easier. I would rather see this handled through adapter external to the binding library or allow some factory builders to assist in this versus trying to account for it directly in the binding library. Perhaps that this is the thinking underneath the hood.

  Posted by: aappddeevv12 on February 07, 2007 at 08:17 PM

• pupmonster,

  Thanks for the quick description of presentation model. With a presentation model approach, you would bind the UI to your presentation model. I suspect it would work out nicely.

      -Scott

  Posted by: zixle on February 12, 2007 at 08:23 AM

• mikeshimura,

  I have experience trouble with JTabale data binding, because I am editing table field and I clicked other field such as JTextField but still JTable is editing mode and not commit automatically. Is there any method to fix this behavor?

  Try setting the client property terminateEditOnFocusLost to Boolean.TRUE on your table, and you should get what you're after. A real API will be added for this in the future.

      -Scott

  Posted by: zixle on February 12, 2007 at 08:25 AM

• Scott - thanks
  It worked perfect. I can't reach this information before.
  I feel this behavior is better than current default behavior.
  

  Posted by: mikeshimura on February 17, 2007 at 03:06 PM

• Hello.
  Can I use JRadioButton with ButtonGroup for binding component?

  Posted by: naoki_kishida on April 07, 2007 at 10:57 AM

• Nice example, concerning other posts:
  - I really do not mind the EL, and although I do not like the "elements" hack I cannot see an alternative.
  - Also, I have found a bug in the code related to multiple beans selection. I selected several items them I changed the ID !! And every Item changed it too!!. ID should be read only, is there a way to do this? Also a Condenser values should not be editable? Or should they? (I cannot find I use case for editing a Condensed value)

  Posted by: levmatta on April 11, 2007 at 07:53 AM

• Instead of the EL, wouldn't it be better to send an instance of a Method object in to bind to (which may be directly on the domain object, or on some intermediary class, such as a transformer)?

  Later, when Java supports it, the syntax would be simplified by passing in something like myObject->setName(), or, in the alternate, myObject.myProperty.

  Having an entire EL provides alternative ways of transforming (per your example for the number selected of total count), when this could easily be handled within the method bound to, using standard Java, instead of some other expression language to pollute the source.

  My 2 cents....

  Posted by: pjlacrosse on April 19, 2007 at 12:49 PM

• Hi Scott,

  I understand the motive and rational behind the decision to make the developer write the PCL-related code, and I agree they are valid. There is, however, a complication when you consider ObservableList/Map/etc - as these are no longer standard JDK PCLs, but custom "com.sun.util.*" interfaces. One could implement them himself, but that would require using custom sun classes. Would it be possible to include these ObservableXXX interfaces into "java.util" package, or perhaps "javax.beans.binding"?

  Posted by: arikk on April 29, 2007 at 03:14 PM

• How does the JSR 295 code compare to the new JFace DataBindings framework developed by the Eclipse Foundation? The JFace code is readily available via CVS, and most of the API discussions are public record on Bugzilla. I'm sure we'd all appreciate it if you could contribute your thoughts to the Bugzilla item for that purpose:
  https://bugs.eclipse.org/bugs/show_bug.cgi?id=177024

  In particular, I'm also concerned about the issue of a (non-existent) standard for observable collections. The concept of an indexed property exists in the Java Beans standard, but this is sadly insufficient for real applications. Apple's work on their KeyValueObserving protocol in Cocoa is significantly ahead of Java in this regard. Does the JSR 295 team have enough influence to push through the needed changes to the Java Beans and JSF EL specs?

  Posted by: pcentgraf on May 09, 2007 at 08:34 AM

• Is it possible to bind JTree? (got exceptions)

  Posted by: filimono on May 15, 2007 at 05:01 AM

• Can you post an example binding for your drop down combobox.

  Posted by: bwells2004 on May 24, 2007 at 12:18 PM

• How about the code snippet where you bind to the ComboBox?

  Posted by: carljmosca on May 24, 2007 at 01:32 PM

• Concerns
  - I'd echo concerns over using EL - but I appreciate that its an interim hack.
  - How scalable is this ? First looks seem to indicate its ok for a couple of 100 rows, but that it might suck significantly after that.

  Query
  - Back in the old days Master/Detail was necessary because table's weren't very flexible when it came to editing values - i.e. they were pure display grids. Does this Binding model allow for a table to be self editing ?

  It seems that this would make the creation of those little data-maintenance apps that much easier - I could have a single reconfiguring table which transformed itself according to the DB table I was looking at.

  
  

  Posted by: jb22 on June 01, 2007 at 07:42 AM

• Hi Scott,

  Is there a simple working example showing bean binding to a JTable? The description above seems to be out of sync with beansbinding-0.6.1. It would be good to include such an example with the source.

  Can beansbinding address the following usecase: the model consists of a list of orders - List<Order>. This model is shown in two JTables. Any changes to the model should be reflected in both JTables.

  Is this as simple as creating two bindings to the same model?
  Does Order have to be Observable?
  Does List<Order> have to be Observable?
  Is there an implementation for com.sun.java.util.ObservableList?

  
  

  Posted by: nbhatia on June 27, 2007 at 12:08 PM

• Thanks for your sharing! 中港物流

  Posted by: winrelocation on August 09, 2007 at 01:12 AM

This work is licensed under a Creative Commons License.