Shannon Hickey's Blog

Beans Binding 1.0 Released

-- From Saint Petersburg, Russia @ 3:30 AM local time

It's finally time! After months of eating, sleeping and drinking Beans Binding, I'm thrilled to finally announce that version 1.0 has been released at http://beansbinding.dev.java.net for your binding pleasure!

1.0 represents a major re-architecture of the Beans Binding API, based on the extremely valuable feedback from members of the expert group and the community. I'd like to say thank you to all of you who have discussed ideas with me and contributed your own. I've tried to combine and build on these ideas and create an API that is powerful, flexible, extensible and easy to use. I hope you'll keep the feedback coming so we can continue this rewarding process.

While the work on this project continues through the JCP process, with feature additions and possible API changes to come, the current state represents the core API that is expected, for the most part, to persist. As such, we're calling it 1.0 and releasing!

Some of the major points of interest in this release:

• The concept of a property has been factored out into an abstract Property class, with two concrete implementations of interest: BeanProperty and ELProperty.
• Binding is now an abstract class representing a binding between two Property instances (typically associated with two objects).
• Binding with automatic syncing is implemented by a new concrete AutoBinding subclass.
• Bindings to complex Swing components (such as JTable, JList and JComboBox) are now handled by custom Binding subclasses.
• The synthetic Swing properties that offer multiple possible behaviors are now exposed via multiple versions of the property. For example: "text", "text_ON_FOCUS_LOST" and "text_ON_ACTION_OR_FOCUS_LOST" for JTextField; "selectedElement" and "selectedElement_IGNORE_ADJUSTING" for JList and JTable.
• Everything has been repackaged into org.jdesktop packages.

It is my hope that the JavaDoc provided with this release will have you well on your way to binding with the new API very quickly. While I would love to take you on a tour through the entire API here, composing such a tutorial would delay this announcement. As such, I'll present a few examples to get you started, let you get going with the new API, and then follow up with additional blog entries, as time allows, on particulars deserving more attention. As always, please feel free to send me your questions and/or feedback at any time.

Examples

For the purposes of these examples, we'll work on Person beans, and assume that Person has the following properties: firstName, lastName, age and mother.

Creating and using BeanProperty and ELProperty:

  // create a BeanProperty representing a bean's firstName
  Property firstP = BeanProperty.create("firstName");

  // create a BeanProperty representing a bean's lastName
  Property lastP = BeanProperty.create("lastName");

  // create a BeanProperty representing the firstName of
  // a bean's mother
  Property motherFirstP = BeanProperty.create("mother.firstName");

  // creata an ELProperty representing a bean's mother's full name:
  Property motherFullP =
      ELProperty.create("${mother.firstName} ${mother.lastName}");

  // create an ELProperty representing whether or not a bean's
  // mother's age is greater than 65
  Property motherOlderP = ELProperty.create("${mother.age > 65}");


  // print Duke's first name
  System.out.println(firstP.getValue(duke));

  // print John's first name, reusing the same property
  System.out.println(firstP.getValue(john));

  // print Duke's mother's full name
  System.out.println(motherFullP.getValue(duke));

  // set Duke's mother's first name
  motherFirstP.setValue(duke, "Jennifer");

  // set John's mother's first name, reusing the same property
  motherFirstP.setValue(john, "Melanie");

  // listen for changes to motherOlderP for Duke
  motherOlderP.addPropertyStateListener(duke, listener);

Creating AutoBindings between two properties:

  // Bind Duke's first name to the text property of a Swing JTextField
  BeanProperty textP = BeanProperty.create("text");
  Binding binding =
      Bindings.createAutoBinding(READ_WRITE, duke, firstP, textfield, textP);
  binding.bind();

  // Bind Duke's mother's first name to the text property of a Swing JTextField,
  // specifying that the JTextField's text property only reports change
  // (thereby updating the source of the READ_WRITE binding) on focus lost
  BeanProperty textP = BeanProperty.create("text_ON_FOCUS_LOST");
  Binding binding =
      Bindings.createAutoBinding(READ_WRITE, duke, motherFirstP, textfield, textP);
  binding.bind();

  // Bind the motherOlderP for Duke to the selection of a display-only Swing JCheckBox
  BeanProperty selectedP = BeanProperty.create("selected");
  Binding binding =
      Bindings.createAutoBinding(READ, duke, motherOlderP, checkBox, selectedP);
  binding.bind();

