View Full Version : xml and xslt support in php

09-29-2004, 01:02 PM
I am confused by the lack of support for xml and xsl on servers that have php installed.

I generally make my living writing server applications in asp (jscript, no vb), and I have come to use xslt for all my html formatting. It took me some time to really digest it and start using it effectively, but now there is simply no other template technique that I would even consider using, at least as long as I have xslt available at my disposal.

Some 6 years ago, when I first started with web development, I worked with Perl, and when it came to outputting html, I used the plain old 'mix-it-all-together' approach, by hard-coding the html within the Perl scripts, and than using variables within html where dynamic data was required. It only took a month or two until I found an article that demonstrated a technique of using html templates, so I moved my html out of the scripts and into the templates.
The technique was in essence very simple, utilizing codes and comments within html to denote variable insertion points and loop block starts and ends, and regular expressions to process it all. Not particularly elegant, but it worked just fine, and in any case, it was a lot better than mixing html and perl code together in one file.

At some point, my work led me to asp, so I started using JavaScript as a server-side language, and one of the first things I did when beginning in this new environment, was to create a template model that worked just like the one I used in Perl.

And again, all was well, for a time.

Until I got to work on a massive project for a website that was, among other things, supposed to speak multiple languages. The problem with my templates was that now that they also needed to have the labels and other static text inserted according to the user's current language, the whole technique was simply becoming too slow. And due to complex formatting on the pages; many loops and loops within loops, the maintenance (of comments and such, within templates) was becoming a nightmare, and there was so much template processing code in asp script that I could hardly say that I had a true separation of code and formatting. At this point I started to consider xslt as a template system.

To be honest, I had a lot of problems digesting it at first. A lot of typing to do some simple things, and the tree processing logic really took some time to sink in for me. Additionally, if xslt was to process my data for display in browsers, all of it had to be xml. But the more I used it, the more I liked it, and as I said on the beginning of this post, I wouldn't use anything else for my templates now, as long as I have a choice.

During the years of my web development, I followed the progress of php, and have come to use and work with various open source php projects, so even though I have not been doing any projects in php, I kept an eye on it, and have seen really all kinds of applications and various template techniques they use. Not one of them uses xml/xslt for output.

And than recently, I got a relatively simple assignment, with one of the requirements being that it should run on unix servers, so I decided to use php to write it. The very first thing I had to decide was what template technique will I use to output the html. And after some looking around, reading about various 'template engines' for php, I decided not to use any of them and to go for xslt. I enabled the domxml and xslt extensions on my local development copy of php, I wrote a simple XmlData class to gather my data, and a Page class to process the data with an assigned template, and the basic output model was up and running with xml/xsl in php within 2 hours. And I was very pleased. Sablotron parser works with xslt 1.0, so 95% of all xsl I would write in asp for Msxsl parser works exactly the same. The php I wrote is also very elegant - gather some request data, talk to the database, create a result xml document and than call the xslt transformation - zero lines of formatting or anything even remotely connected with the html output.

