subscribe: Posts | Comments

XSL Transformation

0 comments



If you’re pulling a lot of your content from a
database, don’t count on it.

Here’s a secret – if you want scalability – check out XML, XSL and XSLT
Processors. What’s a XSLT Processor? It’s an idea that makes rendering XML and
XSL a breeze. And guess what? Microsoft’s .NET provides a class, XSLTransform,
that’s going to make your life a breeze. Pretty sweet, eh? What’s fantastic
about XSL Transform is that you can output all of your content (data, links,
frequencies, etc.) into XML, then transform it into whatever you desire (text,
html, xml, aspx) using XSL.

What really makes XSL Processing work well is that you can forget browser
incompatibilities and old browsers that don’t have the facilities to render
XML. XSL Transform along with CSS will format your website so well, even your
mother can’t tell the difference between the transformed web page and one
painfully hacked out in HTML. Seriously, though, the real money is in the
speed and scalability of your system – that’s why, if you can do it, you
should move all ‘static’ content from the database to XML documents. When I
say ‘static’, I mean the data in your database that won’t change, or is very
unlikely to be changed.

This ‘static’ data can be stored as XML – relieving pressure from an expensive
database query that could be used for something more useful, like a dynamic
search against an author column. By moving the burden from SQL and network
traffic to mere I/O, you’ve bought yourself some real scalability.

But, uh, ok. I’ve got all this data in XML, and it looks like crap. I can’t
make sense out of it and the guys in marketing are going to be screaming
bloody murder…Relax. This is where XSL comes in. XSL stands for eXtensible
stylesheet language – you can just think of it as a script that formats XML
into a nice looking page. XSL can take any XML document and make it into
anything you want – whether that’s another XML document, a text file or an
ASPX page. The key here is that XML is your content and XSL is your
presentation layer – and XSLTransform is the glue that binds them together.

Here’s some code I’ve used on my site tiberi.us

public string TransformXML(string strXMLURL, string strXSLURL)
{
//Create a IO Stream
System.IO.StringWriter oSW = new System.IO.StringWriter();
try
{
System.Xml.XmlTextReader oXR =  new
System.Xml.XmlTextReader(strXMLURL);
System.Xml.Xsl.XslTransform oXSLT = new
System.Xml.Xsl.XslTransform();
oXSLT.Load(strXSLURL);
System.Xml.XPath.XPathDocument   oXPath = new
System.Xml.XPath.XPathDocument(oXR);
oXSLT.Transform(oXPath,null,oSW);
}
catch (System.Exception e)
{
//Put in custom error handler here...
string x = e.ToString();
}
return oSW.ToString();
}

A quick walk-through of the code will show the power of the XSL Processor.

public string TransformXML(string strXMLURL, string strXSLURL)
{
//Create a IO Stream
System.IO.StringWriter oSW = new System.IO.StringWriter();
try
{
System.Xml.XmlTextReader oXR = new
System.Xml.XmlTextReader(strXMLURL);

Our two parameters that we pass to this method are the URL of the XML file
and the URL of the XSL file. After we have both of these parameters, we can
transform our two files into something useful. Notice that we’ve created a
StringWriter object and have fired up an XMLTextReader and passed in the URL
for our XML file.

Now, here’s the real meat of our method…

System.Xml.Xsl.XslTransform oXSLT = new
System.Xml.Xsl.XslTransform();
oXSLT.Load(strXSLURL);

The XSLTransform object that we’ve instantiated will do the pack-mule
amount of the work here. Once we let it know where our XSL file is, and passed
it an XPathDocument, we can do the Transform.

System.Xml.XPath.XPathDocument   oXPath = new
System.Xml.XPath.XPathDocument(oXR);
oXSLT.Transform(oXPath,null,oSW);
}
catch (System.Exception e)
{
//Put in custom error handler here...
string x = e.ToString();
}
return oSW.ToString();
}

Notice that the oXSLT.Transform method takes three arguments, an ‘input’,
an args list for XSLT, and an ‘output’. We’re passing in an XPath Document for
our input, NULL for our arguments and we’re dumping the transformed XML into a
StringWriter. Although you could use an overloaded method of the Transform
method that directly references the URL of the XML and XSL files, I’ve decided
to walk you through the long way of doing the Transform so you’ll learn what
this object is capable of. Although we are passing in NULL for our XSLT
arguments, we are taking advantage of something very cool – the ability to
render portions of our XML based on parameters provided in our XSLT args. We
could write our XSL in such a way that it refers to parameters we’ve set up –
such as the current time.

//Create an XsltArgumentList.
System.Xml.Xsl.XsltArgumentList xslArg = 
new System.Xml.Xsl.XsltArgumentList();
TimeSpan oTime = DateTime.Now.TimeOfDay;
xslArg.AddParam("cur_time", "", oTime.ToString());

And in our XSL sheet, we’ll refer to our parameter we’ve passed in, rather
than rely on a script embedded in the XSL.

<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:param name="cur_time"/>
<xsl:template match="/">

Current Time:

<xsl:value-of select="$cur_time"/>
</xsl:template>
</xsl:stylesheet>

To take the XsltArgumentList to the next step, we could render off of the
conditional statement based on the parameters you’ve passed in via the
XsltArgumentList. Now that we’ve got a good grounding of how XSLTransform
works, let’s talk a bit more about scalability and how we can push the
envelope even more. There are three strategies that most businesses would use
when applying the power of XSL Transformation.

Strategies for XML and XSLT

1. Transformation on Demand

2. Transformation Factory

3. Cached Transformation Factory

Transformation on Demand

When using the Transformation on Demand strategy, HTML or ASPX pages are
created dynamically by applying a XSL style-sheet to an XML document and using
a transformation object to create the output. When a user requests a resource
on your website, an XSL Transformation object is used to format the resource
according to the layout in the XSL document. You may wish to pursue this
strategy if you’re creating an XML document by using the
System.Data.SqlClient.WriteXML() method based on a dynamic query from your end
user, if your XML or XSL documents are created on the fly, or if you need
absolute dynamic information pushed to your end user.

Transformation Factory

In a Transformation Factory, HTML or ASPX pages are created from the XML and
XSLT and saved as ‘static’ pages. By using a Transformation Factory, you can
create hundreds of static pages from dynamic sources and save the overhead of
creating these pages on demand. You could set up a Transformation Factory to
whip through thousands of XML files, apply the XSL and save the output as
HTML, ASPX or any other format you desire. End users would connect to these
‘static’ pages without the overhead of the ‘on-demand’ XSL Transformation. You
may wish to use this strategy if you don’t anticipate the ‘look and feel’ of
your website or the information to change. There is no need to apply an XSL to
the XML every time an end user requests a resource on your site.

Cached Transformations

A cached transformation is simply a transformation that takes places on a
given schedule, say 24 hours. The result of the XSL Transformation is cached
for a day or until needed and dished up to the end user. This is the strategy
most ‘dynamic’ sites should take unless you need to dish out dynamic
information that is up to the minute – like the information needed in a stock
market application. Most business needs are met with a daily or twice daily
caching of information. Simply cache each page with a cache time expiration of
24 hours. You can also create a dependency to any file (in this case, an XML
file), so if the file changes, your cache is updated with the information in
the updated file. To conclude, XSL Transformation is a very slick and needed
technology. This powerful tool allows you to scale upward rather than outward
– giving a needed break to your corporate pocketbook.