So after several days of adding to a JavaScript Coding Standards document explaining Design Patterns at my most recent job, it got me to thinking ‘how can I protect the code yet not loose any flexibility that the Module Pattern provides?‘ It’s one of those problems you think about when you go to sleep and are still going at it when you awake at sunrise and stubbornly refuse to get up despite your brain saying ‘get at it lad’ just to add to the encouragement from your bladder. Like many problems you fiddle about with code constantly hitting F5 in your browser as your brain goes into overdrive as it is fully convinced this has to be possible!  Then the solution hits you and you exclaim to yourself ‘man that’s so f’ing obvious and simple what was I thinking!!‘.  The solution is wrap your singleton in an anonymous function – duh! So here you go enjoy:

(function(){

	var myApp =function(){
		//add your application code here as you normally would
	}();

}());

Yes its that simple!  In essence wrap your application in an anonymous function.  So long as all of your child classes within myApp reference myApp.whatever then no problem.  Give it a try then hit your page with Firebug or any other dev tool and look in vain for myApp, you will not find it.

But this introduces a problem.  Your busy working on your highly complex web app and you need to be able to do console.log statements to my app. Well no problem:

(function(){

	var DEBUG = true,

	var myApp =function(){
		//add your application code here as you normally would
	}();

	if(DEBUG){
		window.MyApp=myApp
	}
}());

Now you can debug to your hearts content and when ready for the big release set your DEBUG switch to false.  So now the next issue, ‘ya that’s all very nice Keith but I NEED to expose some of my methods for consumption by 3rd parties‘.  Again very simple:

(function(){

	var DEBUG = true,
	EXPOSED_NS = 'ForTheCosumer';

	var myApp =function(){
		//add your application code here as you normally would
		return {
			DoSomething 	: function(){},
			DoSomethingElse : function(){}
		}
	}();

	// expose my public methods
	window[EXPOSED_NS]={
		doSomething 	: myApp.DoSomething,
		doSomethingElse	: myApp.DoSomethingElse
	};

	if(DEBUG){
		window.MyApp=myApp
	}
}());

So thats about all there is to it.  In my next post I will deal with another contentious issue with the Module Pattern. Code segmentation into separate files and how to get them into your now hidden application.

Cheers

Keith

Since I am very evidently sticking my nose out I had best explain ‘What is Elegence?’ In terms of a JS implementation the object model should provide for an obvious segmentation of functional areas that reflect their purpose and the interface itself.  Having an overly flattened object model simply makes it confusing for developers to inherit the code base and work with it.  I usually layout my base class with the following structure. 

• .ui
  Contains all of the components that make up the base interface.  Most often this a direct pointer to the created viewport.
• .user
  The user class holds the context of the currently logged in user and any methods for login, logout, options etc.  It will contain interface components/methods but most often these are modal dialog in nature so do not impact on UI. The user class should also provide for permission methods.
• .remote
  The remote class is most often a function and is in charge of ALL remote calls whenever possible.  It is important that an attempt be made to push all of your remote REST calls or any server requests through a single point of entry/exit.  In some cases this is not possible, for example with a tree control or with a panel with autoLoad set, but these are special circumstances.
• .component
  The component object is a holder for specific component objects that your interface supports. It relies on both ui and user classes.  Often I have a common or core subclass within component that provides for common functionality that is shared amongst components.
• .util
  A catch all class for methods that support all the other primary classes.
• .config
  I flip flop on this one frequently.  The config object is used to store configuration objects that are commonly used throughout the application.  For example default panel configs that are applied with Ext.applyIf within functions.  I flip/flop on this one because with it being exposed it opens opportunity for nosey hackers to fiddle with it and introduce behaviors.

In many cases I see very large flattened object models and exposed components because for some very bizarre reason people have not picked up on the ref property of a container config in ExtJS.  Ref is your best friend and simplifies your life.  As you may well know one of the major challenges in ExtJS or any JS application is maintaining a reference to that object you just created.  Sometimes we drop in our on ID so that we can use Ext.getCmp(‘thatDangObject’) or pre-create a id with Ext.id, add it to the config and store the id somewhere for later retrieval.  Well by using the ref function you do not need to.  For example let’s look at a standard 3 panel viewport with a North, South, Center layout. 

First off you will note __root.ui, __root is a reference to the base class of the application but I will get to that a little later.  For now you can assume that myapp.ui is now a pointer to the created ExtJS viewport object.  If you were to use FireBug and look at myapp.ui within the DOM explorer you would see under myapp.ui, _panelNorth, _panelWest and _panelCenter.  A quick comment, if you have not heard of Firebug stop reading this article, get it, learn how to use then by all means come back and read the rest. A note about my use of the underscore in the ref property.  I use this for two reasons.  One, I know that the ref name I come up with will NOT conflict with any ExtJS property and more importantly they show at the top of the list in the DOM explorer when expanding the object. 

__root.ui= new Ext.Viewport({
layout: 'border',
items: [
{region:’north’, ref:’_panelNorth’},
{region:’west:’, ref:’_panelWest’},
{region:’center’,ref:’_panelCenter’}
]});

With ref one of the very spectacular things you can do is move it up the object hierarchy by the use of ‘..\’. So for example if I had a tbar in the _panelNorth and I want to have it exist within the DOM hierarchy directly under myapp.ui I could add in ref:’..\_topTbar’ in the tbar config within the north panel.  There are cases you may want to do this but remember if you do then you loose your logical object flow in your code which means as a result you had better name it something very logical.  For example really which is better of the below two: 

                myapp.ui._panelNorth._topToolBar
                myapp.ui._panelNorthTopToolBar 

Personally I prefer the first case because that little ol’ dot tells me something directly where as in the later example I am trusting the name to indicate it.  I will defer to dot whenever I can! 

‘Dude it’s an object no need to wrap it more’, this is one of my favorite issues I see in ExtJS development.  Creating components that wrap ExtJS components because of the need to track some aspect of that component.  It is kind of akin to that annoying Uncle who thought it was cute to wrap a small present inside a big box that was also wrapped.  It’s not funny and it just adds waste!  Waste is the important word here.  Not only are you wasting time but you’re wasting memory and my time while I try to figure out what the hell you are trying to do.  You can add anything to an ExtJS config object and it will show up as part of that object.  Take for example the following panel config: 

__root.ui._panelCenter.add({
	xtype:’panel’,
	ref:’_panelForSomething’,
	_myProperty1:’abc’,
	_myProperty2:’def’,
	_myMethod:function(){callmyprivateMethod(this)}
})

Now when I want to get to _myProperty in this added panel I can simply say myapp.ui._panelCenter._panelForSomething._myProperty1 and I get abc.  What I often see is the reverse where a class has been created that contains the control and a lot of extra code expended to make available certain properties/methods of the container available for consumption.  If you are comfortable with the security issues of this then make use of that ExtJS object.  There is a reason they have the functions Ext.apply and Ext.applyIf, read up on them as they are another best friend of ExtJS development.  A small comment on the use of underscore!  I realize and recognize that this is not a recommended implementation according to Mr. Crockford but I would argue this point with him with some zealousness and perhaps a slight grin on my face that I am arguing with Douglas Crockford! 

I mentioned the term security and this leads me to my next point. Not everything needs to be a publicly accessible method or property. Object scope is an incredibly important aspect of any complex application design and making EVERYTHING scoped at the object level is just asking for some pimple faced annoying genius kid to go nutty on your application in Firebug and post it up to the world in some sense of accomplishment over your lack of thinking!  This is where ‘design patterns’ come in, there are many, most notably Douglas Crockford’s. It is Crockford’s implementation that is used witin ExtJS for components. I could probably dedicate an entire book or a least a lengthy blog post to JS design patterns for the purposes of this discussion I will outline two that I use primarily.  The first is a basic class that one instance of will be created for the purpose of service the application. 

function myClass(scope){

	// private variables
	var _me = this;			// internal reference
	var __root = scope		// constructor reference
	var pTermLength = null		// exposed property

	// private methods
	function doSomething(){};

	// shared methods
	function pIAmASharedMethod(){};

	// shared property setters/getters
	function pSetTermLength(v){pTermLength=v};
	function pSetTermLength(){return pTermLength};

	// public methods/properties
	this.doSomething=pIAmASharedMethod;
	this.getTermLength=pGetTermLength;
	this.setTermLength=pSetTermLength;
	this.letItAllHangOut=new Number(1)
}

Notice that in this class we only have 3 exposed or public methods and one exposed variable name.  I like to have my public methods point to private functions.  This allows for internal/private functions to call them directly without the use of the this reserved word.  It also means that your exposed methods and properties are simply pointers.  When using this style of implementation it is important that you come to a consistent naming convention on the function and variable declarations. With regards to variables the basic rule of thumb is you should not let them hang out there publicly but rather create public setter and getter methods.  If the variable has a direct impact on the behavior of the class and typing is important then don’t just let it hang out there for consumption and override. Using a getter/setter implementation allows for you to check type and value scope of the var before fubarring your class.  Now I will fall back to Mr. Crockford and his implementation which is slightly different and serves a different purpose.  Remember the above example is for a class that will behave more like a singleton. ‘Why not a singleton’ you ask, well I will get to that next.  Mr. Cockford would say the above implementation should be done thus: 

function myClass(scope){

	// private variables
	var _me = this;			// internal reference
	var __root = scope		// constructor reference
	var pTermLength = null	// exposed property

	// private methods
	function doSomething(){};

	// shared methods
	function pIAmASharedMethod(){};

	// shared property setters/getters
	function pSetTermLength(v){pTermLength=v};
	function pSetTermLength(){return pTermLength};

	// public methods/properties
	return {
		doSomething : pIAmASharedMethod,
		getTermLength : pGetTermLength,
		setTermLength : pSetTermLength,
		letItAllHangOut : new Number(1)
	};
}

Note that in this case that when creating an instance of the class it returns an object which in essence does the same thing as the earlier class.  The difference is that the return statement returns an object which is in essence a singleton or in this case a singleton expressing the instance of the object.  My problem is that a singleton implementation is extremely limiting in its internal scope referencing.  You must follow the object convention of using commas and can NOT have locally scoped variables within the return object.  The argument would be that you should not have locally scoped variables within the returned object but I feel that is limiting.  This leads me to the second style of class implementation and for this let’s try and use a real world example to show why.  Let’s assume we have an application with a standard viewport.  On the left is a tree in which a bunch of users are listed.  In the center panel we have a tabpanel implementation.  When the user selects a user in the tree we have to create a new tab panel for that user.  Obviously then we are going to have a class that manages the interface for the selected user in the tab panel.  In Mr. Crockford’s implementation we would have a class which we would create an instance of and part of its initialization would be to create the interface.  Problem here though is we now have to write a bunch of code to manage the instances of user we have created.  Where should that code go then within are architecture?  Logically it should go in the user class itself but that class is only designed to manage an instance of a user not instances. 

Remember way back in this article I had a child class of off base entitled component.  Well this is where out component would go.  Let’s look at the code for our user class that manages multiple instances: 

function myClass(scope){

	// private variables
	var _me = this;			// internal reference
	var __root = scope		// constructor reference
	var pTermLength = null	// exposed property
	var instances=[];

	// private methods
	function doSomething(){};
	function createInterface(instance){
		// create the interface for the instance and store
		instances.push(__root.ui.center.add(instance.config))
	}

	// shared methods
	function pIAmASharedMethod(instance){};
	function pcloseAllUsers(){
		Ext.each(instances,function(o){
			__root.ui.center.hideTabPanel(o.id)
		})
	}

	// shared property setters/getters
	function pSetTermLength(v){pTermLength=v};
	function pSetTermLength(){return pTermLength};

	// public methods
	this.closeAllUsers=

	// start component
	this.component=function(config){
		var _me=this;				// pointer to this instance
		var myTermLength=1			// local instance variable

		function initialize(){
			createInterface(_me)
		};
		this.config=config
		this.doSomething = function(){pIAmASharedMethod(_me)},
		this.getGlobalTermLength = function(){return pGetTermLength()},
		this.setGlobalTermLength = function(v){pSetTermLength(v)},
		this.getTermLength=function(){return myTermLength},
		this.setTermLength=function(v){myTermLength=v}
		this.letItAllHangOut = new Number(1)		

		// init instance
		initialize();

		return _me;
	}; //-> end component
}

Notice a couple of things: 

1. Initially we created a single instance of this class with myapp.component.user=new myClass(this) where this is a pointer to the root of our application myapp.  This means that the class can now get to any of our child classes, such as ui via the locally scoped variable __root.
2. When we want to create a new user interface we call new myapp.component.user.component({some config})
3. The component creates a locally scoped variable entitled _me that points to its self. On creation the internal initialize function is called which in turn calls the base class createInterface function and passes an instance of its self.
4. Since createInterface is passed a pointer to the instance and instance has a public property that points to the passed config our createInterface method in the base class can now say create the tab panel using the passed instance.config.  The createInterface stores a pointer to it in a LOCALLY scoped array.
5. When creating the component it returns a reference to itself for further manipulation.