And after two days, with the application nearing completion, I figured it was time to install it on the server so that the client can have a look at it and test it. I have a windows hosting (asp is the primary environment I work with), where I am also subscribed to the php/mysql option, and I am running dotproject (open source php application) on my website for project and client management tracking. Naturally (I expected that), the domxml and xslt extensions were not enabled on the server so I asked them to do that. For some reason, this has still not happened, even though they said they enabled them. It took a few days before I got the proper reply and I was also busy with other things, so as the extensions were still not enabled, I asked my client for login details for his own linux host, and uploaded the files over there yesterday. Needless to mention, the same set of extensions needs to be enabled there as well ( dl('xslt.so') for example, won't work in safe mode, so they have to do it themselves, on the server). This has been requested yesterday, and more than 24 hours later it has still not been done, so here I am, writing this post as I wait for them to do it so that I can go on with installation.

The things is, in the past year I have made a test that verifies if the xslt extension is enabled on a host and tried it on two more linux servers, and found that it was not. I think that's a shame, since xslt has been bundled with php for quite some time now, and this shows the general lack of interest in xsl within the php community.

I'd like to wrap up my post with a list of arguments for using xslt for html output.

- xslt is a standard
- xslt is a form of xml, just like (x)html, so the formatting instructions can be within the html itself (actually it's the other way round, html is within xsl :)), therefore there is no need to switch between two (or more) files to see and change how the end result will come out
- its very fast when processing xml
- it can be used across different environments, it doesn't care about your programming language of choice, all it requires is a valid xml input
- it provides way more transformation possibilities than any custom-made template engine can hope to achieve (as long as it's xml it's working with)
- it has a future (being a standard)

.... and since, to work with it, the environment has to be adjusted so that it can wrap all required input data as xml, as a side effect, the application using xslt will be ready to output xml to other outlets as well (xml feeds, xmlhttp etc).

It is my opinion that custom template engines are really 'rediscovering the wheel', and that there is no long-term future in these systems. On the other hand, having had my journey through learning xslt (and it did take some time...) I can understand that in many cases it may just be too much to digest and go learn an entirely new technique to achieve something that you can already do with a custom template engine (even though the differences and possibilities are very different, the essential goal is to output html).
But why is there such a low support for it on servers? Why would not a php developer would be able to try it out and experiment with it? The fact that xslt support on servers is so rare is discouraging to any would-be xslt developers in php.

What is your opinion?
Has anyone here already used xslt?
I'm curious to know what you guys think about it.

09-30-2004, 07:16 PM
I can agree with the other points but ...

- its very fast when processing xml
>> absoloutely not , XSLT transformations carry a fair overhead as compared to munging with PHP/whatever

- it provides way more transformation possibilities than any custom-made template engine can hope to achieve (as long as it's xml it's working with)
>> transformation of what to what ? XML to XHTML? yes , database in a DB to XHTML ? no

To many developers PHP is the templating engine.
I personally also find transformation of data from source (DB) to output HTML/XHTML far easier than via XSLT (and find overly complex templating (think smarty) to be totally OTT.

Anyway , as to why XSLT is not often found on shared hosts historically are issues with/worries about, performance , PHP XSLT transformations are neither fast nor 'efficient' (efficient perhaps if the results are cached and sensibly reused) , earlier versions were buggy and slower still.

PHP is an interpreted language & as such efficiency/performance is cherished , many peeps (like me) worry far too much about gaining the odd millisecond here or there and probably need to get a life ;) , however serverside transformation with an interpreted language on shared hosting ... is scary.

JAVA/.NET as compiled (almost) languages suffer less from this.

I do not know how XSLT has improved with PHP5 , I know that the simpleXML functions are fast and working with XML in PHP5 is almost a joy , certainly compared to the horrible parsers we used to have to use (now we at least got a choice)

I can only assume that XSLT will have improved to match , if so expect better `built-in` support when php5 finally hits the hosts.

09-30-2004, 08:11 PM
I'm with the original poster here - the benefits of XML far outweigh the drawbacks. There's nothing "wrong" with XSLT, you just need a faster-than-currently-typical server to use it effectively.

Anyway there is a PHP XSLT engine, I have it on my server - check out http://www.gingerall.com/charlie/ga/xml/p_sab.xml

09-30-2004, 10:16 PM
Thank for providing some feedback.
Like I said in the first post, I am only starting with php at the moment an it is questionable weather I will continue working with it seriously.
I suppose asp got me spoiled. The point firepages puts out about it not being easy (effective?) to go from (key/value pair arrays) data retrieved from database to (x)html is a good one.
Only now I realize how much for granted I took ado's recordsetObj.Save(adPersistXML) .... which does all the hardwork for you by saving the retrieved data directly as xml.
If you read my original post you know that I have been struggling to get the server's support people to enable the domxml and xslt extensions. Eventually they did it (they recompiled php), but they had to do it twice because they simply didn't get what I mean with domxml and kept saying xml was already there. Which indeed was the case, but I needed 'domxml', not 'xml', for this particular application.
Which is another point where I am quite startled with - that whatever php people are doing with xml they mostly don't use dom (it even states on php.net that domxml is experimental, and that with php 5 dom (rather than domxml) should be used instead) - which is yet another standard.
I suppose than that most xml related coding in php is performed using strings....
I will get used to the situation with time I guess, and my surprises ( :eek: ) and questions ( :confused: ) will reside, but at this point I am still wondering what is the php community waiting for, when it comes to moving on with time, and using the technologies made to make our web development lives easier, and our code more portable.


10-01-2004, 12:49 AM
many peeps (like me) worry far too much about gaining the odd millisecond here or there and probably need to get a life ;)

Yeah, I need the geek's guide to getting a life ;)