Latest: Express.js Route Middleware

Content with Style

Web Technique

XML as intermediate application layer

by Pascal Opitz on May 31 2005, 08:37

Why bothering?

Dealing with any server-side scripting language the things that I find most annyoing are the ones where I have to change
echo '<a href="' . $url . '">' . $text . '</a><br />';
to something like
echo '<li><a href="' . $url . '">' . $text . '</a></li>';

It's always a waste of time, and often, due to some typo, errors sneak in and suddenly you're debugging again.

In this article I want to share my thoughts on techniques for keeping our code XML-based - so there's no need to get your hands dirty in your application code to change the markup that is rendered afterwards. Most things will be PHP related though.

Other benefits

Once we get the seperation working properly, we can completely detach the development of front end from the application logic by first agreeing on an XML scheme to exchange data between those two.

By providing dummy XML to the guy doing the XHTML and CSS he can flesh everything out and then put it into an XSLT. Even before the application is built he can have finished everything... Then to get up and running, just the XSLT files, images and CSS need to be dropped in. Good to go.

By keeping the dataflow of the application logic stricly XML compliant we also have no problems using the same code for outputting a different version, to mobile devices, for example, OR to swap the data-source with an external web-service.

And did I mention that suddenly you can work with UTF-8 throughout the whole application and the XSLT automatically transforms it into the needed output format? You just need the right parser.

On top of all that, we are using a w3c technique and have the ability to render tree structures and stuff...

A 5 layer approach

The 3 layer paradigm has been around for a while and most of you probably are familliar with it.

I mostly agree but for our needs, just half of the job is covered. That's why I want to extend it into a 5 layer approach.

5 layer approach

Planning your application

First of all you obviously need to flesh out what the application does etc. and which part does what.

We should also take care of the platform that we'll be developing for, to avoid facing the worst of all situations: having to throw the whole goddam thing in the bin and start from scratch.

Then, like I already mentioned, we can work out the output XML structure and pass it on to the front end developer. As soon as that's done we can move on to plan the code for our application.

Structuring the application code

Now that we know what needs to be done we can assemble a robust set of classes, either the PEAR ones or custom ones (I tend to use custom ones) that perform several actions for us:

General DB class
A class that gives us easy access to our database and returns resultsets or arrays, manages updates and inserts and explains tables and all that ...
If you're working with several database-types I'd recommend to make use of ADO in ASP, and there is an ADODB toolkit for PHP as well.
Database output to XML
It's a very simple thing, but it makes life very comfortable. I use my own one in PHP, but there is a PEAR class for this as well.
XSLT transformation class
This class should manage to process XML input by using XSL files. And again, there is a PEAR class for doing this.

Obviously it's down to the developer to add more classes for specific problems, but once we have gathered our basic toolkit we can think about ways to transform things easily.

Class based application

I highly recommend taking a big big step back from procedural scripting. Instead you can work out a class structure and write rendering methods for either the page or parts of the page. Again, classes are robust and reusable. If you are unfamiliar with OOP in PHP, make yourself familiar with it ASAP.

PHP - output buffering

And here comes one of the nicest ideas ever.

I think that output buffering is a handy thing anyway. And there are many ways to benefit from it. But the coolest feature though is the callback function.

Instead of having a method called by something to finally get the XHTML out of our application, we just process the whole output generated in PHP with this single callback funtion. Some flags can trigger which XSLT to use.

And there we are, we have a strictly XML based internal dataflow, but rendered HTML in the output.


I hope everyone sees the point of my approach and how you can work out a robust application. I also hope everyone understands why I didn't provide much code this time, since it would be quite a lot of code and still be platform specific.

Using output buffering may seem a bit like a loss of control, since you cannot pass parameters to the callback function, but it makes sense to just call one XSL and, similar to use @import in CSS, include XSL files for patricular elements. How to do that will be the next topic, so stay tuned.


  • Interesting concept.

    Perhaps I’m being obtuse, but what would be the advantage of this approach over a template system like Smarty for example?

    by Adam Thody on May 23 2005, 19:35 - #

  • Nice article. I use a similar approach for my developments and I love how everything is neatly compartmented.
    When appropriate, I even move XML and XSLT to the client. It trims down on server access and allows for more responsive and faster apps. Of course it’s not supported by all browsers.

    Adam: I don’t know Smarty, but XSLT is a W3C standard.. That count for something.

    NB: Your comment form is stressing me out… I thought my caps-lock was broken or something.

    by Cedric on May 23 2005, 20:49 - #

  • @Adam:
    I’m not sure about Smarty, since I never bothered to use it, but XML leaves definetly more and as Cedric pointed out, standard compliant opportunies.
    For example could the XML directly be used as feed for web services.
    Also, with developing the frontend using a dummy XML and writing the XSL by testing it on the client, the swap is incredibly easy afterwards. No need to take HTML-templates apart and put in smarty placeholders … Point?

    Thanks, yeah, I see your point and I wish I could go for that, but since especially accessible applications demand markup that screenreaders and lynx can digest I’ll do it on the server … ... If I know it’ll be IE 6 with MSXML I do stuff like my XML Editor in pure JS …

    think that’s better now

    by Pascal Opitz on May 23 2005, 23:28 - #

  • From what little I’ve seen of Smarty, there’s an awful lot in there that you’re never going to use. I was looking to use it quite recently but decided that the added overhead (mental, as much as processor) was just too great and sacked it off in favour of a custom, lightweight approach. That said, I know people who swear by it so I guess it’s whatever suits you and your project best…

    by Mike Stenhouse on May 25 2005, 01:27 - #

  • Smarty is the worst. Not only do I have to learn a templating format, I am forced to use a propriety standard and that is something I am not ok with.

    In addition, XML and XSLT can be used to provide accessibility for other devices with little to no code changes, so it extremely flexible, unlike Smarty.

    Plus, as someone mentioned above Smarty is terribily bloated and you probably won’t even use half of its “features”.

    by Ian Gordon on May 27 2005, 00:11 - #

  • All this sounds fine and dandy but unless you can run the xslt transformations on the client then arent you adding processing overheads?

    Surely PHP based templates are the most effective methods. I’ve followed the arguements on templating engines and come to the conclusion that they are mostly pointless (since php makes a fine template language).

    The one advantage of systems like smarty over php is they enforce discipline so nasty php code that shouldn’t be in the template can’t be in the template.

    Also adding smarty/xslt/xml to the mix adds further complexly and the requirement to know additional markup/code.

    My final issue is 5 layers adds to the number of files to think about when trying to nail down an problem. I already find this an anoyance with the MVC system I have in place and 5 layers sound like they will increase the problem.

    Phew thats a large post but I am interested to see what you think of my view and to learn of any possible improvements I can make to my MVC code

    by Ben on June 3 2005, 04:49 - #

  • Hey Ben. I don’t really know if and how much XSLT with e.g. Sablotron
    increases the processing load on the server. But even if it increases it, I’d trade that against a flexible layer that afterwards can be processed into anything.
    If it became a serious issue for the server to handle it i’d say just cache the XML or even better, the whole page :)
    Also let me point out that with XML as application layer you can use one XML output and transform it for each targeted platform.

    It would be interesting to get a Benchmark on how much the processign load and execution time are increased by stuff like that. Anyone got some links?

    by Pascal Opitz on June 3 2005, 18:42 - #

  • Hi, I totaly agree with you, and if my host supported XSLT conversions(server-side) I would be far on my way. Though, this also have it’s problem, as you would have to come up with a standardized way of making your XML, as making new XSLT for every project you do might be a little tedious and I’ve never had a project where I had time to do this.

    by taare on June 5 2005, 02:04 - #

  • With MSXML and .NET’s XSLT implementations (don’t know about other ones unfortunately) you can cache a compiled version of the XSLT.

    In ASP you use the XSLTProcessor and you can put the compiled version into an Application variable, for example. With .NET’s version you have much more power e.g. putting it into the Cache object and setting a dependency on itself so if you update the XSL you don’t have to reset the web server or invalidate the cache manually through admin scripts like you would with ASP.

    This helps with performance. (The idea is similar to using Stored Procedures or parameterized SQL queries, so the compiled statements can be cached internally, etc.)

    by Anup Shah on June 16 2005, 14:32 - #

  • Thanks Anup for flagging that up.

    Also I had a chat with Matthias who spotted that there is a little discussion going on on a couple of sites that goes like “XSLT vs Smarty”.
    I already made my point on that earlier, but one thing I forgot to mention: Smarty or any PHP templating language is PHP only, XSLT is multi-platform and nearly every up-to-date language offers an XSLT processor.

    Means that, if you’re forced to port your project, you can still keep the XSLs …
    Also your skills (I guess it’s more than a five minute job to “learn” Smarty) are presistant troughout all platforms and languages. That’s where I see a major benefit in using w3c techniques.

    by Pascal Opitz on June 16 2005, 17:40 - #

  • Pascal,

    I forgot I posted to this some time ago, and never saw your reply, but your point about keeping the XSL skills when you port is very important, I think.

    In fact, my personal site for 8 years has been ASP (glueing a 99% XML/XSL driven content). I have finally decided to port to PHP, and you are right (and that is what I hoped too!) that it is not as much work as needed.

    Not finished porting yet, but my XSLs hardly changed at all (the main problem being with ASP (and ASP.NET) you can pass XML Nodes as XSLT parameters, but with PHP 5 it seems you cannot. But that was not a major issue for me anyway, as I simply inserted the nodes into the XML anyway.

    by Anup Shah on July 28 2006, 08:51 - #

  • As far as I know, a problem with XSLT approach is the designing part—I haven’t seen a WYSIWYG editor that would let you see a rendered HTML/CSS result before you run the transformation. However, using a template such as PHPTAL does.

    If there’s an editor that would do that, I’d like to know what it is.

    P.S. It would be good to see in which year posts were made.

    by Victor on March 10 2008, 19:58 - #

  • I just read this again, after a long long time. It's coming to my 6th year in London soon, and even for me "Why bothering" is a funny funny headline. I can understand why my partner accuses me of overusing the progressive.

    by Pascal Opitz on December 13 2008, 17:44 - #

  • This helps with performance. (The idea is similar to using Stored Procedures or parameterized SQL queries, so the compiled statements can be cached internally, etc.)

    by amber jewellery on March 20 2009, 10:31 - #

Leave your comment

Comments are moderated.
Tags allowed: a, strong, em, code, ul, ol, li, q, blockquote, br, p