XSLT browser mapping vs XSLT PHP rendering

Question

I am using XML and XSLT in my current project, and I would like to know if it is good to let the browser convert XML to HTML with style, instead of using something like PHP xsltprocessor.

One of the main reasons I use the xslt processor for the browser is to allow the API to access my XML data in the near future. So I want the client-client to be converted, so my XML is still available.

I may be wrong in PHP xsltprocessor, but when xml is processed through PHP, the resulting data is processed XML (in my case, HTML), and the XML data is no longer available. Is it correct?

Thanks for sorting out.

Answer 1

It all depends on your ultimate goal. I am working on an application that generates reports as xml, and we send xml and xslt to the browser to do the processing. There are several reasons for this approach:

• as you mentioned, you can perform further processing on the client
• html is pretty verbose, and if you have control over your xml, you can make sure it isn’t so verbose, so at the end you send a small amount of data between the server and the browser.
• xslt can be cached in the browser, so after the first use there will be no overhead
• Performing a conversion on the server adds to the load on your server, which can have an effect if you have many people trying to access the page at the same time.

In some cases, we do the conversion on the server. for example, we convert to an html table and then change the type of the http content to send the result as excel.

Answer 2

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

In order to get accessible XML on the client side, as part of your conversion, you can output the XML sections that you need (or the entire DOM) and place them either in a JavaScript variable or somewhere accessible on the page.

I found that client-side rendering is good for small, controlled (for example, internal) applications, but for something where you want tight control over the output server side to be more reliable.

Answer 3

If you are creating an application with an MVC pattern, it does not matter. You can expose HTML to regular browsers and XML through the API.

And even if you are using XSLT on the server side, it should be pretty easy to skip this step if / when you add the API.

Usually XSLT on the client side has many drawbacks - high latency, because both the stylesheet and all the data must be fully loaded before anything starts rendering. Using regular HTML, you get lower latency (only one file, streaming), and additional resources begin to load even before HTML is completed.