JSON, JSONT, and my take on them

JSON is cool stuff. Basically, there's no faster way to feed structured data to your browser. The arrangement is simple. The browser is really good at interpretting javascript, so we arrange to send it a literal javascript object in source code form. On the browser, it's an eval() and two parenthesis to a perfectly formed data structure. Naturally, we can save lots of server effort by delivering json to the browser as much as possible, and offloading the rendering gunk into javascript.

Maybe you can tell I'm headed into AJAX territory. Well, actually, I'm collecting parts for a framework I intend to call "Borax". So far, it's quite small, but I want to let it grow organically and see how far it gets.

So anyway, some genious by the name of Stefan Goessner came up with the brilliant idea to let you write a rules-engine based, essentially, on css-like selectors for parts of a potentially complicated JSON object. (Actually, that term is reduntant. JSO should read "JavaScript Object".) The rules are written in JSON, so he called this tactic jsonT, reminiscent of XSLT, which uses XML to transform XML.

If what you want is a document at the end, then jsonT is great. I've used it and liked it. I cannot recommend it highly enough for the generally simple case of turning a JSO into some text or HTML which you will then stuff into a document via something like the innerHTML property of a DOM node.

JsonT has also given me a few ideas.

I'd like to separate the object-tree-walking behavior, the rule matching behavior, and the rule execution behavior. Here's why:

The way jsonT is currently written, your basic default result is a text document. If you wish instead to produce a tree of DOM nodes based on the semantic content of your JSO, then all that string conversion and concatenation in the standard jsonT function gets in the way. It's hard to develop toward your goal incrementally. In this case, we want to change how subtrees are combined in general, and that means hacking up jsonT to produce a version that doesn't constantly lean toward strings.

Note that much of the behavior remains the same in both versions. If I had the parts in a separate and composable form, I could construct a new part that let me create DOM trees with less incremental effort. Of course, getting there is rather difficult in the short run. The jsonT code is rather dense, and I'm not really that great with JS as it is.

We'll see what happens.