Background to Javascript Frameworks

My first experience of a javascript library was to build a debug console for my framework. Version one of the console was built in jQuery (v1.2, I think). I liked it. I liked how you no longer needed to repeat the same cross-browser checks every time you built something new; how effects were easy to acheive without having to create your own; chaining. Most importantly, though, I liked how the library made the development experience a little more unified.

First Taste of YUI

A few months later I decided to migrate the jQuery console to YUI2. I quickly found that the documentation was not brilliant for new-comers (and still isn’t). My migration, although worked, was not how YUI2 intended a widget to be built. Overall, it took me a lot longer to learn YUI2 than jQuery and I put this mostly down to the documentation (jQuery API docs are brilliant) though also because jQuery tutorials are abundant as are community plugins which you can rip apart to assist your learning.

Upgrading to YUI3

Last week I decided to have a go at upgrading the console to YUI3. Once again, the documentation was pretty poor for new-comers but at least this time at least I had a foundation to work with. This time I wanted to do things right. I wanted to extend the YUI Widget class and do things how YUI wanted me to do things. Just a week later, it’s done.

Benefits of YUI3

I couldn’t give you a fair comparison between jQuery and YUI, or advise you on which is the best for your project, as I’ve not kept up with the progress of jQuery. However, I’m happy YUI is the IPC standard as it’s something I’ve had a lot of fun learning and playing with.

Key components of YUI3 that I’ve come to love are:

• Loader
• Widget
• Attribute
• Event
• Node, specifically their consideration for WAI-ARIA support and Node Queries/CSS3 Selectors

Next, to get the most out of YUI3, I need to look into:

1. Profiler
2. Test
3. …and the other many utilities available

Summary

In summary, once you’ve grasped YUI and put together your first widget you’ll feel like you’ve acheived something a lot more pure, legible and stable than you do with jQuery. Or at least I do.

More to Come

Over the next few days I hope to put together some tutorials to assist people with their first YUI widget. It’s been a struggle for me to find the help I needed so, hopefully, I can help a few of you out there.

Take a look.

This has significantly improved our performance for Exemplar. However, just recently I came across this page: yaml.org/refcard.html which pretty much said what we were trying to achieve is (or should be) already available in our YAML parsing. I thought I’d share my findings with you as a lot of people don’t seem to know of these features.

Aliasing

here’s an example of repetitiveness in YAMLs:

bill-to:
  given: Chris
  family: Dumars
  address:
    lines: |
      458 Walman Dr.
      Suite #292
    city: Royal Oak
    state: MI
    postal: 48046
ship-to:
  given: Chris
  family: Dumars
  address:
    lines: |
      458 Walman Dr.
      Suite #292
    city: Royal Oak
    state: MI
    postal: 48046

Here’s how to write the above example with aliases:

bill-to: &id001
  given: Chris
  family: Dumars
  address:
    lines: |
      458 Walman Dr.
      Suite #292
    city: Royal Oak
    state: MI
    postal: 48046
ship-to: *id001

And even better… you can override previous values, or even add extras by ‘merging’ an anchor:

bill-to: &id001
  given: Chris
  family: Dumars
  address:
    lines: |
      458 Walman Dr.
      Suite #292
    city: Royal Oak
    state: MI
    postal: 48046
ship-to:
  <<: *id001
  given: Sam

This would have been a fantastic alternative to what we have already created, however, YAML to PHP parsers don’t seem to like the merging syntax

I understand there’s already a logging tool for YUI, but if you don’t want to initiate the logger, here’s a quick fix:

YAHOO.namespace('IPC');
 
(function(Y) {
 
	var Log = {
		debug : function(message) {
			if (window.console && window.console.firebug) {
				console.debug(message);
			} else {
				alert("Debug Message: " + message);
			}
		},
 
		info : function(message) {
			if (window.console && window.console.firebug) {
				console.info(message);
			} else {
				alert("Info: " + message);
			}
		},
 
		warn : function(message) {
			if (window.console && window.console.firebug) {
				console.warn(message);
			} else {
				alert("WARNING: " + message);
			}
		},
 
		error : function(e) {
			if (window.console && window.console.firebug) {
				switch (typeof e) {
					case "boolean":
					case "number":
					case "string":
						console.error(e);
						break;
					case "object":
						console.group(e.name);
						console.error(e.message);
						if (e.object) {
							console.dir(e.object);
						}
						if (e.xml) {
							console.dirxml(e.xml);
						}
						console.trace();
						console.groupEnd();
						break;
					default:
						Y.IPC.Log.warn("Problem logging error. Unknown error type: '" + typeof e + "'");
						console.error(e);
				}
			} else {
				var message = "FATAL ERROR!: ";
				switch (typeof e) {
					case "boolean":
					case "number":
					case "string":
						alert(message + e);
						break;
					case "object":
						alert(message + e.name);
						break;
					default:
						Y.IPC.Log.warn("Problem logging error. Unknown error type: '" + typeof e + "'");
						alert(message + e);
				}
			}
		},
 
		throwError : function(info) {
		    var error = new Error(info.message);
 
		    if (info.name) {
				error.name = info.name;
		    } else {
				error.name = 'Error';
		    }
 
		    if (info.object) {
				error.object = info.object;
		    }
 
		    if (info.xml) {
				error.xml = info.xml;
		    }
 
		    throw error;
		}
	}
 
	Y.IPC.Log = Log;
})(YAHOO);

