UI Databinding: alternatives and future

Question

UI Databinding aka transfer of information/data from the biz-layer/datamodel of an application to the UI and from the UI back to the datamodel, seams to be ignored a little by language and framework designers.

Almost all information processed by software systems today has to be presented at some point of the processing chain to human users, still the support we get from our programming systems to present info to users mostly consists of hard to maintain transfer methods, some systems using reflection with no compiletime verification ("propertychanged" anyone?), or propritiary code generators.

I mean Erik Meijer, Anders Hejlsberg and their teams f.e. have put huge efforts to solve the impedance mismatch between DBs, XMLs and the code... but left out UI mostly. (well yes .net has databinding, but try to use it and then let's talk about a real solution) The point is: what is the rational behind NOT treating databinding specially as first class feature of a language f.e? Why is there only so limited (or none) support for MVC/MVP patterns in our tools today?

Please provide comments, hints and pointers to alternative concepts available and maybe even work in progress in this field. Is there even any new creative and fresh ideas? Any helpful frameworks, language concepts supporting databinding, and maybe tools which help you to handle databinding in your apps or systems?

Answer 1

Databinding in Cocoa and Objective-C is very much alive and well. Part of that is because it's built on top of key value coding and key value observing, which are very solid and well thought out features in Cocoa. It's also well integrated in a lot of the new technologies Apple is developing, such as Core Data.

Answer 2

Other frameworks that support databinding are Adobe Flex and Microsoft's WPF.

Answer 3

The databinding and UI models in WPF are nothing short of amazing. You can bind to methods of objects, bind asynchronously, bind one-way (from source to target or vice versa) or 2-way directionally, and bind to other UI elements on the screen.

You can specify DataTemplates, which control how a particular type is displayed. You can define triggers, which allow the UI to change based upon changes in the bound objects (or elsewhere in the UI). In short, you should really look at WPF if you feel the state of UI/binding representation is lacking.

Here's a recent post which illustrates the power of WPF, where using basic constructs you can display a map with coordinates on it.

Answer 4

The WPF binding although good is too complex, it combines features of XPath with normal .Net binding and is super flexible, but very difficult to debug when it gets complex, and also very longwinded - how many IValueConverter's does one piece of code need?

The DependencyObject from WPF is brilliant though - a property that manages memory sensibly, has built in notification of changes - that's a good start for binding and properties in general.

Answer 5

In Python, you can use Enthought Traits for this. You define a model and that model already contains all the knowledge and logic so that you can create an editor for it with a single line of code.

Answer 6

I'm in the late stages of a porting project taking code generated by AppMaker from a C-based Macintosh GUI to WPF.

AppMaker's code generation style was well ahead of its time - 15 years ago it generated model-based code with data binding and a property-based approach. The disadvantage of the C code is that all the plumbing has been exposed.

This project has been fascinating - taking an architecture with a pure binding and command structure (albeit ugly code) across to WPF. I actually wrote a new AppMaker code generator to export the original object model to XML and have been working from that with Ruby to generate XAML, C# and C++/CLI since.

I'm very impressed with how well the data binding model in WPF works, although finding the sweet spot of what to put in XAML vs C# is interesting. As explained in a recent DevJam presentation, we decided on a three layer approach of

1. very lean XAML for styling,
2. C# for binding,
3. C++/CLI for ViewModel implementation.

I'm a binding fan from way back - my C++ OOFILE framework first used a binding approach to simplify database connections to forms in different GUI frameworks around 1997.

As a point of interest, I acquired AppMaker from the original USA-based owner, after a number of years collaboration where I wrote the Windows code generators. It seems almost unbelievable that a small company in Perth, Western Australia, with a complex AppMaker-generated GUI to port, should find the remaining AppMaker expert in the world lives about 30 miles away!

Answer 7

SWT / JFace, Eclipse's UI layer, has been extended recently with UI data binding capabilities. See http://wiki.eclipse.org/index.php/JFace%5FData%5FBinding