Data Binding in Dynamic HTML

Accessing data on the Internet using current technology is slow. Pages are slow to render because they are being built by server processes. The processes building these pages are slowing down your server because your server is generating HTML rather than transmitting files. Since, on the client, the data in a page is indistinguishable from the page that contains it, additional requests are made to the server to manipulate the data.
Data binding is a new feature of Microsoft® Internet Explorer 4.0 (IE 4.0) that enables authors to create Web pages that are faster to render, more interactive, easier to author, and that require fewer server resources. It does this by using the Dynamic HTML support built into IE 4.0.

Dynamic HTML allows all the elements on a Web page to be manipulated through scripting languages. Data binding uses Dynamic HTML in conjunction with a simple declarative syntax to display data using standard HTML elements without resorting to complex scripting. Instead of the traditional method of merging the data with the HTML through server-side templates or CGI scripts before it’s sent to the browser, data binding performs this operation on the client after a page is received.

ata binding differs from traditional data publishing methodologies in that it uses standard HTML as a template for the data and merges the data with the template asynchronously as the data is transmitted to the client—like rendering a GIF—rather than building the entire page on the server. This results in a page that displays data incrementally as it’s transmitted to the client for faster initial response time. It also allows authors to create pages that build client/server applications using HTML elements without creating server-side CGI scripts to process the forms. With data binding, users can manipulate the data on the client without a round-trip to the server and without losing the context of the current page, giving the user a more interactive experience.

A Common Scenario for Data Binding

If you’re like me, an example is worth 30 pages of a manual. Consider a fairly common scenario: a brokerage firm that provides access to customers’ portfolios through the Web. The customer will want to see a list of the stocks in his portfolio and be able to sort that list by stock symbol, total asset value, number of shares, and so on. The customer may also want to limit the list of stocks viewed to those purchased in a single calendar year.
Before data binding, the author of the Web pages would have had to use CGI scripts or a template processor to construct three pages: one to display a list of stocks in the user’s portfolio, another to show the list sorted by symbol, and a third to display the list sorted by asset value. Moreover, to display the list of stocks for a single year, a fourth page would have to be created with an HTML form on it. The user then enters a year using this form and submit it to a server process (CGI or similar) which would then construct a page containing a list of stocks for the year requested. To give the user the ability to sort this new single-year list, the server would have to maintain which year was being viewed so the data could be sorted appropriately. Anyway, you get the idea. Lots of pages, lots of round-trips to the server, and transmission of the same data multiple times over a 28.8 Kbps modem.

f only the brokerage firm had used data binding, they could have created a single page to provide the entire set of functionality described above. The list of stocks in the customer’s portfolio would display more quickly because the data would be asynchronously rendered as it was transmitted to the client. Once the data was received by the client, it could be sorted and filtered directly on the client, without a round-trip to the server. The user wouldn’t have to wait for the same data to be transmitted over and over again just to change the sort order on the page. Redisplay would be virtually instantaneous.

Building a Page with Data Binding

The best way to understand data binding is to build a page that uses it. I’ll do that in this article using the scenario I described in the previous section. Along the way, I’ll explain the components of the Dynamic HTML data binding architecture for those of you who like to look under the hood as well as drive the car. The best part is, you’ll be able to write this code and experiment on your own today. Data binding is available in the Platform Preview of IE 4.0 at http://www.microsoft.com/ie/ie40/. If you still haven’t started using it, you may want to download the code now so you can execute as you go.

Data Source Objects

To construct a data-bound page, the first steps are determining the source of the data, the data-manipulation capabilities to give the user, and whether or not the user should be able to update and save the data. These capabilities are provided by data source objects (DSOs).
When designing the data binding architecture for IE 4.0, the design team wanted to ensure that the method for specifying the data on a Web page was as open as possible. The result of this goal was to introduce DSOs for supplying data to the page.

SOs encapsulate four specific functions. First, they provide an open method for transporting data to the client. A DSO is free to use the protocol and transport of its choice to access the data. Similarly, the DSO determines the method for specifying the data it supplies. It can use SQL, URLs, or any other method it chooses to specify the data set.
Since the DSO is responsible for the transport and specification of the data, it must also be responsible for supporting any manipulations to the data. All sorting, filtering, transformation, and user update support is the responsibility of the DSO, not the server. Generally, DSOs expose data manipulations through methods or properties.
The fourth function of a DSO is to expose an object model for script access. DSOs are free to expose properties, methods, events, and script-accessible objects to provide access to and manipulation of the data they supply. Again, the DSO determines the programming model. No specific model is imposed upon it by the architecture.

You’re probably wondering how the DSO exposes the data it supplies to a Web page. This is one area where there is a strict requirement on the DSO: it must provide access to the data through the OLE-DB API. Implementing the OLE-DB API in a DSO is not complicated. DSOs are available written with Java, using JavaBeans, or as ActiveX controls written in Visual Basic® or Visual C++®. A Data Source Object Gallery will be available on the Microsoft Site Builder Web (http://www.microsoft.com/sitebuilder). Check there for DSOs to use as well as the source code for the DSOs. The details of building a DSO are beyond the scope of this article.

Source: Microsoft