Introduction to Data Binding
Microsoft Internet Explorer 4.0 and later enables content providers to develop data-centric Web applications that support retrieval and update through native data binding facilities. The use of HTML extensions and pluggable data source objects (DSOs) makes data-driven pages easy to author, with minimal scripting required. Because data is downloaded to the client asynchronously, pages render quickly and provide immediate interactivity. Once downloaded, the data can be sorted and filtered without requiring additional trips to the server. Compare that to traditional Web pages and those generated by server-side scripts. Once the data reaches the client, it's static, and any manipulation of that data requires another server request.
Consider a simple example, such as the list of samples in the Internet Client software development kit (SDK). While the list could be hard-coded into this text, a better solution is to store the data external to the document, in a delimited text file. If the samples change, only the data in the database needs to be modified. Once the modifications are made, this page and any others that display that data will reflect the changes.
While this maintenance issue justifies the use of data binding in place of a static page, consider a slightly more complex scenario, such as an online classical music catalog maintained on a server in a relational database management system. Using today's server-side technologies, such as the Common Gateway Interface (CGI), the Internet Server Application Programming Interface (ISAPI), or one of its derivatives, such as Active Server Pages (ASP), a developer can write a script to extract a subset of data based on criteria specified by the client, such as all titles by a particular composer. The script might generate and return to the client a Web page that includes a tabular view of this data, including the title, the year composed, the type of composition, and a list of the movements in the composition.
While the page can contain the information in date order, to view the compositions in alphabetical order or to limit the view to orchestral works, or fugues, the user is forced to submit additional requests to the server. This is a memory-intensive way to view the same data in only a slightly different way. The problem is compounded if the Web author decides to present each composition in single record view, that is, one record per page. A full round-trip to the server is required to obtain each subsequent record.
If Web authors want to allow the user to add or update the data, they typically create HTML forms and submit GET and POST requests to an application running on the server. The server application parses the data from an HTTP data stream and then logs the data to a database. For every update request, the page containing the Submit button and the form data is reloaded. This is not a seamless experience for the user.
The following sections show how the various components in the data binding architecture offer solutions to these problems and make the most efficient use of the Web.