Tech Ravings

An Opinion is a Terrible Thing To Waste
Subscribe

Archive for the ‘JavaScript’

Web 2.0, Namespacing

April 03, 2008 By: ScottK Category: JavaScript No Comments →

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.

Web 2.0, tested?

February 04, 2008 By: ScottK Category: JavaScript 1 Comment →

Being on both sides of the fence between server side and client side programmers I hear two different calls to duty. On the server side it’s test, test, test. On the client side it’s get it out the door! Client side testing is absolutely no different from server side testing but since web site widgets are here to stay, where is the emphasis on testing.

This is the first part in a series of creating and testing JavaScript functions and libraries for use across all browsers and in conjunction with other libraries a user may include from other vendors. I mean just because you might write a beautiful library and completely test it, doesn’t mean another vendor doesn’t kill yours. Or is that testable in itself?!?

If you develop in .NET, Java, PHP, or any language that resides on the server to deliver the application I’m sure that you have heard the Test Driven Development (TDD) or Behavior Development Development (BDD) for writing your tests first and then code to make it happen and be bug free. Maybe even validate your producing HTML against the various W3C validator. When it comes to the client side programming of JavaScript you just grab a handy library from the most relevant open-source search. Maybe you test the application in your browser of choice or even use such applications as Selenium.

As the buzz word for today is Web 2.0, in that web sites are “interactive”. Yet the emphasis for applications is still on testing server side code to make sure that the server side programming still operates as expected, although continuing to use or creating client side libraries that are not tested and don’t operate as expected in various browsers. In short no matter how awesome your house is if no one can get to it then what’s the point.

Web 2.0 is not built on the fashion of server side programming, it’s built on the premise that a user can have interaction with a website without the traditional delays as refreshing the page. This means that JavaScript and DHTML is to be incorporated correctly for all browser supported. This requires a paradigm shift in thinking that JavaScript and HTML is a small part of the “total programming” that a web application can have.

Let’s explore the server side programming environment for a moment. On the server side you have a controlled environment. As a programmer you know your environment, you know your current version of the language you are programming in, you know when updates/upgrades are going to be performed. These things are no surprise to you and you know what exactly you can do to optimize your code. Fundamentally, server side programming a a clean room environment here you have total control.

On the client side it’s a bit different. You don’t know everything about the visitor you are try to serve. It’s well known that as far as JavaScript and CSS support across the different browsers isn’t always the best since. Even the difference’s from the same host JavaScript object in Safari and Firefox makes client side programming difficult.

Client side programming is not necessarily about knowing code it’s how to code to prevent crashing in the browsers. Your elegantly written JavaScript library that works beautifully in Firefox but fails in Internet Explorer 7 and completely crashes Internet Explorer 6 will cause you to lose a lot of visitors. It’s the same code, different environments. Certainly it’s easy to say “Firefox” is only the supported browser. Seriously?

Client side testing also about downloading as well. Here the price is doubled for bad code. The first price is for the visitor leaving the site because the download time is to long. Unless the website has a flat usage fee arrangement then most come with a transfer overage stipulation.

Where the script src include statement has a huge effect on how long it will take a site to load. Most sites typically include these just before the ending head tag. If the JavaScript file is huge or is loaded slowly the rest of the page load is severely delayed. Hence the long wait time for the visitor. Off-site JavaScript files suffer server outage that can kill the web page completely.

So a JavaScript file has been called for inclusion to a web page. The file being huge makes the visitor leave, the bandwidth has still been used. Evaluating that how can this be made more efficient without changing the code. You can minify this by removing all the white space from the file. The other thing that really does not need to happen is “cache busting”. Ever since a file(JavaScript, Image, object) with a src url of “my_image?324234″? The query on the end (?324234) is keeping the visitor browser from caching the file. So every time they repeat visit they still get a file download.

I’m all for server side testing in whatever language that’s chosen. If you’re a programmer in those languages you certainly know what I mean. I also love client side programming, yet every job or consultation I have been on takes this area as superficial; at least until the application doesn’t work correctly. More times then naught it’s because a “library” was chosen and not tested before integration.

JavaScript and DHTML client side testing is no different from server side testing. In the next part I’ll describe the initial set up of a library so that you have control of it even if the user of your code includes other vendors.

Module Pattern Objects

September 24, 2007 By: ScottK Category: JavaScript No Comments →

Just last night I discovered a new pattern for writing encapsulated JavaScript patterns. Christian Heilmann @ Wait Till I Come wrote about the module pattern in the article Show Love to the Module Pattern.

The pattern itself is interesting and would like to test it’s performance. Being that you are creating this on a var object means that after definition it’s immediately available and the new operator is not necessary makes this singleton in nature. Just as JSON pattern objects. However I haven’t tried the test code or built an object as of yet, I wonder how the prototype scoping holds up.


ss_blog_claim=ef6135f29164404afb5ea2743196c435