I just learn of ways to use XML data file and XSLT to create a webpage (transform from XML to HTML or XHTML). But I have never seen a webpage that has the source code of XML with a link to an XSLT file. Is it not a good solution?
+1
A:
You’ll have to do the conversion on the server, because not every browser supports XSLT.
Scytale
2010-08-12 12:07:06
oh... "most browsers" won't cut it huh... because what if it is a simple browser like Lynx or mobile browser, that probably is the reason. Companies want to show content to any simple browser capable of simple HTML handling.
動靜能量
2010-08-12 12:09:57
All of the major browsers support XSLT including mobile. The problem, as always, will be IE since it cannot handle XHTML.
Rob
2010-08-12 12:28:12
I don’t think so.
Scytale
2010-08-12 12:32:55
IE is not really a problem here for once - its XSLT support, even in IE6, I've found always found to be acceptable, or at least workable. XHTML doesn't come into it: XSLT (1.0) itself doesn't support XHTML either, since it predates it.
Will Prescott
2010-08-12 14:50:41
+2
A:
Sure there's pages that are generated using XSL+XML, but I bet most of them are parsed server-side, not clientside. Then, if you open an aspx or php page, you can't really tell whether or not it's been parsed from XML and XSL files.
It's quite a decent template mechanism, too. We use it for web pages at our firm, as well as e-mail and some other media. That would be the advantage of XML in this regard; it's not media aware and you can transform your source xml into many formats (most of which will be xml-based).
Rob
2010-08-12 12:09:52
A:
There is a sample PHP Application using XML/XSLT to generate HTML, with server- and client-side demos at Tony Marston's A Sample PHP Application, with plenty of reasoning, howtos and such.
Alan
2010-08-12 12:14:19
A:
Blizzard's world of warcraft websites and their armory website have the only website I've ever seen that sends xml and uses client side xslt to display it. It seems to work quite well and they are pretty high volume sites. (Be aware that it looks at the user agent and does the transformation server side for some browsers, I know it does it client side for IE)
John Burton
2010-08-12 12:22:02
I wish I could show a link to a restaurant ecommerce site I'm working on that does the same. It works everywhere and very well except in IE, of course. For that we have to add some javascript.
Rob
2010-08-12 12:30:15
+2
A:
If you already have the data as XML (or its easy to turn it into XML) then I'd say it's a good solution. You probably want to make sure that your web server is configured properly to ensure that the XSLT is getting cached on the client side so that it doesn't have to do the request every time.
If the data isn't in XML already, there are better templating solutions out there (PHP, JSP, ASP, etc.) that are better suited to whatever environment you're in.
jmo
2010-08-12 13:48:11
A:
It's a good solution if it fits your needs. A client side XSLT transformation is ...
... good because:
- you can use templates on cheap netspace without any server support
- very good for heavy traffic
- the site works even offline on CD/DVD/USB-Stick
- header, footer, navigation etc. is in the XSLT script and loaded only one time, good for speed with many similar pages.
... bad because:
- Some niche browsers may not support XSLT
- you will not be present at google, the XML file ist not appropriate for serch engine spider
Andreas
2010-08-12 14:43:06
Can you explain how 'the site works even offline on CD/DVD/USB-Stick' or 'you can use templates on cheap netspace without any server support' any more than a non-XSL site. If there is dynamic data it will need to generate XML anyway, and if it is not, a flat HTML site would be equivalent. So what is the benefit of XSL?
DanSingerman
2010-08-12 15:06:24
@DanSingerman: With XSLT you can use dynamic data but it will be processed client side by the browser. The provider serves .xml and .xsl as static files, no difference to serving static html pages. Everything works just the same opening the .xml in your browser as a local file. But e.g. 10 static html pages are 10 x header, menu and footer. With client side XSLT 10 pages are 10 .xml files with specific page data and 1 .xsl file with header, menu and footer. To see this running, look at http://www.klassikmotorrad.de
Andreas
2010-08-13 06:44:09
+1
A:
I do not think it is a good architecture for public-facing web sites:
- Although most browsers will support client side XSLT, not all will
- Even if they do, there may be individual browser compatibility issues as with javascript
- Being able to 'view source' is an incredibly useful tool for debugging. You can't do this with XSL
- Google supposedly will rank well marked up HTML higher than XML documents
- XSL is a horrible language
- You still need to render to XML (unless your data is natively XML), so why not render directly to (X)HTML?
If your data is natively XML, then it might make sense to convert it via XSL on the server side (I have written systems that do this), but that is the only situation and architecture I would use XSL in building a web site.
DanSingerman
2010-08-12 15:02:15
So XSLT is not a good architecture for public-facing web sites just as Javascript isn't? If your data is not XML, the browser can't use client side XSLT. If you need server support, you can use anything available.
Andreas
2010-08-13 06:54:26