Using Swing Binding subclasses:

  // Bind a List of Person objects as the elements of a JTable and specify
  // that columns should be shown for the beans' first name, mother's full
  // name and whether or not the mother is older than 65
  JTableBinding tb = SwingBindings.createJTableBinding(READ, personList, personJTable);
  tb.addColumnBinding(firstP)
      .setColumnName("First Name").setColumnClass(String.class);
  tb.addColumnBinding(motherFullP)
      .setColumnName("Mother's Full Name").setColumnClass(String.class);
  tb.addColumnBinding(motherOlderP)
      .setColumnName("Mother older than 65").setColumnClass(Boolean.class);
  tb.bind();

  // Bind the last name of the table's selected element to a JTextField
  Property selectedLastP = BeanProperty.create("selectedElement.lastName");
  Property textP = BeanProperty.create("text");
  Binding selBinding =
      Bindings.createAutoBinding(READ_WRITE, personJTable, selectedLastP,
                                             textfield, textP);
  selBinding.bind();

  // Bind a List of Person objects as the elements of a JList
  // and specify that the list should display the first name of the beans
  JListBinding lb = SwingBindings.createJListBinding(personList, personJList);
  lb.setDetailBinding(firstP);

  // Bind the last name of the list's selected element to a JTextField,
  // specifying that changes to the selected element are ignored while
  // it is adjusting
  Property selectedLastP =
      BeanProperty.create("selectedElement_IGNORE_ADJUSTING.lastName");
  Property textP = BeanProperty.create("text");
  Binding selBinding =
      Bindings.createAutoBinding(READ_WRITE, personJList, selectedLastP,
                                             textfield, textP);
  selBinding.bind();

Comments

• Moving to Saint Petersburg because you're afraid of the community reaction... You're now much closer to Mikael :)

  Posted by: kirillcool on September 05, 2007 at 05:24 PM

• Shannon, Thank you for all your hard work on JSR-295 and thanks to the community members who have been down this road and helped make it better. I have not had time to play with the latest release yet but I will soon; it looks like a very rich set of binding features. I am most anxious to get a JComboBox example going because we're doing a good bit of that (this worked nicely in the 0.6 release and I suspect it will be good once I figure it out in 1.0). Have a great month away; hope it's for fun!

  Posted by: carljmosca on September 05, 2007 at 05:53 PM

• Hehe, rock throwing distance almost .... ;-)

  Posted by: mikaelgrev on September 05, 2007 at 10:00 PM

• Congrats on the release. One of the most pervasive and exciting JSR's these days for sure!

  Posted by: mrmorris on September 05, 2007 at 11:45 PM

• Hello Shannon,

  Is JSR 295 going to define properties as well, and not just the binding between them? Properties in Java is a very complex addition in itself and it needs to be carefully though about. Do you see any problem with JSR 295 defining a property interface when there is no agreed upon property proposal? It would be unfortunate if JSR 295 defines a property interface as it might tigh the hands of a real property proposal. What are your thoughts about this?

  Cheers,
  Mikael

  Posted by: mikaelgrev on September 06, 2007 at 12:37 AM

• Well that was a surprise, last we heard you were off travelling for a month.. how do I go about migrating code binding to documentmodel changes? I mean the old the textchange strategy:

  binding.putParameter(ParameterKeys.TEXT_CHANGE_STRATEGY, TextChangeStrategy.ON_TYPE);
  

  Posted by: osbald on September 06, 2007 at 02:56 AM

• Just looked over the source re: TEXT_CHANGE_STRATEGY and it's just the baseproperty 'text' I was after. e.g. BeanProperty.create("text")

  Posted by: osbald on September 06, 2007 at 03:27 AM

• Great! When will the API changes be integrated into the Form Designer of NetBeans 6?

  Posted by: mbien on September 06, 2007 at 04:11 AM

• So if I'm reading this correctly, you can use BeansBindings without EL? Thats the purpose of the plain BeanProperty class right?

  Posted by: aberrant on September 06, 2007 at 05:39 AM

