aspose file tools*
The moose likes Swing / AWT / SWT and the fly likes Using JSR-295 beansbinding, where do you bind to? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Swing / AWT / SWT
Bookmark "Using JSR-295 beansbinding, where do you bind to?" Watch "Using JSR-295 beansbinding, where do you bind to?" New topic
Author

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

Janne Mattila
Ranch Hand

Joined: Jan 10, 2005
Posts: 32
(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

Joined: Jul 11, 2001
Posts: 15299
    
    6

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.


GenRocket - Experts at Building Test Data
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

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

Joined: Jan 10, 2005
Posts: 32
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

Joined: Jan 10, 2005
Posts: 32
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

Joined: Jul 11, 2001
Posts: 15299
    
    6

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

Joined: Jan 10, 2005
Posts: 32
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

Joined: Oct 27, 2005
Posts: 19761
    
  20

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.


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Using JSR-295 beansbinding, where do you bind to?