Subject: Re: [xsl] Modern web site design with XML and XSLT From: "Eric J. Bowman" <eric@xxxxxxxxxxxxxxxx> Date: Mon, 4 Jan 2010 09:59:18 -0700 |
"Michael Kay" wrote: > > Well, a lot depends on your detailed requirements and on where you are > starting from (in both technology and skills), but my preferred target > architecture would probably be: use XSLT server-side to generate > HTML, CSS to render the HTML, and XForms to handle the user > interaction. Using XSLT client-side is viable, but I don't see many > benefits over using it server-side. > I agree with your preferred target architecture; that's what I do, too. But I take it a step further. I have a basic weblog that uses Atom for its native data format, everything is either a Feed or an Entry. Each Atom representation also has an XHTML representation generated by XSLT. So all the template-y goodness and static menu links and such, are contained within the same XSLT transformation for every page on the site. But, the output of the transformation is mostly larger than the combined size of the Atom input and the XSLT stylesheet. Add to this the fact that the XSLT doesn't change, so it's cacheable on the client. Pushing the XSLT transformation out to the client saves on CPU utilization and bandwidth at the server -- as CPU and bandwidth are the basis of my webhosting charges, I see this as a Good Thing. When following a link to another page on the site, only the Atom for the new page needs to be transferred over the wire. The client has already cached the XSLT document (preferably *after* compiling it), the Atom content is pulled through it, and the result is rendered in the browser in less time than it would take to transfer the full XHTML document from the server. The benefit is increased user-perceived performance. This is particularly true in the case of using Xforms. I love Xforms, but there's no denying that the resulting code is heavyweight. If I want an interface which allows me to moderate comments, I have an awful lot of repetitive code on a long comment thread. For the case of a weblog with busy comment threads and an Xforms interface, client-side XSLT can save up to 80% on CPU and bandwidth, while doubling user- perceived speed (granted, this last score would be better if not for the poor state of XSLT web-browser implementations). (Unfortunately, I've not been able to make client-side XSLT generation of Xforms work in the real world. Generating the document is easy enough, but the result isn't connected to the model for some reason. Hopefully, this situation will improve over time.) I am writing another response to this thread, explaining HTTP Content Negotiation's use for this task, and addressing the issue of code maintenance by explaining that the client-side and server-side XSLT code can be exactly the same. -Eric
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] Modern web site design wi, Rob Belics | Thread | [xsl] Re: Modern web site design wi, Vladimir Nesterovsky |
Re: [xsl] reading a large XML file , Martin Honnen | Date | Re: [xsl] reading a large XML file , David Carlisle |
Month |