From Eclipsepedia

[edit] Why JFace Data Binding? (code name: Krispy Kreme)

Developing line of business applications as Eclipse Rich Client Platform applications presents a number of unique challenges.

• How does one validate data entry when the number of possible interactions between validation rules rises proportional to the square of the number of data entry fields on an input form?

• How does one avoid coding repetitive, dull, tedious, and error-prone SWT event handlers?

• How can one improve reuse of data-driven user interfaces?

All of these concerns are improved using JFace Data Binding.

[edit] How does this work?

Traditionally, database-driven line of business applications are organized into tiers:

• a database tier
• a business or domain model tier
• a presentation tier

The communication paths between these tiers are organized along the routes that data flows within and among these tiers.

Recently, Hibernate, EJB3, and Rails technologies have emergedas a means of automating the data flow between the business tier andthe database tier.

By analogy, just as Hibernate helps automate the data flowbetween the business tier and the database tier, JFace Data Bindinghelps automate the data flow betweeen the business tier and thepresentation tier. It does this via a simple update to themodel-view-controller pattern that enables us to create a set ofcompletely generic and reusable controllers between the business modelobjects and the view (or presentation) tier.

[edit] JFace Data Binding from 4000 meters

Traditional object-oriented architectures use themodel-view-controller pattern to persist changes in a user interface toa model. This architecture can be visualized as follows:

This works the following way:

• The view observes (listens to) the model for changes and redraws itself when it detects a change.
• The controller observes (listens to) the view for change events.
• When the controller detects an event that needs to cause a change, it is responsible for mutating the model, which implicitly refeshes the view because the view is listening to the model for changes.

There are a few problems with this pattern:

• The view has to understand the model.
• The controller has to understand both the view and the model.

Data binding is a recognition that most of the time, Text widgetsare bound to single properties of objects, a radio group has ajava.util.List or a java.util.Set of choices and its selection is boundto a single property of an object, and so on. Since we know that thedata type in the business model tier has to match the data type in theGUI widget, we can build a generic mapping layer between POJOs and GUIssimilar to the way Hibernate is a generic mapping layer between POJOsand databases.

In general, the architecture then looks like:

The implementation is simple. The generic controller representsdata binding. It listens to changes on both the model and on the GUIview. When a change in a property occurs in the model, it isautomatically copied to the GUI. Similarly, when the user changes avalue in the GUI, the change is automatically copied back to the model.

To make this concrete, let‘s look at an example:

Suppose the model object is an Integer property of an Employeeobject called "numberOfYearsWithFirm". This property is to be bound toan SWT Text control. Then:

• The data type of the model object is "int".
• The data type of the UI is "String" (the data type of the text property of the Text).

The controller simply listens to the model for changes in the"numberOfYearsWithFirm" property. Similarly, it listens to the SWT Textobject for changes the user makes in the UI.

If the user changes the UI or the underlying model objectchanges, that change is copied to the other side, automaticallyapplying any validation and/or data type conversion rules that arenecessary to make the whole thing work.

For example, if the user changes the SWT Text object, the newString value is validated that it can be converted to an "int", thevalue is then converted to an "int", and the new integer value is thenset in the model object.