AjaxLine

Walking on JavaScript objects trees. Can we do it with JSON or JavaScript like we can while we work with XML?

If JavaScript code is written in object oriented way, developer uses instances of objects to manipulate object properties, invoke methods and control objects functionality. However, any object, regardless of the functionality if offers, usually does not exists in vacuum – on the contrary, instances of objects are related and use each other to perform method calling, obtaining and receiving data and so on.

Due to this, casual instance of JavaScript object often contains reference to another JavaScript objects instances and these (or different) instances, may, in turn, include references to that instance.

Taking into consideration this fact, it’s quite easy to imagine some tree of graph of inter-related JavaScript objects exist on runtime.

Of course, as soon as we have objects, we’d like to do something with them (and usually developers write code which performs various manipulations over JavaScript objects).

While there are many custom algorithms and manipulations, which can be need (at least, we are talking about the logic which makes your page unique), there are still many common, repetitive but necessary tasks which are performed as part of everyday development activity.

For example, data copying, populating, validating, merging objects data and so on. They are not fun, but they are really should be performed to bring your application to life.

Sure thing, each operation and each piece of code that does something with object instance can be considered as something unique and exceptional one. The only drawback of this – lots of quite boring, stupid and error-prone code occurs.

Ok, but what could be done to eliminate that? Oh, let’s think about it… But first try to look at the JavaScript objects from another point of view.

What is JavaScript object? Well, the question answers itself – it’s object. Object is the foundation of Object-Oriented programming and contains data with methods which allow performing manipulations over these data.  Let’s try to concentrate on the first part of “object” form definition – data. Do we know something similar to this (please note that we don’t consider single instance of object there – but the entire object graph)? Yes, surprisingly, XML (or rather abstraction of data storing in XML) is quite close.

Let’s think about XML – what it is? Is it just a plain text, data format or tree of objects which store the same data as original text? What if we consider the tree of JavaScript object as object model for some data? We have DOM (document object model) for XML (or HTML, it doesn’t matter), so we could have our own, custom object model based on JavaScript objects (and JSON is quite close to this).

Ok, we are close so far but it’s not clear how we can simplify writing common repetitive code which, for example, populates HTML form by underlying model represented by tree of JavaScript objects (mind the JSON!)?

It seems that answer is quite simple – we should have some uniform way to access elements of objects tree, to traverse and lookup individual components of the object graph, and to be able to perform operations over particular object instance. Oh, and of course, we don’t want to write that code – we agree just to write code which is salt of our application, not other mess, right?

Let’s return to XML. We can utilize one of two common technologies if we want to parse or transform XML element – either SAX (simple API to XML) or DOM (document object model) based approach.

In both cases, XML parser makes for us all dirty work of parsing initial XML (reading incoming streams, manipulating characters, insuring proper string encoding) and so on. DOM parser provides us in-memory presentation of original XML as set of objects with well defined interface, while SAX let us obtain information about XML via  set of events (like element start, element stop etc) generated by SAX parser via appropriate callbacks we provide to it.

So, if we have such functionality for XML, and XML is used to store data, and JavaScript objects are used to store data – why can’t we use similar approach to work with JavaScript objects?

The correct answer to this question – surely we can and moreover, there is an open source JavaScript library which offers us API to traverse and access trees of JavaScript object in uniform way.

That library is developed by Alexey Luchkovsky and is called JSONER (originated from JSON supportER). It provides event based model (which ideologically is similar to SAX) to process arbitrary tree of JavaScript objects.

An event-based API reports parsing events (such as the start and end of JSON node) directly to the application through callbacks.  In both  cases, an event-based API provides simpler, lower-level and uniform access to data structure represented by JavaScript objects.

Unlike SAX, which is not applicable for changing data, JSON event-based API can be used not only to get unified access to JavaScript objects, but also to manipulate them (for example, by changing particular attributes or even changing structure) since it works with complete objects stored in memory.

Since JSONER performs all behind-the-scene operations necessary to traverse elements of objects graph, developer is free from it and needs to write code that performs only particular specific functions. That code is placed to appropriate callback function which will be invoked by JSONER.

Basically, the JSONER event-based API allows having a standard approach for solving different tasks, such as (just to name a few):

• Filling HTML form by JavaScript model and, on the  contrary, extra data from HTML form and store them back in JavaScript data;
• Comparison  graphs of object;
• Cloning /merging graphs of objects;
• Lookup and searching for  data in arbitrary graph of objects;
• Modification of exiting object;
• Building elements of UI based on JSON object;
• Transforming data stored in JavaScript objects to maps, XML, HTML and so on;
• Serialization of  the entire tree of JavaScript objects tree to string which can be sent to the server and later back to the client to restore saved state (yes it is)
  

In general, having unified algorithm of working with objects allows simplifying code and separate business logic required to implement specific tasks and, as result, to increase overall code flexibility.

However, it’s not necessary to write custom code for such tasks as, for example, data lookup, binding, comparing and many other – JSONER already includes ready-to-use implementation of various widely used algorithms.

By the way, one can said – wait, it’s not honest to compare data in XML with data in JavaScript! While it’s not possible to make some cross-links or cross-relations between elements in XML, it’s quite fine (and often necessary) to have them in JavaScript (in other words, object A has reference to object B and object B refers A).

Yes, that’s true. But if JSONER library handles cross-links correctly – should we really think about this too much?

And wait again, the name JSONER originated from JSON – so why do we talk about generic JavaScript objects and don’t mention JSON too much? The answer is clear – if we can handle custom JavaScript objects, JSON is just a simplified case.

Well, definitely, such a way to work with objects is different. But it is up to you to give it a chance,  to cast a glance at it (come and see live JSONER there) and decide whether it helps you to be more productive, have more fun and more free time!

Oh, and finally, JSONER is free and opensource - so it's naturally that you can find that project on SourceForge!