Ext.extend and Conquer

Today it was a very productive day.

I’ve redesigned several problematic screens of an application into more functional versions, working much faster, providing more information to the end user and – the best thing – with a very consistent appearance on their layout.

ExtJS provides some nice features to standardize its components by extending its standard classes.

The simplest way to do that is like what I show on the code snippet below. It simply provides some default values – that can be easily overriden when the custom component is instantiated – that help with the implementation of sets of components.

var myCustomCombo = new Ext.extend(
    Ext.form.ComboBox,
    {
        width: 180,
        mode: "local", // I load the data manually from the store.
        triggerAction: "all",
        emptyText: 'Choose an option...',
        autoSelect: false,
      editable: false
    }
);
Ext.reg('mycustomcombo', myCustomCombo);

I did custom implementations of panels, forms, combo boxes and grids. With that, I make only slightly variations from one case to the other – imagine addresses, where you have several different components from the country up to the zip code for a street, avenue, square, etc.

The new layout also made it possible to eliminate different pages and consolidate all the information on a single page where all records could be browsed, edited, removed or new records could be added to the database.

On the backend – my TurboGears application – my code also shrunk considerably as I didn’t have to make some convoluted queries to get the information. All modules were better decoupled and obtaining the information using AJAX – or better AJAJ since I don’t use XML but use JSON – much easier through a cleaner interface.

Summing up: it was a complete redesign of a whole module in a day. Some hundreds of lines of code eliminated and functionality added to the system.

I hope that tomorrow the day becomes as productive as today.

An AJAX option to remember

I always forget how useful is the “$(<selector>).load(‘url’, {para: meter});” function on jQuery.

It is really a problem solver when loading HTML structures.  I am converting some old code where I got HTML fragments to replace some existing content on the page and using the usual process, I’d have to do the AJAX query, call a callback procedure and then there I’d replace the contents of the section / div / whatever I wanted.

With jQuery.load I can do that on a single call and in a more effective way.

Silly thing and so simple that I always keep forgetting about it.

Creating namespaces for your code

As part of the migration I mentioned earlier, I adopted one of the many recipes available on the Internet to start creating a namespace for my common code as well as exclusive namespaces for each project I’m delivering.

The idea is to minimize how much code is available globally as well as to prevent name collisions.  It also allows me to isolate my code from some JavaScript frameworks (as I said, I’m still migrating code, so I have both MochiKit and jQuery loaded) or all of them.

if (typeof MainNamespace == "undefined") {
    var MainNamespace = {};
}

MainNamespace.namespace = function () {
    var a=arguments, o=null, i, j, d;
    for (i=0; i<a.length; i=i+1) {
        d=a[i].split(".");
        o=window;
        for (j=0; j<d.length; j=j+1) {
            o[d[j]]=o[d[j]] || {};
            o=o[d[j]];
        }
    }
    return o;
};
;

The above code is available on a file by itself and its only purpose is to initialize the main namespace for my own code.  Since it allows me to create any namespace, I don’t need to replicate that on individual projects.

To use the above, my code looks like this:

(function($) {
  MainNamespace.namespace('NewNamespace.common');
  NewNamespace.common = {
    __name__: "NewNamespace.common",
    __version__: "1.0",

    myFunctionOne: function() {
        // code
    },

    myFunctionTwo: function() {
        // code
    }
})(jQuery);

This is also an implementation of the Module Pattern, from Douglas Crockford (or is it more from Dustin Diaz?) as explained by Eric Miraglia, from YUI.  I believe this comes from Crockford, due to his prior work on this area, but the discussion on Diaz’ blog is really full of useful information.

After showing this, some recommendations:

  1. Use UPPERCASE for your MainNamespace (making it MAINNAMESPACE) as this is more visible and make it clear that you are using a module
  2. Use a name that is under your control: your company name, for example.  This will prevent namespace clashes with other code
  3. Make your code generic enough so that you can reuse it as many times as needed

I hope this helps with a better coding practice as well as to spread the word on namespaces 🙂

jQuery: this and that

Actually, I prefer using self instead of that, but just because I’m more used to program in Python.

The problem actually started when I decided on doing two big changes to my JavaScript code: move from MochiKit to jQuery and change from plain functions in a global scope to namespaced “classes”.

The first part is mostrly straightforward…  Some things change here and there, some rewriting is needed in a few places, but then it is not all that hard after you start to understand the differences between both libraries.

The second part, though, is what prompted me to write this article here.

To make your life easier, jQuery changes the context of the this object according to what triggered the code to run.  It might be an object or it might be a DOM element (another kind of object).

By comment 9 from the above link I found the solution to allow me to use jQuery and keep my object oriented code, using namespaces and factoring out common code.

$('selector').bind('event', {self : namespace}, my_function);

Then, at my JavaScript function, I have:

namespace = {
    my_function: function(evt) {
        var self = evt.data.self;
        // code
    }
};

This allow me to use other functions within the same namespace by referring to this namespace as self.

It took me a while to join the pieces together and the mentioned post helped a lot on creating a clean solution to the problem.

Dojo: Still not ready for business applications

I felt in love with Dojo.  I loved the way it interacted with my existing code and its compatibility with MochiKit (that I am currently using).

Unfortunately, I can’t migrate some business applications to it because Opera isn’t supported.

I did test a very simple website using Dojo 1.1.1 from AOL CDN where I implemented just some layout Dijit widgets and an accordion pane, but it wasn’t rendered correctly on Opera.

What happened?  I had to move back and remove Dojo from the code.  I’ll keep on looking at it, but for now I’ll have to search other JavaScript frameworks (jQuery and YUI come to my mind) to implement my applications.

As I said, too bad because I was really liking Dojo.

Accessibility when developing for the web

There are two concerns when speaking about accessibility: accessibility for disabled people and accessibility for “disabled” browsers.

I’m talking, on this post, about the second category.

So, is this really something that is needed nowadays?  Even the browser on my mobile phone has JavaScript support (though it doesn’t have Flash support) and can run a complex dynamic website without any special change or anything designed to be used on mobile browsers (be them Blackberries, iPhones or other mobile phones).

Some recommendations are to degrade the design when JavaScript is disabled, but the vast majority of users has no idea how to disable JavaScript on their browsers.  If some IT guy from a company does that, should you really be worried with this person accessing your website?  Of course, you are reducing the market for your product, but how many people are excluded?  Are they people that would “buy” some service from the website?  Is this amount of people worth the extra investment that it takes to design a website to degrade and to be pleasant when used fully dynamically?