• Cool! Will you create some tutorial about creating and using own convertors and validators? I think, this is very interesting area, especially for beginners.

  Posted by: bianco on September 06, 2007 at 05:40 AM

• kirillcool: Thankfully, I'm not afraid this time as I'm hoping to receive much more positive response to the new API. As for Mikael, I recall a positive JavaLobby post in the recent past saying he was on board - yay! Oh, and while I love Saint Petersburg, I'm just visiting colleagues, and of course having some fun at the same time.

  Posted by: shan_man on September 06, 2007 at 06:44 AM

• carljmosca: Thanks for the post and the best wishes on my time away. Please let me know how it works out converting your JComboBox bindings!

  Posted by: shan_man on September 06, 2007 at 06:45 AM

• * Shannon throws a rock to mikaelgrev *

  Posted by: shan_man on September 06, 2007 at 06:46 AM

• mrmorris: Thanks for the congrats!

  Posted by: shan_man on September 06, 2007 at 06:50 AM

• mikaelgrev: Defining first class property support in the Java language is something that I continue to hear about internally. I'm not sure what the current status of such a proposal at this time, but it exists outside of the scope of JSR 295. As you know, JSR 295 is being designed to be used now and with versions back to 5.0. I've planned for JSR 295's abstract Property class not to hinder development of first class property support, but rather to make it easy to adapt any such future development to Beans Binding. Thanks for the great question!

  Posted by: shan_man on September 06, 2007 at 06:55 AM

• osbald: Surprise! Yes, I'm travelling, but the first three weeks are for business, followed by a needed week of rest. Creating a Property representing a JTextField's text, and specifying the text change strategy is now a single operation:

  BeanProperty.create("text");  // updates on all changes
  // OR
  BeanProperty.create("text_ON_FOCUS_LOST");
  // OR
  BeanProperty.create("text_ON_ACTION_OR_FOCUS_LOST");
  

  Hope this helps!

  Posted by: shan_man on September 06, 2007 at 06:59 AM

• mbien: This work is going on now and expected to be done in the beta release.

  Posted by: shan_man on September 06, 2007 at 07:00 AM

• aberrant: Yes, you can definitely ignore EL completely if you so choose. You can use BeanProperty to reference properties by dot-separated path, or even write your own Property implementation!

  Posted by: shan_man on September 06, 2007 at 07:01 AM

• bianco: Conversion and Validation is definitely something that I plan to write about. However, it's clear to me that validation, being extremely important , needs to be made even more convenient. I also need to spend some time developing the use patterns to advocate. As such, I'm holding off on such a tutorial until additional effort can be spent in the area. Thanks!

  Posted by: shan_man on September 06, 2007 at 07:10 AM