You’d use it in the same way as before, either a separate method in your object, use one of the logging methods directly, or use the throw method directly.

We’ve been looking around at what’s available and what we think could possibly suit exemplar best. We’re looking for:

• simplicity
• extensibility
• good performance

I can’t see any of us wanting to build our own framework when there are so many good ones around, so that’s out of the question. So I guess the real competitors are:

• Scriptaculous
• jQuery
• Mootools
• YUI
• Dojo

I’ve personally looked at the 1st 3 in depth and wish to look at the last 2 aswell before making any proposal. So far I feel that once you’ve got to grips with any of them, they become very natural and easy to use.

The prototype framework was the first JavaScript framework I had ever used and was immediately impressed. The syntax is lovely and especially coming from a OO background, being able to create patterns and separate your code into classes and objects was a real relief and most of our work is already using this framework, we could simply revisit it. However, it is slow… real slow. When creating a mass of libraries the page load gets very heavy. I also found that some things didn’t seem consistent, and doing small tasks could take quite a while.

Next, I moved onto Mootools. It’s a very, very sweet framework. It felt like someone got hold of prototype, pulled it apart, tore out all the unnecessary bits and put it together again. It’s solid, really quick and the syntax is very familiar to prototype. I was originally introduced to it by our favourite French man Fabien about a year ago, but it’s lame website didn’t sell it to me. Now that I’ve actually used it I can’t see why this wouldn’t be a good one to choose, other than there isn’t a much of a community yet. This also means, less developers are going to know it. If we were to get another developer on board, there’s a small chance they will know how to use it.

Next, the mother, jQuery. Syntactically, totally different to the other 2, but it can live up to it’s name. It feels a bit strange to use after coming from the OO style frameworks, but it’s very, very simple. It’s so simple in fact, I felt like I was cheating. There’s no way that it would ever get confusing bouncing code from one developer to another and it’s real simple to pick up. The community is pretty large and a lot of people swear by it. Although the other two are good competitors and I wouldn’t mind using any, for IPC, I feel jQuery is the right move.

(So far anyway. To be continued…)

Here’s where I am so far, I’ve created an error throwing plugin which will take several parameters; an exception name, a message and a number of debugging objects (like a XML object or a JavaScript object).

You would use it like so:

$.throwError({
  name    : 'MyException',
  message : 'You simply can\'t do that!',
  object  : $(this),
  xml     : $('#mungElement')
});

…or… it would be better to have a method for each plugin to create the above:

var handleError = function(message, debugInfo) {
  var error = {
    name    : 'MyPluginError',
    message : message
  };
  error = $.extend(error, debugInfo);
  $.throwError(error);
};
 
if (!thisWillWork) {
  handleError('You simply can\'t do that!', {xml: this});
}

Then, I have a logging plugin which can be used for catching these errors:

try {
  $('#ticker').ticker();
} catch(e) {
  $.log.error(e);
}

The ‘$.log.error’ method checks if a ‘console’ is available and then records the error as a traced exception with the given debug objects displayed. If the console is not available, it will then use the alert function.

I intend on extending this functionality so that the error will be displayed in a nicely formatted popup (if the console isn’t available).

Obviously we don’t want this to be displayed on production so another feature will be to separate environments. Does anyone have any suggestions on how to do this? I was thinking putting another query string on the URL, for instance: http://mysite.com/mung.html?_js_dev=1

Source code for the plugins:

