Internet Explorer allows us to use many common and custom-made Data
Source Objects (DSO) to bind data to controls and elements on a Web
application. My earlier article, about Tabular Data Control DSO and
how to use it to access legacy custom-formatted data explained how to
do basic data binding (see
http://15seconds.com/Issue/010116.htm). In this article we'll
move from legacy data to Extensible Markup Language (XML)-formatted
data, the type of format you'll come to see more and more. The object
of this article is twofold. The first is to demonstrate how to change
the data content of your Web application pages client side through
the use of DHTML events and dynamic data
binding with XML island DSOs. The second is to help you decide in
what format the XML should be saved.
Using XML island as a Data Source Object has a number of distinct
advantages. This DSO object is built into IE's XML island tag so
there is no need to script object tags with hard-to-read ClassID
Globally Unique Identifiers (GUIDs) (although you can specify its
ClassID in an object tag and use it that way). XML, as you may be
aware, is the harbinger of data standards on the Web. And since XML
has been vigorously accepted and persued by both Oracle and
Microsoft, it'll be here for a long time, meaning your Web apps will
require less maintenance and have a long life.
XML data island can be a disadvantage because they are read only.
Since the XML is simply a text file on the server or a section of
code on the client side, you could imagine the problems in trying to
maintain concurrency and connection. If you need to update the data
source, use the Remote Data Service (RDS).
IE's implementation of the DHTML event model gives us the power to
instantly, and with little code, change what data an element is bound
to. All of this is done client side, which has the added benefit of
leaving the server unburdened by repeated database-access requests
just to change the look and feel of the Web page.
Creating an XML Data Island DSO
As a refresher, remember an XML data island is simply a small piece
of XML code on the Web page that is available to the client directly.
Its data source (datasrc) can be
connected to an external source or actually written to the page
itself. XML data islands are only available in IE 5 and above.
This is an example of a data island that has its data written
directly to the page.
The <XML> tag is interpreted by IE as an HTML tag and is
converted to a DSO. It is then ready to be associated with a Datasrc parameter of a data-bindable element
on the Web page (<tagname DATASRC="#xmlEmployees">). It's
important to note that the XML syntax rules apply to the data in the
XML island. The elements are case sensitive and all elements require
closing tags.
Another way to get the data is to refer to the data externally.
It's much easier to read the script this way, and is less work on the
server because the Active Serve Page (ASP) server-side code doesn't
have to generate the XML and write it to the page for each request.
The Datasrc is simply pointed to an
outside XML file and it's downloaded automatically. Having the server
send a small text file is less expensive than having it create it and
write it to the Web page for client-side use.
Hiding XML Islands for Down Level Browsers
The fundamental rule in tag usage by browsers is that if the tag is
not recognized, it is ignored. However, with a XML island, although
all the tags would be ignored, the data they surround would not be
ignored. If a Netscape user visited this page, they would see the
data inside the XML island displayed.
To get around this, we can use IE 5's new Conditional Comments. (See
the Links section of this article for information on the various
usage rules.) Basically Conditional Comments wrap the entire XML
island in anHTML comment tag that other browsers will ignore. It's
similar in concept to frame pages where browsers that couldn't
support frames were shown a warning.
<!--[if IE 5]>
<XML id="xmlEmployees">
...some xml...
</XML>
<![endif]-->
<![if ! IE 5]>
SORRY: This web page requires IE 5 or higher
<![endif]>
Getting the XML for the XML Island
We're almost ready to connect the XML to our controls on the Web
page, but there remains one simple question. How are XML islands
created? Using ASP and ActiveX Data Object (ADO) you can create the
code to write the XML to the client side or to a separate file in a
format similar to the above example. The other option is to use the
Save method of the ADO Recordset object. This method, although easier
to write, makes it much more difficult to bind data. Because of this
we'll assume that the XML is written using a format similar to the
above example. At the end of this article I'll explain how to access
the XML written by the ADO Recordset's Save method and how to use it
with bound controls.
In script, your code for writing XML to the client could look like
this. This example assumes an active connection to a database and an
open recordset. It is simple ASP script hat runs server side.
Once we have an XML island (which becomes a XML DSO when it's bound
to an element) in a simple format, binding it to a control is quite
straightforward. Specify the Datasrc
parameter of the bound element to the ID of the XML island and the
DataFld parameter of the bound element
to the field you wish, and IE will handle the rest for you. This
example uses the Employee XML outlined in the beginning of the
article. The data is in a file on the Web server called employees.xml and is created nightly because
it's a relatively static data set.
<XML id="dsoEmployee" src="employees.xml"></XML>
<span DATASRC="#dsoEmployee" DATAFLD="name"></span> is
<span DATASRC="#dsoEmployee" DATAFLD="age"></span>
The Span tag connects to the XML DSO called dsoEmployees. The # mark
is needed in the Datasrc parameter. The
field whose data is to be shown is indicated by the Datafld parameter. This will display the first
name and age of the first record in the XML island, i.e. "Ian Vink is
30."
To move through the recordset, which the XML DSO provides, use this
script. For the sake of simplicity there is no error checking to see
if the Beginning of File (BOF) or End of File (EOF) has been reached.
When the Button element is clicked, the XML DSO's corresponding
recordsetpositioning method is called and the bound controls are
updated with the new record automatically.
Now that we have a basic understanding of the way an XML island is
used, created, and manipulated, we move to how to use this to create
a dynamic drop- down and link that to a table of data. When the user
clicks this drop down the contents of the table will change
dynamically. The data itself is very simple, a list of countries and
their provinces or states. In this case, Canada and the United States
are the only two countries.
This is a screenshot of the table in Microsoft Access. It was
exported to an XML file in a simple format and is called
countries.xml. Its source can be seen in the following section.
Creating a Drop-down Control to Select Data
The first task is to create a drop down dynamically from the Country
table. The data is saved in the above-mentioned XML file,
countries.xml, on the Web server. The "state" data is in a separate
file called "state.xml" and the province data is in "province.xml."
Normally the state and province data would be in the same file, but
to demonstrate dynamic data-source assignments, they have been
separated.
The following code will connect an XML data island to this data
source, "countries.xml," and then iterate though the recordset the
XML DSO exposes to populate the drop down. I do this by creating
OPTION HTML elements and then adding them to the drop down with the
ADD method.
It is important that you wait for the XML DSO to complete its
download of the data before you iterate though its recordset,
otherwise you'll get errors. Simply placing the script for the
recordset iteration in the ondatasetcomplete event will do this for
you.
<HTML>
<SCRIPT for="dsoCountry" event="ondatasetcomplete"
LANGUAGE="vbscript">
dim oRS, oOption
set oRS = dsoCountry.Recordset
do until oRS.eof
set oOption = document.createElement("OPTION")
oOption.text = oRS("CountryCode")
oOption.value = oRS("CountryName")
cboCountry.add oOption
oRS.movenext
loop
set oRS=nothing
set oOption=nothing
</SCRIPT>
<BODY>
<XML id="dsoCountry" src="countries.xml"></XML>
<select ID=cboCountry name=cboCountry></select>
</BODY>
</HTML>
With this, a drop down appears with the elements "USA" and "Canada,"
and their associated CountryCodes, "1" and "2," embedded.
It looks like this:
The next step is to write code to respond to the OnChange event of
the drop down and populate a table with the data -- state or province
-- of the country chosen. For this we'll need another XML island DSO
and a HTML table bound to this DSO. We then check to see what was
chosen and change the XML island DSO's source (SRC) parameter to the
corresponding XML source. The DSO defaults to no data. Add this code
to the bottom of the previous code example.
<SCRIPT ID=clientEventHandlersVBS LANGUAGE=vbscript>
Sub cboCountry_onchange
select case cboCountry.value
case "1"
dsoStateProvince.src="state.xml"
case "2"
dsoStateProvince.src="province.xml"
end select
End Sub
</SCRIPT>
<XML id="dsoStateProvince" src=""></XML>
<table id="tblStateProvince" datasrc="#dsoStateProvince" border=1>
<TR>
<TD><span
datafld="StateProvince"><span></TD>
</TR>
</table>
In the OnChange event of the drop down, its value is used to select
if the user choose the USA or Canada. Here are two screenshots of the
different selections, each showing how the table is different for
each selection.
Example 1: User choose USA
Example 2: User choose Canada
That's all there is to connecting XML to data-bound controls and
having those controls alter the data source of the XML DSOs they are
bound to.
Saving Data Using the Save Method of the ADO Recordset Object
This section focuses on a different way to save XML data and how to
use it. Because the format of the XML saved by the ADO Recordset is
quite different from that of simple, native XML, you need to decide
what kind of persistence (or saving) method you are going to choose.
Here's the fundamental decision to make. You have to decide between
the following:
to save the data quickly and easily using the ADO Recordset's
Save method, but then have to create more complex Web pages in order
to access the data in this format, or
to write the XML in a simple format using script, as we did in
the above sections, and make it easier to write Web pages that access
that data.
It's your call and depends on how many times the data is updated, how
much there is to update, and the skill of your front-end Web
developers.
How to Persist the XML to a TXT File
The simplest way is of persisting data ("saving to a text file") in
XML format is to save it by setting the adPersistXML parameter of the
ADO Recordset Save method. This saves the file, with a fully
populated schema, into a text file that any XML-aware database or
application can use.
This example uses an Access database and Visual Basic (VB), and
assumes you have a reference to ActiveX Data Objects 2.5 or higher in
your Interdev Project's preferences section.
Dim cn As New ADODB.Connection
Dim rs As New ADODB.Recordset
cn.ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=c:\inetpub\data\employees.mdb"
cn.Open
Set rs = cn.Execute("select * from employees")
rs.Save "c:\inetpub\employees.xml", adPersistXML
cn.Close
Set cn = Nothing
Set rs = Nothing
The key to getting the XML is to specify the parameter adPersistXML.
This will save the XML into a simple file you can include in your Web
application. Of course, you could write this in an ASP page and have
the XML created dynamically if the content is dynamic. If the data is
static, a nightly process run on the server will be more efficient.
The format of the XML output is different than the simple XML we've seen
so far. A XML schema is added to the output and the XML is in a row
format. However, it's still XML and can be read by the XML DSO in IE.
In the next section I'll outline how to data bind a table to this
information.
Accessing XML Saved by ADO
It takes a few more lines of code to bind the XML data saved by the
ADO Recordset. The XML looks like this (with the schema removed for
the sake of brevity).
You'll see it isn't the simple XML you're used to. Since the data is
actually a level down in the XML data tree, you need to use two
nested tables. The first table accesses the RS:DATA namespace; the
second accesses the Z:ROW element and its corresponding data.
The TopLevel table specifies the namespace (RS:DATA) to access. The
nested table SubLevel specifies what columns of the Z:ROW row to
access. When run, the full table is displayed.
Conclusion
The XML DSO in IE 5 gives the designed Web a simple interface to XML
data saved in any format. However, because the XML formats vary so
much and the way to bind them varies correspondingly, the time saved
creating the XML is often offset by the extra work needed to bind the
data. Which method will save you the most time and make the most
robust Web applications is a judgment call.
Ian Vink is a Canadian who has worked all over the world in the IT sector,
most recently in Haifa, Israel. He has been an intranet Webmaster for
four years and has been writing code since 1982. He's taught computer
technology since 1994 and owns a number of Web stores. He's married to a
wonderful Australian Oracle designer. Please send comments or questions to
Ian at ian@ianvink.com.
Stonebroom.ASP2XML(c) is an interface component designed to make building
applications that transport data in XML format much easier. It can be used
to automatically pass updates back to the original data source.
Right now the latest buzzword around town is AJAX. AJAX is an acronym for Asynchronous JavaScript and XML and is a method used to implement remote calling. The problem is that AJAX is only implemented in ASP.NET 2.0. This article will show you one way to implement remote calling without using AJAX or the XMLHttpRequest object. The technique outlined can even be used from classic ASP and is sufficient for most remote calling needs. [Read This Article][Top]
This article is the third and final installment of Alex Homer's series covering the new XML support in Microsoft SQL Server 2005. In it he covers updating the contents of xml columns, comparing traditional XML update techniques with XQuery, and using XQuery in a managed code stored procedure. [Read This Article][Top]
In the second part of his series on SQL Server 2005's new XML support, Alex Homer looks at extracting data from XML columns, comparing traditional XML data access approaches with XQuery, and combining XQuery and XSL-T.
[Read This Article][Top]
Microsoft SQL Server 2005 now offers great support for and close integration with XML as a data persistence format. In the first article of his series examining this new support, Alex Homer offers an overview of how SQL Server 2005 stores XML documents and schemas, examines how it supports querying and manipulating XML documents, and provides a simple test application that allows you to experiment with XQuery. [Read This Article][Top]
In the final article of his series on reading and writing XML in .NET 2.0, Alex Homer looks at how the updated XML document store objects XmlDocument, XmlDataDocument and PathDocument can be used to read, persist and write XML documents and fragments more easily and more efficiently than in .NET 1.x. [Read This Article][Top]
In the final article of his series on reading and writing XML in .NET 2.0, Alex Homer looks at how the updated XML document store objects XmlDocument, XmlDataDocument and PathDocument can be used to read, persist and write XML documents and fragments more easily and more efficiently than in .NET 1.x. [Read This Article][Top]
Alex Homer continues his series on reading and writing XML in .NET 2.0. In part one, we focused on the reading side of things, examining the XmlReader and XmlReaderSettings classes. In this article, we move on to look at the XmlWriter and XmlWriterSettings classes, and how they can be used to write XML documents and fragments more easily and more efficiently than in version 1.x of .NET.
[Read This Article][Top]
Alex Homer continues his series on reading and writing XML in .NET 2.0. In part one, we focused on the reading side of things, examining the XmlReader and XmlReaderSettings classes. In this article, we move on to look at the XmlWriter and XmlWriterSettings classes, and how they can be used to write XML documents and fragments more easily and more efficiently than in version 1.x of .NET. [Read This Article][Top]
In the first part of his series on reading and writing XML in .NET 2.0, Alex Homer discusses the XmlReader and XmlReaderSettings classes. The XmlReader exposes several useful new features and the all new XmlReaderSettings class makes it easy to generate single or multiple instances of an XmlReader with a range of useful properties. [Read This Article][Top]
In the first part of his series on reading and writing XML in .NET 2.0, Alex Homer discusses the XmlReader and XmlReaderSettings classes. The XmlReader exposes several useful new features and the all new XmlReaderSettings class makes it easy to generate single or multiple instances of an XmlReader with a range of useful properties. [Read This Article][Top]
Mailing List
Want to receive email when the next article is published? Just Click Here to sign up.