• * Mikael puts rock on shelf, for optional usage, later *

  Shannon, one thing that you have taken side on is whether a property should be stateless or not. You have chosen the stateless route. Stateless in this context means that the property is not connected to the bean and thus the bean has to be provided to get/set the value. Most people I have been talking to (about a new property proposal that isn't public yet) think properties need to be holding on to the bean. A notable exceptions is Jesse Wilson who argues for statlessness.

  I am more for properties holding on to the bean but I am willing to discuss it. What is important here is that one can not have it both ways. Stateless or not is a one time choice and can not be changed once the decision has been made. Therefore, if you introduce statless properties in JSR 295 the final property proposal also needs to be stateless or they will be incompatible. Stateless means that properties will be much less powerful.

  So, my question is, have you carefully made the choice to make properties statless or is that something that just happened as a use case for binding?

  Cheers,
  Mikael

  Posted by: mikaelgrev on September 06, 2007 at 07:50 AM

• Well I'd like to say thanks you Shannon for building a structure that does not depend on EL specifically. I was rather vocal in my disapproval of that system. I probably will have to write my own Property implementation, but now I don't have to write everything from scratch.
  Thanks again,

  Collin

  Now... to go think real hard about the statefull/stateless argument Mikael brought up.
  

  Posted by: aberrant on September 06, 2007 at 08:06 AM

• mikaelgrev: This is a great conversation to have! The stateless Property decision was made with an enormous amount of consideration, and I am absolutely convinced of the current design. Let me first point out a very important point: Although the Property API obviously lends itself to the concept of statelessness, it was designed to not preclude its use as the basis for stateful subclasses, including wrappers for first-class properties in the language. This is actually called out in the class level documentation of Property.

  A subclass can easily add support for associating a bean, or for not requiring a bean at all. For example, one could define a ColorProperty that stores a Color object itself, and is not associated with any bean. It would, of course, document this, and ignore the source parameter in method calls. Such a ColorProperty could be used by itself as an instance member of a bean, or be used in a Binding.

  And what I've outlined above is fantastic, because it turns out that JTableBinding and JListBinding need stateless properties. Both of these bindings need to re-use Property instances for both rendering elements (which could be handled by changing the source on a stateful property) and, more importantly, listening for changes to every element. This second part is impossible without a reusable stateless property.

  There is actually one more discussion that needs to take place, but I'll admit that I'm not quite ready for it yet. BeanProperty and ELProperty are "stateless" from the outside but they do, in fact, internally keep track of listeners that they've installed on source objects. Jesse Wilson has suggested that, for various reasons, it would be nice to not do this record-keeping in the Property itself. As of now, I'm not sure there's another viable approach for these two property implementations, but I'll be resurrecting the conversation when I have some more time.

  Thanks!

  Posted by: shan_man on September 06, 2007 at 09:28 AM

• aberrant: Thanks for leaving your comment. And you're very welcome :)

  Posted by: shan_man on September 06, 2007 at 09:30 AM

• I cannot compile your code with NetBeans M10. This line (that is correct):

  BeanProperty textP = BeanProperty.create("text");

  get marked as wrong (incompatible types)

  I've tried with eclipse and all works fine. I think there must be any jar clash somewhere..any idea ?

  ssette

  Posted by: ssette on September 06, 2007 at 09:37 AM

• Shannon: It sure is a great conversation! :-)

  I have tried for some time now to marry the two concepts in a way that would make sense API wise. Your solution, to have a documented exception that the source will be disregarded, is not particularly nice to tools as they have no way to distinguish the two cases. Tools need consistency, firmness and predictable results. The API needs to be good or it will not be used (indexed and vetoable properties in the JavaBean spec 1.01 comes to mind..)

  They way you model a property, statelessly, is not really a Property, it's a PropertyAdapter or maybe a PropertyAccessor. A Property is a part of something (of which it is a property), or so I see being the general interpretation: (http://en.wikipedia.org/wiki/Property_%28programming%29)

  So, in short, stateless properties are not really properties, they are property accessors. This is since they live outside the object, on its own, allowing access to a property of some bean.

  I do not understand your example where JListBinding need stateless properties. It should never be up to the property to 'listen' for anything, it is only denoting a property. In my proposal I also define CollectionProperty, ListProperty and MapProperty. They would be used to denote a one to many relationship and if I understand some of what you mean, they solve that use case (a JList would expose at least (ListProperty) selectedItems, (Property) editingItem and (ListProperty) items, all of which you can listen to).

  IMO properties, validation, binding and the new JavaBean spec are tightly interconnected and can not be created on their own. Also, this is a very very complicated issue where the wrong starting point will cripple the synergy forever. I therefore urge that a few smart people with the right background and leverage, within Sun and outside, come together and outlines how this mesh of techniques should be crafted. That should ideally be done before any of the parts gets finished. Btw, this touches a whole bunch of the JSR slated for Java 7...

  In any case, I am glad you refactored to not be dependent upon EL. That would have been a real show stopper I think.

  Btw, have you seen the pre-release of my property proposal?

  Cheers,
  Mikael

  Posted by: mikaelgrev on September 06, 2007 at 01:53 PM

• ssette: I've just sent e-mail to the NetBeans engineers whom I work with on Beans Binding integration. I've asked them to investigate and post a response directly. Thanks!

  Posted by: shan_man on September 06, 2007 at 03:17 PM

• ssette: NetBeans M10 is bundled with the old (0.6) version of the library. You should try the latest development builds of NetBeans or wait for 6.0 Beta 1 build (these contain 1.0 version of the library).

  Posted by: stolis on September 07, 2007 at 12:11 AM

