Data Binding

DataBinding is common to FunctionalReactiveProgramming, and describes the case where one value is automatically (implicitly) maintained as a function of another. For example, one might bind the height of a picture to be a function of its width, such that changes to height automatically change the width of the image without any explicit code (other than introduction of the binding).

DataBinding can potentially incorporate sources that are outside the language in which the binding is performed. In that case, some sort of PublishSubscribeModel or (if no other options) plain old polling can be used. This might be performed to support live mashups and TransClusion, track 'views' of a database in realtime, etc.

DataBinding is a useful design for describing documents in terms of 'real' data, but is antithetical to the DocumentObjectModel . In particular, the document 'description' should be produced as a function of one or more data-sources, and so does not require addressable elements that can be explicitly modified. DataBinding supports many forms of UI composition: inclusion, inheritance or extension, transformations (similar to XSLT or CSS). Linking can be added easily (though DataBinding doesn't provide any special support for it).

DataBinding is especially amenable to automatic caching, parallelization, and DataDeltaIsolation... i.e. one only needs to recompute a function when one of its arguments have changed, so maintaining a DataBinding can cut down on network traffic, and one can recompute and obtain data for many such functions simultaneously. Use of DataBinding to describe elements of SceneGraphs relative to a POV can help achieve RealTime displays that 'pop-in' higher LevelOfDetail? and access other data based strictly on requirements at the moment. DataBinding is also amenable to MultiCaster domain-based addressing of 'data', and for distributed multi-cast trees that cut down on network traffic (i.e. with a distributed network overlay, total traffic can be reduced by an exponential factor to O(log(N)) for N concurrent users of data). So DataBinding is very 'upwards' scalable.

Some languages support DataBinding via 'getters' that may transparently be functions rather than stored data. However, this is incomplete since it lacks support for the optimizations described above. Especially, the ability to introduce SideEffects as part of a 'getter' can be problematic. Even if you don't use the side-effects, the ability to do so makes verifying any automated optimizations a challenge - doubly so if there is any black-box modularity involved.

However, there are costs associated with fine-grained DataBinding: when dealing with low-level code, DataBinding tends to have a large overhead per unit of data. This space overhead includes descriptions of the functions and relationships between them, less-efficient data transport designs (such as use of a message queue) that avoid the problems of cycles but lose something in terms of locality, etc. These costs resist heavy use of DataBinding at the lower level, resulting in a 'layer' above which DataBinding influences a SceneGraph and below which the current data is explicitly transformed and mapped into view code.

DataBinding will probably be the basis for any truly DeclarativeGui (since DataBinding itself is declarative in nature). WindowsPresentationFoundation supports a bit of DataBinding.

DataBinding is essentially RestArchitecturalStyle + PublishSubscribeModel.