| SitePoint Sponsor |
My question... What aren't people using XSL instead of PHP template engines? I can see the value of PHP as a template engine, but when comparing XSL to a PHP tag-parsing template engine, it seems that XSL wins.
Just curious as I've been dabbling in XSL this weekend and really think it's quite cool. Besides making sure your host has the needed tools for XSL, what are the down sides?
-matt
I think that's the biggest one. Most hosts don't want to install Sablotron or whatever, and a lot of them don't want to move to PHP5 yet.Originally Posted by mwmitchell
Downsides are that it isn't easy to pick up for a lot of folks - I had bother for a while myself, and still do - I suppose?
There is some common programming functionality missing from the first version as well, (regular expression being one example, there are more though) but are now addressed in the second version.
For more information and a better, more informed view (than mine that is, I don't know all the facts) try looking at www.xml.com and have a look around?
After thought, look at the specifications as well, between the original version and the newer version
Another reason is that XSL is tedious. I'm not saying it's not useful, but to me, it makes the presentation layer a bit harder to deal with. I'm using it now alongside Java. It turns out that it's more of a hassle than using a normal templating engine with Java such as velocity. Ah well, lesson learned.
XSL is a great technology, don't get me wrong. It just isn't suitable for all web applications out there.
feti
Mojavi Project - Mojavi 3.0.0-dev available now!
I agree with this article as it sums up my views on the subject:
http://xao-php.sourceforge.net/ctrl....ing_pty-vs-std
JT
Thanks everyone. I haven't seen the XAO site for a while and I couldn't remember the name, but knew it was out there. Thanks for that link. It does a good job of making XSLT seem ideal. But I understand the reasons why people aren't using it also. Not sure myself. I think I'll have to just build a site and try it.
One thing that I might be building a site that needs a flash front/back end and an html front/backend. Seems to me that XML would be the best bet. And for the HTML, XSLT would be the way to go.
-matt
I seem to be one of the few people who is actively using XSL as a templating engine within my PHP application. I knew XSL before I taught myself PHP so it was not a difficult step.
If you want full details then visit my website (link below) and browse through the numerous articles.
Tony Marston
http://www.tonymarston.net
I came across this project a while ago:
http://xsiteable.org/
Now ... I would argue that xsiteable kind of keeps PHP out of the loop (XML->XSL->HTML), but still it has some really nice things going on. Maybe that's the core of the problem - XSL provides transition from data to presentation - That's basically the same role that PHP fills out, so having both technologies going on at once is bound to give an overlap of some kind.
I went through a period of liking XSL, but when I applied it to real projects, I just got too irritated by <apply-templates />.You can't put a template inside a template, so it leads to fragmented and hard to follow templates.
For PHP, I'm now using PHP templates and the structure feels much better.
It is perfectly simple to represent the data in your application as XML for the benifit of an XSL template, but at the end of the day, it is much eeasier to hold your data from PHP in PHP datastructures (arrays, objects etc), so a PHP template ends up being more natural.
Regards,
Douglas
Hello World
You may not be able to DEFINE a template from within a template but you can certainly CALL a template from within a template. I use this feature extensively in my own code so I know it works. Take a look at my website (link in my signature) where you can read some articles I have written, and even download a sample application which shows how these ideas work in practice.
There is no overlap if you know what you're doing. In my application the PHP code does not generate any HTML code whatever - it simply creates an XML file then performs an XSL transformation using a predefined XSL stylesheet. This is what the separation of business logic and presentation logic is all about.
I'll agree with Tony, particularly keeping PHP out of the picture when it comes to building up the HTML. From the perspective of MVC, PHP can relegated entirely to the realm of the controller, XML becomes the model, XSL becomes the view. XSL definitely requires a mindset that is far removed from PHP when it comes to laying out a page's structure, but I believe it is well worth learning. Also, combining XSL with some well-thought-out CSS can make for a very lean, VERY flexible application.
PHP becomes more of an XML generator than anything else. You can change to Perl, Python or .NET, it doesn't matter, the XSLT stays the same.
JT
I would say that every technology has its place, but there are certainly times when you can over-engineer a project for technologies sake beyond anything else. In a recent project we were pulling back stacks of XML data from a corporate system that needed to be parsed ready for output on huge printing presses. Due to the way the interface worked it was natural to use XSL for this transition and it suited our purposes wonderfully. However as part of the same project the data also needed to be presented to management via their intranet - again we could have gone down the XSL route and built complex CSS/XSL templates, but there has to come a point when you stop and think "what are the actual benefits of doing it this way?". Ultimately we would have had PHP pulling in the XML feed, parsing, manipulating and then creating a new XML structure from that, only to be handed to XSL for transformation into HTML. This would have been for this case a pointless exercise in over-engineering. There was simply no tangible benefit. In the end this section of the project relied on PHP and a templating system to create the HTML. The end result was less overhead on the servers, less complication for changes further down the road and the exact same end result.It is perfectly simple to represent the data in your application as XML for the benifit of an XSL template, but at the end of the day, it is much eeasier to hold your data from PHP in PHP datastructures (arrays, objects etc), so a PHP template ends up being more natural.
Don't get me wrong, it's a very cool technology, but there is a right time and use for everything and to say "all web sites would benefit from XML/XSL" isn't really looking at the task in hand and the best suitable solution for it.
Tony - very interesting articles btw, I liked your challenge to achieve a similar level of re-usability in your own applications
Cheers,
Rich
I agree that for now XSLT is too much work and too slow to be worth it. However tools and time may change that. From Tony's sample application showing 100 records:page created in 0.12271 seconds (XSLT= 7.63736 seconds)
I should point out that my web hosting service is running PHP 4 where I use the sablotron XSLT engine. On my development PC I am using PHP 5 with the XSL extension, and the transformations are up to 10 times faster.
I disagree that XSLT is too much work. Like everything else it is an investment. I have created a library of reusable stylesheets which I can reuse over and over again, so the time I am saving now is well worth the effort I put into creating them.
XML is not the model as it contains nothing but flat data. In my MVC implementation the model is a PHP class which processes any business rules. When it is time to show the results my view component sucks data out of the model, converts it to XML, then performs an XSL transformation.
Each XML file is created from scratch for each web page, therefore the contents of each XML file can be totally different each time. The model, on the other hand, is defined once (in a class) and this definition persists between page requests.
The model has the capability of processing business rules, an XML file does not.
The model has the capability of communicating with other objects in the system, an XML file does not.
Therefore XML cannot be regarded as the "model" in an MVC application. It is merely part of the "view".
I agree, you can build up a very powerful set of sheets reasonably quickly that can be re-purposed across many projects. But to be honest, you can do that with any templating system, the fact it's XSL doesn't make it any more (or less) re-usable. At the end of the day it's just a style transformation and if you want all your apps to look the same (which is no bad thing if you have a good working gui formula) then re-use away to your hearts content, it's just not a benefit exclusive to XSL - any well developed template system would do the same.I disagree that XSLT is too much work. Like everything else it is an investment. I have created a library of reusable stylesheets which I can reuse over and over again, so the time I am saving now is well worth the effort I put into creating them.
As we see more and more hosts move to support PHP5 (and as we see faster releases of PHP5 for that matter!) I think the PHP/XML/XSL combination can only increase in use as more people dive into it.
Where is the benifit?
I know it sounds good, I bought it for a while myself, but it is BS. How often do you rewrite your whole application without touching your user interface?
If your style sheets are so general that they will apply to any application, even when you rewrite from the ground up, the XML will be the HTML. It comes back in a big loop, and soon you'll be looking for XML template managers...
Douglas
Hello World
Sorry Tony, that's not good enough. Look at the numbers, even with this apparent 10 times increase in speed:
page created in 0.12271 seconds
XSLT = 0.763736 seconds
You are still taking more than six times as long to phrase a template than it takes to run the application, including database callls, probably authentication, model logic, everything else to generate the page.
In your live example, that is sixty times as long. And that isn't even a "real" example, because it isn't an application in use by lots of people. Add some load to your server, and watch those numbers climb.
Not all investments are good investments. Multiplying the generation time by 60 for no real benifit is a bad investment.
Douglas
Hello World
The original figures were obtained from a page that was 100 lines deep, which is far too big for most users. If you look at the timings for a page that is 10 lines deep you will see a BIG difference.
The purpose of a templating system - ANY templating system, not just XSLT - is to save developer time which nowadays is far more expensive than hardware. It may take longer to run, but it is sure faster and cheaper to develop.
If pure runtime speed was the be-all and end-all we would all be writing in C, but at what cost in programmer productivity?
The speed of XSL transformations is "good enough" for most people. If the load on the server starts becoming a problem it is cheaper (and quicker) to simply plug in another server.
Let me clarify, or rather restate...the model is not implemented in raw XML, but rather (in my rudimentary implementation) as a class that inherits from DOMXML. that class builds up a DOM object with whatever data is necessary, and is pushed directly into the xslt processor. I never explicitly dump the dom object to xml as the xsltprocessor handles it. so you're right in saying that XML can't be the model. what i should have said was an xml document (DomDocument in php5) is used as the model. which technically means that the model is implemented in php. heh, so yeah, scratch that "php is just the controller" statement i made.
I'll agree with most folks that using XSLT isn't a solution to every application out there, not even every web application. i'm personally a fan of it at this point, but that may be because it just feels fresh to me.
Also, to deal with performance, it's fairly easy to build a caching system that serializes the xml document to a file by using either serialize() or just dumping the raw xml to a text file, so successive page hits mostly just deal with XSLT processing. again i know this won't work in every application, especially where content is updated very frequently, but it is pretty nice for sites that have dynamic content that is not updated very often, or read from much more than it is written to (ie, contact information, blog entries, etc).
There's an interesting (and old) article at xml.com called Style-free XSLT Stylesheets that shows how to seperate a majority, if not all, of the html from the xsl stylesheet. i tried a variation of this and ended up with 3 xml documents used during page generation. 1 file that was almost entirely html, with the exception of some custom marker tags (ie, <insert-site-title/>, etc), 1 file that contained all of the xsl templates for matching each custom marker tag, and the xml document with all of content of the site. the site in question had a small control panel for updating content, but after the content was written to the database, it was then pulled out and dumped to an xml file in the site's directory. page hits to the public site never sent any requests to the database, and the DomDocument didn't have to be built up. it was simply read from the "content cache" on the filesystem, transformed using the xml/html template AND the xsl template, and fired back to the client. the turn around time for generating any given page was on average .02s (p3 600mhz, 512mb ram, not much traffic).
There are, of course, plenty of kinks to be worked out and plenty of dark corners to explore. for one, i don't have any real standard for naming the marker tags. right now it's just <insert-whatever/>. namespaces would probably be helpful. regardless, what i've seen has convinced me that xslt a worthwhile pursuit when it comes to handling presentation for my web apps.
-Drew
If there wasn't, I'd be very worried.
Yes, that is a comment on templating systems - not specifically XSL. Please don't try and confuse the subject. Noone is saying "don't use templates" let alone saying "you should write your pages in C". Please make some effort to keep on topic.The purpose of a templating system - ANY templating system, not just XSLT - is to save developer time which nowadays is far more expensive than hardware.
XSL doesn't save developer time or designer time, and results in an objectively weaker performing application. It needs more services set up (sablotron) which costs developer time. Setting up a second server costs developer time too remember, and maintenance time.
"What aren't people using XSL instead of PHP template engines?"
Because in many cases it is over engineering: if you have data comming to you as XML, and you want to output XML, great. That's what XSL is for. Use it for that. If your data is comming from a database, and the output is XML you might as well output XHTML rather than inventing your own in-between XML. Have XML (=XHTML too) templates, and feed data from PHP directly into them using <?php ?> tags. It is fast, can be converted to byte code by zend, mmcache etc, easier to work with, less bloated. Go use it.
Douglas
Hello World
I will add to your reply with a link to some posts I had a while back which show how you can use the XSLT "Simplified" syntax making things easier on the Web designer and some other interesting XSLT applications including the "Style-Free" Stylesheets you mention.
http://www.sitepoint.com/forums/show...&postcount=133
http://www.sitepoint.com/forums/show...&postcount=134
http://www.sitepoint.com/forums/show...3321&mode=list
I agree that, in a real-world XSLT application, caches are implemented to drastically improve performance. Also, enterprise apps often deliver content in different forms (e.g. RSS, WML, etc.). XSLT is obviously a perfect fit for such an application. The link to the article I posted earlier in this thread boldly challenges those who doubt the use of XSLT in real-world Web applications. I am interested in seeing someone here construct a sound counter-argument to that article. Like everything XSLT is not a silver bullet, but it definitely has it's place.
Thanks,
JT
Last edited by seratonin; Jan 21, 2005 at 12:35.
But it was you who stated that because it seemed to take longer to produce XHTML output by using a templating system (in this case XSL) instead of pure PHP that it was not worth the investment in learning XSL. My point is that speed is irrelevant if it is "good enough". At today's prices it is often cheaper to throw in more hardware than it is to try and tune the code with expensive developers.
My remark about programing in C is perfectly valid. Why do the programmers in this forum use PHP instead of C? Because programming in PHP is quicker. It runs slower, but that is outweighed by the speed of development. Why use XSL (or any other templating system) to produce XHTML instead of doing it with PHP? Because once I have bullt up my library of standard templates then I do not have to waste any more time in creating any XHTML output - I simply create an XML file, throw it at a template, and everything is done by magic. The less time I have to spend on generating presentation layer code the more time I have to spend on the important stuff in the business layer.
You seem to think that execution speed is more important than development speed. I am simply saying that I disagree.
Posting Permissions
Bookmarks