• Shannon, like many others I was quite disturbed by the initial proposal, where the binding was tightly coupled to EL. I also share Mikael's concerns regarding the "big picture" of potential future property proposals. However, I was following the mailing list discussions, and I'm very pleased about the constructive dialog with the community. Good job!

  Posted by: scotty69 on September 07, 2007 at 02:42 AM

• The new API is clear and simple. Everything seems at its place.
  One more step in the right direction...
  Congrats !

  Posted by: nopjn on September 07, 2007 at 04:24 AM

• Hello Shannon, Thank you for all API changes, it really makes that project cleaner and easier to use. Abstraction to Property level is also nice to have, it gives more flexibility for developers like me. Looking at new API I believe we will use it in our current project, where we have already designed forms from one hand and generated domain objects from other one. I started to test latest version and met one problem: selectedElement property doesn't work. As I understand from your docs this property is not "readable". Any idea?

  Posted by: sozonovsky on September 07, 2007 at 05:32 AM

• Well, This looks great but is it possible to have a [strong]documentation[/strong] or a simple example ?

  Posted by: pseudo on September 07, 2007 at 07:07 AM

• pseudo: Glad you like it! As for documentation, have you downloaded and browsed the JavaDoc yet? It's extremely thorough, with many simple examples. A full tutorial is forthcoming. Thanks!

  Posted by: shan_man on September 07, 2007 at 08:36 AM

• Oh no, I haven't cheched the the javadoc yet. Thx shan_man :-)

  Posted by: pseudo on September 08, 2007 at 05:49 AM

• nopjn: Thank you for the comment and congratulations!!

  Posted by: shan_man on September 09, 2007 at 04:41 AM

• scotty69: Thank you for your encouraging comment on the way this project is being discussed with the community! It can often be difficult to manage so many excellent ideas with such a wide range of opinions, and still drive the project forward. I'm very happy when I hear that this appears to be working on this project. All the best!

  Posted by: shan_man on September 09, 2007 at 04:51 AM

• sozonovsky: You're very welcome, and I'm happy to hear that you see this as being useful for your current project! You mention that the selectedElement property doesn't work. Can you possibly elaborate some more? selectedElement IS readable. It's just not currently writeable. This means that it can act as the source of a READ or READ_ONCE Binding, but it's not currently appropriate as a target, or part of a READ_WRITE binding. This is a temporary limitation that will disappear as soon as I'm able to implement writeability. Thanks!

  Posted by: shan_man on September 09, 2007 at 04:53 AM

• What happened with BeanContext.clearHasEditedTargetValues method? BeanContext is now BeanGroup, getHasEditedTargetValues is now getHasEditedTargetBeans, but clearHasEditedTargetValues is missing. Same situation is in Binding class.

  Posted by: aurelije on September 09, 2007 at 08:46 AM

• Hello Shannon,

  I tried the following code:

  public class TestSelectedElementBinding {
  
    @Test
    public void testSelectedElementAsInExample() {
  
      JTable table = new JTable();
  
      Permission permission1 = new Permission("p1", "Permission1");
      Permission permission2 = new Permission("p2", "Permission2");
  
      List<Permission> permissions = new ArrayList<Permission>();
      permissions.add(permission1);
      permissions.add(permission2);
  
      JTableBinding<Permission, List<Permission>, JTable> tableBinding =
          SwingBindings.createJTableBinding(
              AutoBinding.UpdateStrategy.READ_WRITE,
              permissions, table);
  
      BeanProperty<Permission, String> shortNameProperty = 
          BeanProperty.create("shortName");
      BeanProperty<Permission, String> nameProperty = 
          BeanProperty.create("name");
  
      tableBinding.addColumnBinding(shortNameProperty);
      tableBinding.addColumnBinding(nameProperty);
  
      JTextField field = new MyJTextField();
  
      AutoBinding binding = Bindings.createAutoBinding(AutoBinding.UpdateStrategy.READ,
              table, BeanProperty.create("selectedElement.shortName"),
              field, BeanProperty.create("text"));
  
      binding.bind();
  
      table.getSelectionModel().setSelectionInterval(0, 0);
      Assert.assertEquals(field.getText(), permission1.getShortName());
      table.getSelectionModel().setSelectionInterval(1, 1);
      Assert.assertEquals(field.getText(), permission2.getShortName());
    }
  
    public static class MyJTextField extends JTextField {
      public void setText(String t) {
          System.out.println("Text: " + t);
          super.setText(t);
        }
    }
  }
  

  where Permission is a simple POJO with property change support. My expectation was this test should work, but I couldn't get it working.

  PS By the way, how long time do you plan to stay in Saint-Petersburg? Our team are native Saint-Petersburg people and probaby we could have some beer together, what do you think? ;-)

  Posted by: sozonovsky on September 10, 2007 at 12:27 AM

• Shannon, did you read my last message?

  Posted by: mikaelgrev on September 10, 2007 at 01:52 AM

• From the release notes: "Please note that the process of updating the project's unit test suite for the re-architecture has not yet been completed. As such, the majority of unit tests are not compileable or runnable." Um.. if the unit tests weren't working, how did you know the code was working properly for the 1.0 release? :-) If the unit tests aren't used, why bother having them?

  Posted by: swpalmer on September 10, 2007 at 09:11 AM

• Hi mikaelgrev! Yes, I've definitely read your message. I'm just wrapping up my busy Russian trip and heading to a few work days in Prague, followed by a week or so of vacation with the family. I've been trying to keep up with blog comments where possible, but the important discussion we've started on properties is likely going to have to continue when I return. It's one that shouldn't be rushed. I hope you understand, and I'll ping you on it when I can. Thanks!

  Posted by: shan_man on September 11, 2007 at 02:54 PM

• The JTable binding example code works with an explicit model binding:

  ==> List<Person>

  Example from http://weblogs.java.net/blog/shan_man/

  // create the person List
  List people = createPersonList();
  
  // create the binding from List to JTable
  JTableBinding tb = SwingBindings.createJTableBinding(READ, people, jTable);
  
  // define the properties to be used for the columns
  BeanProperty firstNameP = BeanProperty.create("firstName");
  BeanProperty lastNameP = BeanProperty.create("lastName");
  BeanProperty ageP = BeanProperty.create("age");
  
  // configure how the properties map to columns
  tb.addColumnBinding(firstNameP).setColumnName("First Name");
  tb.addColumnBinding(lastNameP).setColumnName("Last Name");
  tb.addColumnBinding(ageP).setColumnName("Age").setColumnClass(Integer.class);
  
  // realize the binding
  tb.bind();
  

  Does the binding API cover List<List<...> binding? For example :

  JTableBinding tb
      = SwingBindings.createJTableBinding(READ, modeListListReference,sortableTable) ;
  BeanProperty aColumn = BeanProperty.create("(0)") ; // row.get(0)
  BeanProperty bColumn = BeanProperty.create("(1)") ;// row.get(1)
  BeanProperty cColumn = BeanProperty.create("(2)") ;// row.get(2)
  BeanProperty dColumn = BeanProperty.create("(3)") ;//// row.get(3)
  
  tb.addColumnBinding(aColumn).setColumnName("A").setColumnClass(String.class);
  tb.addColumnBinding(bColumn).setColumnName("B").setColumnClass(String.class);
  tb.addColumnBinding(cColumn).setColumnName("C").setColumnClass(String.class);
  tb.addColumnBinding(dColumn).setColumnName("D").setColumnClass(String.class);
  tb.bind() ;
  

  The basic TableModel corresponding code is:

  public Object getValueAt(int rowIndex, int columnIndex) {
      List row = (List) getRow(rowIndex);
  
      switch (columnIndex) {
          case 0 : return row.get(0);
          case 1 : return row.get(1);
          case 2 : return row.get(2);
          case 3 : return row.get(3);
          default :
              throw new IllegalStateException(" Unknown column index ");
      }
  }
  

  How to do this with BeanBinding API 1.0?

  Posted by: kangguru on September 14, 2007 at 12:30 AM

• Hello Shannon, really a great work! I tried JTableBinding and JListBinding, and they work fine... and there is really little code to write. I have some problems with JComboBoxBinding: I want to bind one or more columns of a database table field to a JComboBox, but there is nothing like BindingDetail of JListBinding; I tried with source Properties, but there is so little doc about this. Can you show me some lines of code? Thanks very much!

  Posted by: ambrcol on September 21, 2007 at 04:06 AM

