JQuery_ Novice to Ninja - Earle Castledine [77]
namespaces: "cool",
boolean = true,
pi = 3.14159,
css = {
"color": "#c0ffee",
"top": 0
},
setup: function() {
TRKR.one = 1;
…
},
exclaim: function() {
alert("hooray");
}
};
This code block results in exactly the same namespace object as the one we saw before, and it’s up to you which you prefer. Most of the code you’ll encounter in the remainder of the book will make use of namespacing, whenever it’s appropriate.
Scope
In programming, scope refers to the area of code where a defined variable exists. For example, you can define a variable as global by declaring it outside of any loops or constructs. Global variables will be accessible from anywhere in your code. Likewise, a variable that you declare inside a construct (such as a function or an object) is said to be local to that construct.
This seems simple, but it can become messy when we start defining callback methods for our Ajax requests, because the callback will often be run in a different context than the one where it was defined. So if you try to refer to this in a callback, expecting it to point to your widget namespace, you’ll be unpleasantly surprised: it might be undefined, or it might refer to something else entirely. For example:
var WIDGET = {};
WIDGET.delay = 1000;
WIDGET.run = function() {
alert(this.delay); // 1000 … good!
$(p).click(function() {
alert(this.delay) // undefined! bad!
});
};
When a p tag is clicked, our event handler runs in a different context than the widget object itself. So this.delay will most likely not exist (and if it does, it’s a different variable to what we wanted anyway!). There are a few ways we can deal with this, but without being too JavaScripty, the easiest way is to store the widget’s scope in a variable:
var WIDGET = {};
WIDGET.delay = 1000;
WIDGET.run = function() {
alert(this.delay); // 1000 … good!
var _widget = this;
$(p).click(function() {
alert(_widget.delay) // 1000 … yes!
});
};
By setting _widget to point to this in the context of the widget, we’ll always be able to refer back to it, wherever we are in the code. In JavaScript, this is called a closure. The general convention is to name it _this (though some people also use self). If it’s used in a namespacing object, it’s best to name it with an underscore (_), followed by the widget name. This helps to clarify the scope we’re operating in.
Client-side Templating
Most of the menus and effects we’ve seen so far have contained static content. Of course, most menu text is unlikely to change, but as we explore Ajax-enabled widgets, the need to inject and replace text dynamically becomes more of an issue. This brings us to the problem of templating: where do you put the markup that will structure the content you’re inserting into your pages?
There are a number of ways you can approach this issue. The simplest is to replace the entire contents of the pane every time it’s displayed—say, via the html action. Whenever we need to update a content pane, we replace its entire contents with new markup, like so:
$('#overlay').html("
You have " + cart.items.length +
↵" items in your cart.
");
Note: Data Sources
Throughout our discussion of templating we’ll be assuming that the content we need to update is coming from some fictitious JavaScript data source (like cart.items in the above example). The format of your data source is likely to vary widely from project to project: some will be pulled in via Ajax, some injected directly via a server-side language, and so on. Evidently those parts of the code will need to be adapted to your needs.
Directly writing the HTML content is fine if we only have a small amount of basic markup—but for more elaborate content it can quickly lead to a nasty mess of JavaScript or jQuery string manipulation that’s difficult to read and maintain. You will run into trouble if you try to build complex tables via string concatenation.
One way of circumventing this problem is to provide hooks in your HTML content, which can be populated with data when required:
You