User Tools

Site Tools


blog:on_collecting_ideas_for_a_simplified_data_binding_api

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
blog:on_collecting_ideas_for_a_simplified_data_binding_api [2012/05/18 17:11]
127.0.0.1 external edit
blog:on_collecting_ideas_for_a_simplified_data_binding_api [2014/10/17 22:08] (current)
Line 1: Line 1:
 +====== On collecting ideas for a simplified data binding API ======
 +
 +In my previous entry, I referred to [[http://​toedter.com/​blog/?​p=36|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.
 +
 +  - 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.
 +  - Given the previous, I prefer to keep the existing API and view it like an assembly language for bindings.  ​
 +  - 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?​
 +
 +===== Have two sets of UI widgets: unbound and bound widgets =====
 +
 +The bindable widgets themselves have the intelligence needed to bind them.
 +
 +I dislike this approach for several reasons.
 +
 +  - 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.
 +  - 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.
 +  - 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.
 +
 +===== Layer an external DSL on top of data binding =====
 +
 +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:
 +
 +<code java>
 +String someOutput = "​Hello,​ my name is ${person.firstName} ${person.lastName}";​
 +</​code>​
 +
 +Or (from [[https://​bugs.eclipse.org/​bugs/​show_bug.cgi?​id=195222|bug 195222]]):
 +
 +<code java>
 +BeanObservables.observeValue(person,"​parents[@mother=true]/​person/​name"​);​
 +</​code>​
 +
 +My personal thought here is that:
 +
 +  - This would be really nice
 +  - It would be hard to code correctly
 +  - 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.
 +
 +===== Implement an internal DSL to simplify binding =====
 +
 +Using the Builder pattern, one could easily imagine something like:
 +
 +<code java>
 +IValueProperty objectAddressStreet = BeanPropertyBuilder.value("​address"​).value("​street"​).build();​
 +</​code>​
 +
 +More thoughts along these lines are in [[https://​bugs.eclipse.org/​bugs/​show_bug.cgi?​id=195222|bug 195222]] and [[https://​bugs.eclipse.org/​bugs/​show_bug.cgi?​id=194734|bug 194734]]
 +
 +===== Open questions =====
 +
 +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:
 +
 +<code java>
 +dbc.bind(SWTObservables.observeText(txtFirstName,​ SWT.FocusOut),​
 +     ​BeansObservables.observeProperty(person,​ "​firstName"​),​ null, null);
 +</​code>​
 +
 +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.
 +
 +===== Your thoughts? =====
 +
 +Please comment.
 +
 +
 +20081226: Edit: Fixed link to Kai's blog entry
 +
 +~~LINKBACK~~
 +~~DISCUSSION:​closed~~
 +
  
blog/on_collecting_ideas_for_a_simplified_data_binding_api.txt ยท Last modified: 2014/10/17 22:08 (external edit)