• Hi, I do not like the "text_ON_FOCUS_LOST" synthetic property syntax. It looks like a hack. Would it be possible to extract the notification semantics into a separate argument of the BeanProperty constructor, or alternatively into custom Property implementations?

  Posted by: bono8106 on September 25, 2007 at 01:52 AM

• Hi. I really love this swing binding stuff. I'm just curious, but how would I go about binding to a JTextArea or JTextPane?

  Posted by: jayeaeotiv on September 27, 2007 at 03:46 PM

• Hello Shannon, I found my own mistake in checking "selectedElement" code. Problem was very stupid - IntellijIdea didn't copy resource file "org.jdesktop.beansbinding.ext.BeanAdapterProvider" and no adapter were found. Sorry for that. Now we need to add our own adapters because of some reasons, but the only way to do that is now extention of your "org.jdesktop.beansbinding.ext.BeanAdapterProvider" file, which is really not best solution. One could see you are planning to support that, is it correct?

  Posted by: sozonovsky on September 28, 2007 at 03:13 AM

• Hello Shannon,

  Hello, I try the following code, but the refresh do nothing, why ?

  A monBean = new A(); //contains a single property "label"
  monBean.setLabel("LABEL1");
  JLabel jlabel = new JLabel();
  
  AutoBinding binding
      = Bindings.createAutoBinding(READ_WRITE, monBean, BeanProperty.create("label"),
                                               jlabel, BeanProperty.create("text"));
  binding.bind();
  
  //print : bean=LABEL1/jlabel=LABEL1
  System.out.println("bean=" + monBean.getLabel() + "/jlabel=" + jlabel.getText());
  monBean.setLabel("label2");
  
  binding.refresh(); //or	binding.refreshAndNotify();
  
  //print : bean=label2/jlabel=LABEL1
  System.out.println("bean=" + monBean.getLabel() + "/jlabel=" + jlabel.getText());

  Posted by: jcarre on September 28, 2007 at 08:59 AM

• Hello Shannon. I'm trying to wrap my brain around Bean-binding and automatic testing of legacy SwingApps. Hopfully in a way with minimal changes to the original SwingApp. I'm aiming at a new test-project in Eclipse. This will start the original SwingApp, bind to some Gui-components(e.g. Buttons),and simulate user-gestures by changing the bindings value. This will trigger ChangeEvent-listeners in the SwingApp and send messages to backend. Backend responds, and the reponses update visible GUI-components. Also updated & controlled are corresponding bound-variables. These bound-variable's value, decide if the test succeeded or not. Possibly, jUnit can be employeed. Out SwingApp is highly multi-threaded, with events comming all the time reflecting changes on the server, could this become a issue? Is this king of "automatic testing" right Problem-domain for Bean-Binding?? Hopfully there soon will come a illustrative example, how to preserve the legacy Original, and introduce tests of this kind. best reards Ivan P.

  Posted by: ivanp98 on October 04, 2007 at 06:03 AM

• Hello jcarre! I suspect the problem is that your A bean isn't firing property change notification. Please see the following JavaDoc in BeanProperty:

  "...when there are PropertyStateListeners installed, the beans along the path (including the final value) are cached, and only updated upon notification of change from a bean. Again, this makes it very important that any bean property that could change along the path fires property change notification."

  Posted by: shan_man on October 22, 2007 at 01:11 PM

• Anyone got any sample code of binding JComboBox beyond the simple List example? I.e. I have a list of User entity beans and want to bind to the UserName property?

  Posted by: bartlettpsj on October 22, 2007 at 03:33 PM

• Hi bartlettpsj. As you've probably already seen, the JavaDoc for JComboBoxBinding shows how to bind a list of objects to a JComboBox. The objects are displayed using their toString() values, and one can bind to the "selectedItem" property. At the current time, this is the extent of support for JComboBox. In a future version I hope to support DetailBinding like for JList, and a "selectedElement" property. Thanks!

  Posted by: shan_man on November 01, 2007 at 12:18 PM

• aurelije: A while back you asked about getHasEditedTargetValues() and clearHasEditedTargetValues(). Sorry for the delay in responding. These methods have been removed for the time being while I investigate adding back a robust system for managing things that are edited in a BindingGroup. Thanks!

  Posted by: shan_man on November 06, 2007 at 10:30 AM

