On Collecting Ideas for a Simplified Data Binding API

In my previous entry, I referred to Kai's blog where various community members wished for a simpler data binding API and asked for comments.

This blog is intended to collect the various proposals I've seen for simplifying data binding into one place so we can discuss their relative merits.

First, I'll state my personal biases.

1. Although I find it a bit verbose, I still really like the existing data binding API. This is because every other API I've tried has imposed assumptions about what I wanted to do that eventually constrained me too much.
2. Given the previous, I prefer to keep the existing API and view it like an assembly language for bindings.
3. It's easy to imagine a convenience layer added on top of the existing code; this way if you need data binding's full power, you drop down to the lower level of abstraction.

Second, what are the various ways to raise the level of abstraction?

The bindable widgets themselves have the intelligence needed to bind them.

I dislike this approach for several reasons.

1. From a community point of view, this forces authors of SWT widgets to build two versions of every widget: a normal one and a bindable one.
2. The bindable widget nearly always makes assumptions about the sorts of things you might want to bind to it. For example, table controls in the Microsoft world at least used to assume that you were binding to a database cursor. Android (which also uses the bindable widget approach) solves this problem somewhat by letting you implement your own database cursor.
3. In the end, this doesn't feel like the optimum separation of concerns. When reading the API for a control, you have to keep in mind that APIs for dealing with the control itself are mixed with APIs for binding to it. The result is a less intentional API in the control itself.

This is the approach of things like Beans Binding, as well as several well-known scripting languages like Perl and Ruby.

Folks would like to write something like:

String someOutput = "Hello, my name is ${person.firstName} ${person.lastName}";

Or (from bug 195222):

BeanObservables.observeValue(person,"parents[@mother=true]/person/name");

My personal thought here is that:

1. This would be really nice
2. It would be hard to code correctly
3. Ideally, you would want IDE support extending Java's static type checking to that embedded string-based query language

Basically, I like it but it sounds like a lot of work.

Using the Builder pattern, one could easily imagine something like:

IValueProperty objectAddressStreet = BeanPropertyBuilder.value("address").value("street").build();

More thoughts along these lines are in bug 195222 and bug 194734

Someone on the E4 developer list (sorry, I'm too lazy to look up who said this) complained that data binding's problem is that it conflates data flow with the user's work flow.

In other words, it directly represents data flow in the observables and the binding:

dbc.bind(SWTObservables.observeText(txtFirstName, SWT.FocusOut),
     BeansObservables.observeProperty(person, "firstName"), null, null);

But if you need to alter the user's work flow, for example through validation, then this validation code becomes a cross-cutting concern across all of your bindings.

However, unless one uses something like AspectJ, this seems like essential complexity to me.

Somebody please prove me wrong.

From http://www.coconut-palm-software.com/the_new_visual_editor/doku.php?id=blog