I previously used a custom collection to display the article titles and summaries on my /dotnet landing page. This involved reading the XML file, hydrating a business object for each article, returning the business object to the page, explicitly setting the data source for the DataList, and finally calling DataBind for the DataList. Since I had my XSD schema I was able to use xsd.exe and generate the business object, but the whole process still required quite a bit of code. Just the business object hydration (upgraded to the .Net 2.0 version using a Generic implementation) might include code like the following:

public List<ArticleType> GetAllArticles()

{

this.ValidateUrls();

List<ArticleType> articles = new List<ArticleType>();

XmlTextReader xtr = null;

try

{

xtr = new XmlTextReader(this.XmlDataFileUrl);

xtr.MoveToContent();

//read the file

while (xtr.Read())

{

if (xtr.LocalName == "article" && xtr.NodeType == XmlNodeType.Element)

{

xtr.Read();

//move past the article element to id

while (xtr.NodeType != XmlNodeType.Element)

{

xtr.Read();

}

//get the id value

ArticleType article = new ArticleType();

article.id = xtr.ReadString();

//move to date text element

while (xtr.NodeType != XmlNodeType.Element)

{

xtr.Read();

}

article.date = Convert.ToDateTime(xtr.ReadString());

article.dateSpecified = true;

xtr.Read();

//move to title text element

while (xtr.NodeType != XmlNodeType.Element)

{

xtr.Read();

}

article.title = xtr.ReadString();

xtr.Read();

//move to description text element

while (xtr.NodeType != XmlNodeType.Element)

{

xtr.Read();

}

article.description = xtr.ReadString();

xtr.Read();

//move to content text element

while (xtr.NodeType != XmlNodeType.Element)

{

xtr.Read();

}

article.content = xtr.ReadString();

articles.Add(article);

}

finally

{

xtr.Close();

}

return articles;

}

Since my data's original source is XML, it seemed silly to translate the XML to an in-memory object when I could bind the DataList directly to the XML file. I didn't mind not having to write the code either... So how do we use the XmlDataSource? Simply specify a URL where the data comes from, a URL for any XSLT transformation, and the XPath query to grab the records of choice from the data file. For example:

Note that due to the fact that my XSD schema defines the properties of each article as an element rather than an attribute, I transform the data coming from http://www.brettresources.net/xml/articles.xml so that for each article, the elements are transformed to attributes. The transformation is shown below.

<?xml version="1.0" encoding="utf-8"?>

<xsl:stylesheet version="1.0"

xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

xmlns:brett="http://www.brettresources.net/xml/articles.xsd">

<xsl:template match="/">

<xsl:for-each select="brett:Articles/brett:article">

<xsl:attribute name="id">

<xsl:value-of select="./brett:id"/>

</xsl:attribute>

<xsl:attribute name="date">

<xsl:value-of select="./brett:date"/>

</xsl:attribute>

<xsl:attribute name="title">

<xsl:value-of select="./brett:title"/>

</xsl:attribute>

<xsl:attribute name="description">

<xsl:value-of select="./brett:description"/>

</xsl:attribute>

</article>

</xsl:for-each>

</Articles>

</xsl:template>

</xsl:stylesheet>

Finally we get to our XPath query. I use "Articles/article" because I'm pulling back all the articles in the file.

Let's discuss the syntax to actually display this data in the DataList. Instead of using the Container.DataItem methodology, such as

(shown again with a format string). Note the @ symbol in front of the attribute name, as this is XPath syntax for an attribute. My DataList now has a DataSourceId attribute with the ID of the XmlDataSource associated with it. The ItemTemplate now looks like the following:

This by no means reduces the necessity for business objects when doing CRUD functions with your data, obviously, but this is a nice and easy way to present XML in ASP.Net 2.0 applications. It's also worth noting that caching comes out of the box with the XmlDataSource, so that's additional code which you don't have to write.

I really like what I see so far from ASP.Net 2.0 so far. The amount of code we as developers have to write to present data in applications has been greatly reduced, and this is just one example.