Thoughts on Data Binding and Swing

by Robert Cooper

This isn't much of anything, really. More the beginings of ideas, but I was chatting with Josh Marinacci earlier about databinding in Swing, and frankly, how completely unimpressed I am by what I have seen of JSR-295. Honestly, I implemented all of the functionality I have seen there in about a week on my own. Having a whole spec that does, frankly, that little work for me doesn't get me all hot and bothered.

I made some notes about what I consider -- off the top of my head -- the ultimate Swing binding framework. I don't pretend that all the issues have been worked out, but I think it is a good starting place to think about it.

More after the bump.


2006-11-23 01:20:52
You're right that one can implement a basic Presentation Model binding framework in a coupla days (or nights). I disagree that there's no value in such a thing being standardised though.
2006-11-24 05:55:24
Certainly a binding framework can be written in a day or two.
But we all have taken different approaches in some aspects of the interfaces and implementations; having a standard approach is a good thing.
Michael Nascimento Santos
2006-11-27 21:13:37
genesis implements Swing binding using a concept similar to what you described, except its is more generic and there are implementations for Thinlet and SWT.
2006-11-27 23:53:39
Interesting. Genesis looks interesting, but at first glance it has a few things which kind of irk me:

Looking at the short example:

1. The "binding" is one way, perhaps only the call to new SwingBinder(this, new LoginForm()). I would expect a binding framework to allow for propertyChangeEvents.

If you had:

LoginForm login = new LoginForm();
SwingBinder binder = new SwingBinder(this, login);

login.setUsername( "FOO" );

I expect nothing would happen.

2. It requires that the "Model" be altered.
public class LoginForm ...
or it looks like optionally, and perhaps better:
* @Form
public class LoginForm

Still, that means I have to edit the form level code, which is something I would want to explicitly never have to do. Model code is often (usually in my experience) something that is generated (via xjc/something-web-service-ish or from an ERD), and frequently shared across projects.

3. While I assume @Action methods can be separated out into something with a cleaner MVC type separation of concerns by doing something like:

UserBean user = new UserBean();
SwingBinder binder = new SwingBinder(this, user);

LoginProcessBean login = new LoginProcessBean(user);
// @Actions declared here
binder = new SwingBinder(this, login);

It seems a big... basic. In terms of invoking controller/logic operations, I would really rather use something better anyway (read: GUICommands).

Genesis has some interesting ideas in terms of Gui development, but I expect that actually using it, you end up doing things the way a lot of Struts developers do: creating "Form Beans" then mapping those back to the "Real" model, instead of just using the "Real" model from the beginning.

2007-02-26 09:43:52
I cannot understand why relatively so little interest has been given to data binding in Java Swing applications. I have been looking around on the Internet to find a decent data binding library (preferably free) and could only find JGoodies (not free). I mean this kind of functionality has been around for years in Microsoft development tools and they do increase programmer productivity. Am I missing something?
Michael Nascimento Santos
2007-02-27 06:40:39
Hi Robert,

Sorry for taking so long to reply.

1-) genesis has been conceived to avoid coding PropertyChangeListeners and all this stuff. We intended to make the framework as easy for developers as possible.

If you modify a bean in response to any view event, all changes will be detected by genesis. In our experience, it is very rare to change a bean property outside of this context, so we were not concerned about it. It is possible to update the view in these rare situations by using ActionInvoker.refresh(form), but for genesis 3.1 we intend to support it as described in issue 385.

2-)@Form is no longer needed since 3.0-EA5. However, the form class usually is a subclass of a model class, as there is usually a lot of presentation logic that belongs to the view tier.

3-)If you want to decouple actions from the model, you are going against a core principle in genesis: object-orientation. We believe data and operations belong together, as a rich domain model.

I really value your feedback, so if you can come up with a few use cases for which genesis would not be appropriate, please let me know.

Vinicius Carvalho
2007-03-05 12:16:56
Few years ago I've worked on a SWT project, and binding was the real pain of the project (excuse me for the comparison, but much like strusts forms -> model binding).
Few weeks ago I was wondering how to provide a better way, I'm starting a new pilot for it. Based on AOP + Annotations. The concept is very similar to what you've said on the post (isn't amazing how convergence works? Ppl all around the world having similar ideas for same problems).
My idea is to annotate the class, plus the properties (JTextField, Radio, CheckBox). Through AOP I would bind those values after an event is fired (must be registred as well) I'm defining transformers for the types (Component-> Double, Enum etc). Also, a RefreshPolicy Annotation to define how should the framework deal with the bound entity (discard on trigger, cache for latter use) and a Transaction annotation to deal with concurrency (optimist locking for instance). I really would love to integrate with Hibernate Validator Framework as well.
I just start coding, having plenty of ideas though.
Michael Nascimento Santos
2007-03-05 18:13:56

Hi Vinícius,

genesis works on a UI-toolkit independent way, so its programming model is quit similar for SWT as well.