• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Using JSR-295 beansbinding, where do you bind to?

 
Janne Mattila
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
(spin-off from http://www.coderanch.com/t/450800/Swing-AWT-SWT-JFace/java/good-desktop-application-architecture-with#2007519)

For those who use beansbinding to bind your Swing UI components into something, what is that "something" youre binding to?

A practical example: I have object Bank inside my application domain model layer:



This Bank class is part of application logic which should not be aware of anything Swing -related.

Lets' say my UI consists of 3 JTextFields (firstname, lastname, salary) and a "create new customer" JButton.

How and into what do you bind those textfields and the button?
 
Gregg Bolinger
GenRocket Founder
Ranch Hand
Posts: 15302
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Your Bank object doesn't need to be "swing aware" but if you want to bind it it needs to be a true JavaBean which means property change support must be added to that class. It will have no effect on that class at all. But it does allow the object to fire change events when its properties change and allows the UI component to do the same.

You'd place the binding code in the same chunk of code where you declare and initialize your UI components. As an example, when you create a JTextField you would then bind that textfield to a property of Bank.

 
Gregg Bolinger
GenRocket Founder
Ranch Hand
Posts: 15302
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
BTW, swing binding it a pain in the ass. It's verbose and nearly always a hack because Java doesn't have true Property support. There are some libraries out there that try and remove the pain but nearly all of them stop short at some point. The best I've seen to date is binding support in the Griffon framework. The nice thing about Griffon even beyond binding is it structures your application into very logical points of interest. You might consider taking a look at it.

As an example assume the following domain object, the groovy way:



In a griffon view, you would define the text fields like so



model - this is the name of your Bank object in the view, because each view is associated, generally, to a single model object. Griffon automatically creates this for you in the view.

mutual:true - This tells the binding that you want it to be bidirectional. So if your model is updated, the UI gets updated and if the UI changes, the model is changed.

Pretty cool, huh?
 
Janne Mattila
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Gregg Bolinger wrote:Your Bank object doesn't need to be "swing aware" but if you want to bind it it needs to be a true JavaBean which means property change support must be added to that class. It will have no effect on that class at all. But it does allow the object to fire change events when its properties change and allows the UI component to do the same.

You'd place the binding code in the same chunk of code where you declare and initialize your UI components. As an example, when you create a JTextField you would then bind that textfield to a property of Bank.



I'm kinda asking in more general scale - do you bind directly to your domain objects, or do you have some sort of layer structure in between where you bind to? What's your application architecture like in that sense?
 
Janne Mattila
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Gregg Bolinger wrote:BTW, swing binding it a pain in the ass. It's verbose and nearly always a hack because Java doesn't have true Property support. There are some libraries out there that try and remove the pain but nearly all of them stop short at some point. The best I've seen to date is binding support in the Griffon framework. The nice thing about Griffon even beyond binding is it structures your application into very logical points of interest. You might consider taking a look at it.

As an example assume the following domain object, the groovy way:



In a griffon view, you would define the text fields like so



model - this is the name of your Bank object in the view, because each view is associated, generally, to a single model object. Griffon automatically creates this for you in the view.

mutual:true - This tells the binding that you want it to be bidirectional. So if your model is updated, the UI gets updated and if the UI changes, the model is changed.

Pretty cool, huh?


I'm using beansbinding at the moment and I've seen complaints about it many times. I'm not sure, what is the main problem with it?

I know it's annoying that you have to add the firePropertyChange code to your propertie's set -methods, but is there something else too wrong?
 
Gregg Bolinger
GenRocket Founder
Ranch Hand
Posts: 15302
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Janne Mattila wrote:
Gregg Bolinger wrote:Your Bank object doesn't need to be "swing aware" but if you want to bind it it needs to be a true JavaBean which means property change support must be added to that class. It will have no effect on that class at all. But it does allow the object to fire change events when its properties change and allows the UI component to do the same.

You'd place the binding code in the same chunk of code where you declare and initialize your UI components. As an example, when you create a JTextField you would then bind that textfield to a property of Bank.



I'm kinda asking in more general scale - do you bind directly to your domain objects, or do you have some sort of layer structure in between where you bind to? What's your application architecture like in that sense?


Personally, directly to domain objects.
 
Janne Mattila
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Gregg Bolinger wrote:
Janne Mattila wrote:
Gregg Bolinger wrote:Your Bank object doesn't need to be "swing aware" but if you want to bind it it needs to be a true JavaBean which means property change support must be added to that class. It will have no effect on that class at all. But it does allow the object to fire change events when its properties change and allows the UI component to do the same.

You'd place the binding code in the same chunk of code where you declare and initialize your UI components. As an example, when you create a JTextField you would then bind that textfield to a property of Bank.



I'm kinda asking in more general scale - do you bind directly to your domain objects, or do you have some sort of layer structure in between where you bind to? What's your application architecture like in that sense?


Personally, directly to domain objects.


How do you manage the EDT issue with the binding? As in, you bind a Swing UI component C1 into domain object property P1. Now, something changes P1. This change originates from outside of EDT - for example a result of a long running task. This is going to be reflectled in C1 because it's bound to P1 with beansbinding. But, if you just have



the firePropertyChange will end up changing C1 - outside of EDT! Isn't this a major problem?

I have discussed this issue at http://thread.gmane.org/gmane.comp.java.netbeans.user/140505 starting at post 29 Jun 10:50

 
Rob Spoor
Sheriff
Pie
Posts: 20494
54
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can distinguish non-EDT events and EDT events:
Also, it is perfectly safe to call EventQueue.invokeLater in the EDT. EventQueue.invokeAndWait will throw an exception though.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic