I know of , and use, two systems that allows me to test my JavaScript: jsUnit for Test Driven Development and JsSpec for Behavior Driven Development. I find that in order to setup the object in question I lacked the ability to quickly create objects in the states or values that I needed. So more lines where devoted to building the objects than actually needed to test them. This got rather menial.

I though to myself one day, why can’t JavaScript have a quick way to create objects or even DOM elements quickly and in the state that I need them in; other languages have this ability for testing.

So I created jsFactory and it allows me to call the jsFactory class with the name of the object I needed, filled in with my pre-defined field values as well as any special values. I has allowed me more time to test than build objects over an over again for testing.

It has become such an important library for me I want to give this out to everyone that are interested. You can download the library and example files here. jsFactory

Testing without jsFactory would look like this:

function build_person() {
    person = new Person();
    person._firstName  = "Scott";
    person._lastName = "Krutsinger";
    return person;
}

function testPerson() {
    person1 = build_person();
    //Get a second object to test against
    person2 = build_person();
    person2._firstName = "Marvin";
    person2._lastName = "Martian";
    //Test code
}

The function build_person does return a Person object in the state that we need, but when we need another person object then we still have to modify the field values. Which isn’t necessary with jsFactory:

function build_person() {
    return {
        _firstName : "Scott",
        _lastName : "Krutsinger"
    };
}

function testPerson() {
    person1 = jsFactory.create("Person");
    //Get a second object to test against
    person2 = jsFactory.create("Person", {"_firstName" : "Marvin", "_lastName" : "Martian"});
    //Test code
}

jsFactory is there to help us build objects in the testing state we need, whether this is predefined or specialized as we need. When the create method is called on jsFactory it goes through two processes: default field attribute assignment then the assignment of any fields that where present as arguments. jsFactory doesn’t actually care that it is being used in testing so using it for quick object builds in production code is also a way to use it as well.

jsFactory has another function included to build DOM elements quickly.

my_anchor = jsFactory.createHtmlElement("a", {"href" : "http://www.techraving.com", "target" : "_blank"});

my_anchor is a DOM element that I can use for testing or used in my application.  You can even specify that the created element attach itself to another element by id or the object alone:

div1_element = jsFactory.createHtmlElement("div", {"id" : "div1"});

//attach by id
my_anchor1 = jsFactory.createHtmlElement("a", {"href" : "http://www.techraving.com", "target" : "_blank"}, "div1");

//attach by element
my_anchor2 = jsFactory.createHtmlElement("a", {"href" : "http://www.techraving.com", "target" : "_blank"}, div1_element);

//div1 now has both my_anchor 1 & 2 as child elements!

Use this link to download JsFactory . It contains the jsFactory class as well as example for us. jsFactory has let me concentrate more on testing objects than building them and I hope it does the same for you.

A few months ago in Orlando a new idea in transportable widgets was introduced to the developer community. The name of this concept is CloudShout . During this years IZEAFest , CloudShout has developed into a fully functional system and introductory keys were given out to not only developers but blog owners as well.

Being in closed alpha at the moment CloudShout is once again opening looking for more developers and blog operators. Thus allowing me to give out invite keys to those that are interested.

Anyone who surfs, blogs, or develops for the web would find CloudShout highly useful. The idea behind the transportable widget is that you can go from site to site with a set of applications that you or others can use. Instant messaging, LastFM, even a nice game of checkers!

From the surfers point of view they would be able to instant message friends that are also online; as long as both are on CloudShout equipped sites. With your apps in hand you can extend your user experience in real time communication with your friends or the other site visitors.

The first site to adopt CloudShout is SocialSpark and since CloudShout is in closed alpha registration must be done at SocialSpark to gain the full profile potential.

After setting up a blogger profile you can simply surf about your business. Upon happening on a CloudShout equipped site you’ll notice your display name as well as other registered users. The nice thing is through polling requests you can watch others come and go from the site. Contact these users as you wish in a variety of ways.

Each user can choose from several applications to install to increase your or others enjoyment. The big benefit here is that you can install any apps on any CloudShout equipped site you are on. When viewing the profile of a person you can choose to install apps that they have and you want; never leaving the site you are on.

As a blog operator it’s nice to be able to instantly communicate with your visitor as they come and go. Visitors can leave you messages apart from comments, and the benefit of not exposing the owners email address as well. Blog specific apps can be installed, yes via the site, that will potentially have visitors stay longer.

For developers this is another opportunity to get your name out. Just as Netvibes, iPhone, Nokia, Facebook, etc, allow developers to create applications for their community to use, CloudShout is no exception. Using a predefined widget architecture developers can quickly develop applications and submit applications. After a review process the application, if approved, would be made available to the community at large.

I have keys to give out to those interested in developing and or using CloudShout as it is still in closed alpha. Leave me a comment and I will send keys out to the email you leave.

Tags: cloudshout, IZEA, izeafest, uwa, widgets

With plugins, widgets, and what-not’s every JavaScript author is vying for space on a web page, whether their own or someone elses. How then to keep the funciton literal names from colliding with other authors, or even previously written code? Writing JavaScript strictly with global functions really places you in a situation that someone may use the same name and make your function useless, and ultimately your entire program.

This is where namespacing your JavaScript reduces the risk of anyone colliding with your code. Quite simply namespacing in JavaScript is just as simple creating an object and attaching the functions to that object, the JavaScript Prototype scope, gotta love it. Yes, you are building a JavaScript object that sets all the methods apart from anything else someone would create. So this object can, and should, contain any needed functions that it needs to operate.

The actual naming convention of the object is really up you. I personally like to namespace of the object intent, Browser. (Browser detection object), TR. (functions relating to the general javascript of Tech Raving). The real intent is to use a name that someone else may not use. Take Browser for instance, what are the chances that someone else could use that for an object or function name? Probably pretty good. BrowserSJK as a name doesn’t really look good but now what are the chances that someone will use that!

To actually create a namespace object is relativly simple:

var TR = {
    method1 : function() {
        //Do stuff here
    },
    method2 : function() {
        //Do stuff here
    }
}

So now you can use TR.method1().

That’s good for a start but what about variables you would normally need. Easy enough to set up and use and gain access to:

var TR = {
    attribute1 : “hello”,
    attribute2 : “world”,

    setAttribute1 : function(temp) {
        this.attribute1 = temp;
        this.method1();
    },
    method1 : function() {
        //Do stuff here
    },
    method2 : function() {
        //Do stuff here
    }
}

TR.setAttribute1(“test”);

The difference in namespacing this way as opposed to just writing the variables and functions is the attachment to the TR object and the use of the this keyword to make the object reference itself in the executable scope. Here there be dragons when global scoping varibals and functions because of naming collisions, although it’s easy enough to access them if no collision occurs. Namespacing protects the variables and methods by wrapping them in an object, yet some care is needed by accessing them through the Namespace name, and using the “this” keyword for access outside of the method, yet referencing within the object namespace. Sounds complicated I know, it’s a prototype thing, but until you attach events to dynamically created html elements it’s really straight forward.

So what’s a developer to do if they have existing code that has either conflicted or just needs a little love and refactoring? That’s simple as well just create an object and then prepend all the methods and varibles with the Namespace.

old code:

var myVar1 = “hello”;
var myVar2 = “world”;

function method1() {
    //do Somtehing;
}

new code:

var myObj = new Object();

myObj.myVar1 = “hello”;
myObj.myVar2 = “world”;

myObj.method1 = function(temp) {
    this.myVar1 = temp;
}

myObj.method1(“test”);

Now the new code is protected from generalization of naming. Unless you have hundreds of lines of code the refactor should go quickly. If you have hundreds of lines of the old code I would highly suggest breaking into related objects using the same namespace approach.

JavaScript used to be authors writing code for their own sites in order to help acheive some dynamic capabilities. Maybe specialized libraries, such as menu’s or link generators where “given” out, but really only one was used on a publishers site. Now a days with the many widgets given out it’s quite common for publishers to have many third party JavaScripts and not from the same author. Namespacing is a way to protect your code as an author from the other authors.

As web 2.0 grows in popularity, it’s important for us developers to ensure that our code is tested and works even in the event of failure on another party.

Tags: JavaScript, Programming, web 2.0