I recently announced that I am developing Data Binding for TypeScript UI (to be included in version 1.0.2). This article will give some more detail about why this is a good idea and how I plan to implement Data Binding into TypeScript. Data Binding, for those who don’t know and for clarification, is a method of linking data in a source (typically a web server) to a UI control that the user sees. Data Binding involves a number of steps which can be thought of in this structure:
1. Data Access
Data Access is the process of requesting data from the data source or pushing data to the data source. In a web-based context, it has typically been a full page request or more recently AJAX requests. “HTML5” (to use the umbrella term) introduces Web Sockets – two-way streams from server to client – and these are proving particularly good for creating responsive apps. TypeScript UI will support two basic types of data accessor, two types of data and three data formats:
The data from data accessors gets passed to data adapters, which transform the code-readable data into human-readable data, or data which the UI control can understand.
2. Data Adaptation
Data Adaptation is the process of taking raw data from a data accessor and transforming it into human-readable data or data which a UI control can understand. Data Adapters also handle the reverse process. TypeScript UI Data Adapters will have two main functions: I2O and O2I – standing for Input to Output and Output to Input; the latter being the inverse process of the former. The main intention is for them to convert data from a data accessor to data that a UI control can understand. However, they could be used to adapt any form of data or variable arbitrarily; they will have no rigid link to the rest of the Data namespace i.e. Data Adapters will be usable as a standalone unit.
3. Data Binding
Data Binding is the magic of this whole chain. A Data Binding has two main components: the UI Control property and the Data Adapter/Accessor pair. The Data Binding links the inputs/outputs of the Data Adapter to the UI control property. When the server sends updated data, the binding will get the callback from the data accessor, process the data through the data adapter and subsequently update the UI control. Likewise, if the user changes the value of the control, the binding will send the new data to the server, via the Data Adapter/Data Accessor. That’s the simple understanding of what it is supposed to do; the implementation is rather more complex. TypeScript UI will actually implement a more flexible, powerful structure than just plain data binding. The reasoning behind the structure comes from the inclusion of Data Updaters, so I move onto that and come back to Data Binding implementation later.
4. Data Updaters
Data Update is the process of updating the UI control data from the data source or vice-versa. However, Data Update is handled mostly by the data binding, so what is a Data Updater? A Data Updater is code which organises periodic update of data (in whatever way the programmer decides). The primary aim is to allow, for example, periodic updates such as fetching new Tweets or messages from a data source. TypeScript UI will implement a simple Data Updater structure which contains an interval setting, the update method to call and three events:
- OnUpdateInvoke – Occurs when the update method is invoked.
- OnUpdateBegin – Occurs when the update of data actually begins.
- OnUpdateEnd – Occurs when the update of data ends.
TypeScript UI Structure / Implementation
The structure is currently as mentioned in the paragraphs above. So to finish off the explanation from section 3 then. TypeScript UI will implement a structure which includes Binding Groups and Binding Collections (a collection is a list of groups). Each UI Control will have an instance of a Binding Collection to which all Binding Groups will be added. A Binding Group will contain the list of one or more Data Bindings in the group and an associated Data Updater that will handle updating all the bindings in that group when requested (or scheduled). The Data Updater may be omitted if no updater is wanted. The reason for this slightly more bloated structure is that it allows multiple data bindings to be updated at the same time, by the same updater without needing to store multiple references to an instance of an updater or data binding. This simplifies managing where bindings are created, held and destroyed and also allows more powerful update systems to be developed. The current working version of the full structure is shown below (image from the documentation on CodePlex):
If you have any comments specifically about TypeScript UI Data Binding, please either create a discussion on CodePlex or fill in the comment form below. All (mature) comments are welcome!