Now a couple of other things.  Let’s assume that the config we pass to the component creation contains a ref value, for example it is set to ‘userABC’. Now if we want to get to it publicly through our object hierarchy it would be myapp.ui._panelCenter.userABC.  This of course would only get us to the ExtJS component.  Now is where things can get a bit confusing and there are several approaches you can use depending on your requirement. 

For arguments sake let’s assume you want to be able to get to that control directly then you could do this.  Remember you can add anything to that config! 

// start component
	this.component=function(config){
		var _me=this;				// pointer to this instance
		var myTermLength=1			// local instance variable

		function initialize(){
			createInterface(_me)
		};
		this.config=config
		config._doSomething = function(){pIAmASharedMethod(_me)},
		config._getGlobalTermLength = function(){return pGetTermLength()},
		config._setGlobalTermLength = function(v){pSetTermLength(v)},
		config._getTermLength=function(){return myTermLength},
		config._setTermLength=function(v){myTermLength=v}
		config._letItAllHangOut = new Number(1)		

		// init instance
		initialize(config)
	}; //-> end component

Now we have added our public component methods as part of the config of the ExtJS object.  So now I can say myapp.ui._panelCenter.userABC._doSomething() 

The advantage of doing this is of course the base user class when enumerating through its array of component instances can access each of the public methods of each since they are part of the ExtJS component. 

How you decide to implement these types of components comes down to what your needs are.  Questions such as does this need to be accessible from other classes, what are the security risks of being public exposed, do I need a component or will a singleton do?  Should my controller base class provide all the functionality needed? 

In my next post I will discuss the overuse of Ext.extend and Observable. When to use it and when to not use it. 

One last thing to think on… config.instance=_me!!  Now you’re going down the rabbit hole and saying to yourself ‘I should have taken the blue pill’  Try it and see what you see in Firebug DOM J 

Until then….cheers 

Keith Chadwick

Imagine you have just been handed an existing web site to do some upgrades.   You are tasked with modifying some dialog style interfaces on the site and adding some new fields to the user form. As you start to scour through the server side code and the front end html you finally dig up an onclick event something like createDialogInterfaceForm(this) bound to an HTML element.  Great you say, now you start digging through all of the JS looking for this magical function that you have found appears all over the site.  When you finally find it you discover it and it has a tonne of internal branches based on the caller which then call other functions.  Great you say, this function is used all over the place so making any modifications will result in me having to retest everywhere, so much for an easy fix. Now imagine instead, you see something like site.ui.dialog.user and to your astonishment there is only one single JS file for the site.  Hmm, you say cool. So upon opening the single JS file you are presented with the following:

