Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Version History

« Previous Version 2 Next »

Soft binding versus hard binding

DomUI data binding uses a form of data binding we call "soft binding". When you bind some model property to a component it is the component which maintains (remembers) the binding. The actual binding of the data is triggered by two global events:

  • When a request enters the servers we move data from control to model
  • When all user logic has finished, and the response is to be rendered back we move data from model to control. This means the control will show the value from the model when rendered back in the browser.

Because the binding itself is maintained by the control bindings are only active while the control itself is attached to a page. If a control gets removed from a page it's bindings will not update. But as soon as a control is added to a page (again) binding will be updated.

The alternative to "soft binding" is "hard binding". In hard binding all property setters of classes are coded in such a way that they call listeners as soon as a setXxx() call changes the value of the property. Instrumenting all setters to do this properly adds yet more boilerplate to Java's already very verbose "properties" which is a disadvantage. In addition having setters propagate changes means that it is very hard to control when bindings execute. And finally, since objects might live quite a while it becomes important to be able to clean up listeners on properties, or the system leaks memory or CPU cycles.

Using soft binding prevents all this: the update mechanism is bound to the request/response cycle, and bindings are automatically removed as soon as components go out of scope.

How components register bindings

Binding error handling

Binding order

Components on the screen are ordered naturally, by their DOM location as created by the developer. But to handle binding properly it is important that binding is done in proper order. Let's give an example. We have a screen with two combo boxes:

The "Country" combo contains a few countries, the "City" combo contains cities in all of these countries - not just of the selected country.

The UI should act as follows:

  • When the country changes the City should be set to the 1st city of that country in the city list
  • When the city changes the country should be updated.

We bind these controls to two properties in our model, called "country" and "city".





  • No labels