Top ASP 101 Stories Migrating to ASP.NET Getting Scripts to Run on a Schedule The Top 10 ASP Links @ Microsoft.com QUICK TIP: Use the front door, please! Show All Tips >>  ASP 101 Updates

Once the data has been retrieved and cached locally, we can use it to populate HTML controls in a Web page (a process called data binding), or we can work with it directly using ADO code within the page. In fact, even when using data binding, we'll often still implement ADO code in the page. This is particularly the case when we want to update the data and submit the changes back to the server.

Data binding uses the Data Binding Agent object that is part of Internet Explorer 4 and higher. When programming in a language like Visual Basic or C++, the special controls that are part of that environment are used to implement data binding instead.

The Web-based Data Binding Agent can provide two types of data binding, either tabular data binding or single record data binding (often called current record data binding). All DSO controls can take part in tabular data binding or single/current record data binding. We'll briefly summarize the HTML controls that are used in Web pages next, then go on to look at the two types of data binding where they can be used.

So, as an example, we could bind a SPAN element to the value in a field named tTitle, which is in a recordset exposed by a DSO that has the ID of dsoBookList, using:

The value of the tTitle field in the current record in the recordset would then be displayed in the page within the SPAN element as plain text (the default). If the tTitle field contains HTML formatting within the value, we can cause the browser to render it as such using:

We can also use client-side script to set up or change the bindings once the page has loaded, by changing the dataSrc, dataFld and dataFormatAs properties of the appropriate elements. To remove the bindings, set the properties to an empty string. To change the binding of elements within a bound table, we must remove the binding of the table first (in the <TABLE> tag), change the bindings of the elements in the table, and then reset the binding of the table.

Tabular data binding depends on the ability of the <TABLE> element to repeat the contents of the <TBODY> section once for each record. It's important to recognize that the use of the word tabular - in the sense of the way the data is bound to controls - is entirely unconnected with the name of the Tabular Data Control.

The data source object is identified within the opening <TABLE> tag, and the column or field name for each bound control is identified within each table cell. Note that the <TD> element itself does not take part in the data binding process. Instead, a bound element is placed within each cell. This could be a <SPAN> or a <DIV> element, or one of the other HTML controls. For example:

ADO recordsets support paging, as we discovered in Chapter 5 when we looked at the Recordset object. When tabular data binding is used, the <TABLE> element is bound to the DSO that provides the source recordset, and displays the records in that recordset. The DSO properties are exposed through the bound <TABLE> element, and this includes the dataPageSize property. In IE4 and above, this property is mapped to the DATAPAGESIZE attribute of the table as well:

By setting this attribute in the opening HTML <TABLE> tag, we can create a table that displays only a specified number of records:

Then, we can move through the recordset by using the nextPage and previousPage methods. The bound table also exposes the recordNumber property of the underlying data set for each element within the table.

As soon as a recordset is created by a DSO, the first record becomes the current record, in exactly the same way as when we create a recordset using ADO directly (if the recordset is empty, the EOF and BOF properties are both True at this point). We can display the values from the current record in any of the bindable HTML elements listed earlier by setting their DATASRC and DATAFLD properties. For example:

This produces the page we first saw earlier in this chapter, and the screenshot is repeated here. The buttons at the bottom of the page allow users to move around the recordset, and they work by calling the appropriate move methods of the underlying recordset object-as described below.

To move to the next record, as shown in the previous screenshot, we can use a normal HTML BUTTON control to call the exposed methods of the DSO:

When a page containing a DSO is unloaded, or when the user edits the data in HTML controls that are bound to a DSO, various events are raised. Some can be cancelled by returning the value false from the event handler routine:

The onbeforeunload is raised by the window object, while the remainder are raised by the HTML controls on the page. With the exception of the onbeforeunload event, all events bubble up through the document hierarchy. So, we can display a message when the user changes the value in a control with:

The RDS Data Source Object itself raises events as various actions take place. Most are concerned with indicating the current state of the DSO as it loads the data. However, the first two are fired when the 'current record' changes as the user moves through the recordset. This could be by clicking on a tabular data-bound table, or when the code in a page that uses single-record data binding calls one of the recordset move methods:

Only the onrowexit event can be canceled by returning false from the event handler routine. All events bubble up through the document hierarchy. It's usual to take advantage of the ondatasetcomplete event for any script that you want to run once the data has arrived:

It's important to realize that each data source object is itself a DataControl object, and as such is an OLE-DB data provider. This has to be the case for ADO to be able to access the data exposed by the DSOs-remember that ADO is a way of communicating with an OLE-DB data provider (or an ODBC driver that exposes an OLE-DB interface).

The only difference here is that the data store is now a locally cached recordset, and so the DataControl object or DSO takes the place of the server-side OLE-DB data provider. In fact, ADO continues this terminology by referring to bound controls on a Web page as data consumers.

Each DSO exposes the cached recordset to code running on the client through its recordset property. We can create a reference to this and work with the contents of the recordset. So, once we've got the data into a client-side cached recordset, we can use it just like we would in ADO on the server. For example we can use it to populate a <SELECT> list by iterating through the recordset. Note that we do it in the ondatasetcomplete event handler, where we know that the data has arrived:

Here's the result, showing the list box contents after the ondatasetcomplete event has fired, and the values have been inserted into the list by creating new <OPTION> elements within it:

As another example of using the recordset directly, we can create output in the page using Dynamic HTML-here to place values from the records into a <H3> heading element previously defined in the page: