XML as intermediate application layer
by Pascal Opitz on May 31 2005, 08:37
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.
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.
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.
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.