Template Engine - Why Bother? XML + XSLT

I am not sure I read the entire recent "war" in the PHP general mailing list about the best PHP Template Engine Option but, generally speaking, this argument is truly loads of solutions and controversial opinions. Here I am with mine.

PHP 5 And In Core DOM, XML and XSLT

Apparently, all these "Smarty adorers" did not consider that PHP 5 introduced a lot of core classes to work over DOM, XML, and transform them via XSL files. Nothing to do, they prefer to move an entire template application rather than use the best native, fast, in core, solution. Here a couple of reasons to generally prefer XML and XSL Transformations rather than whatever engine, specially those written in PHP itself, a not that fast interpreted programming language.

Think Portable

Apparently developers like to be stuck forever in a single programming language, something I cannot even try to consider, since Information Technology means Flexibility and Updates. An extremely valid point to choose XML as output, and XSL as Transformer, is the universality of the XML markup language first, and complete separation between data and business logic from its presentation after.
Something PHP developers often look for, discarding without a valid reason what is already there since ages. Even if the entire website or application programming language will change (performances anybody?), rather than simply take care about how to reproduce the same XML via the new language, they prefer to recreate for each sub-part of the website the code to make that completely new and different template engine work. This becomes even more ridiculous when arguments are like:

if I need php in the middle of the presentation layer, I simply put it there ...

... "good thinking", isn't it?

Think Scalable

First of all, XML can be easily cached without even moving a single database connection. Moreover, having zero dependencies from external engines probably based on the same XML + XSLT concept, could simply make our application faster. XML has thousands of implementations, libraries, and fast parsers, for every kind of programming language and latest dabases could even interact directly with stored XML (or retrieve data directly in XML, did you know that?)
An application that as main intermediate layer has XML will have so many long therms advantages hard to imagine, are you still thinking a foreach inside the layout is a good solution?

Think About Your Career

Ok, I use PHP and I want a template engine that will bring me nothing new to learn, except its own PHP exposed API. And tomorrow, when I'll move into another better structured company, everything about XML, XSL(T), and XPath, will be a non-sense, "'cause I know peeaichpee", isn't it?
If you think you know enough about XML and XSLT and you are not using these layers I bet you do not truly know them or real potentials.
I bet you do not know XPath, you do not know how to generate a valid XHTML/HTML layout, and you do not know XSLT strategies to retrieve only info you want to show and nothing else.
Well, think about this, more enterprise ready stuff, rather than just whoevercanuseit programming language (easy to start, hard to use properly, that's PHP) ... is it an extra plus to at least give them a try?

Extreme Performances? A concrete Example

The New York Times website is using these technologies since ages and it implemented its own XSL Cache Extension in order to obtain best performances with xsl documents. At the same time, XSLT is present in every browser, included Internet Explorer 5 so it is even possible to simply delegate transformation to the client, speeding up even more the server. Here a simple example, based on my "old" JXON proposal.

Do you still think there are so many better options?

JXON - A little update loads of documentation

I have updated my lightweight JXON library right now, lightly improving them, and adding a consistent documentation for each method as well.

At this point, the last thing I could do about JXON, is to talk about what exactly is, and what is not at all.

JXON IS

• An intermediate, well defined, layer between native JavaScript variables, and a generic page content (their representation inside the layout)


• A fast and cross-browser JS to XML, and vice-versa, parser


• A human comprehensive way to represent JavaScript Object Notation via XML using a natural, lightweight, and unambiguous, schema, that will make XSL files creation, manipulation, and maintenance, more clear and natural than ever, working over both XPath, and semantic data types nodes with optional keys for object members


• A simple and crossbrowser global object, with few methods to transform JavaScript raw data into a valid (x)HTML layout page, or portion


• An advanced, XSLT based, enterprise ready way to represent data in a generic browser, with possibility to re-use thousands of time the same XSL file, or choose which one should be loaded for that browser (device browser indipendent)

JXON is NOT

• A JSON parser


• An Ajax library


• A template Engine

Indeed, JXON aim is to be easily integrated inside your library, or your own code.
You do not necessary need a JSON parser, but every famous client library has one, so you can still perform client / server interactions using that parser, if necessary, and putting JXON between the evaluated result, and the layout.
The load method principal aim is to assign the public xml property that will be the JXON XML node you need to transform. This means that you have no options to change both its syncronous nature, or to use them to send POST parameters, it is NOT Ajax, but you can use every kind of library or code to perform these tasks putting JXON, again, between these interactions and your automatically updated layout portion.
Finally, thanks to JXON, you could focus entirely about data, instead of data plus its layout representation, delegating latter task to one of the most related languages to do that: XSL, a dedicated markup template engine transformer.

JXON - In line JavaScript to XSLT Example Page

P.S. Above link uses an object instead of a regular layout, and of course, even if when you look at that extremely light page (1.24 kB without gzip), Google and generally every kind of search engine, is able to read those information.

JXON - Lossless JavaScript to XML Object Notation convertion

It seems to be the time to talk about JavaScript template engines, and DocumentFragments, so here I am with my last idea: a JavaScript XML Object Notation transformer.

Introduction

There are a lot of ways to interact between the client, and the server, in a W3 friendly way, such Ajax, the classic remote scripting, Comet, and last, but not least, and probably first of all, XML. The latter "protocol" is one of the most flexible, compatible, and cross platform one you can find in the IT sector, in a word: universal.
Over XML we are loaded of different standards to transport every kind of data, which one should be compatible with browsers, parsers, and preferably with JavaScript DOM implementation as well.
One of the main limitations I have spotted about XML to JavaScript and vice-versa conversion, is the data type, usually lost, and the prolixity of JavaScript data representation.

JSON is great, but whtat's up if we destroy its nature?

The JavaScript Object Notation model, aka JSON, has been one of the most revolutionary protocol between the browser and server, thanks to its thin nature: completely non-redundant against the open and close XML tag style, that is able to make client server interactions faster than ever.
At the same time, JSON is not only about data transportation, it is about data, and data type transportation, so every server side language can receive an object, an array, and every string, number, date, or null, nested information, and this is great!
Some project aim, is to use JSON notation to transform common (x)HTML data into a JSON string, making things almost useless for daily applications.
As example, JSONML goal is to transport HTML over JSON, loosing a consistent portion of this protocol nature because of redundant informations between the client and the server (JSON aim is to transport data, and not its representation in the generic document).
Other libraries try to convert XML or (x)HTML to JSON, and vice-versa, using attributes like "@class", that make client side code usability close to zero

var info = eval('({"@class":"my-class-name"})');
info.@class // error!!!
info["@class"] ...

As I said, JSON is great, robably the best one, to transport data, not its representation, so, the point is: do we really need to put all those information inside a protocol born to be light and essential?

To loose, or not to loose

A common problem in daily XML to JSON and vice-versa transformation, is the data type. A number, is a number, as an array is an array, but XML data is inevitably stored as a string, so the final result, is that almost every XML to JSON parser maintain XML data representation, but looses original JavaScript object notation. The main purpose of JXON, is to maintain original JavaScript data type, using XML to represent them:

<element>
Boolean = <boolean>true|false</boolean>
Date = <date>YYYY-MM-DDTHH:II:SS</date>
Null = <null/>
Number = <number>N|Z</number>
String = <string>string content</string>
Array = <array><element-list/></array>
Object = <object><element-list key="element-key"/></object>

<element-list> = a list of precedent element

For a better explanation about what I am talking about, next example is a full JXON compatible XML node:

<jxon>
    <array>
        <object>
            <string key="developer">Andrea</string>
            <number key="age">30</number>
            <array key="sites">
                <string>webreflection.blogspot.com</string>
                <string>www.devpro.it</string>
            </array>
        </object>
        <object>
            <string key="developer">Cristian</string>
            <number key="age">24</number>
            <array key="sites">
                <string>mykenta.blogspot.com</string>
            </array>
        </object>
    </array>
</jxon>

Where everything, could be represented in JavaScript, as a developer list, in this way:

[
    {
        developer:"Andrea",
        age:30,
        sites:[
            "webreflection.blogspot.com",
            "www.devpro.it"
        ]
    },{
        developer:"Cristian",
        age:24,
        sites:[
            "mykenta.blogspot.com"
        ]
    }
]

And converted to XML, and vice-versa, with a truly simple, and fast, parser.

JXON transformation? XSLT, of course!

The XSLT language, is (x)HTML dedicated, standard, and supported by a wide range of browsers. XSLT could be based on components, matches and templates for every kind of structure, or could be simply dedicated for a single piece of code.
The main advantage of XSLT, is that an XSL file could be easily cached via browser, or server, but it could be always used in the future, while the only thing that will change will be the data, and not its entire structure representation.
What I mean, if you still wondering them, is that we do not need layout informations inside JSON strings at all, since the only thing that we need, and that could change, is the raw data itself, and nothing else.
JXON goal is to completely separate useful JSON informations, from useless, redundant, pointless, layout informations inside JSON protocol itself, making interactions exremely fast, and XSL files re-usability similar to the same we use daily with CSS, to transport only what we need, and to transform them quickly, and in a W3 recommended way as well.

Not clear enough, yet?

So, as last example, I can directly show you what could be possible to do with JXON, and its cross browser implementation, having a look into this unofficial JXON Example page, where you can directly spot the idea, its implementation, and finally its page source code :geek: