Browser rendering XSLT vs PHP rendering XSLT

I use XML and XSLT in my current project and I would like to know if it's good to let the browser render the XML into HTML with stylesheet instead to use something like the PHP xsltprocessor.

One main reason I use the Browser xslt processor is to allows API to access my XML data in a near future. So I want the transformation client-side so my XML is still available.

I m开发者_开发技巧ight be wrong about the PHP xsltprocessor, but when a xml is processed via PHP , the data received is the rendered XML (in my case HTML) and the XML data is no longer available. Is that right?

Thank you for clearing things out.

I recommend doing the transformation server-side because you have more control over it. If you rely on the browser you may see slight differences in the rendering engines in different browsers. If you transform on the server and pass down html then you can do cleaner testing by specifying exactly what html you want to generate, making sure a static version of that html looks correct, and then working on your XSLT to make sure it generates the html correctly.

To get the XML available on the client-side, in part of your transform you can output the sections of XML that you need (or the whole DOM) and put that either in a JavaScript variable or somewhere accessible on the page.

I've found that rendering client-side is nice for small, controlled (e.g. internal) uses but for anything where you want tight control over the output server-side is more reliable.

If you design application with MVC pattern, then it won't matter. You'll be able to expose HTML to regular browsers and XML via API.

And even if you do XSLT on the server side, it should be fairly simple to skip that step if/when you add an API.

Usually XSLT on client-side has many disadvantages — high latency because both stylesheet and all data have to finish loading completely before anything starts rendering. With plain HTML you get lower latency (just one file, streamed) and additional resources start downloading even before HTML is finished.

It all depends on what your end goal is. I work on an application that produces reports as xml and we send the xml and xslt to the browser to do the processing. There are a few reasons for this approach:

• as you have already mentioned you can do further processing on the client
• html is fairly verbose and if you have control of specifying your xml you can ensure that it isn't as verbose so in the end you send a small amount of data between the server and the browser
• the xslt can be cached on the browser so won't be an overhead after the first time it is used
• doing the transform on the server adds load to your server which can have an impact if you have many people trying to access the page at the same time.

In certain cases we do the transform on the server. e.g. we transform to an html table and then change the http content type to send the result as excel.