Re: [XSL] XSL Browser Integration
In the above case, if you view the source from the browser, you'll see
I don't think it is likely that many people use client side transformation like you suggest here (on a side note, I know one site that presents their pages as somepath-to-page.xml, you reckon this should be XML post-processed on the client, but no, it is not even correct xml, it is just badly constructed html: http://www.brainbench.com). If you do not use the (X)HTML tags in your pages, search bots won't easily find you or you have to put in quite some effort for them to do find you. Furthermore, I totally agree with your standpoint that it is not so handy to show the bare data to the user. Which is why this is a far from typical use.
Several uses on client side, however, are very worthwhile:
1. Post rendering basic XHTML
2. Transforming data for respresentation on the client side through XHR
3. Transforming representation data for processing on the server side as XML, through XHR
4. Pre- / post- processing and building command XML, where your server "talks" with XML commands
6. XUL / XAML like processing (widgets etc)
Of course, 2 and 3 do not necessarily need to be XHR, but it is by far the most versatile way to communicate under the surface with the server. Nr 4 is the one I mostly see because of lightweight command services that build up client side RIA applications. For instance, in a Excel-like grid, when a user changes a cell, the data entered is validated on the client, than send to the server after being processed with XSLT into an XML object.
As it turns out, it is very tedious to build XML objects using pure DOM. It is very handy to just use an XSLT processor with a couple of parameters (which can of course be DOM objects themselves) and build the XML command entirely using XSLT.
Nr 6 is something very useful, I think. There is a specification coming up for widgets, but it will take quite some time before that is finalized. I use my own widget format, and probably many with me, to build my own RIA application by just putting together the building blocks. Again, both the putting together and the processing from widget-xml to XHTML is done in XSLT.
This is what I meant when I said "presentational purposes only". If all
Some of the examples above are not about presentational purposes. However, I think they have a well-deserved place on the client side when correctly balanced against possible resources and roles (you don't want the client to do the hardcore xslt processing that indeed *should* take place on the server). When balanced correctly, the overall performance of both client *and* server increases dramatically.
I don't think I understand you here. Of course, persistence is on the server. But in the Excel-like example above, any changes are send through a POST with a body of XML, expecting XML in return. The data is then stored on the server.
And when I do a POST/GET using XHR, I get XML back and I almost *have to* use XSLT to make it more accustomed to client side scripting, processing or presentation.
Cheers, -- Abel Braaksma
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format