AJAX Patterns: Introducing JavaScriptBeans – Bringing JavaBeans to JavaScript
In software engineering deja vu is called design pattern

Six month ago, Alex Iskold (pictured) switched from J2EE Grid Computing to Web 2.0, JavaScript and Firefox extension development. He has been writing in Web 2.0 Journal about his experiences - see "From J2EE to JavaScript".

Through this transition, I am continuing to have a feeling of deja vu. I write code thinking – 'Hey I've seen this before or I've done this before'. In software engineering deja vu is called 'design pattern.' If there is a good way to do something, we discover it, add it to the patterns catalog and apply it again and again.

I remember being very impressed with elegance and simplicity of JavaBeans framework. This was one of the early naming-convention based patterns introduced by Java designers. The bean pattern was simple, but very powerful; it showed that a simple naming convention can go a long way. Naming conventions fuel automation, lead to reduction of code and save time.  
 
Problem

The application that we are developing at adaptiveblue, is called blueorganizer. It is smart browsing extensions for Firefox, which brings semantics of everyday objects into the browser. Among key concepts of the blueorganizer is the concept of collection. The users are able to collect objects like  books, movies, wines, restaurants or cars from blogs and web pages.
 

Early on we realized that we need to design the blueorganizer in such a way that users do not have to reinstall the extension each time when we roll out new functionality. We were inspired by the way that pure web applications work – the new functionality can be rolled out literally overnight to everyone. We needed the same capability for many aspects of the blueorganizer. Essentially we needed a hybrid between a classic desktop application and a dynamic web site. We accomplished this by bringing JavaBeans to JavaScript.

 
JavaScriptBeans

The idea that we came up with was to have each collection defined in a separate file and loaded via XMLHttpRequest. We also have a master file in the well known location that would list all available collections. At startup, the collections list is fetched and then all collections are loaded one by one. We needed a mechanism for instantiating the collection from the XML file, and thats when we naturally thought about beans.
 

We looked around and found JSON. - a common way for serializing JavaScript objects. JSON is nice and quite popular. It is used for example, by del.icio.us API to stream responses directly to JavaScript clients. But we decided that it would not work for us because it is not easily readable. We wanted a solution where we can describe the configuration of the object using XML file, which would be read in at the run time to construct corresponding JavaScript objects.

 

Here is the simple example of what we had in mind as an input file:

<!--[if !vml]-->



<!--[endif]-->

This should construct JavaScript object of type BasicModel and to set a name property of this object to be 'Books'.

 
Mechanics
 
Recall that in Java the basic deserialization of beans from XML follows a pattern: a tag is processed and complex object is instantiated, then process recurses into children tags instantiating children objects and setting them as bean properties of the parent. When the tag specified a trivial property like integer or a double, the property editors where used as converters to convert the object from string to the specific data type. With JavaScript things are even simpler, since there is no need to convert primitive types.
 

To handle the deserialization we create BeanUtils.js with the following main interface:

 

<!--[if !vml]-->



<!--[endif]-->

That is, the function takes as an input the root element, parent object and the urlBase (we will explain this parameter in a bit) and returns the fully instantiated JavaScript object. Here is the simplified version of our implementation:

 

<!--[if !vml]-->



<!--[endif]-->

This is it in a nutshell, but there is one caveat – in order for eval() to work, the object that is being instantiated needs to be part of the JavaScript files already loaded into the browser. To avoid this limitation, we need to add an instruction to load JavaScript code dynamically. This can be accomplished by using JSAN library, which allows loading a script from a known location.

We can now write code like this:
 

<!--[if !vml]-->



<!--[endif]-->

The import directive implies that specified file needs to be loaded, and so the DynamicValue now can be defined in the DynamicScript.js file. Here is the code that does the import:

 

<!--[if !vml]-->



<!--[endif]-->
Making it flexible

We showed above the basic mechanics of how to load JavaScriptBeans from an XML file. We can now think of other things that would be useful to add to this framework.
 

First, we'd like to have an ability to handle arrays. We can do this in several ways. First, we could require that objects pre-declare all array properties in the constructor like this: myArray = [].

So when the new object is instantiated, the property would set. Then when we are add bean property, we can check and see if it is array and handle it appropriately. Another idea is to specify that a property represents arrays in XML file. This can be accomplished with array=”true” property.

 

Other things that you might want to add include the handling of maps, ability to define variables and referencing them so that you do not need to create more objects than necessary.

 
Conclusion
 
Instantiate JavaScript objects from XML file comes particularly handy when you are developing Mozilla extensions with dynamic behavior. But even if your are doing pure web site applications, using this technique can greatly simplify your configuration and setup process. Beans and naming conventions are good patterns to have under your belt. They were handy in Java and they are still handy in JavaScript.


Don't miss Alex Iskold's blog: http://alexiskold.wordpress.com
About Alex Iskold
Alex Iskold is the Founder and CEO of adaptiveblue (http://www.adaptiveblue.com), where he is developing browser personalization technology. His previous startup, Information Laboratory, created innovative software analysis and visualization tool called Small Worlds. After Information Laboratory was acquired by IBM, Alex worked as the architect of IBM Rational Software Analysis tools. Before starting adaptiveblue, Alex was the Chief Architect at DataSynapse, where he developed GridServer and FabricServer virtualization platforms. He holds M.S. in Computer Science from New York University, where he taught an award-winning software engineering class for undergraduate students. He can be reached at alex.iskold@gmail.com.

In order to post a comment you need to be registered and logged in.

Register | Sign-in

Reader Feedback: Page 1 of 1

Six month ago, Alex Iskold switched from J2EE Grid Computing to Web 2.0, JavaScript and Firefox extension development. He has been writing in Web 2.0 Journal about his experiences - see 'From J2EE to JavaScript.' This is the next instalment...


ADS BY GOOGLE