(function($) {
  $.log = {};
 
  $.log.debug = function(message) {
 
    if (window.console && window.console.firebug) {
      console.debug(message);
    } else {
      alert("Debug Message: " + message);
    }
 
  };
 
  $.log.info = function(message) {
 
    if (window.console && window.console.firebug) {
      console.info(message);
    } else {
      alert("Info: " + message);
    }
 
  };
 
  $.log.warn = function(message) {
 
    if (window.console && window.console.firebug) {
      console.warn(message);
    } else {
      alert("WARNING: " + message);
    }
 
  };
 
  $.log.error = function(e) {
 
    if (window.console && window.console.firebug) {
      switch (typeof e) {
        case "boolean":
        case "number":
        case "string":
          console.error(e);
          break;
        case "object":
          console.group(e.name);
          console.error(e.message);
          if (e.object) {
            console.dir(e.object);
          }
          if (e.xml) {
            console.dirxml(e.xml);
          }
          console.trace();
          console.groupEnd();
          break;
        default:
          $.log.warn("Problem logging error. Unknown error type: '" + typeof e + "'");
          console.error(e);
      }
    } else {
      var message = "FATAL ERROR!: ";
      switch (typeof e) {
        case "boolean":
        case "number":
        case "string":
          alert(message + e);
          break;
        case "object":
          alert(message + e.name);
          break;
        default:
          $.log.warn("Problem logging error. Unknown error type: '" + typeof e + "'");
          alert(message + e);
      }
    }
 
  };
 
  $.throwError = function(info) {
 
    var error = new Error(info.message);
 
    if (info.name) {
      error.name = info.name;
    } else {
      error.name = 'Error';
    }
 
    if (info.object) {
      error.object = info.object;
    }
 
    if (info.xml) {
      error.xml = info.xml;
    }
 
    throw error;
 
  };
})(jQuery);

For some unknown reason, occasionally my PHP IDE decides, by itself, to start converting my unix line endings to Windows ones. Yes, I do have the correct configuration setup. So, while this bug in the IDE exists, I like to run a quick command in my Ubuntu shell before commiting the code back into the repository.

First, you need a little app called flip (available for multiple platforms but I’ll focus on Ubuntu).

sudo apt-get install flip

Next, head to your project root folder and run the following command:

for i in `find . | grep -v "\.svn"`; do flip -vu $i; done;

This will first find all non-Subversion files then flip them to Unix-format line endings. And don’t worry about binary files, these will be untouched unless you explicitly tell flip to convert these using the -b option.

On Solaris and other linux flavours, you will probably have access to dos2unix which does the same thing. The syntax is a little different:

dos2unix <filename> <filename>

That’s not a typo, specify the filename twice otherwise you’ll get the updated content spewed out at you in STDOUT.

What you’ll probably want in most situations is for the session not to die (or ‘expire’) until the user closes their browser. Unfortunately, there is no server-side way of knowing for certain when the browser is closed and can only assume it has been closed after a period of inactivity (user hasn’t made any requests).

First, let’s take a brief look at how the default PHP session handler works…

Before a session can be used, the session_start() function must be called. This function will perform the necessary steps to initialise a new session and read in any data from an existing one. In addition, this method also does some tidying up which ultimately kills your sessions prematurely.

To keep session data tidy on your server, PHP will perform some ‘garbage collection’ (GC) — that is, PHP will search for any session data that it thinks is old then deletes it. The default session handler uses a session.gc_maxlifetime configuration option which allows the application to set the lifetime of its session. This value is in seconds and defaults to 1440 (24 minutes). Therefore, any sessions that have been inactive for more than 24 minutes will be considered dead. This is not very helpful in Content Management Systems where it can take longer for the user to write their copy, only to be logged out when they come to submit the content.

One other little quirk that PHP likes to throw at you is the issue that arises when attempting to store session data with varying lifetimes in the same directory. What the default handler will do in this case is get the shortest lifetime and apply it to all sessions in the same folder. For example, let’s say you have Project A which used a session lifetime of 1440 and Project B which used 2400, both storing their session data in /tmp/sessions. It”ll save you a headache to know that Project B sessions will die after 1440 seconds. There are two obvious solutions for this: 1) create a subfolder for each project (e.g. /tmp/sessions/myproject; or 2) create a subfolder for each lifetime (e.g. /tmp/sessions/1440).

As a sidenote — to minimise the load that GC process puts on the server, PHP will not perform a GC every time the session_start() is called. Instead, the directives session.gc_probability and session.gc_divisor can be set. For example, 1 and 100, respectively, means that there is a 1-in-100 (1%) chance that PHP will perform a GC when a session is started (more information available in the PHP manual).

So, how do we change the default lifetime of 24 minutes? There are two solutions:

1. Play around with a few PHP settings, either in the php.ini file or at runtime using ini_set(), so that they have a longer lifetime
2. Create a custom session handler with a more complex GC strategy

In most instances you’ll probably go for the first option as it is relatively simple and probably faster than most custom solutions. So, to get you started, here is a snippet of code which will create a 24-hour session (you could class this as an ‘infinite’ session for most typical cases).

// Choose your desired lifetime
$lifetime = 86400; // 24 hours
 
// Consider sessions dead after 24 hours
ini_set('session.gc_maxlifetime', $lifetime);
 
// Store the sessions in a subdirectory based on the lifetime
ini_set('session.save_path', ini_get('session.save_path') . '/' . $lifetime);
 
// Now start the session as usual
session_start();

Let us know how you get on!