• sozonovsky: It seems I owe you answers to a few questions, and I apologize for the delay. It looks like you solved the problem you had with selectedElement, so I'll leave that one alone.

  You kindly asked how long I was in Saint Petersburg. Unfortunately, that last trip was a rather short and busy one, so I was unable to catch you in time. I tend to visit every year, however, and would love to try again next time.

  Finally, you asked about adding your own adapters. This is something that I have plans to support in the future. For the time being, however, I haven't finalized the API to support it.

  Thanks!

  Posted by: shan_man on November 06, 2007 at 10:37 AM

• swpalmer: You asked about the non-functioning unit tests. With the major re-architecture for 1.0, most of the API and functionality changed so drastically that I've deemed it cheaper to write a new unit test suite from scratch rather than try to update the existing tests. And I want to do this in an organized way, rather than throwing a bunch of things into JUnit. This will take time. For the 1.0 release, the code was tested with manual tests by myself, our SQE, NetBeans SQE and other team members. Some of this work will eventually make it into the JUnit test suite.

  As for the question of why the tests were left in the release, that was merely a temporary convenience for myself. I left the tests in the repository simply as a place to keep the code for reference. And the build system automatically packages it up into the release. I've now archived them and removed them.

  Thanks!

  Posted by: shan_man on November 06, 2007 at 10:51 AM

• kangguru: You asked a great question! BeanProperty and ELProperty do not currently support referencing items in Lists or Arrays. I've made a note to myself to consider adding support for this. Note that Maps are supported, and allow values to be looked up by keys:

  BeanProperty.create("key1");
  BeanProperty.create("key2");
  BeanProperty.create("key3");
  // etc...
  

  Posted by: shan_man on November 06, 2007 at 11:06 AM

• ambrcol: Thanks for the nice feedback on the project. To answer your question about JComboBoxBinding - unfortunately the current support for JComboBox is very limited, and all objects show their toString() values. In a future version I hope to support DetailBinding like for JList and JTable. Thanks!

  Posted by: shan_man on November 06, 2007 at 11:10 AM

• bono8106: I agree that attaching the behavior aspect to some of the synthetic properties isn't beautiful. However, it turned out to be the best of numerous options:

  One of the things I tried was having Property subclasses for such properties. Such as JTextComponentTextProperty. This had two main drawbacks: The first concerned third parties wanting to adapt their own beans - It's simple to write an adapter to adapt an object to the beans specification. It's something more to force them to adapt to the Property interface. The second drawback was that these custom properties could not be used within ELProperty or BeanProperty as part of an expression.

  Another approach that I tried was similar to what you proposed. That is, having (an) additional parameter(s) to *configure* how the property is interpreted. Something like:

  ELProperty.create("${textfield1.text} ${textField2.text}", ON_TYPE, ON_FOCUS_LOST);
  

  For multiple reasons, this approach was unfavorable when I shopped it around to fellow engineers. And it would also prove very tricky to implement. It was proposed that it would be nicer if I could invent a syntax that would allow the configuration information to sit beside the property it applies to. While investigating this, it dawned on me that rather than invent a syntax (which must not conflict with EL) I could just expose extra synthetic properties, with configuration information built into their name. This provides multiple benefits: 1) It's easy for third parties to implement, 2) It requires no extra parsing and state tracking, 3) PropertyDescriptors can be provided for the synthetic properties, stating their behavior, to be displayed by builder tools.

  Posted by: shan_man on November 06, 2007 at 11:32 AM

• jayeaeotiv: You ask about binding to a JTextArea or JTextPane. It's the same as JTextField; you bind to the "text" property.

  Posted by: shan_man on November 06, 2007 at 12:01 PM

• ivanp98: I don't know enough about your problem domain to say whether or not Beans Binding is part of a good solution. But Beans Binding certainly simplifies making connections between properties of beans. You mention that your application is highly multi-threaded. Just make sure that all interaction with Swing components, including through Bindings, occur on the Swing Event Dispatch Thread.

  Posted by: shan_man on November 06, 2007 at 12:05 PM

This work is licensed under a Creative Commons License.