Note : This is not by any means an exhaustive guide to Data Binding HTML elements, nor a control reference for the TDC control, or RDS. Some information on data binding is available in the Internet Client SDK, and some feature articles at the Sitebuilder Network describe Data Binding in greater detail. Data Binding is only currently supported by Internet Explorer 4.0.
Data binding represents a relatively simple way to display data in web pages without having to write extensive server side procedures. Basically, you insert a standard <OBJECT> element, which inserts a Data Source object. Then, HTML elements that support Data Binding can use the data referenced by the Data Source object in the HTML document.
Data Sources
Internet Explorer 4.0 supports 2 types of data sources. RDS (Remote Data Service - formerly known as ADC) and TDC (the Tabular Data Control).
Generally speaking, the RDS Data Binding component would be used if you wish to publish data from ODBC, SQL, Access, Oracle etc, databases, or you wish for users to be able to interact with the data from the database (i.e. add, or update records for example). The somewhat simpler to use TDC Data Binding component can be used if you have simple data to display. For example, if you just want to publish some data that's been extracted from a data source as a standard text file. Using the TDC Data Binding component doesn't allow any udpate/creation interaction with the data, although the user can sort, filter and manipulate the data in any way you allow through scripting in the document.
Displaying Data
Once you've decided on a Data Source object and what data is going to be presented to the user, you need to decide how that data is presented to the user. There's three basic options:
<FORM> fields, allowing the user to change the data), with scripted navigation buttons, allowing the user to navigate forwards and backwards through the recordset.
Binding HTML elements
Once the data source and presentation method are decided, the elements that are going to be used for the presentation of the data need to be bound to the Data Source. Below are the Data Binding HTML attribute extensions, supported by elements that support Data Binding.
DATAFLD
The DATAFLD attribute is used to set which column in the data referenced by the data source the element is going to use as the contents of its display. See the examples for an example
DATAFORMATAS
The DATAFORMATAS attribute accepts either text or HTML as its values and specifies whether the data being taken from the data source should be displayed literally DATAFORMATAS="text" or parsed before being displayed DATAFORMATAS="HTML". If the data source column being used contains HTML formatting, then DATAFORMATAS="HTML" should be explicitly used. DATAFORMATAS defaults to text if not specified, and any HTML from the data source would be treated as plain text.
DATAPAGESIZE
For repeated Data bound tables, the DATAPAGESIZE attribute specifies how many records should be displayed by the table at any one time. The table will then be repeated to display that number of records only. If this doesn't cover the entire contents of the data source data, then navigational buttons will need to be used to allow the user to retrieve the next 'block' of records. Using data bound tables in this way can greatly increase the perceived speed of your site, as the rendering time for smaller tables is less.
DATASRC
The DATASRC attribute is the most important Data Binding attribute, as it defines for the element, which Data Source object it is to use, to retrieve the data from. Once a Data Source object has been included in the document (with the <OBJECT> element), the DATASRC attribute should be set to #ID, where ID reflects the ID attribute of the <OBJECT> element used to insert the Data Source object.
Note that the DATASRC attribute can be inherited. In the case of repeated tables, if the DATASRC attribute specifies a valid data source in the main <TABLE>, then subsequent DATAFLD attributes in elements contained within the table need only specify a DATAFLD attribute - the data source referenced will be resolved by looking to the parent <TABLE> element for a valid DATASRC attribute.
Data Binding Scripting
When elements are data bound, they support a number of properties and events. The dataFld, dataFormatAs, dataPageSize and dataSrc properties are all read-only and directly reflect the DATAFLD, DATAFORMATAS, DATAPAGESIZE and DATASRC attribute settings for the elements. For the HTML elements that support in-place editing/Data Binding (e.g. <INPUT>, <SELECT>, <TEXTAREA> etc.) and certain other Data Consumers support the following events (when used with RDS Data Binding, which is allowing user updates to the data source). (Note : Review the element topic to see what (if any) of the following topics it supports. Also, these are events that are supported on the element object, not the data source object. For such information, consult the ADO/TDC/RDS documentation in the Internet Client SDK).
onafterupdate
The onafterupdate event is fired after data is transferred from the element to the data provider and will only fire after the onbeforeupdate event has fired and was successful.
onbeforeupdate
onbeforeupdate fires when a data bound element loses the focus, or the current document is unloaded and will only fire if the value of the element is different to the original value that was present when the element received the users focus. Note that onbeforeupdate is a cancelable event (setting returnValue=false for the Event object), which allows the document /script author a chance to validate the new data entered by the user on the client-side, before sending the data to the data provider.
onerrorupdate
The onerrorupdate event fires when a data transfer error occurs, through some action by the user (i.e. pressing the 'Stop' button on the browser for example), but not if a script generates the transfer error.
onrowenter
The onrowenter event fires on the data source control when the current record has been changed, so new data is available to populate the HTML display elements that are bound to the data source. Somewhat confusingly, this will typically happen after the onrowexit event has been fired.
onrowexit
The onrowexit event is fired immediately before the data source changes the current record (i.e. when the user has requested another record, or set of records by pressing a button perhaps). Note that unlike the onafterupdate and onbeforeupdate events, onrowexit is fired by the data source, not any of the HTML elements used to display the data. Changes to the data in the HTML elements should have been transferred to the data source (with validation being taken care of in the on*update events). onrowexit will also fire if the record position is changed through scripting.
onbeforeunload
The onbeforeunload event fires on the document (via the Window Object), firing before any onunload events, in order to give the author a chance to do any necessary data updates, before the page is unloaded. For example, the user makes some data edits, but before moving to another record (and having the changes committed to the data source through the on*update events), they close down the browser, or navigate to a different site. Any unsaved data changes should be taken care of in the onbeforeunload event. For security reasons, the onbeforeunload event is not cancelable, but a string value can be returned from the event, which is used as a prompt to the user.
Data Source Object events
Only the <OBJECT> and <APPLET> elements can insert Data source objects into a document. For these elements, the following properties and events have been introduced with data binding.
recordset
The recordset property returns a reference to the ADO recordset supplied by the Data Source object. For more information, see the ADO reference in the Internet Client SDK.
ondatasetchanged
The ondatasetchanged event is fired when a new set of data is available and a recordset can be retrieved from that set of data, or when an existing set of data has been changed - for example after a filter has been applied to the data.
ondataavailable
The ondataavailable event being fired indicates that more records for the referenced Data Source Object are available. It doesn't necessarily fire for every single additional record though.
ondatasetcomplete
When all the data in the referenced recordset is available, the ondatdasetcomplete event fires. For the ondatasetcomplete event, a reason parameter is available through the Event Object, which can have values of 0, 1 or 2, corresponding to successful completion, Aborted completion (i.e. 'Stop' button pressed for example), or Error (some other error) respectively.
<TABLE> Paging
For most small data sets, using the standard <TABLE> template method of table repetition will be OK, but for larger datasets, to prevent swamping the user with data, the DATAPAGESIZE attribute in the <TABLE> can be used to specify that only a certain number of records are retrieved and displayed at any one time. The table still repeats, as normal, but only by the number of times specified in the DATAPAGESIZE attribute.
When such a table is used, the previousPage() and nextPage() methods can be used (typically attached to buttons in the document) to refresh the table with the next, or previous DATAPAGESIZE records from the data set. Whenever the amount of records to display is less than the value of the DATAPAGESIZE attribute, then the table will simply repeat its content until all the records are displayed and then close - i.e. 'shrinking' to fit the amount of data shown.
Data Binding examples
Presented here is a brief and simple data binding example, with the necessary code explained. Firstly, the code will be examined, then the table example will be shown. For the purposes of this example, a portion of the HTMLib Comparison table will be used to provide the data.
Inserting the TDC control
The TDC control that ships with Internet Explorer 4.0 is just like any other ActiveX control and is inserted into a document with the <OBJECT> element, as below:
<OBJECT id=comp CLASSID="clsid:333C7BC4-460F-11D0-BC04-0080C7055A83">
<PARAM NAME="DataURL" VALUE="compdata.txt">
<PARAM NAME="UseHeader" VALUE="True">
</OBJECT>
Notice the ID attribute that's been used - that's what is used to bind the <TABLE> to the Data Source.
Creating the <TABLE> template
Next, the <TABLE> template needs to be set up. The data file that we're using compdata.txt is a comma delimited file.
As you can see, in the data file there is references to images and some text that needs to be formatted as HTML. The main <TABLE> element used in the template is:
<TABLE datasrc="#comp" BORDER DATAPAGESIZE="10" ID="TABLE1">
The DATASRC attribute references the TDC control inserted into the document earlier and the DATAPAGESIZE attribute is set to 10, which means that only 10 records from the data set will be displayed at any one time. The main part of the table that is repeated for each record is:
<TBODY>
<TR>
<TD><DIV DATAFLD="Element" DATAFORMATAS="html"></DIV></TD>
<TD><IMG DATAFLD="IEx" WIDTH="11" HEIGHT="11" ALT="Y"></TD>
<TD><IMG DATAFLD="Netscape" WIDTH="11" HEIGHT="11" ALT="Y"></TD>
<TD><IMG DATAFLD="Mosaic" WIDTH="11" HEIGHT="11" ALT="Y"></TD>
<TD><DIV DATAFLD="Spec" DATAFORMATAS="text"></DIV></TD>
</TR>
</TBODY>
The DATAFLD attribute for each element specifies the column name that it uses from the data file (see above), with the DATAFORMATAS attribute specifying whether the two text fields are formatted as HTML, or text. Note that for the <IMG> element, the data taken from the data source is used for the SRC attribute of the element, so extra attributes, such as WIDTH and HEIGHT etc., still need to be specified. The <TBODY> element is used to separate what is actually repeated for each record. Only table rows/cells between the <TBODY> and </TBODY> elements are repeated.
What's next?
That's about as much as it takes to set up a data bound repeating table. The only HTML that's not been included in the sample code given above is additional stylings and the table header and footer. All that's left is a pair of navigational buttons. Remember, only 10 records are being displayed at any one time, so there must be a way for the user to navigate through the records. Any standard button will do, the script function it runs just needs to be:
TABLE1.nextPage()
or
TABLE1.previousPage()
Depending on whether it's navigating forwards or backwards through the recordset.