WHAT: this is a blog where i collect news about the usage of javascript a serious programming language on the client side and server side. WHY: because it seams to be the most ubiquitous language and has functions as first class objects, and closures and ....

Sunday, June 29, 2008

Rendering, HTML/XML to JSON, JSON to HTML/XML

Why? you could ask. Both XML and JSON have strengths and different origins. XML unstructured texts with some markup, and JSON from describing javascript data structures.

HTML is our 'Rendering Engine Language'
Is it not HTML as mixture of incorrect XML with javascript hooks, CSS linkage the main javascript GUI 'rendering' engine?

Well assume we simply wnat to describe HTML within javascript. Why learn different languages HTML/CSS/Javascript if one would be good enough? Using just javascript could remove the artificial break between the active javascript and the declerative XML.

Well there has been some mapping posts:


Stefan Goesner brought up some good points:

  • JSON has and ordered list of values: arrays, objects as name/value pairs, with unique names. Each value can be an object an array or a literal string, number etc.

  • XML elements have a single set of non named attributes with string values, and has an ordered list of childnodes, wich can be text nodes, and other named child elements.


While the set of attributes could easily be directly mapped to some name/value pairs in JSON, this is not the case with the child nodes. They have an order and a name.
The correct way woud thus be an array to preserve order and within the array we then could put text or object with a name value pair:



<p class="c1 c2 c3" style="border: 3px coral solid;font-size:1.5em">
bla bla
<ul><li>one</li><li>two</li></ul>
bla bla
<input type="button" onclick="alert('click');"/>
</p>


How could we map this to JSON/Javascript like syntax?, we propose using an array where the [0] index contains the attributes, this makes the notation somewhat shorter: Note that XML path uses sets beginning with index 1. So this could maybe justify this decision.


var c1={},c2={},c3={}
json = {p:[{class:[c1,c2,c3],style:{border:[{px:3},'coral','solid'],font:{size:{pt:12}}},
"bla bla",
{ul:[,{li:[,"one"]},{li:[,"two"]} ]},
"bla bla",
{input:[{type:'button'},{onclick: function(){alert('click');}}]}
]}


Is this much sorter or cleaner then XML itself? I'am not convinced. It still looks ike we misused JSON
But what becomes obvious is that HTML is not that clean as XML. Just look at the class attribute and the style stuff. A language within a language encoded in a string.
I just played a bit around and translated the multi value class attribute to an array, and the style css syntax also to a json like syntax.
Look at the java script code linked to the click event, here it is a real function not just a text.

The advantage could be that HTML/CSS/Eventhandling could all be defined and processed in a single language.

Stefan Goessner and others also wantet to keep accessing elements easy. He even used an non bidrectional XML to JSON mapping to keep access easy. p.ul.li.text could deliver 'one'. While this is a nice idea it is hard to keep it that simple if there is a bidrectional general mapping needed. In our mapping we can access both list items:


p[1].ul[1].li[1] = 'one';
p[1].ul[2].li[1] = 'two';


As always with hierachical structures an processsing whe soon have the desire to
access sets of nodes them using query language like XPATH or JSONP or CSS selectors.
Designers are so used to CSS Selectors jQuery was designed around this.

But back to our language description. In the end its all about language and we just introduced a new 'data' language. More on that in the next post.

Why not using this?

p @ class{ c1, c2, c3} , style{ border{ px:3, coral, solid } , font:size:pt:12
{ bla bla,
ul { li:one, li:two }
bla bla
button@onclick:alert('click');
}

A little precompiler could transform this to javascript





JXMLmaps to JSON
X1..Xn"X1..Xn"
X@A1,..,An{E1,..,En} X:[{{A1,..,{An}},{E1},..,{En}]
X:Y:ZX:{Y:Z}


Oh yes now we again left the one language approach :-)

No comments: