Binding to XML Data in ASP.NET 2.0
One of the nice things about the original release of ASP.NET was the ease with which you could bind data to the user interface of a Web page. Microsoft defined a relatively simple declarative syntax for hooking up databases to Web pages, and this made it pretty easy to build database-backed ASP.NET Web sites. But things never stand still in the development world, and there are advances in this area in ASP.NET 2.0. Not only has it gotten easier to design database-backed Web pages using Visual Studio 2005, but the range of data sources has increased. In this article, I'll show you how easy it is to hook up an XML file as the source for a grid on an ASP.NET Web page. This article is based on beta 2 of Visual Studio 2005, so there may be some changes in the final shipping product.
Building the project
To get started, I created a new ASP.NET application using Visual Studio 2005. The next step was to add a new XML file to the application, which I named Translation.xml:
<?xml version="1.0" encoding="utf-8" ?> <Names> <Name CodeName="Longhorn" RealName="Windows Vista" /> <Name CodeName="Indigo" RealName="Windows Communication Foundation" /> <Name CodeName="Avalon" RealName="Windows Presentation Foundation" /> <Name CodeName="Whidbey" RealName="Visual Studio 2005" /> </Names>
With ASP.NET 2.0, you can bind an XML data source anywhere you could bind any other type of data. For instance, the new GridView control can be bound directly to an XML file. To do this, I switched the default.aspx page to design view and dragged a GridView control from the Data tab of the Toolbox to the form. The next step is to click the GridView control's smart tag and select <New> from the Choose Data Source dropdown. This opens the Data Source Configuration Wizard, as shown in Figure 1.
I selected the XML File data source type and kept the default ID of XmlDataSource1. Clicking on OK opens the Configure Data Source dialog box shown in FIgure 2.
Here I browsed to the XML file that I added to the application to be the source of the data. I didn't specify any transform file because this XML file is already in the format that I want, but you can supply the name of a standard XSLT file here if you want. The third box here is for an XPath expression that specifies the nodes in the XML file that will supply the data for the data source. The expression
Names/Name says that I'm binding the contents of the
Clicking OK in this dialog box creates the XmlDataSource control and binds it to the GridView control - and that's it! Visual Studio just does the right thing at this point. Figure 3 shows the resulting page in design view, and Figure 4 shows the same page in the browser. As you can see, each attribute of the
<Name> nodes has been translated to a column in the GridView.
Looking Behind the Curtain
So much for the pretty face. What does it look like behind the scenes? Actually, it's not much more complex, thanks to the plumbing that's built into ASP.NET. Here's the source code for the page that I just built:
<%@ Page Language="VB" AutoEventWireup="false" CodeFile="Default.aspx.vb" Inherits="_Default" %> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" > <head runat="server"> <title>Codename Translator</title> </head> <body> <form id="form1" runat="server"> <div> <asp:GridView ID="GridView1" runat="server" AutoGenerateColumns="False" DataSourceID="XmlDataSource1"> <Columns> <asp:BoundField DataField="CodeName" HeaderText="CodeName" SortExpression="CodeName" /> <asp:BoundField DataField="RealName" HeaderText="RealName" SortExpression="RealName" /> </Columns> </asp:GridView> <asp:XmlDataSource ID="XmlDataSource1" runat="server" DataFile="~/Translation.xml" XPath="Names/Name"> </asp:XmlDataSource> </div> </form> </body> </html>
You can see the XML file name and the XPath expression in the attributes for the XmlDataSource control, and the binding of the XmlDataSource control to the GridView control through its DataSourceID attribute. A little thought will convince you that it would be simple to generate code like this with any code generator, which opens up all sorts of possibilities for automatically building a user interface on top of XML files.
So Where Does XML Fit In?
Storing data in XML files in not going to replace storing data in relational databases any time soon. I wouldn't recommend trying to migrate your customer and order database to XML files any time soon, for example. There are many good reasons (such as support for transactions, built-in backups, and replication) for storing data in a database. Nevertheless, the addition of XML databinding to ASP.NET 2.0 opens up some promising new avenues for development.
XML is an utterly ubiquitous file format these days. No matter what unusual storage format you're faced with, it's getting more and more likely that it can export to XML. In these cases, when XML is all the data you have, being able to bind directly to the user interface saves you the time and bother of importing to another database format.
Beyond that, though, XML offers a human-readable universal format that many people find a comforting form of insurance. XML files are about as far from vendor lock-in as you can get. As long as your data storage needs are reasonable, putting the data in XML files means you're assured that you'll always be able to read that data, even if your software platform changes. This makes the XML databinding capabilities attractive to organizations that might otherwise be reluctant to move a site to ASP.NET, and lets you build ASP.NET sites that maintain compatability with sites and processes written in other languages.
About the Author
Mike Gunderloy is the author of over 20 books and numerous articles on development topics, and the lead developer for Larkware. Check out his latest books, Coder to Developer and Developer to Designer, both from Sybex. When he's not writing code, Mike putters in the garden on his farm in eastern Washington state.