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).
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.
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).
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 SceneGraph
s 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 SideEffect
s 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.
will probably be the basis for any truly DeclarativeGui
itself is declarative in nature). WindowsPresentationFoundation
supports a bit of DataBinding
is essentially RestArchitecturalStyle