mf Object Methods Part 2 {mf.object}

This is a series of posts that explains some of the fundamental rules for developing complex JavaScript applications and the mf framework.

In my previous post on the mf object methods I discussed several methods that act against a single object. In this next series of object methods I will begin demonstrating some of the mf object methods that deal with arrays of objects. When we look at applications within the business sphere we in most cases have to deal with large amounts of data that is displayed in grids and other standard user interface implementations. When dealing with this type of data you need to envision, in regards to a grid, what types of behaviour and functionality you need to provide to the consumer. There are some obvious features like sorting and search plus filter. As such we need to provide these types of methods as part of the object methods. In the future of mf I will be developing a store object which will make significant use of these methods. In this post I will discuss the following methods…

  • mf.object.exec
  • mf.object.normalize
  • mf.object.merge
  • mf.object.sort
  • mf.object.search
  • mf.object.difSearch

Continue reading

Singleton to Prototype Design Guidelines

This is a series of posts that explains some of the fundamental rules for developing complex JavaScript applications.

I am a real bugger when it comes to how my code is organized. Given the advanced user interfaces that we have today I have often noticed that JavaScript developers have become, for lack of a better adjective, bloody lazy!  Before we get into the singleton design patter a short discussion is warranted on when a singleton should be used versus a class that supports instantiation.

The most common examples of a singleton are existing JavaScript frameworks such as ExtJs, jQuery, etc. In essence we would only ever have a single instance of each of these frameworks each represented by its own unique namespace Ext and $ respectively. The other most common example of the singleton pattern is the root namespace that represents your JavaScript application because you would under most circumstances only have one. Note I said most circumstances.  There is often the case in the real world where a requirement initially requires a singleton pattern but over time it becomes evident that a class instance would be better.  The golden rule of ‘the only constant is change’ should always be kept in mind when designing your code structures. The purpose of this post is to demonstrate how to effectively use the singleton pattern properly and in such a way as to allow for the easy migration to a class pattern. The secondary goal is to show how writing your singletons in this fashion leads to consistency of code which is something we should all strive for!

First let’s look at the basic singleton design pattern that I often see exemplified on the web.

var mySingleton = {
                 globalVar1 : null,
                 globalVar2 : null,
                 myMethod1 : function(){},
                 myMethod2 : function(){}
 }

So I will state this very clearly and strongly, the above is NOT a singleton.  In my opinion this is a simple object that does nothing more provide a hierarchical structure of variables and methods under a root namespace.  For starters this pattern does NOT use closures and does not have the concept of private/protected vs public methods and variables. At a minimum the singleton design pattern should be written as follows.

Continue reading

Drive your site with a JS Singleton

Over the past years I have created far too many web sites that I can honestly recollect.  Some were great, some were not but what all of them had in common was a lot of JavaScript.  Way back in the early days and I’m talking about the 90’s, we all enthusiastically created our sites mixed in with a jumble of JS functions.  Many of us in those days thought it so cool to be doing rollover functions and preloading images with JS functions and all other sorts of funky stuff.  However, over time as sites became more complex the JS code started to look like spaghetti and was difficult to maintain.  In comes the JS Singleton to the rescue.  Continue reading