var site={
      // some code
      ui:{
            dialog:{
                  user:function(){
                        var dialog=site.ui.oDialog({width:600,height:400})
                        dialog.addControl({type:’textbox’,label:’Name’)
                        // do a bunch of stuff
                        dialog.show()
                  },
                  company:function(){
                        var dialog=site.ui.oDialog({width:400,height:300})
                        dialog.addControl({type:’textbox’,label:’Name’)
                        dialog.show()
                  },
                  oDialog:function(oConfig){
                        return new dialog{oConfig}
                        function dialog(configObject){
                              this.width=500;
                              this.height=300;
                              this.show=function(){}
                              this.addControl=function(oConfig){}
                              // do a bunch of stuff
                        }
                  } // end oDialog 
            } // end dialog
      } // end ui
} // end site

Wow you say this looks complex but as you start to break it down it become apparent that it is actually fairly simple and rather convenient.  For starters all of the sites JavaScript exists within the Singleton called site. Within the site object there is a sub class entitled ui, and within that class there are several methods, user, company and oDialog.  Notice that  the oDialog method returns an object of type dialog.  Also notice that it takes a variable entitled oConfig. This in turn is an object itself which is passed to provide parameters/defaults to the class/object dialog.  What is important to note in this style of implementation is that both the user and company methods of ui rely on the common class oDialog.  It is also abundantly clear that each of the two methods in essence do the same thing but pass different config objects to the oDialog method which returns an object which is assigned to a local variable.  Notice also that since the local variable dialog in both user and company is an object it also provides methods for adding controls to the dialog before it is shown.  Wow you say to yourself, all I have to do then to add the necessary field is a single line of code in the user method.  This is of course pseudo code, but by using a singleton implementation it becomes much more evident how and where you would do you work.  Also, it allows for the simple addition of methods within a logical class structure rather than writing individual functions and struggling for a name that is evident.  In essence it’s all about elegance that provides clarity and manageability of code.  I feel that elegance is something that is sorely missing in web code these days.  When I look at what is served up by server side implementations like .NET and Java/JSP all I see is a massive jumble of poorly formatted html and script tags all over the place.  The argument is ‘well who cares it works’.  Well I care and think there is no excuse for lousy resulting source code.

So what does a singleton provide you:

1. Elegence in code
2. Greater maintainability
3. More obvious method calls
4. A clear object structure that reflects the site structure in many cases

You may be saying at this point that this may be cool but wouldn’t I just end up with a massive single piece of code and even code that I do not need for a specific page.  Well you would be correct in that assertion.  So in the next post I will discuss how to separate your singleton code out into individual class files and load on demand into the master singleton.

Regards
Keith Chadwick

This is a long story but it’s necessary for everyone to see it in its entirety since the aforementioned blog was taken down.  In May 2008 I plopped down 25K, yes Twenty Five Thousand Dollars, on a new home being built by Mattamy in Kanata.  In early August we got a letter from them stating that construction had been delayed due to permit issues with the city of Ottawa and the province of Ontario.  By the way our original closing date was March 3^rd 2009, if memory serves me correctly.  Upon receiving the letter I of course immediately called Mattamy for further information from their sales office/front line PR person.  She was a very pleasant young women who could offer me no more information and I did feel sorry for the position she was in as I imagined she was getting inundated with calls.  During the conversation I asked her when Mattamy would be providing up a follow up letter and she stated most likely sometime in October/November.  I was a little put back that they were not going to provide me, the customer, any more information for another 3 or 4 months while my money was sleeping in their bank account.  So I suggested to her that perhaps they could start a blog to provide at a minimum weekly updates, or hold an information meeting in short order, something at least.  The young women said that was a good idea and would feed it up the food chain.

So a couple of weeks went by and nothing happened, it was now late August and I happened to be on holidays for a week.  So the wife and I decided to take things into our own hands by initially starting a blog and a group on FaceBook.  We did this for about a week and then my wife suggested we contact the media as it would make a good story and perhaps we could get some traction from Mattamy and the city of Ottawa that way.  So on the Thursday we were on CJOH then on the Friday we were on CBC and also got a write up in the Citizen.  This resulted in Frank Cairo, vice president of Mattamy, calling me directly to set up a meeting.  He was impressed with the level of attention we had achieved in such a short period of time and wanted to come around and discuss working together.  So around came Frank Cairo along with his co-worker Susan Murphy.  A very quick back story on Susan Murphy.  She is a lawyer who used to work in the planning department of the City of Ottawa and was involved in the shutting up of a certain city water engineer who raised concerns about the planning in Kanata West.  She subsequently jumped ship from the City of Ottawa and went to work for Mattamy homes and Frank Cairo.  So along comes Frank and Sue into our backyard where we sit down and have a beer and Frank proceeds to explain the history of what has happened etc, etc, while Sue looks on.  During our discussion Frank goes on to say that it would be great to work with us, in essence we could be the public face of the issue as from his point of view the problem lies with the city of Ottawa. We of course are more than happy to oblige his concept on the proviso that he has to fill us in on what is going on at his end and we can blog about it. At the end of the backyard have a beer summit Frank and Sue shake our hands and I remind him to ‘participate’ with us and ‘use’ us to help push the city.  In other words email or phone would be required, but hell he’s a vice president and a smart guy so he did not need to be told that.  I realize now that the meeting was in essence bullshit and was just a scouting mission to see if we posed any real threat.  I think in hind sight they had a mistake in there impression.  I will say this however, I honestly did like Frank.  He was a nice down to earth guy, seemed genuine and was honestly enthusiastic about the community they where building out in Kanata. Remember, Frank was a fast riser at Mattamy.  Straight out of school he was in Mattamy where he drastically improved some of there business models, he even apparently, wrote some software to help them do it.  He was a fast mover and to be given V.P. in Ottawa was a very big step in his career, but I honestly felt he must have worked for it.

Anyways, so a week goes by and I call Frank a few times and leave a message of his cell phone but he does not return my calls.  Meanwhile, we have been contacted be a lot of home buyers and even some people ‘in the know’ from within the industry who are providing us a lot of information.  I will not say whom these individuals are as I said I wouldn’t.  By the end of week two we have arranged a meeting of homebuyers in our home on a lovely September Saturday morning.  During this meeting  we discuss what the next steps could be etc etc etc.  In the end we decide to ask Mattamy 3 options which we posted up on the blog.  These where:

1. Allow home buyers out of their contracts if they should choose.
2. Freeze Upgrade prices and present values
3. Allow home buyers to switch lots to the new Barhaven community

We also wanted to have a meeting with the city planners along with Mattamy and the Ministry of the environment.  In other words, all of the players in the same room, what a novel idea!  I met with Shad Qadri, city councilor for the area and he agreed and he and his staff would set it up.  By the way Shad was great as was his staff.  In the end the meeting was set for sometime around the end of September beginning of October if memory serves me correctly.

Meanwhile, my calls to Frank had gone unanswered after numerous attempts.  Finally one Friday afternoon after calling him numerous times on his cell phone I got a little frustrated.  So I left him a message that went along the lines of ‘Frank, if you do not call me back I will be forced to continue my conversation with W5”. 5 minutes later RING! Hey Frank, how are ya!  I cannot honestly remember the context of the conversation as I was too busy laughing inside my head at how fast my message had elicited a return call.  Perhaps it was only chance that he called back immediately after that message, who knows, but certainly by this time I was feeling a little jaded about Mattamy’s behavior. 

The following week we had another piece in the paper run as we wanted to keep the pressure up.  One Friday afternoon while at work I received a phone call from my lawyers secretary.  She informed me that my release form from the Mattamy contract was ready for me to sign.  It took me a few seconds before I said ‘what?’  The secretary then proceeded to tell me that Mattamy had decided to release me from the contract sighting a comment by my wife that we wanted out of the contract.  I guess she should have said we would have liked a bigger home for the same price as compensation.  Since when can you take 3^rd party edited comments as the wishes of the individual who has a signed contract!  I was a little incensed to say the least as I felt like they were trying to pull a fast one and get rid of us.  So I told the secretary that I would NOT be signing and promptly hung up and went for a smoke to think for a bit.  When I got back to the office I picked up the phone and called the sales office and I said ‘Hey this Joe from over at phase 3.  I was taking to Frank this morning about some issues we need to discuss but I don’t have his office number with me, can you give it to me?’  She promptly gives me Frank’s office number.  I say thanks and hang up.  I then call the number and get the secretary and I say.  ‘Afternoon, its Joe from over at phase 3, I was talking to Frank this morning about some issues he wanted to discuss this afternoon.  Is he in?”.  The secretary says “Yes he’s in Joe, I will put you through.”, thank you I say.  A few seconds later I hear, “Frank Cairo!”.  “Hi Frank its Keith Chadwick calling how ya doing!”.  This was followed by about 5 seconds of silence then finally a begrudging “hello Keith”.  The conversation went on where I explained to Frank that you cannot use  3^rd party reports in the media as a means to push me out of my contract.  Let’s not forget that this offer had NOT been made to any other home buyer.  I wish I had recorded the conversation as I had the ability to but did not think of it at the moment.  Two comments of Frank’s from that conversation have stuck in my brain every since and probably will until I die.  These where:

• I don’t think you are a Mattamy type person!
• Every time you write a blog post it’s like a stab to my heart!

After the conversation I sat a little dumbfounded for a minute then shook my head vigorously and turned to my coworkers and told them what had been said.  They were as stunned as I.  First off, when I signed the contract there was not a personality or aptitude test that could be used to help in defining me as a ‘Mattamy type person’.  Hell, i’m a bloody WASP, how much better to fit into tight suburbia or am I wrong.  I did not know that Mattamy looked for a ‘certain type of person’.  I will not even go into the tones of discrimination Franks statement can lead to.  The second statement is just plainly bizarre but I have had a fair amount of time to think on it.  Remember my comments about Frank earlier, that I thought he was a genuine person and honest.  I feel now that on that day I was talking to a person under an extreme amount of pressure to do things one way that went against his own personal views.  This type of work environment can really kill you so in retrospect I do feel sorry for Frank.  However, as a V.P., those comments are inexcusable to a customer regardless of how much stress you are under.  Enough said!

So the meeting I had requested to be set up went ahead at the local Sportsplex on Woodroffe avenue.  The city was there in full force.  In fact the city brought basically numbers’ 1 and 2 from every department including legal that had anything to do with the issue, good on them I thought. I cannot remember if the MOE was there so I will leave them out of it.  Of course Mattamy declined to show.  You would have thought this would have been a wonderful opportunity for Mattamy to discuss in front of several, about 12, of their CUSTOMERS!!!  But alas, in the world of building common sense does not seem to exist when it comes to customer service.  You know where J.D. Powers can stick its award for customer service as far as I am concerned.  So, back to the meeting.  It was a very interesting experience and certainly the head legal guy, I apologize for not remembering his name, was a real pleasure to listen to.  He was the definition of saying a lot without saying much but was one hell of a smart guy.  He had a lazy eye which left me with the effect of listening to some Greek Oracle. He was indeed one hell of a smart guy.  The meeting of course was completely the cities side of the equation since Mattamy was not there for any counterpoint.  Overall however, I felt it is was informative and constructive.

A short time later I heard through the other home buyers that Mattamy had decided to call a meeting at a local hotel of all the home buyers.  The meeting was invitation only and of course they did not send us an invitation.  This spoke volumes of how Mattamy viewed my wife and I, so much for working with us!  Luckily the invite to the meeting included a guest and I went with another home buyer along with my father.  Of course we all got in, they even had a name badge ready for me but I will be honest on the way there was not sure if there was going to be a few tough’s waiting for me to bar my way.  At this point I was starting to get a little paranoid about Mattamy to be honest.

During the meeting Frank went on about how approval was underway and was not a problem and was very upbeat.  In fact during this meeting I spoke on several occasions attempting to back what Frank was saying.  I was trying to be a conciliator as much as possible.  As part of the meeting Frank introduced several options to the home buyers.  Guess what they where, you guessed it the same ones we and the other home buyers came up with and put on the blog.  The condition to resign was time based and we had until the following Saturday to sign up under the new contract which included an extra 5K in upgrades and upgrade prices frozen.  After some discussion with my wife and parents I phoned Mattamy on the Monday to inform them that I would be resigning and would be around that week to do so.  A short time later I got a call back from the sales office asking if I could come in on the Saturday to meet with Frank directly to go over the new contract. I of course said yes would love to.  I figured after my backing of him at the hotel meeting it would be an opportunity for him to say thanks and bury the hatchet, boy was I wrong.

So on the following Saturday I, with my father in tow headed off to the main office of Mattamy in Kanata to meet with Frank.  We arrived at an old farm house they were using as mission control and where escorted into the board room at the back.  After a few minutes Frank came in with a large bundle of papers with one of his sales guys in tow.  He introduced the guy as I sales guy but I half suspect he was a lawyer.  He then proceeded to go through the enumerable schedules that make up a housing contract in Ontario. Schedule A, Schedule B, Schedule C then finally schedule X.  Hang on I thought, we missed a lot of letters there!  Frank then went on to explain that schedule X was a gag order preventing me from any further contact with the media or public in general in regards to Mattamy Fairwinds Phase 5.  It also stated that anything I had said in the past about Mattamy or wrote about Mattamy was incorrect!  My father argued this point at some length as he was a bit put off because he felt I had not said anything but the truth. In fact he was correct but I said screw it, I did not care, I wanted my bloody house and if this is what it took fine, the hell with it.  The gag order was to be in place until one year after taking possession of the home.  This is why I took the blog down.  Although I was not going to write anymore, my fear was they could use its existence as an excuse/evidence that I was breaking the order.  Now interestingly I was never made the offer to take the contract back and review it although I did have 5 days to pull out.  I was told in no uncertain terms sign the gag order or no deal.  Interestingly Frank said it was because they had trouble in the past with customers going to the media etc so this was there policy.  Really!!!  I wonder how many Mattamy home buyers out there have had their traps shut with a ‘sign the gag order or no home’ situation. Of course we will never know because they are not allowed to tell you.  Oh before I forget, during this meeting I pointed out that the options they had provided where the same ones we had recommended to them at our very first meeting then on the blog after we met with those home buyers on a Saturday morning.  He said that was not true and of course I was signing to that affect, funny isn’t it!

Fast forward one year and another letter arrives from Mattamy, the first we have had from them.  Apparently more delays have occurred and now they cannot give us any closing date.  This time the options are provided right in the letter, hey they learned!  We opt for option A, time to get the hell out of this thing and get the 25K back.  So again I call them and inform them of my decision and again I, with my father in tow, head up to the Mattamy sales office.  In we go where we are asked to sit and after a short time a gentleman approaches with some papers for me to sign.  He barely says a word, in fact in general he was distasteful in his demeanor. He hands me a lousy cheap bic pen to sign the papers, makes the necessary copies and hand them back to me.  Not so much as a ‘sorry for all the trouble’, ‘sorry for the inconvenience’, not so much as a f’ing simple have a nice day.  I cannot resist so I say to him on parting ‘As Joe Pesci said in Casino to the banker, You put my fucking money to sleep you asshole’ and I left.  Not one ounce of interest on 25k over 20 months.  I did however manage to keep that lovely Mattamy pen they gave me when I signed my original contract.  I think I will sharpen the tip, put some wings on the back and make it into a dart that I can throw at pictures of Mattamy homes in the news paper.

So if you are thinking of buying a new home and are considering purchasing from Mattamy go for it.  Just be prepared to bend over and get not so much as a please or a thank you as they shove there nice Mattamy pen where it should not be!  J.D Powers award for best customer service 3 years running, give me a break, Mr. Powers must be on drugs or on the take.

Sincerely
Keith Chadwick

Object Oriented programming is a conceptual model that can be applied to ANY language that supports it. Therefore regardless of the language you learn OO in you can apply it. OO is in essence very simple at its core and I shall give you a real world example I often use when I have taught. Imagine that your object is a case of beer. The beer case has many properties, such as color, width, height etc. It also has several methods, like open case, close case or getCountofBeer. Now we have a class called beer. We create many instances/copies of beer and then call the method on beer case called add and we pass that method a beer object. This results in the beer being added to the case. The beer of course has properties like width, height, weight, color etc and methods such as open. Now since a beer is based on a base class that we create instances of, if I ‘prototype’ a method or property into that beer base class then ALL existing beers that have already been created automatically get that new method or property we added to the base class. So from a OO perspective the beer case object ‘inherits’ X number of beer objects. Now suppose your fridge is an object and it can inherit multiple beer case objects. So in coding terms you could have this:

var fr = new Fridge()       // create a fridge
var bc = new BeerCase()     // create a beer case
var br = new Beer()         // create a beer
bc.add(br)                  // add the beer to the beer case
fr.add(br)                  // put the beer case in the fridge
fr.open()                   // open the fridge
// Get beer case number 1 from the fridge and call the beer case method get beer
// and get the first beer and call the method open on the beer.
// This returns beer liquid to the variable getMeABeer
var getMeABeer = fr.beerCases[0].getBeer[0].open()
getMeABeer.drinkIt()             // drink the dam beer

This is the essence of OO and the above example is JS syntax.

So there you have it, the OO Beer Case analogy. Hope you enjoyed it.

Cheers
Keith

Rich Internet Applications (RIAs) are web applications that have many of the characteristics of desktop applications, typically delivered either by way of a site-specific browser, via a browser plug-in, or independently via sandboxes or virtual machines.^[1] Adobe Flash, Java and Microsoft Silverlight are currently the three top frameworks, with penetration rates around 95%, 80% and 45% respectively.

Wikipedia goes on to say that the introduction in the past few years of JavaScript frameworks is also now considered by most to be supportive of the development of RIA’s.  What I find of interest is Wikipedia and other sites go on to speak of the expected functionality of RIA’s but none appear to delve into the development benefits in conjunction with the available JS frameworks and other more traditional implementations. 

This is the context that I will cover in the below pasted comment from the afore mentioned thread on LinkedIn.

As for comments about client side vs. server side let’s remember the context of this group, Rich Internet Applications. I disagree with the viewpoint that JS is simply a handy tool, it, flash, Silverlight and Java are presently the only tools that meet the requirement to create RIA’s. I say this because in my view an RIA not only provides for a rich user experience but more importantly for the first time on the web as a delivery mechanism, we are actually able to support a pure 3 tier model.

RIA’s as a 3 tier implementation provide for segmentation of layers allowing for parallel development of each tier where the only interconnection is data. It is unfortunate that development platforms such as .NET and Java(JSP) for example are far too tied to the front end by making the business decisions on what to serve up. This is not a 3 tier model but in essence a two tier model where the interfaces of the server side objects just happen to be disconnected. I cannot count the number of times I have seen .NET developers make a simple hyper-link a server side component, this to me is bizarre.

In developing an RIA the segmentation of each layer into its own distinct project with specialists in each area allows for a more robust application and greater reuse. ‘Smart’ front ends written in JS or Flash that communicate over the cloud with JSON or XML or even basic asynchronous methods allow for this. As the web has developed we are now starting to see this level of segmentation reflected in the workforce where we have front end specialists who now work in tandem with designers and clients.

From a business perspective a pure RIA 3 tier model allows for a smaller investment on the initial design by allowing the front end to be truly vetted by the client. This can be accomplished by using static xml or json files that drive the front end. When the client is satisfied with the results, the middle tier can then be completed in the prescribed language and a database added if necessary. This type of development is in essence top down where as historically we did bottom up. This type of model also allows for geographical segmentation of the application and in so doing so can also reduce cost. Font ends can even be compiled into desktop apps, see Javaline and business tiers and databases can be distributed. Again this can provide for cost savings and greater distribution of workload amongst each tier.

So to say the JS is only a small part is in my view incorrect. In order to meet the definition of a RIA it IS the language of choice. I expect it will not be long before libraries become browser based and JS becomes a compiled deliverable package. This is bound to happen as a simple result of how ‘we’ the community are driving the development of RIA’s.

As with anything you write I have to comment on my own comments from the thread.  I am not prescribing the radical concept of dropping fundamental design principles, far from it.  What I am doing however, is pointing out that RIA’s allow for a more top down development implementation.  This style of development allows us to focus on the most important aspect of a RIA, the interface.  I know many developers will say that the database design is most import or the server side OO design is most important but the fact is they are not.  Neither of these tiers, however important and they certainly are, do NOT sell product either to the client or the clients prospective clients.  It is the interface that is consumed by the viewer, tiers 2 and 3 are simply supporting that consumption.  It’s analogous to buying a good steak, you don’t consider for a moment how it was shipped or raised when you’re eating it.  Only how it was presented to you at the restaurant and how darn good it is  to eat.

In summary RIA’s provide for top down development that allow for better vetting of functionality directly with client.  This in turn helps to ensure reduced iterative development cycles through all three tiers.  This in turn reduces cost, improves client buy in and allows development shops to do incremental fixed price bidding on projects.  Imagine bidding on a project with the model of 4 stages of contract such as:

1. Requirements gathering and analysis
2. ‘Functional’ Interface development, presentation and vetting.
3. Server Side and Database development
4. Deployment

Notice another aspect of building contracts in this nature.  The client is free to take the results of each stage and put out further requests for proposals.  Now this may be counter intuitive to development shops but how often have we seen a 100% buy in on the whole plan only to result in cost overruns and therefore reduced profit.

3 Tier RIAs allow us this type of contractual model which if adhered to is too everyone’s benefit!

This first episode is in regards to everyone’s favorite company procedure “performance measurement”, enjoy!

Rules of Performance Measurement

However, in the majority of cases the source of your XML is from within your own system and in those cases it is safe to assume that the resulting objects are safe and can be typed to a certain degree.

Data Typing your JSON

Typing your result set offers numerous advantages in your client side code. In this section I will discuss how to do some basic typing of your XML to JSON values.  It would be fairly easy to expand upon the number of types but for starters we will stick with the basics, numbers, booleans, dates and JavaScript functions.

Let’s assume the following XML structure:

 In part 2 of this series I discussed how to do character escaping within an iterative template entitled “replace”.  This template returned the escaped content and placed it in a result variable entitled $cleanData. In order to implement datatyping of the content we need to pass this value to the data typing template. But in order to do this correctly we need some way of identifying the value that is being passed to the data type it is to be converted to.  Again, we will turn to the configuration file to provide the ability:

The above pointers element within the config.xml file contains pointer nodes that define the data type to convert to, the type of match to look for and the string/xpath to match on.  Based on this information we therefore need to track the full xpath location of the current element as we enumerate through the xml data.  This is done fairly easily by iteratively passing the name of the current element to the same template with the name() function and appending on a / for the path.  This value is then passed to the data typing template along with the value for processing. In the below example I will provide a full example of the workflow of the template in order to fully express the logic.

As can be seen above in each instance where we either call the build, elements or attributes template we are passing the current path as a concatenated string.  Notice that within the attributes template that we add in a @ value to indicate an attribute. Once this has been accomplished the actual data type template is a fairly simple matter to code.  Notice in the below template that I automatically derive a number when the numbe() method returns True within XSL.

As can be seen above the first case statement checks for the correct data type and the second template implements the resulting code.

Flattening that Fat JSON

While it can easily be argues that JSON is a much more efficient means of tranportng asynchronous data to the caller there is still some ‘fatness’ in it that could be trimmed if desired.  Take for example the following XML snippet.

 In a normal JSON implementation the above XML would be converted under the BadgerFish convention would be converted into a rather FAT JavaScript object. For instance, to get to the sell element value you would have to do MJSON[0].mydata.volume.$.  In code this would appear as:

Noticed that I have Data Typed the above example and moved even further from the BadgerFish convention by not enclosing object names and values in “.  The idea of flattening your JSON is to streamline the data coming down the pipe.  It does not inherently allow for reverse engineering back to XML but along with Data typing provides for a much more accurate and streamlined resulting JavaScript Object.  In essence we want to drop the $ for text elements or other child elements who’s name does NOT conflict with any parent element or attribute.

In order to flatten an node it must meet some basic criteria:

• The node must not contain any attributes 
• The node must not contain any child nodes

If the current node meets each of the above three criteria then it can be safely moved into the parent JSON object without fear of conflict.

The difficult part in implementing this logic is recognizing that there are child nodes that fit the category and to incorporate them into the current object.  The result is a fair amount of impact on the majority of templates to ensure valid JSON.  I will not however go into great detail on the actual XSL implementation for flattening the JSON as it would take far longer than all of the other posts combined. But I will go over some of the switches supplied within the CONFIG.XML file and how they impact on the resulting JSON along with some examples.  Following is a basic summary of the CONFIG options the transformation supports: 

• Encase For Array [boolean string true|false]
  Location: xmltojson/options/encaseforarray
  XSL Param Name: $encaseForArray
  Wraps the resulting JSON output in [ ] when true.
• Drop Root [boolean string true|false]
  Location: xmltojson/options/dropRoot
  XSL Param Name: $dropRoot
  Drops the root XML element for the resulting JSON when true.
• Flatten Simple Elements [boolean string true|false]
  Location: xmltojson/options/flattenSimpleElements and xmltojson/options/flattenSimpleCollectionsToArrays
  XSL Param Names: $flattenSimpleElements and $flattenSimpleCollectionsToArrays
  Forces simple child elements to be moved into the parent object as direct properties with no BadgerFish convention for element values.
• Append to Element Name to For Uniqueness [string]
  Location: xmltojson/options/elementAppendForUnique
  XSL Param Name: $elementAppendForUnique
  When flattening JSON child node names can conflict with parent attribute names.  This string is appending to the child element name in order to ensure uniqueness. Works for both singletons and array constructs.

Of the 4 above CONFIG switches both Encase for Array and DropRoot are fairly obvious in nature and result and therefore I will not provide examples of.  The other two switches, specially Flatten Simple Elements, can be fairly difficult to understand with regards to their impacts.  As a result the following code block with provide several examples of JSON with the switch on or off.

----------------------------------------------------------------------
Example 1: Parent Inherits Child
----------------------------------------------------------------------
Flatten Simple Off:
   [{data:{id:1,someinfo:{$:"This is a simple element"}}}]
Flatten Simple On: 
   [{data:{id:1,someinfo:"This is a simple element"}}]

----------------------------------------------------------------------
Example 2: Parent Inherits Simple Children Only
----------------------------------------------------------------------
<data id="1">
   <someinfo>This is a simple element</someinfo>
   <key stamp="2009-01-01">123435</key>
</data>
Flatten Simple Off:
   [{data:{id:1,someinfo:{$:"This is a simple element"},key:{stamp:"2009-01-01",$:123435}}}]
Flatten Simple On: 
   [{data:{id:1,someinfo:"This is a simple element",key:{stamp:"2009-01-01",$:123435}}}]
----------------------------------------------------------------------
Example 3: Parent Inherits Simple Children but Ignores Collection
----------------------------------------------------------------------
<data id="1">
   <someinfo>This is a simple element</someinfo>
   <key>1</key>
   <key>2</key>
   <key>3</key>
</data>
Flatten Simple Off:
   [{data:{id:1,someinfo:{$:"This is a simple element"},key:[{$:1},{$:2},{$:3}]}}]
Flatten Simple On: 
   [{data:{id:1,someinfo:"This is a simple element",key:[{$:1},{$:2},{$:3}]}}]
Flatten Simple On and Flatten Simple Collections On
   [{data:{id:1,someinfo:"This is a simple element",key:[1,2,3]}}]

 As you can see in the above examples the impacts of turning both Flatten Simple and Flatten Simple Collections on can be fairly dramatic in the size and complexity of your resulting JSON.  There is however a situation that can occur that can cause this to break.  This is when a child node name conflicts with a parent nodes attribute name.  This is the reason for the append to element name for uniqueness parameter setting:

Conclusion

Although far from perfect JSON provides for easy integration into your client side code.  It is still fairly early in its development and has not yet been fully adopted by the W3C.  That being said it still offers some advantages over XML.

This transformation is far from perfect. For instance it does not render attributes are elements with a null, rather it ignores them.  This is the first issue that comes to mind and I am sure there will be others as time goes by. Also the code has changed somewhat since the writing of this series but remains in essence the same.  I have split some of the templates in order to provide greater readibility.

You can download the coad at  http://code.google.com/p/xmltojson

Until next time….
Keith Chadwick

There are several types of clients one will meet in your foray into software development.  Here are some of the ones to watch out for:

The “Nod in complete agreement” Client
We have all been there.  You sit down with a client and explain what your plans are for their requirements and instead of asking questions they simply nod in agreement.  This type of client will kill you in the end as their expectations will never live up to the final result.  It is often the case that this type of client does not want to appear dumb and so simply nods in agreement to everything you say. When dealing with this situation you need to make the client feel at ease and place yourself as the dumb one who does not understand their business.  This will place the client in a feeling of knowledge and superiority and allow them to open up with comfort.

The “buzz word” Client
These types of clients are trickier to deal with as it is hard to tell if they actually understand what they are saying.  The worst part is that you have to tread a fine line of insult if you push this type of client on any particular concept they are throwing out into the air.  If you are lucky you can pick up on the terms they actually understand versus the ones they are just throwing out there to appear knowledgeable.  Again, this type of client needs to be made to feel at ease and you need to stress a non combative environment and at all times that they are the knowledgeable one and in control.

The “Just Like this” Client
These clients are the one who throw out example web sites in rapid succession with no details as to what they are referring to.  These are the type of clients who drop in things like FaceBook, Feedburner, Google Maps, RSS without any thought to the cost of such implementations.  To them everything is easy and simply plug and play.  In the developers case this results in plug and pray we stay on budget.  In order to deal with these sorts of clients you need to slow the conversation down and get the client to focus in on their needs and the costs associated with them.

Of course I do not want to spend this entire post berating clients as they are only half of the equation if not less.  The majority of the responsibility in my opinion sits with the developers and project managers.  The client came to us not the other way around and therefore it is our job first and foremost to provide the necessary solution.  Unfortunately as ‘techie’ guys we all have a bad habit of falling back on big ‘techie’ words to impress the client and take them off the real issues.  Below are some techie terms you should never ever say to a client under any circumstances.

• Object Oriented (OO)
  Object Orient is bad enough but to mutter OO as if it is an exclamation of awe is simply a no no under any circumstances. If OO has a direct impact to a client in there long term plans then explain it in terms they can understand. I like to use a fridge as an example; it has properties such as color and methods such as open. You can then have a truck with many fridge’s and with the press of a button change all of their colors to red instantly. It may seem a little silly but you have to judge the clients knowledge and use the right example and stress how this will help them in the future.
• Serialization
  Don’t use it, they don’t care and never will. I hate this word even among fellow chip heads and it is extremely overused.
• Polymorphism
  Instant ticket to jail with no ‘get out of jail’ free card in my opinion. Dropping this one on a client is beyond reproachable and there should never ever be a reason for it. Again a term thrown out for no good reason by developers to developers as well. This term is like using ‘tuple’ for describing a database record rather than the term ROW!!! It has been around since the 60′s just like polymorphism and nobody cares.
• Cross browser compliant
  How about ‘Works in all browsers’. Need I say more.
• Obfuscation
  Not only hard to pronounce and spell right but nobody cares if the client side code has been obfuscated. Drop this one into a client conversation and be fearful of the results. Hell the definition of the word on the urban dictionary used the quote “Any politician worth his salt is an artist in obfuscation”. You really want to be paired with politics in the client’s eyes. How about simply saying ‘we have changed the code in the browser to make it more difficult to be hacked or played with!’
• AJAX
  I am a massive fan of AJAX but don’t use it with clients. How about Web 2.0 or even better ‘improved user experience’. Stick to a more PR/Marketing term for this one, they will get it.
• Reuse
  Saved the best for last and it goes hand in hand with OO. Never ever ever use this one on a client. Simply put in most situations the ONLY person who is going to get reuse out of the code you wrote is YOU. By the time the client comes back to revamp their site chances are technology has moved on so much that you simply CAN NOT reuse that code you wrote 5 years ago. But, if you dropped this one on the client then their question becomes ‘You said it was reusable so why so much cost to redesign the site?’ Need I say more?

Until Next Time
Keith

Source XML

In my previous post we have a fairly simple XML document to convert.  For this example we will use the same XML but create 2 book elements.  In our JSON this would result in a array of books.

The basic resulting JSON structure would be the below, I have left out the second book element in order to save a little space as the structure would be the same as the first book element.

Step 1: Implementing a Config File

Given the number of different conventions for JSON it is difficult to build that level flexibility directly into the XSL.  However, if we introduce a config.xml file and use the document() command with the XSL to load we can provide a much greater level of switches and configuration.

If we use the root/book[@id="780102497"]/pricing/sales/item nodes as an example the basic JSON under the Badgerfish convention would be as follows:

The above JSON snippet allows us to get to the item values within the array as ..preamble["item"][0]["item"]["$"]  or …preamble.item[0].item.$.

If we look at the syntax for the above JSON, the count property could be viewed as :

[encase object] [xml attribute name] [ encase object] : [encase value] [ xml attribute value] [encase value]

The Item node content could be interpreted as:

[encase object] [node name] [encase object] : { [encase object] [element text identifier] [ encase object] : [encase value] [node text value] [ encase value] }

Based on the above we have several variables we can place into our configuration file.  Originally these where defined as params in the XSL but let’s now push them over into config.xml.

So far fairly straight forward.  Moving these parameters to a config file has no impact on the XSL code. Notice that the document() function takes a variable as well, $doc.  This allows for passing in the doc parameter on transformation in order to over ride the default config.xml file.  This means that you can define multiple configuration files on your site and pick the one that you need for the current request.  The above config settings adhere to the BadgerFish convention.

Step 2: Escaping XML Characters

Since our source xml could have rich text content that contains both \ and ” we have to be sure to be able to escape these characters within the resulting JSON otherwise this could result in an error.  Again we will use our config.xml to provide the list of items to escape.

As can be seen from the above structure it is a fairly straight forward operation to add in values to check for, from element, then convert to, to element.  For each conversion we add in an item node with the corresponding from and to.  In order to implement this the XSL we, unfortunately, have to create an iterative template that does the replacement.  It is frustrating that XSL does not provide for a translate method that acts more like a replace with n characters to n* characters. We need to call the cleaning template from within both the param and element templates.

Although the replace template looks fairly complex, it is rather simple in its implementation. In essense it enumerates though the passed in value looking for the \escape\from value and when found takes the left of it, appends on the \escape\to value and the remaining content to the right in the value.  The template then calls its self and passes the same string.  The process then repeats. If the \escape\from value is not found in the string it enumerates the nodePos in \escape to the next character to replace and the process start all over again.  Finally when all enumeration is complete and there are no more \escape elements to test for, it returns the result.

Finally 

In the next installment of this series I will move outside of the normal JSON conventions in order to provide greater flexibility in the result set.  In the final post I will show how to provide for data typing of both elements and attributes plus returning native javascript functions within your JSON.  Finally I will introduce how to flatten your JSON for greater efficiency in both size and complexity.  I like to call this SJSON, Simplified JavaScript Object Notation.

I will also make all of the code available in the last post on a code hosting site but have not decided which one to go with yet.

Until then…
Keith Chadwick