TypoScript vs XSLT
Lately I was asked a few questions about my opinion on the standardized template technology XSLT/XML. I compiled the essence of my answer into this little article:
Are there reasons why you have chosen <i>not</i> to employ XSL?
First of all, I don't know the technology. Especially i did not know about it when I needed something like TypoScript. As far as I remember the XSL proposals were published in November 1999 which is a little later than TypoScript was born. Anyways I wouldn't have considered a brand new technology until it was more stable and had proved to be useful and supported. At that time there certainly were no significant XSL(T) processors.
But TypoScript is also a concept that fits the PHP/TYPO3 configuration very well although I admit that it has been taken too far in certain areas. TypoScript is basically a large object-like structure of information which can be set from text-files (DB-records...) and the TYPO3 default PHP front-end code just reacts to the settings in TypoScript.
TypoScript was not destined to be a procedural language and it is not today! I prefer to compare it to Windows registration database which - to my knowledge - is a similar bunch of hierarchical configuration.
XSLT vs TypoScript - my comparison
- A XSLT stylesheet transforms XML into something else, eg. HTML or a PDF-file. XSLT could also translate XML to XML if you need a conversion of XML formats. XSLT is a "template" which is given as argument along with the XML file to a XSL processor which converts the XML document to some output based on the content of the XSLT stylesheet
- TypoScript (TS) and XSLT are both "declarative" languages as opposed to "procedural" languages. PHP is procedural - executed from start to finish. TS and XSLT are rather a huge setup of information which can almost be processed in any order.
- XSLT is required to be without side effects which means that you can process any part of the XSLT stylesheet without regard to the order other parts are processed - if they are at all. Side effects simply is if a part of the processing is able to set global variables which other parts of the processing may use. And this is not allowed so therefore you can process XSLT in any order and even process only parts of it!
- TS has side effects to the degree that the TS programmer has chosen to use the so called register to pass values around. Also using PHP scripts with TS has the same consequence: You may set global vars which determine later rendering. But to a certain degree TS is also without side effects! An example is how USER_INT objects are processed. They are stored objects dynamically inserted in cached content and therefore rendered independently of their original context in TypoScript.
- You can escape the built-in functions of xPath in XSLT by calling user defined code written in languages like Java. This is very similar to TS in which you have certain functions available through the TS configuration but can in most cases escape the hard-coded features of TS and process data with a PHP_SCRIPT cObject or better yet, call a user-function or method in a user-class by the USER cObject.
- XSLT is stored in an XML-document. TS is stored in a huge array in PHP in a DOM-like tree with nodes.
- TS special features are conditions which defines if a certain part of the TS configuration is going to be parsed based on some conditions you set. This could be based on client browser, IP number or any user defined result from a function you write yourself.
- TS also features 'copying' of TS configuration which means that you can make TS objects in a temporary space which you copy to other positions in the object tree where you can further override the parent-properties of the objects. I don't know if XSL lets you reuse code like that.
Using XSLT for rendering HTML in TYPO3?
In order for this to make sense, there would need to be a "Typo3ML" XML schema which an XSLT stylesheet is able to process into something useful.
The first problem I see here is, how much information should that XML-file contain? Only the information of the TYPO3 page? Or the whole MySQL database? It's a very inconvenient problem that XSL stylesheets needs all information in the XML file and further that todays XSL processors are able to process only fully loaded XML documents. So basically XML is a poor solution when a SQL database is so much more useful (and scalable) here. And everything is in the SQL database already.
The second problem is that it seems to be awkward to dynamically transform SQL data into XML data which are processed by an XSLT processor into HTML while it would be so much easier to output the HTML directly from TypoScript!
So how can XSLT fit into the TypoScript world?
If you go for XSLT you would still need TypoScript for at least the most basic configuration in order to generate the XML-document needed! This would be a task equalent to making WAP pages with TYPO3.
So for rendering ordinary HTML, I would say XSLT is a too clumsy process. Too much work and too much overhead.
But for rendering a PDF version of a page, XSLT would probably be the most suitable solution, if some XSLT stylesheet for such a conversion is readily available! That would be a cool trick; Making some XML-output (by TypoScript/PHP of course) which conforms with the input specifications of the XSLT-stylesheet which then outputs a nice PDF document! Certainly a good solution. Especially you could imaging programming the XSLT stylesheet with some graphical application like InDesign or whatever package may support development of templates (Framemaker?). Would be a great way to produce printable PDF catalogs from the MySQL database content in TYPO3.
Are you planning XSL support for future releases?
XSL support is as far as I see a question about making XML output from TypoScript/PHP which fits an XSLT stylesheet.
So... no. Not for HTML. But if anybody could point out a useful XSLT for which to write XML output via TS/PHP, surely I would be interested. Especially a way to convert web-data to print-data (eg. PDF).
Please correct me if I have missed some things or if I've incorrectly described how XML/XSLT is working. I had to read a little information about it before I could say anything (hopefully) competent on the matter.
The original conversation was with Joachim Peer.
- kasper
