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:
