SitePoint » Tools and Libraries

Unheap.com: a Better jQuery Plugin Repository?

Craig Buckler — Fri, 03 May 2013 16:36:48 +0000

I’ve never been particularly complimentary about the official jQuery Plugin Registry. The team are working on it, but perhaps the kindest observation is that it’s “ctional” — functional with all the “fun” removed. The system lacks an easy interface, good search facilities, online demonstrations, developer ratings and reviews.

As an alternative, why not try unheap.com — a new independent jQuery plugin repository…

The benefits of unheap.com become apparent the moment you use it:

The site has a gorgeous dynamic and responsive interface — it’s a pleasure to use
Plugins are categorized in sections and sub-sections for interface, inputs, media, navigation and miscellaneous code.
The search facility works well.
Plugin lists have direct links to demonstration pages and videos.
Related plugins are listed.
User views, votes and bug reports are recorded.
Social media sharing facilities are provided.
An RSS feed of new and updated plugins is available for you to check in ~~Google Reader~~, erm, a compatible RSS Reader.
The plugin submission process is easy and straight-forward.
Almost 700 plugins are available at the time of writing.

I’m impressed. Unless the jQuery team can produce a system as nice as unheap.com, perhaps they should give up now and adopt it as the “official” repository?

Unless you’ve found something better?…

Selective Content Loading

Andrew Fisher — Wed, 03 Apr 2013 13:32:22 +0000

One of the techniques we talk about in Jump Start Responsive Web Design is called Selective Content Loading (SCL). This technique is really useful in situations where you want to load small pieces of data into an already loaded page in a structured way. When would this be useful?

When you have serious bandwidth issues between your server and the end user’s device (for example, on a mobile connection that is moving on a poor network with lots of errors and having to deal with cell handoff).
When your pages are largely the same structurally from page to page and simply reloading the content saves many requests.
If you have chunked your content nicely and want to simply load in the next piece in the sequence (for example, infinite scrolling on a Twitter feed)

Some of these issues can be dealt with by good caching and using local storage and these should definitely be explored as good practices generally. However, even with smart asset caching you still require server round trips to retrieve a document, all the page HTML still has to be sent to the browser and then the browser still has to render the page.

If your page has only added a couple of additional bits of data (for example, a tweet) or is only changing a small amount of content (for example, the details for a product) then SCL may be a good option for you. This doesn’t work in every circumstance and it also causes a number of possible issues with URLs, browser history and what content gets spidered on a “page” by search engines (if this important to you).

Recapping our approach from Jump Start RWD, this is what we’re going to do conceptually:

On the first page request we’ll load up all of the page content including the site navigation, content layout, CSS and JS files as normal.
After the page has loaded we’ll override all of the links in our page to make them XHRs rather than a standard request for a document.
We’ll then process the response (the XHR response will only be the internal page content in JSON rather than the entire page) and overwrite the content that was in the page.
We can then use pushState() to modify our browser history (so the URL updates to something shareable and we can go backwards if needs be).

Here’s an example that should illustrate the point simply. The content has been truncated purposefully in order to keep this concise.

We’re going to set up a page that can load content about books without having to reload the entire page, just the pertinent content. We’ll also use pushState() from the History API to ensure that if the user wants to share or come back to the URL they’ll be able to do so.

To make things simple to express, we’re going to use jQuery for the DOM manipulation and a JavaScript templating library called Handlebars.js. If you haven’t checked out JavaScript templating options and what they can do, Handlebars is an excellent choice to get your feet wet.

The core of our solution relies on the fact that URLs can respond differently depending on whether they are an XHR or a normal HTTP request. If the server gets a normal request then the view will deliver the full HTTP response (containing all the document and then the JS, CSS etc). If the server gets an XHR, it will respond with JSON which only contains data about the book requested.

So, as an example, the standard HTTP response for the “Frankenstein” page looks like this:




  
 
var original = null;
var backtostart = true;
 
  


  
      Moby Dick
      Gulliver's Travels
      Frankenstein
  
  
      
          Frankenstein
              Mary Shelley
              Doctor creates artificial life

NB you can download code used in this article in a zip file linked at the end of this article

However, the equivalent JSON response for an XHR will look like this instead:

{
  "location": "/frankenstein",
  "title": "Frankenstein",
  "author": "Mary Shelley",
  "synopsis": "Mad doctor creates artificial life"
}

All the code required to make the selective loading work is requested and loaded in the first request. After that, we only get the data and then load it into the template. Let’s take a look at how the code works.

NB you can download code used in this article in a zip file linked at the end of this article

Handlebars uses a script element to create a template for what an article looks like (this content won’t be rendered by the browser as it won’t take an action on its type). Variable locations are defined using {{variable}} syntax. You can do a lot more with Handlebars (conditionals, loops, block execution etc) that we aren’t using in this instance though. Note the ID for the script, we need this so we can pass it into the Handlebars template compiler.

In our document ready function, we grab the HTML from the template script tag we defined above and then we compile it into a template object we can use with new data later.

  var source = $("#story-template").html();
  var template = Handlebars.compile(source);

Next, we define a function we can use for our link onclick event handler. Here we’re simply stopping the actual request to the file by preventing its default behaviour. From there we make a jQuery XHR that returns JSON to the URL that was defined in the link’s HREF attribute.

  var story_link_handler = (function(evt) {
      evt.preventDefault();
      $.get(this.href, function(data) {
          $("#contentarea").html("");
          $("#contentarea").html(template(data));
          history.pushState({url:data.location}, data.title, data.location);
      }, "json");
  });

When the response comes back, we simply overwrite the div content area that holds all our book data.

$("#contentarea").html(template(data));

We also use pushState() to push the URL we just requested onto the browser history so we can go backwards using the back button.

history.pushState({url:data.location}, data.title, data.location);

That’s not quite the whole picture with pushState(), though, in order for it to “just work” for the user. We next create a popstate event handler on the window so that when the user hits the back button we can update the content with the appropriate data for the book. In this case we’re going and getting the data again using an XHR. With pushstate, it’s possible to store data in a state object. In our case the amount of data is small and it’s bad practice to load up the user’s browser with additional data (especially on mobile) so only do it if you can guarantee it’s a tiny amount.

  $(window).bind("popstate", function(evt) {
      if (event.state) {
          url = event.state.url;
          $.get(url, function(data) {
              $("#contentarea").html("");
              $("#contentarea").html(template(data));
          }, "json");
      }
  });

One of the things we need to consider with this technique is what happens when the browser gets back to the start of the list. That is, you’ve popped all of your XHRs off the stack and you’re back to where you started.

To remedy this, we use a flag to determine if we’re back to the start or not and we save the content that was in #contentarea so we can replace it. You can use other techniques such as simply hiding the original content area or storing the original document’s JSON.

We then update the popstate event to check if there’s no event.state. If so, we revert to our original form.

$(window).bind("popstate", function(evt) {
              if (event.state) {
                  url = event.state.url;
                  $.get(url, function(data) {
                      $("#contentarea").html("");
                      $("#contentarea").html(template(data));
                  }, "json");
               backtostart = false;
              } else {
               if (! backtostart) {
                  // revert the content to the original
                  backtostart = true;
                      $("#contentarea").html("");
                      $("#contentarea").html(original);
               } else {
                 // store original content to retrieve later
                 original = $("#contentarea").html();
                    backtostart = false;
               }
            }
          });

Finally, we add our click event handler to all the relevant links. In our instance, we’re just using the links in the list, but in practice you could do this to a whole range of links based on class or HREF attributes.

$("ul#storylist li a").bind("click", story_link_handler);

The rest of the page is the page structure and the actual content that was requested – in this case the /frankenstein URL.

As can be seen, this approach gives us a nice, responsive setup. The initial page request is a little heavier (in this case about 1Kb) but provides all of the scaffolding needed to layout the page and provide the interactions. Subsequent requests get the benefit of only having to return very small snippets of data, which are then loaded into the template.

The URL is updated using pushState() which means the user can still share the URL using intents or copy and paste and that URL will work properly for whomever it is shared with. You also get the benefit that each document still exists properly – this means search engines can still correctly index your site, if that’s needed.

One of the things we need to be careful of with this technique is that if we have content that exists in many different templates, the benefits from only loading the snippets of data via XHR will be destroyed by having to load all of the different content templates into the first page request and masking it from the user until it’s used. Don’t forget, all of the HTML still has to be loaded, regardless of whether it’s used or not.

Where this technique works particularly well is in an “infinite scroll” scenario such as a stream of content or very long article. The content type doesn’t change almost at all (or only within a very defined way)—this technique does for “page content” as a whole what the lazy loading technique does for images within a page. If you’ve taken the time to chunk your content, this can be especially effective as it means you can avoid the user hitting “goto page 2” even though search engines will follow happily.

Download code files used in this article

Delve further into the world of responsive web design in Andrew’s new book with Craig Sharkie: Jump Start Responsive Web Design.

Unit Testing Backbone.js Applications

Stephen Thomas — Mon, 25 Feb 2013 09:00:01 +0000

After spending hours, maybe days, putting the finishing touches on an awesome new feature for your web application, you’re finally ready to see it in action. You add the new code to your JavaScript base, build the release candidate, and fire up your browser, expecting to be amazed. Then … Uh Oh… the new feature may be working fine, but some other critical part of your app – a part you didn’t touch while developing the new version – has gone horribly awry. Now you’re faced with the challenge of backtracking through days of work to try and figure out how you broke the existing code. Happy days are definitely not here again.

That very scenario has bitten me more than I’d like to admit. And if you’ve been coding awhile, you’ve probably seen it as well. Consider, though, what makes this scenario so painful. It isn’t really because our new code broke existing code; that’s inevitable in development. The real pain is that it took so long to notice the breakage. With so much development since we knew our application was working, there’s a vast amount of code in which the bug may be hiding. And, though it may seem a bit like hunting for a needle in a haystack, we have no choice but to dive it.

In this article we are truly going to banish this scenario from our JavaScript development. No more digging through hours, days, or weeks of code looking for a needle. The principle we’ll adopt is a simple one: find any bug as soon as we create it. That’s right; we’re going to set up a development environment and process that tells us immediately when we write code that introduces a bug. Furthermore, the extra effort we put into the process won’t go to waste once initial development is complete. The same test code that catches our development bugs will be completely reusable in an integration environment. We can easily incorporate the tests into our source code managements system, blocking bugs before they can even get into our code base.

In the four sections that follow, we’ll first look at the tools we need for a JavaScript testing environment. We’ll then consider a trivial application, one that’s simple enough to understand, yet has all the features and functionality that might exist in a real production web application. The final two sections demonstrate how we can use our environment to test the example app during development and, once initial development is complete, during integration.

Assembling a JavaScript Testing Environment

Our unit testing nirvana requires some development tools that may not be in your workbench (yet). The news, both good and bad, is that there are options aplenty. That’s good news because it gives us options, and that’s bad news because the pace of front end development today means that there are far too many options. To focus our evaluation, let’s be explicit about our top two goals. Everything else is secondary:

Our environment must support frictionless, continuous testing during development.
Tests created during development must be equally usable in integration.

Execution Environments

For JavaScript coding, there is no better development environment than the modern web browser. Whether your taste is Firebug or Webkit’s Developer Tools, the browser supports live DOM inspection and editing, full interactive debugging, and sophisticated performance analysis. Web browsers are great for development, and so our test tools and environment must integrate with in-browser development. Web browsers, however, are not so great for integration testing. Integration testing often takes places on servers somewhere in the cloud (or a least somewhere in the data center). Those systems don’t even have a graphical user interface, much less a modern web browser. For efficient integration testing, we need simple command line scripts and a JavaScript execution environment that supports them. For those requirements, the tool of choice is node.js. Although there are other command line JavaScript environments, none has the breadth and depth of support to match node.js. In the integration phase, our test tools must integrate with node.js.

Test Framework

Now that we’ve established that our test tools must support both web browser and node.js environments, we can narrow the choices enough to select a core test framework. Many JavaScript test frameworks exist, but most are heavily biased towards browser testing; getting them working with node.js is usually possible, but often requires inelegant hacks or tweaks. One framework that does not suffer from this problem is Mocha, which justifiably describes itself as:

Mocha is a feature-rich JavaScript test framework running on node and the browser, making asynchronous testing simple and fun.

Originally developed for node.js, Mocha has been extended to readily support web browsers as well. By using Mocha as our test framework, we can write tests that support both development and integration without modification.

Assertion Library

Unlike some JavaScript test frameworks, Mocha was designed for maximum flexibility. As a consequence, we’ll have to choose a few additional pieces to make it complete. In particular, we need a JavaScript assertion library. For that, we’ll rely on the Chai Assertion Library. Chai is somewhat unique in that it supports all of the common assertion styles – assert, expect, and should. Assertion styles determine how we write tests in our test code. Under the covers, they’re all equivalent; it’s easy to translate tests from one assertion style to the other. The main difference in assertion styles is their readability. The choice of assertion style depends mostly on which style you (or your team) find most readable, and which style produces the most understandable tests. To see the difference, consider developing a trivial test for the following code:

var sum = 2 + 2;

A traditional, assert-style test could be written as:

assert.equal(sum, 4, "sum should equal 4");

That test gets the job done, but unless you’ve grown accustomed to old-school unit testing, it’s probably a little challenging to read and interpret. An alternative assertion style uses expect:

expect(sum).to.equal(4);

Most developers find expect-style assertions easier to read and understand than assert-style tests. The third alternative, should, makes test assertions even more like natural language:

sum.should.equal(4);

The Chai library supports all three assertion styles. In this article we’ll stick with should.

Spies, Stubs, and Mocks

Most web apps, including the trivial example we’ll consider in this article, rely on third party libraries and services. In many cases, testing our code will require observing – or even controlling – those libraries and services. The Sinon.JS library provides a lot of tools for testing those interactions. Such tools fall into three general classes:

Spy. Test code that observes calls to functions outside of the code under test. Spies do not interfere with the operation of those external functions; they merely record the invocation and return value.
Stub. Test code that stands in for calls to functions outside of the code under test. The stub code doesn’t attempt to replicate the external function; it simply prevents unresolved errors when the code under test accesses the external function.
Mock. Test code that mimics functions or services outside of the code under test. With mocks, test code can specify the return values from those functions or services so it can verify the code’s response.

Along with the Sinon.JS library itself, we can augment the standard Chai assertion library with Sinon.JS Assertions for Chai.

A Unit Test Development Environment

The final tool for our testing workbench is a development environment for unit testing. For our example we’ll use Test’em. Test’em is a collection of handy scripts to set up and run a continuous test environment. We could, if we chose to, write the scripts ourselves and manage the environment manually; however, Toby Ho (Test’em’s creator) has put together an awesome package that can save us the trouble.

The Example Application

To see our testing environment in action, let’s consider a simple application. Although pared to its bare essentials, this application includes all the functionality required for a real application. (Complete source code for the application is available on GitHub.)

[image src="http://jspro.com/files/2013/02/01-jstest-app.png"]

Users can see their list of todos, and they can click on a check box to toggle any todo’s status.

The Todos Database

Our application starts with a database table that holds the information for todos. Here’s the SQL that we could use to create that table.

CREATE TABLE `todos` (
  `id`       int(11)      NOT NULL AUTO_INCREMENT COMMENT 'Primary key for the table.',
  `title`    varchar(256) NOT NULL DEFAULT ''     COMMENT 'The text for the todo item.',
  `complete` bit(1)       NOT NULL DEFAULT b'0'   COMMENT 'Boolean indicating whether or not the item is complete.',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='To Do items.'

And here’s how the table might look after we’ve put some test data in it.

id	title	complete
1	A sample todo item in the database	0
2	Another sample todo item	1
3	Yet another sample todo item	0

As the table shows, our todos only include a primary key (id), a title, and a status bit to indicate whether or not they are complete.

A REST API

Our web application needs access to this database, so we’ll provide a standard REST interface. The API follows Ruby conventions, but can be easily implemented by any server technology. In particular:

GET api/todos returns a JSON-encoded array of all rows in the database.
GET api/todos/NNN returns the JSON representation of the todo with id equal to NNN.
POST api/todos adds a new todo to the database using the JSON-encoded information in the request.
PUT api/todos/NNN updates the todo with id equal to NNN using the JSON-encoded information in the request.
DELETE api/todos/NNN deletes the todo with id equal to NNN from the database.

If you’re not particularly fond of Ruby, the source code includes a complete PHP implementation of this API.

JavaScript Libraries

Our modest application is simple enough to implement in pure JavaScript without any libraries, but we have far bigger plans. We may be starting small, but eventually the app will feature amazing functionality and a delightful user interface. In preparation for that day, we’ll build on a framework that can support our ultimate killer app:

jQuery for DOM manipulation, event handling, and server communications.
Underscore.js to enhance the core language with many indespensible utilities.
Backbone.js to define the structure of the application in terms of models and views.

An HTML Skeleton

Now that we know the components that will comprise our application, we can define the HTML skeleton that will support it. There’s nothing fancy about it (yet), just a minimal HTML5 document, some JavaScript files, and a small bit of code to get things started.



  
    
    
  
  
    List of Todos

Testing During Development

Now that we’ve selected our tools and specified the application, it’s time to start development. Our first task is installing the tools.

Installing the Tools

Even though we’ll be developing in the browser, our test environment relies on node.js. The very first step, therefore, is installing node.js and the node package manager (npm). There are executable binaries for OS X, Windows, Linux, and SunOS on the node.js web site, as well as a source code for other operating systems. After running the installer, you can verify both node.js and npm from the command line.

bash-3.2$ node --version
v0.8.18
bash-3.2$ npm --version
1.2.2
bash-3.2$

Everything else we need is conveniently available as a node package. The node package manager can handle their installation, as well as any dependencies.

bash-3.2$ npm install jquery jsdom underscore backbone mocha chai sinon sinon-chai testem -g

Creating the Project Structure

The source code for this example includes a complete project structure with the following 15 files:

todos.html
testem.json
api/htaccess
api/todos.php
lib/backbone-min.js
lib/chai.js
lib/jquery-1.9.0.min.js
lib/sinon-1.5.2.js
lib/sinon-chai.js
lib/underscore-min.js
mysql/todos.sql
php-lib/dbconfig.inc.php
src/app-todos.js
test/app-todos-test.js
test/mocha.opts

Here is what each folder and file contains:

todos.html: The skeleton HTML file for our application, shown in full above.
testem.json: The configuration file for Test’Em; we’ll look at this in detail shortly.
api/: A folder for our REST API implementation.
- api/htaccess: Sample configuration for the Apache web server that supports our REST API.
- api/todos.php: PHP code to implement the REST API.
lib/: A folder for JavaScript libraries used by the app itself and the test framework.
- lib/backbone-min.js: Minified version of Backbone.js.
- lib/chai.js: Chai Assertion Library.
- lib/jquery-1.9.0.min.js: Minified version of jQuery.
- lib/sinon-1.5.2.js: Sinon.JS library.
- lib/sinon-chai.js: Sinon.JS Assertions for Chai.
- lib/underscore-min.js: Minified version of Underscore.js.
mysql/: A folder for MySQL code for the application.
- mysql/todos.sql: MySQL commands to create the application database.
php-lib/: A folder for PHP libraries and configuration for the application’s REST API.
- php-lib/dbconfig.inc.php: PHP database configuration for the REST API.
src/: A folder for our client-side application code.
- src/app-todos.js: Our application.
test/: A folder for test code.
- test/app-todos-test.js: Test code for our application.
- test/mocha.opts: Configuration options for mocha; we’ll look at this in the next section.

During development, we’re only interested in three of these files, testem.json, src/app-todos.js, and test/app-todos-test.js.

Configuring Test’Em

The last step before actual development is defining the Test’Em configuration. That configuration resides in the JSON-formatted testem.json, and it’s simple enough to create in any text editor. We simply specify that we’re using Mocha (Test’Em supports several frameworks), and we list the JavaScript files our application and our test code requires.

{
  "framework": "mocha",
  "src_files": [
    "lib/jquery-1.9.0.min.js",
    "lib/underscore-min.js",
    "lib/backbone-min.js",
    "src/*.js",
    "lib/chai.js",
    "lib/sinon-chai.js",
    "lib/sinon-1.5.2.js",
    "test/*.js"
  ]
}

Start Developing

Finally, we’re ready to code. In a command shell, navigate to the root folder of our project and execute the command testem. The Test’Em scripts will run, clearing the terminal window and giving us a URL in the upper right. Copy and paste that URL into our browser of choice and we’re off.

[image src="http://jspro.com/files/2013/02/02-jstest-testem.png"]

As soon as we launch the web browser, it will automatically execute any tests that we’ve defined. Since we’re just beginning development, we won’t have any code, nor any test cases. The browser will kindly point that out to us.

[image src="http://jspro.com/files/2013/02/03-jstest-browser-none.png"]

The terminal window from which we launched Test’Em will also give us the status.

[image src="http://jspro.com/files/2013/02/04-jstest-console-none.png"]

A First Test Case

In the spirit of true Test-Driven Development, we’ll begin by writing our first test case in the test/app-todos-test.js file. Like any good web app, we want to minimize global name space pollution. To do that, we’ll rely on a single global variable, todoApp, to contain all of our code. Our first test case will make sure that the global name space variable exists.

var should = chai.should();
describe("Application", function() {
  it("creates a global variable for the name space", function () {
    should.exist(todoApp);
  })
})

As you can see, we need one preliminary statement to tell Mocha that we’re using Chai assertions. Then we can begin writing tests. By convention JavaScript tests are organized into blocks (which can be nested into sub-blocks, and so on). Each block begins with a describe() function call to identify what part of the code we’re testing. In this case we’re testing the overall application, so that’s the first parameter to describe().

Within a test block, we document each test case by what it tests. That’s the purpose of the it() function. The way to read any test case is to combine the describe() and it() strings into a single statement. Our first test case, therefore, is

Application creates a global variable for the name space

The test code itself is inside the it() block. Our test case is

should.exist(todoApp);

Now we have a complete test case. As soon as we save the file, Test`Em automatically takes over. It notices that one of our files has changed, so it immediately reruns the tests. Not surprisingly (since we haven’t written any code for the application yet), our first test fails.

[image src="http://jspro.com/files/2013/02/05-jstest-browser-fail.png"]

The terminal window updates automatically as well.

[image src="http://jspro.com/files/2013/02/06-jstest-console-fail.png"]

To make the test pass, we must create the global name space variable. We shift to the srcapp-todos.js file and add the necessary code.

if (typeof todoApp === "undefined") todoApp = {};

As soon as we save the file, Test`Em once again springs into action. We immediately get updated results for our test cases.

[image src="http://jspro.com/files/2013/02/07-jstest-browser-pass.png"]

Step back for a moment and consider what’s happening! Every time we make a change, either to the test code or to our application, Test`Em immediately re-runs our entire test suite. All we have to do is keep Test’Em’s browser or terminal window visible in a corner of our screen, and we can see the health of our code in real time, as we’re developing. We’ll know as soon as we introduce a bug, even if the bug manifests itself in a part of the code different from where we’re working. No more digging back through hours, days, or weeks of new code to figure out when we introduced a bug.

Testing the Model

With our development environment now fully established, we can begin developing the application. Since our app shows a list of todos, it might be good to create a model for those todos. The model will need to keep track of both the title of the todo and it’s status. Let’s add a unit test that verifies we can create an todo with reasonable defaults.

describe("Todo Model", function(){
  describe("Initialization", function() {
    beforeEach(function() {
      this.todo = new todoApp.Todo();
    })
    it("should default the status to 'pending'",function() {
      this.todo.get('complete').should.be.false;
    })
    it("should default the title to an empty string",function() {
      this.todo.get('title').should.equal("");
    })
  })
})

There are several aspects of these tests worth noting.

We can nest test blocks within each other. One test block will contain all the unit tests for the todo model, and a sub-block of those tests focuses on initialization.
Within a test block, we can define functionality to execute before every test. That’s the purpose of the beforeEach() block. In the example above, we’re creating a new instance of a Todo before every test.
The Mocha framework automatically makes sure that the JavaScript context (i.e. the value of this) is consistent for all our test cases. That’s why we can define this.todo in one function (the beforeEach() parameter) and safely reference it in other functions (such as the it() parameters). Without Mocha working behind the scenes to provide this consistency, JavaScript would define different contexts for each function.

Of course, since we haven’t written the model code yet, all our tests will fail. (And we’ll know that immediately.) But once we’ve added the code for our model, the tests pass and we’re on our way.

todoApp.Todo = Backbone.Model.extend({
  defaults: {
    title: "",
    complete:  false
  }
})

Using Stubs for Third Party Functionality

Now that we have a simple model for todos, we can start to define its behavior. One thing our model should do is update the database whenever any of its properties change. In a unit test environment, however, we won’t have an actual database to check. On the other hand, we’re not actually writing any code to do the database update. Rather, we’re relying on Backbone to handle that interaction. That suggests a unit test strategy for this test case. All we need to know is that Backbone models use the save() method to update whatever backing store is persisting the model. In our case that backing store is the database. Here is the unit test code we can use:

describe("Persistence", function() {
  beforeEach(function() {
    this.todo = new todoApp.Todo();
    this.save_stub = sinon.stub(this.todo, "save");
  })
  afterEach(function() {
    this.save_stub.restore();
  })
  it("should update server when title is changed", function() {
    this.todo.set("title", "New Summary");
    this.save_stub.should.have.been.calledOnce;
  })
  it("should update server when status is changed", function() {
    this.todo.set('complete',true);
    this.save_stub.should.have.been.calledOnce;
  })
})

We’ve included some additional code before each test, and we’ve added a section of code to execute after each test. That extra code manages a sinon stub, a function that effectively nullifies another function in the code. In our case the stub nullifies the save() method of this.todo. With the stub in place, calls to the method won’t actually go to the Backnone library. Instead, sinon intercepts those calls and simply returns immediately. This behavior is important. If we tried to execute the actual Backbone save() method in a unit test environment, the call would fail because there would not be a database or server API available.

With the stub in place, our test cases can use it to verify the model’s behavior. In the first test case, we immediately set the todo’s title to a new value. Since that changes the title property, we want our model to update its backing store. To check that we simply verify that the stub was called. To get our model to pass these tests, we can look for change events and respond appropriately.

todoApp.Todo = Backbone.Model.extend({
  defaults: {
    title: "",
    complete:  false
  },
  initialize: function() {
    this.on("change", function(){ this.save(); });
  }
})

Testing the View

Of course, our app won’t do anyone any good if it doesn’t actually display the todos to users, and that requires creating some HTML. We’ll use Backbone views for that functionality. In our trivial app, we simply wish to render each todo as a list item. Here are the test cases that will get us started.

describe("Todo List Item View", function() {
  beforeEach(function(){
    this.todo = new todoApp.Todo({title: "Summary"});
    this.item = new todoApp.TodoListItem({model: this.todo});
  })
  it("render() should return the view object", function() {
    this.item.render().should.equal(this.item);
  });
  it("should render as a list item", function() {
    this.item.render().el.nodeName.should.equal("LI");
  })
})

We begin our tests of the view with two test cases. First we ensure that the view’s render() method returns the view itself. That’s a common and very convenient convention in Backbone because it allows method chaining. Our second test case verifies that the HTML element the render creates is a list item (

). The code necessary to pass these tests is a straightforward Backbone view.

todoApp.TodoListItem = Backbone.View.extend({
  tagName: "li",
  render: function() {
    return this;
  }
})

Next, we can develop the detailed content of that list item view. As an example, we want the full list item to look something like the following.


  
    
    Summary

For our test cases, we can take advantage of jQuery to extract individual elements from the view’s main element.

describe("Todo List Item View", function() {
  beforeEach(function(){
    this.todo = new todoApp.Todo({title: "Summary"});
    this.item = new todoApp.TodoListItem({model: this.todo});
  })
  describe("Template", function() {
    beforeEach(function(){
      this.item.render();
    })
    it("should contain the todo title as text", function() {
      this.item.$el.text().should.have.string("Summary");
    })
    it("should include a label for the status", function() {
      this.item.$el.find("label").should.have.length(1);
    })
    it("should include an  checkbox", function() {
      this.item.$el.find("label>input[type='checkbox']").should.have.length(1);
    })
    it("should be clear by default (for 'pending' todos)", function() {
      this.item.$el.find("label>input[type='checkbox']").is(":checked").should.be.false;
    })
    it("should be set for 'complete' todos", function() {
      this.save_stub = sinon.stub(this.todo, "save");
      this.todo.set("complete", true);
      this.item.render();
      this.item.$el.find("label>input[type='checkbox']").is(":checked").should.be.true;
      this.save_stub.restore();
    })
  })
})

Notice that in the last test case we’ve stubbed the model’s save() method. Since we’re changing a property from its default value, our model will dutifully try to persist that change to its backing store. In a unit test environment, however, we won’t have a database or a server API. The stub takes the place of the missing components and allows the tests to proceed without error. To get these tests to pass, we’ll have to add some additional code to our view.

todoApp.TodoListItem = Backbone.View.extend({
  tagName: "li",
  template: _.template(
    ""
    +   "/>"
    +   " <%= title %> "
    + ""),
  render: function() {
    this.$el.html(this.template(this.model.attributes));
    return this;
  }
})

Testing Model/View Interactions

Now that we’ve verified that our view implementation creates the right HTML markup, we can test its interaction with our model. In particular, we want to make sure that users can toggle a todo’s status by clicking on the checkbox. Our test environment doesn’t require an actual human user, so we’ll use jQuery to generate the click event. To do that, however, we’ll have to add content to a real live DOM. That content is known as a test fixture. Here is the unit test code.

describe("Todo List Item View", function() {
  beforeEach(function(){
    this.todo = new todoApp.Todo({title: "Summary"});
    this.item = new todoApp.TodoListItem({model: this.todo});
    this.save_stub = sinon.stub(this.todo, "save");
  })
  afterEach(function() {
    this.save_stub.restore();
  })
  describe("Model Interaction", function() {
    it("should update model when checkbox clicked", function() {
      $("").attr("id","fixture").css("display","none").appendTo("body");
      this.item.render();
      $("#fixture").append(this.item.$el);
      this.item.$el.find("input").click();
      this.todo.get('complete').should.be.true;
      $("#fixture").remove();
    })
  })
})

Notice that we’re once again stubbing the todo’s save() method. Otherwise, Backbone will try to update a non-existent backing store when we change the todo status with our simulated click.

For the test case itself, we begin by creating a

element with an id of fixture and we add that element to our live document. The live document, in this case, is the web page displaying the results of our tests. Although we remove the element immediately after verifying the test case, we also set its display property to none so it won’t interfere with Mocha’s display of the test results. The code that implements this functionality includes a small addition to the todo model. The addition is a new toggleStatus() method.

todoApp.Todo = Backbone.Model.extend({
  defaults: {
    title: "",
    complete:  false
  },
  initialize: function() {
    this.on("change", function(){ this.save(); });
  },
  toggleStatus: function() {
    this.set("complete",!this.get("complete""));
  }
})

In the view, we want to catch click events on the element and call this method for the model.

todoApp.TodoListItem = Backbone.View.extend({
  tagName: "li",
  template: _.template(
    ""
    +   "/>"
    +   " <%= title %> "
    + ""),
  events: {
    "click input": "statusChanged"
  },
  render: function() {
    this.$el.html(this.template(this.model.attributes));
    return this;
  },
  statusChanged: function() {
    this.model.toggleStatus();
  }
})

Testing the Collection

At this point our application is nearly complete. The only remaining functionality is collecting all the todos together. Naturally, we’ll use a Backbone collection. We’re actually not going to do anything special with our collection, so we don’t really need any unit tests.

todoApp.Todos = Backbone.Collection.extend({
  model: todoApp.Todo,
  url:   "api/todos"
})

We can, however, verify that our implementation of the collection’s view is appropriate. We want that view rendered as an unordered list (

describe("Todos List View", function() {
  beforeEach(function(){
    this.todos = new todoApp.Todos([
      {title: "Todo 1"},
      {title: "Todo 2"}
    ]);
    this.list = new todoApp.TodosList({collection: this.todos});
  })
  it("render() should return the view object", function() {
    this.list.render().should.equal(this.list);
  });
  it("should render as an unordered list", function() {
    this.list.render().el.nodeName.should.equal("UL");
  })
  it("should include list items for all models in collection", function() {
    this.list.render();
    this.list.$el.find("li").should.have.length(2);
  })
})

The view implementation is also straightforward. It tracks any additions to the collection and updates the view. For the initial render() it simply adds all the models in the collection one at a time.

todoApp.TodosList = Backbone.View.extend({
  tagName: "ul",
  initialize: function() {
    this.collection.on("add", this.addOne, this);
  },
  render: function() {
    this.addAll();
    return this;
  },
  addAll: function() {
    this.collection.each(this.addOne, this);
  },
  addOne: function(todo) {
    var item = new todoApp.TodoListItem({model: todo});
    this.$el.append(item.render().el);
  }
})

Bonus Tests: Verifying the API

Because our REST API perfectly matches the API that Backbone expects, we didn’t need any custom code to manage the API interaction. As a result, we don’t need any unit test cases. In the real world, you might not be quite as lucky. If your API doesn’t conform to Backbone conventions, you may need to override or extend some of the Backbone code to deal with the non-standard API. That extra code will need unit tests as well. Fortunately, it’s relatively easy to test API interactions, even in a unit test environment.

The easiest way to test API interactions relies on the fake server functionality of Sinon.JS. Unfortunately, that functionality is only available (currently) in Sinon’s browser implementation. It is explicitly excluded from the node.js implementation. There are some hacks to get it running in node.js, but those hacks are quite brittle and rely on internal implementation details. It would be best to avoid them if possible. Fortunately, we can get by without Sinon’s fake server.

The secret is knowing that Backbone relies on jQuery’s $.ajax() function to implement REST APIs. We can intercept the API interactions by stubbing that function. When we stub the function, we’ll want to substitute our own response. The yieldsTo() method of the stub gives us exactly that opportunity. It tells sinon what additional action it should take when the stub is called. Here’s a complete test case to verify that our collection correctly initializes itself using the REST API.

describe("Collection's Interaction with REST API", function() {
  it("should load using the API", function() {
    this.ajax_stub = sinon.stub($, "ajax").yieldsTo("success", [
      { id: 1, title: "Mock Summary 1", complete: false },
      { id: 2, title: "Mock Summary 2", complete: true  }
    ]);
    this.todos = new todoApp.Todos();
    this.todos.fetch();
    this.todos.should.have.length(2);
    this.todos.at(0).get('title').should.equal("Mock Summary 1");
    this.todos.at(1).get('title').should.equal("Mock Summary 2");
    this.ajax_stub.restore();
  })
})

Finished!

As you can see from the screen shot that follows, we’ve now written code that passes all the unit test cases. For the time being at least, development is complete.

[image src="http://jspro.com/files/2013/02/08-jstest-browser-all.png"]

Testing During Integration

Now that client-side development of our app is complete (and we have the tests to prove it), we can safely tuck our JavaScript into a source code management system. It can then be integrated into the build process for the entire application. As part of that process, we want to execute all the test cases we’ve developed. That will ensure that the code that makes up the final deployment passes all the tests that we’ve defined. It will also protect against "minor tweaks" to the code that inadvertently introduce new bugs.

During the build process, we’ll likely want to execute our tests from the command line rather than in a web browser. We don’t need the details of individual test cases, just an assurance that they all pass. Node.js makes it easy enough to accommodate this requirement. We only need to make a few small additions to our source code and unit test code files.

Our code needs these modifications because node.js handles global variables differently than web browsers. In a web browser, JavaScript variables are, by default, global in scope. Node.js, on the other hand, confines variables to their local module by default. In that environment, our code won’t be able to find the third-party libraries it needs (jQuery, Underscore, and Backbone. If we add the following statements at the beginning, though, node.js will resolve references to these libraries appropriately. We’ve constructed these statements so that they do no harm in the web browser, so we can leave them in the code permanently.

var jQuery   = jQuery   || require("jquery");
var _        = _        || require("underscore");
var Backbone = Backbone || require("backbone");
Backbone.$   = jQuery;

We also need to adjust our test code. The test scripts need access to their own libraries (jQuery, Chai, Sinon.JS, and sinon-chai). In addition, we need to add a little extra to simulate a web browser’s Document Object Model (DOM). Recall that our tests for click handling required us to temporarily add a "fixture"

to the web page. Node.js, of course, doesn’t normally have a web page. The jsdom node package, however, lets us emulate one. The code below creates a minimal, simulated web page for our tests.

if (typeof exports !== 'undefined' && this.exports !== exports) {
  global.jQuery = require("jquery");
  global.$ = jQuery;
  global.chai = require("chai");
  global.sinon = require("sinon");
  chai.use(require("sinon-chai"));
  global.jsdom = require("jsdom").jsdom;
  var doc = jsdom("");
  global.window = doc.createWindow();
}

The conditional that wraps these statements tests to see if we’re running in the node.js environment instead of a web browser. In a browser, the extra statements aren’t necessary, so we can safely skip them.

With those changes, we can execute the full test suite from the command line. Simply navigate to the project’s root folder and execute the command mocha. The result looks quite familiar.

[image src="http://jspro.com/files/2013/02/09-jstest-node.png"]

Of course, mocha returns an exit level to indicate whether or not all of the tests passed. That lets us automate the tests as part of a continuous integration process, or simply as a local pre-commit script to preserve our own sanity.

Conclusion

At this point we have accomplished our goals. We have a unit test environment that runs in the background during development and immediately notifies us when any test fails. The tests execute in a web browser, giving us full access to the browser’s development tools while we’re coding. The same tests also run equally well from a command line script, so we can automate their execution during the build or integration process.

Resources

Here are the main unit test resources used in the article.

Command line JavaScript execution environment: node.js
JavaScript unit testing framework: Mocha
Test Development Environment: Test’em
JavaScript assertion library: Chai Assertion Library
Spies, stubs, and mocks: Sinon.JS
Additional assertions: Sinon.JS Assertions for Chai

Introducing the Geeksphone by Mozilla

Colin Ihrig — Sat, 26 Jan 2013 10:00:36 +0000

Mozilla has been hard at work on their new operating system, Firefox OS. This week they took another step towards legitimacy with the announcement of developer preview devices – known as the Geeksphone. This article introduces Firefox OS and the Geeksphone to the JSPro audience.

Firefox OS, also known as Boot to Gecko or B2G, is a completely open source operating system designed around HTML5 standards. Under the Firefox OS model, every app is a web app. This means a few things. First, the learning curve is significantly smaller. There’s no need to learn a new language. Second, tying into the principles behind Mozilla, there is no proprietary app store. This means not being a slave to companies like Apple.

Development APIs

One of the most exciting aspects of Firefox OS is the variety of advanced APIs used to interact with the underlying device. These APIs, collectively known as the WebAPI, combine W3C standards with Mozilla’s own specifications. For example, WebAPI developers can access the phone’s address book using Mozilla’s Contacts API and control the phone’s vibration hardware using the W3C Vibration API. The full list of current and future APIs is available on the WebAPI Mozilla Wiki page.

Geeksphone Devices

Currently there are two phone slated for release – the Keon and the Peak. The Keon is the lower end model, while the Peak is slightly more powerful and targeted at “those who like to be one step beyond.” The specs of both phones are listed below.

Keon
CPU Qualcomm Snapdragon S1 7225AB 1Ghz.
UMTS 2100/1900/900 (3G HSPA).
GSM 850/900/1800/1900 (2G EDGE).
Screen 3.5″ HVGA Multitouch.
Camera 3 MP.
4 GB (ROM) and 512 (RAM).
MicroSD, Wifi N, Light & Prox. Sensor, G-Sensor, GPS, MicroUSB.
Battery 1580 mAh.

Peak
CPU Qualcomm Snapdragon S4 8225 1.2Ghz x2.
UMTS 2100/1900/900 (3G HSPA).
GSM 850/900/1800/1900 (2G EDGE).
Screen 4.3″ qHD IPS Multitouch.
Camera 8 MP (back) + 2 MP (front).
4 GB (ROM) and 512 (RAM).
MicroSD, Wifi N, Light & Prox. Sensor, G-Sensor, GPS, MicroUSB, Flash (camera).
Battery 1800 mAh.

Getting Involved

There are several ways to get involved with the B2G project. You can install the Firefox OS simulator, or actually booth the operating system on your own hardware. Soon you’ll be able to purchase one of the developer preview phones discussed above. No matter which route you take, you will definitely want to read over Mozilla’s getting started guide.

Conclusion

Only time will tell if Firefox OS is the next big thing or a bust. Some think that the completely open source nature of the project will help it succeed. Others feel that iOS and Android are simply too entrenched for another player to make much of a difference. However, it is certainly possible for Firefox OS to leave its mark, even if it isn’t the dominant player in the market – much like the Firefox browser.

Ten Useful JavaScript Libraries and jQuery Plugins for Web Developers

Syed Fazle Rahman — Mon, 14 Jan 2013 09:00:25 +0000

Whether you are a novice front end designer or an experienced web developer, every one of us has faced a situation where we write hundred lines of code and nothing seems to run as expected. If you have experience working in JavaScript and jQuery, then you might understand how troublesome it is to find a simple bug which was left behind unintentionally.

Thus, we turn to pre-coded libraries and plugins. These utilities help us solve some specific problem by simply including them in our programs. They were made to solve some frequently occurring problems for developers. It is always good to have them bookmarked or downloaded in a local folder for future use. This article presents ten of the best JavaScript libraries and jQuery plugins developed to solve some of the most frequently occurring tasks in a website’s interface.

#1 jQuery File Upload

[image src="http://jspro.com/files/2013/01/JQueryFileUpload.jpg" href="https://github.com/blueimp/jQuery-File-Upload"]

As the name suggest, jQuery File Upload is a jQuery plugin used as a widget in web pages for uploading files. Some of the best features of this plugin are simultaneous uploading of multiple files, progress bar display, drag and drop from the desktop, cancel and resume of uploads, image previews while uploading, etc. This plugin also supports chunked upload, which means larger files can be uploaded in smaller parts. It is compatible with any server side platform like PHP, Ruby, Python, Node.js, etc.

Source code

#2 Ideal Forms

[image src="http://jspro.com/files/2013/01/IdealForms.jpg" href="http://elclanrs.github.com/jq-idealforms/"]

Ideal Forms is a jQuery plugin for building HTML5 compatible forms. It supports form validation, customizable input types (select, file, radio, and checkbox), keyboard support, localization, custom datepicker using jQuery UI (fallback). This plugin works on Google Chrome, Opera, Firefox, IE8+, iOS5+, and Android 4.0+ browsers.

Source Code

#3 Form Accordion

[image src="http://jspro.com/files/2013/01/FormAccordion.jpg" href="https://github.com/OliverJAsh/FormAccordion"]

Form Accordion is a jQuery plugin used for hiding and displaying related fields conditionally. This plugin can save you lots of time when building a form for a wide range of audiences. You can add conditions to specify which field to appear next if a particular value is selected in the current field.

Source Code

#4 TextExt Plugin

[image src="http://jspro.com/files/2013/01/TextExtPlugin.png" href="http://textextjs.com/"]

TextExt Plugin is also a jQuery plugin that allows you to easily fill HTML text fields with suggestions. As you start typing in the text input field this plugin will show you a predefined set of suggestions matching what you have typed. TextExt is a great tool for making searches faster in web pages.

Source code

#5 Sisyphus.js

[image src="http://jspro.com/files/2013/01/Sisyphus.png" href="http://simsalabim.github.com/sisyphus/"]

Sisyphus.js is a script which helps visitors store form data locally in the browser. This script comes to the rescue when you are filling out a large form and all of a sudden you hit the close button of the browser accidentally. This script will fill the forms out for you automatically the next time you reload the page. This script is supported in Google Chrome 4+, Firefox 3.5+, Opera 10.5+, Safari 4+, and IE8+. For older version of IE (6 and 7) you have to load jStorage before loading Sisyphus.js.

Source Code

#6 jQuery Credit Card Validator

[image src="http://jspro.com/files/2013/01/jQueryCreditCardValidator.jpg" href="http://paweldecowski.github.com/jQuery-CreditCardValidator/"]

jQuery Credit Card Validator validates an input field every time the user inserts a value. It recognizes the card and highlights the card type when a correct number is provided. Some of the supported card types are American Express, Laser, Diners Club, JCB, Discover Card, Maestro, MasterCard, Visa, and Visa Electron.

Source code

#7 FTColumnflow

[image src="http://jspro.com/files/2013/01/FTColumnflow.jpg" href="https://github.com/ftlabs/ftcolumnflow"]

FTColumnflow is a JavaScript library that helps web designers fix inadequacies of CSS column layout. It is named so because it was developed by Financial Times as part of their website layout project. This library helps in managing complex newspaper/magazine style layout and has many important features like fixed position elements, configurable column widths and margins, grouping columns into pages, vertical and horizontal alignment, etc. FTColumnflow is compatible with Chrome 8+, Safari 5+, Firefox 10+, iOS 5+, Android ICS+, Playbook OS 2.0.1+, and IE 10+ browsers.

Source code

#8 FitText.js

[image src="http://jspro.com/files/2013/01/fittext.jpg" href="http://fittextjs.com/"]

FitText is a jQuery plugin to achieve responsive font types in your website. It resizes the headings in your website as per the ratio. It ignores the font size and uses minFontSize and maxFontSize to make the font flexible. If you are building a responsive or fluid design then you can use this plugin to resize the headings.

Source code

#9 money.js

[image src="http://jspro.com/files/2013/01/moneyJS.jpg" href="http://josscrowcroft.github.com/money.js/"]

money.js is a JavaScript library which allows your visitors to get correct and updated exchange rates for free. It uses the Open Exchange rate API as the source for the current exchange rate, but it also has features so you can change the source. This library can be used in any framework, application, or language as you wish. It is not restricted to JavaScript based projects only. The best thing about this plugin is that it charges you no fee. There are also no rate limits!

Source code

#10 gmaps.js

[image src="http://jspro.com/files/2013/01/GMapsJS.jpg" href="http://hpneo.github.com/gmaps/"]

Grab the power of Google Maps with this simple JavaScript library called gmaps.js. It helps you write simple lines of code for specifying what you need and the rest is done by the script. It locates areas, adds markers, shows routes, and has many other features. Some of the features include polylines, overlays, GeoJSON Polygons, Routes Advanced, Geofences, fusion tables layers, KML and GeoRSS layers, overlay map types, street view panoramas, geolocation, and geocoding. This library also has a jQuery plugin for it. So, if you are using jQuery then you can continue to use it without any collision problems.

Source code

Conclusion

We hope you will find these plugins and libraries useful for your work. We are looking forward to hearing from you. We will be back with another set of ten more useful JavaScript libraries and jQuery plugins very soon.

Understanding RequireJS for Effective JavaScript Module Loading

Rakhitha Nimesh — Mon, 07 Jan 2013 09:00:14 +0000

Modular programming is used to break large applications into smaller blocks of manageable code. Module based coding eases the effort for maintenance and increases reusability. However, managing dependencies between modules is a major concern developers face throughout the application development process. RequireJS is one of the most popular frameworks around for managing dependencies between modules. This tutorial examines the need for modularized code, and shows how RequireJS can help.

Loading JavaScript Files

Large applications often require a number of JavaScript files. Generally, they are loaded one by one using

function reserveProduct(){
  console.log("Function : reserveProduct");
  return true;
}

credits.js

function getCredits(){
  console.log("Function : getCredits");
  var credits = "100";
  return credits;
}

In this example, we are trying to purchase a product. First, it checks whether enough credits are available to purchase the product. Then, upon credit validation, it reserves the product. Another script, main.js, initializes the code by calling purchaseProduct(), as shown below.

  var result = purchaseProduct();

`What Can Go Wrong?`

In this example, purchase.js depends upon both credits.js and products.js. Therefore, those files need to be loaded before calling purchaseProduct(). So, what would happen if we included our JavaScript files in the following order?

Here, initialization is done before credits.js is loaded. This will result in the error shown below. And this example only requires three JavaScript files. In a much larger project, things can easily get out of control. That’s where RequireJS comes into the picture.

[image src="http://jspro.com/files/2012/12/requirejs-01.png" href="http://jspro.com/files/2012/12/requirejs-01.png" caption="Plain JavaScript Example" ]

`Introduction to RequireJS`

RequireJS is a well known JavaScript module and file loader which is supported in the latest versions of popular browsers. In RequireJS we separate code into modules which each handle a single responsibility. Additionally, dependencies need to be configured when loading files. Let’s get started by downloading RequireJS. Once downloaded, copy the file to your project folder. Let’s assume our project’s directory structure now resembles the following image.

[image src="http://jspro.com/files/2013/01/requirejs021.png" href="http://jspro.com/files/2013/01/requirejs021.png" caption="Folder Structure"]

All the JavaScript files, including the RequireJS file, are located inside the scripts folder. The file main.js is used for initialization, and the other files contain application logic. Let’s see how the scripts are included inside the HTML file.

This is the only code required to include files using RequireJS. You might be wondering what happened to the other files and how they are included. The data-main attribute defines the initialization point of the application. In this case, it is main.js. RequireJS uses main.js to look for other scripts and dependencies. In this scenario all the files are located in same folder. Using logic, you can move the files to any folder you prefer. Now, let’s take a look at main.js.

require(["purchase"],function(purchase){
  purchase.purchaseProduct();
});

In RequireJS, all code is wrapped in require() or define() functions. The first parameter of these functions specifies dependencies. In the previous example, initialization is dependent on purchase.js, since it defines purchaseProduct(). Note that the file extension has been omitted. This is because RequireJS only considers .js files.

The second parameter to require() is an anonymous function which takes an object that is used to call the functions inside the dependent file. In this scenario, we have just one dependency. Multiple dependencies can be loaded using the following syntax.

require(["a","b","c"],function(a,b,c){
});

`Creating Applications with RequireJS`

In this section we are going to convert the plain JavaScript example discussed in the previous section into RequireJS. We already covered main.js, so let’s move on to the other files.

purchase.js

define(["credits","products"], function(credits,products) {
  console.log("Function : purchaseProduct");
  return {
    purchaseProduct: function() {
      var credit = credits.getCredits();
      if(credit > 0){
        products.reserveProduct();
        return true;
      }
      return false;
    }
  }
});

First, we declare that purchase functionality depends on credits and products. Inside the return statement, we can define the functions of each module. Here, we have called the getCredits() and reserveProduct() functions on the objects passed. product.js and credits.js are similar, and are shown below.

products.js

define(function(products) {
  return {
    reserveProduct: function() {
      console.log("Function : reserveProduct");
      return true;
    }
  }
});

credits.js

define(function() {
  console.log("Function : getCredits");
  return {
    getCredits: function() {
      var credits = "100";
      return credits;
    }
  }
});

Both of these files are configured as independent modules – meaning they are not dependent on anything. The important thing to notice is the use of define() instead of require(). Choosing between require() or define() depends on the structure of your code, and will be discussed in the following section.

`Using require() vs. define()`

Earlier I mentioned that we can use both require() and define() to load dependencies. Understanding the difference between those two functions is essential to managing dependencies. The require() function is used to run immediate functionalities, while define() is used to define modules for use in multiple locations. In our example we need to run the purchaseProduct() function immediately. So, require() was used inside main.js. However, the other files are reusable modules and therefore use define().

`Why RequireJS is Important`

In the plain JavaScript example, an error was generated due to the incorrect order of file loading. Now, delete the credits.js file in the RequireJS example and see how it works. The following image shows the output of the browser inspection tool.

[image src="http://jspro.com/files/2012/12/requirejs-03.png" href="http://jspro.com/files/2012/12/requirejs-03.png" caption="RequireJS Example"]

The difference here is that no code has been executed in the RequireJS example. We can confirm it since nothing is printed on the console. In the plain JavaScript example we had some output printed on the console before generating the error. RequireJS waits until all the dependent modules are loaded before executing the functionality. If any modules are missing, it doesn’t execute any code. This helps us maintain the consistency of our data.

`Managing the Order of Dependent Files`

RequireJS uses Asynchronous Module Loading (AMD) for loading files. Each dependent module will start loading through asynchronous requests in the given order. Even though the file order is considered, we cannot guarantee that the first file is loaded before the second file due to the asynchronous nature. So, RequireJS allows us to use the shim config to define the sequence of files which need to be loaded in correct order. Let’s see how we can create configuration options in RequireJS.

requirejs.config({
  shim: {
    'source1': ['dependency1','dependency2'],
    'source2': ['source1']
  }
});

RequireJS allows us to provide configuration options using the config() function. It accepts a parameter called shim which we can use to define the mandatory sequences of dependencies. You can find the complete configuration guide in the RequireJS API documentation.

define(["dependency1","dependency2","source1","source2"], function() {
);

Under normal circumstances these four files will start loading in the given order. Here, source2 depends on source1. So, once source1 has finished loading, source2 will think that all the dependencies are loaded. However, dependency1 and dependency2 may still be loading. Using the shim config, it is mandatory to load the dependencies before source1. Hence, errors will not be generated.

`Conclusion`

I hope this tutorial helps you get started with RequireJS. Although it seems simple, it is really powerful in managing dependencies in large scale JavaScript applications. This tutorial alone is not enough to cover all the aspects of RequireJs, so I hope you learn all the advanced configurations and techniques using the official website.



Package Management for the Browser with Bower
Ian Oxley — Mon, 31 Dec 2012 09:00:24 +0000
Bower is a package manager for the browser. Developed by Twitter, and available via npm, it means the days of manually managing your client-side JavaScript packages could soon be a thing of the past.
 
To install Bower you’ll need to have Node and NPM installed. You can download and install Node from nodejs.org. NPM comes bundled with each binary package, so when you install Node, NPM should automatically be installed at the same time. You’ll also need to have Git installed, as Bower uses Git endpoints to locate packages. If you don’t have Git installed, you can download it from git-scm.com/downloads. Once you’ve got Node, npm, and Git installed, all you need to do now is open up your terminal and type:
npm install bower -g
If you’re new to NPM, the -g on the end means Bower will be installed globally, meaning we can run it from anywhere in any project directory. Let’s run Bower now and pass it the --help command to see exactly what it has to offer us:
  
bower --help
If you’re following along, you’ll see there’s commands to install, uninstall, and update packages, list the packages you’ve currently got installed, and search for new packages. We can also get help on any particular command by passing that command to help:
bower help list
bower list simply lists the packages we’ve installed. If we run it right now, we won’t see much as we haven’t installed any packages yet. Let’s fix that by installing jQuery using the following command.
bower install jquery
When you run this, you’ll see that Bower clones the package’s Git repository, caches the package in the ~/bower directory, then copies the package to our current project’s components directory (which Bower will create if it doesn’t exist). Once downloaded, the simplest way to include jQuery in your project is via a regular  


Knockout.js: An Introduction
Glenn Goodrich — Wed, 26 Dec 2012 09:00:22 +0000
The rise of sophisticated web applications, such as GMail, has given birth to an army of JavaScript frameworks. These frameworks allow you to, basically, create a client-side application within your web application. Terms such as “MVC” and other design patterns, once saved for only the server-side of the web, are now applied to just the the client bits of your code. The more popular frameworks these days are Backbone, Ember, and Knockout. This article will take a whirlwind look at the latter.
 
Knockout takes the Model-View-View-Model (MVVM) approach to application architecture. MVVM is a architectural pattern that has (some of) its roots in Microsoft and their Windows Presentation Foundation/Silverlight/Failed Attempt at making ASP.NET Web Forms usable. Being honest, I avoided Knockout due to these roots, and I am guessing that many developers do as well. It wasn’t until I inherited an application that uses Knockout that I was forced to I actually learn about it.
  
Yet again, I have been pleasantly surprised to know that my groundless developer bias was very wrong.
At Least it’s Not MVC
Looking at the Knockout home page, the key concepts it lists are:
Declaritive Bindings
Automatic UI Refresh
Dependence Tracking
Templating
I am not going to run through each of these, as you have the same access to their site. I will say what I think it means, in a nutshell. As I see it, the strength of Knockout is it’s data-binding. If you’ve never used a framework that binds the UI to a model (the view model, it this case) the core concept is that any changes to that model are immediately reflected in the view/UI. Adobe Flex is, in my opinion, the most well-known data binding framework. Data binding is enormously powerful, especially if you have pieces of your model strewn about the UI. Updating a value in one place and having 10 UI elements change as a result will bring a smile to any trollface.
Data-binding is the sweetest sauce that Knockout provides, but it is more than that. The templating is very powerful, and you can use any JavaScript templating library you like (jQuery Templates, mustache, etc). Knockout is also extensible, providing a plugin framework that we will take advantage of in the demo application I’ve put together to show Knockout in action.
Lick it, Lick it Good
The demo application is a simple, yet kind of disgusting, app called LinkLicker. The idea is that links are submitted and you lick the ones you like. Yes, I am a 4 year-old.
The server-side of this application is both a Rails app and irrelevant. Your server side application simply needs to spit back JSON, so it can be Sinatra or Rails or Cuba or whatever. I shant bore you with the details of the web app, but they are in the github repository if you simply must know.
The app shows a form that allows links to be submitted, a list of submitted links, and a list of links that have been licked by the current user. When a link has been licked, it’s icon changes. This, I am sure, is the next FacebookTwitter.
Setup
You will need the Knockout code available in your web app to make this work. I’ve put mine in the vendor directory, along with the most commonly used Knockout plugin. This plugin is the Knockout Mapping plugin, and it takes all the hard work out of mapping JSON from the server to JavaScript objects on the client.  Note: I won’t really cover the Mapping plugin in this article, but the important bit is it creates observables out of all our JSON properties when it maps the objects. You’ll see what observables are shortly.
Structurally, I like to put each “model” class in it’s own file on the client. LinkLicker really only has one model: Link. I also like to have a global class that represents my application that I call, unremarkably, App. The final directory sturcture for the JavaScript looks like:
[image src="http://jspro.com/files/2012/12/img1.png" href="http://rubysource.com/?attachment_id=4882"]
UI
The UI for LinkLicker was driven heavily by my desire to do as little as possible while still getting the Knockout concepts across. As I mentioned above, there is a form, as well as three lists of links. The three lists are All Links, New (meaning, unlicked), and licked links. As you may have surmised, a link can be in more than one of these lists at any given time. The screenshot of the UI is below:
[image src="http://jspro.com/files/2012/12/img2.png" href="http://rubysource.com/?attachment_id=4883"]
Bootstrap
Bootstrapping LickLinker consists of binding to the form and creating our three lists. We’ll make all of these properties on our App. Easy stuff.
var App = function() {
  this.newLink = ko.observable(new Link());
  this.mylinks = ko.observableArray();
  this.lickedLinks = ko.observableArray();
  this.allLinks = ko.observableArray();
};
You are likely wondering what all this observable madness be. When you make a property an observable, it becomes a super-powerful notifier of changes to that property. Knockout will keep track (as best it can, and it’s pretty good at it) of things that are interested in your property and notify then when it changes. The Observables docs on the Knockout site are great, and there are interactive tutorials to use as well.
In short, and if you can think ahead, when we bind our UI (form) to the newLink it will then notify our form of changes and vice-versa.
The other three properties are observableArrays. These are, conceptually, exactly the same as observables, except that they work on a collection. An observableArray will track what objects are in the array, and it has many helper methods to add and remove these objects. You can easily pop or push items onto an observableArray, slice it, get its length, reverse it, and many other methods you’d expect.
Again, since observables and observableArrays are notifiers of change, when we bind the lists in our UI to these lists of links, everything will be updated to reflect the latest state. Hopefully, this concept is sinking in.
The Model
The model for LinkLicker is just a link and it has 3 properties: url, description, and lickedByCurrentUser.
The Form
Knockout is all about data-binding, remember? As such, we can bind a new Link to the form and, then, as the user enters data it will populate this newly bound Link. In the code snippet above, we create our newLink property as an observable. Now, to bind it to the form:


 Link:
 
 Description:
 
 
 
In the above snippet, focus on the  line. Knockout offers a couple of different ways to bind parts of the DOM to the view model. This example uses “containerless bindings”, which means, it doesn’t create a DOM element for that declaration.
The other way to do it is to create a DOM element (such as a div) and add a data-bind attribute specifying the template. There are loads of examples on the Knockout site of the latter if you are confused.
That ko with: newLink tells Knockout to find the newLink property of whatever this view is bound to and scope everything within the block to it. This should be a bit clearer if you look at the input tags. Each input tag has a data-bind attribute that binds the value of that input to a property on newLink.
The Ties the Bind
With our UI in place, we need some mechanism to bind it to our view model. In this app, the view model is our global App class on the client. The App is bound to the view when the page is loaded, as shown here:
$(function(){
  App.globalApp = new App();
  ko.applyBindings(App.globalApp);
  App.globalApp.loadLinks();
});
Easy peasy.
Filtering a list can be done by creating two “computeds” (formerly dependentObservables). Here, let me show you:
this.allLinks = ko.observableArray();
this.lickedLinks = ko.computed(function() {
  return this.allLinks().filter(function(link) {
    return link.isLicked();
  });
}, this);
this.newLinks = ko.computed(function() {
  return this.allLinks().filter(function(link) {
    return !link.isLicked();
  });
}, this);
A computed is an observable that depends on the values of other observables. You can see that we filter the allLinks observableArray based on the value of isLicked() for each link. The second argument to the computed (this) is the context to bind the function.
Computeds are enormously helpful and you’ll find yourself using them everywhere.
Extending KnockoutJS
While Knockout has many, many bindings that you can use, such as text, html, css, visible, you will find occasions that require a new binding. Writing a custom binding is very simple. As an example, I am going to write a hidden binding which is the opposite of the visible binding. It’s is below:
ko.bindingHandlers.hidden = {
  update: function(element, valueAccessor){
    var value = ko.utils.unwrapObservable(valueAccessor());
    ko.bindingHandlers.visible.update(element, function() {
      return !value;
    });
  }
};
In the binding, I grab the value of the element being bound, and then pass it to the existing visible binding. The result is negated and returned.
Obviously, this is a trivial binding, but you can get very complex if needed. Google will show you bindings for jQuery UI elements, for example, along with thousands of other custom bindings that the community has authored.
Momma Said Wrap This Up!
There were many other aspects of Knockout I would like to cover, but I think we’ve taken a nice look across many of it’s features. Hopefully, when you are evaluating JavaScript frameworks, this article will help you make a decision.
Remember, the entirety of the LinkLicker source is yours to browse, use, mock, whatever on github.
If you have questions on LinkLicker or Knockout, hit me in the comments. Thanks for reading!
  


Creating HTML Templates with Mustache.js
Rakhitha Nimesh — Mon, 10 Dec 2012 09:00:47 +0000
Web applications use MVC architectures to separate business logic from the presentation views. Complex projects which involves large amounts of client side HTML manipulation with JavaScript can be difficult to maintain. In such scenarios we can use template systems to increase reusability and ease the task of managing views. Mustache.js provides a well documented template system which can be used to manage your templates. And, since mustache supports various languages, we don’t need a separate templating system on the server side. This article covers the basics of working with mustache.
 
Why We Need Template Systems
Most developers that are not aware of template systems create new chunks of HTML code and dynamically insert them into the DOM using JavaScript. A common way of doing this is to specify the HTML elements in a string and then set the innerHTML property or call the jQuery html() method. An example of this technique is shown below.
var dynamic_html = "HighlightedAuthor";
document.getElementByID("container").innerHTML = dynamic_html;
Another method for building the DOM is to create elements and append them individually, as shown below.
  
var title = document.createElement('div');
var highlight = document.createElement('span');
var highlight_text = document.createTextNode("Highlight");
var author = document.createElement('span');
var author_text = document.createTextNode("Author");
var container = document.getElementById('container');
highlight.appendChild(highlight_text);
title.appendChild(highlight);
author.appendChild(author_text);
title.appendChild(author);
container.appendChild(title);
Both the methods above can be used effectively to add elements dynamically into your document. Consider a situation where we have a very well designed bullet list which needs to be used across three different types of pages in our site. Using these techniques, we would have to repeat the HTML code the list in three different locations. This is generally considered to be bad coding practice.
In such scenarios we can use predefined templates in different locations without repeating the code. Mustache.js is a very popular template engine using JavaScript. Since mustache provides both server side and client side templates for numerous languages, we don’t have to worry about choosing separate template engines.
Getting Started with Mustache.js
Mustache is an open source logic-less template system developed for languages such as JavaScript, Ruby, Python, PHP, and Java. You can grab a copy of the library by visiting the official page on GitHub. Mustache provides templates and views as the basis for creating dynamic templates. Views contain the data to be included in the templates as JSON. Templates contain the presentation HTML or data with the template tags for including view data. Earlier, we mentioned mustache as logic-less. This means the templates will not contain any if-else conditions or for loops. Now, let’s get started on mustache templates using a simple example.


  
    Mustache.js Inline Method
    
    
  
  
    
  

First, we need to include the mustache.js file in the document. Then we can work on creating mustache templates. In the above example we have a view containing the name and occupation of a person. Then, we have the template inside the render() function with presentation code and tags for name and occupation data. Tags are indicated by the double braces, or mustaches, that surround them. Now, let’s take a look at how the render() method works.
Rendering Mustache Templates
The following code shows the implementation of the render() function inside the mustache.js file. Three parameters can be passed to render(). The first two parameters, template and view are mandatory. partials can be considered as dynamic templates which you can inject into your main template. In our previous example, we passed the template as an inline parameter and the view as the second parameter, and assigned the result to the output variable.
Writer.prototype.render = function (template, view, partials) {
  return this.compile(template)(view, partials);
};
This is the most basic form of templating with mustache. Let’s see the other methods available for creating more organized code.
Defining Mustache Templates
There are various methods for defining mustache templates in your application. These methods are similar to including CSS using inline styles, inline stylesheets, and external stylesheets. The example we discussed earlier can be considered as an inline method since we are passing the template directly to the function. This method prevents the possibility of reusable templates. Let’s see how we can define templates as inline script templates as opposed to directly passing to the function.
Templates as Inline Scripts
We can define template data inside of a 
You can include as many templates in a document as you wish with different IDs. When you want to use the template, get the HTML inside the script tag using innerHTML, and pass it as a template. Our first example will change to the following code.

As you can see, templates are stored separately and used dynamically when required. This method increases the possibility of reusing templates. However, using inline scripts limits the templates’ scope to a single page. If you have multiple pages, you have to define your templates again. So, including templates in an external file will be the ideal solution – just like with CSS.
Templates as External HTML Snippets
In this technique we are going to use jQuery to implement templating. jQuery provides a function called load(), which can be used to fetch part of an external document. We are going to use this method to load templates dynamically from our external templates files. The load() function executes scripts instead of returning them, so we cannot create templates inside of script tags as we did in the previous method. The following example shows the external template files we are going to use.

{{name}}


{{name}}


{{name}}

We have used 
 elements for templates instead of scripts to keep it compatible with jQuery’s load() function. Here, we have three different templates with three different IDs. Now, let’s move on to using these templates in your pages.


  
    Mustache.js External Method
    
    
    
  
  
    
    
  

jQuery inserts the returned document into an HTML element instead of assigning it to a variable. So, we need a dummy container to keep the templates. I have used the templates container which is hidden by default. The example above retrieves template1, and loads it.  Then, we can get the template from the dummy container and pass it to mustache for rendering. This is how the external method works. We can also get the data from a server using an AJAX request.
Conclusion
Template engines and frameworks are important in managing complex systems with dynamically changing presentation views. Mustache.js is one of the best choices for managing templates on the client side. We started this tutorial by explaining why templates are important. Then, we moved onto various techniques of using mustache templates. Now you will be able to choose the method of implementing mustache templates in your projects.
We have completed exploring various techniques for using mustache templates, but mustache also comes with tags such as variables, sections, functions and partials, which are used to manage complex templates. Discussing the syntax of each tag is beyond the scope of this tutorial. You can find a comprehensive guide to mustache tags on the mustache GitHub page.
Feel free to share your previous experiences in working with mustache.js!
  


Headless WebKit and PhantomJS
Colin Ihrig — Sat, 01 Dec 2012 10:00:21 +0000
If you’re reading this article, you most likely know what a browser is. Now take away the GUI, and you have what’s called a headless browser. Headless browsers can do all of the same things that normal browsers do, but faster. They’re great for automating and testing web pages programmatically. There are a number of headless browsers in existence, and PhantomJS is the best.
 
Built on top of WebKit, the engine behind Chrome and Safari, PhantomJS gives you a ton of browser power, without the heavy GUI. Getting started with PhantomJS is easy – just download the executable. Next, create a file named hello.js and add the following lines.
console.log("Hello World!");
phantom.exit();
To execute the script, run the command shown below. Note, the phantomjs executable must either be in your current directory, or somewhere in your environment’s PATH. If everything is configured properly, PhantomJS will print Hello World! to the console, and then terminate when phantom.exit() is called.
  
phantomjs hello.js
Working With Web Pages
Once PhantomJS is up and running, you can begin automating the Web. The following example loads the Google home page, and then saves a screenshot to a file. Line 1 creates a new instance of a web page. On line 4, the web page loads google.com. Once the page finishes loading, the onLoadFinished() callback function is executed. The callback receives a single argument, status, which indicates whether the page loaded successfully or not. The URL of the loaded page is available in page.url. This property can be particularly useful when pages contain redirects, and you want to know exactly where you landed. A screenshot is taken on line 8 using the page’s render() method. render() can create PNG, GIF, JPEG, and PDF files.
var page = require("webpage").create();
var homePage = "http://www.google.com/";
page.open(homePage);
page.onLoadFinished = function(status) {
  var url = page.url;
  console.log("Status:  " + status);
  console.log("Loaded:  " + url);
  page.render("google.png");
  phantom.exit();
};
Page Settings
Page objects have a number of settings which can be customized based on your application’s needs. For example, if you’re only interested in downloading source code, you can speed up your application by ignoring image files and turning off JavaScript. The previous example is rewritten below to reflect these changes. The changed settings are shown on lines 3 and 4. Note that any settings changes must take place before the call to open(). If you view the screenshot from this example, you will notice that the Google logo image is missing, but the rest of the page is in tact.
var page = require("webpage").create();
var homePage = "http://www.google.com/";
page.settings.javascriptEnabled = false;
page.settings.loadImages = false;
page.open(homePage);
page.onLoadFinished = function(status) {
  var url = page.url;
  console.log("Status:  " + status);
  console.log("Loaded:  " + url);
  page.render("google.png");
  phantom.exit();
};
Accessing the File System
So far, our examples have loaded pages and saved screenshots as image files. While this is undoubtedly cool, many applications would prefer to store the source code to the file system. PhantomJS makes this possible by providing an extensive file system API. The following example uses the FileSystem module to write the google.com source code to a file. First, the FileSystem module is imported on line 2. On line 6, the output file is opened for writing. On line 7, the data is written to file using the write() method. The actual source code is available via the page’s content property. Finally, the file is closed and PhantomJS is terminated.
var page = require("webpage").create();
var fs = require("fs");
var homePage = "http://www.google.com/";
page.open(homePage);
page.onLoadFinished = function(status) {
  var file = fs.open("output.htm", "w");
  file.write(page.content);
  file.close();
  phantom.exit();
};
Executing JavaScript
One of the most powerful features of PhantomJS is the ability to interact with a page via JavaScript. This makes it extremely easy to automate tasks such as clicking buttons and submitting forms. Our next example performs a Web search by loading the Google home page, entering a query, and then submitting the search form. The beginning of the example should look familiar. The new stuff begins, on line 8, where we determine which page has been loaded. If this is the home page, the page’s evaluate() method is called. evaluate() executes the code you provide in the context of the page. This essentially gives you the same power as the page’s original developer. How cool is that?
var page = require("webpage").create();
var homePage = "http://www.google.com/";
page.open(homePage);
page.onLoadFinished = function(status) {
  var url = page.url;
  console.log("Status:  " + status);
  console.log("Loaded:  " + url);
  if (url === homePage) {
    page.evaluate(function() {
      var searchBox = document.querySelector(".lst");
      var searchForm = document.querySelector("form");
      searchBox.value = "JSPro";
      searchForm.submit();
    });
  } else {
    page.render("results.png");
    phantom.exit();
  }
};
Inside of evaluate(), we locate the search box and form. We set the value of the search box to “JSPro”, and then submit the form. This will cause the page’s onLoadFinished() method to be triggered again. However, this time a screen shot is taken of the search results, and PhantomJS exits.
PhantomJS also provides two methods, includeJs() and injectJs(), which allow you to add external script files to a page. includeJs() is used to include any script file that is accessible from the page. For example, you can include jQuery in our previous example using the following code. Notice the call to includeJs() on line 9, as well as the jQuery syntax inside of evaluate().
var page = require("webpage").create();
var homePage = "http://www.google.com/";
page.open(homePage);
page.onLoadFinished = function(status) {
  var url = page.url;
  console.log("Status:  " + status);
  console.log("Loaded:  " + url);
  if (url === homePage) {
    page.includeJs("http://code.jquery.com/jquery-1.8.3.min.js", function() {
      console.log("Loaded jQuery!");
      page.evaluate(function() {
        var searchBox = $(".lst");
        var searchForm = $("form");
        searchBox.val("JSPro");
        searchForm.submit();
      });
    });
  } else {
    page.render("results.png");
    phantom.exit();
  }
};
The injectJs() method is similar to includeJs(). The difference is that the injected script file does not need to be accessible from the page object. This allows you to, for example, inject scripts from your local file system.
PhantomJS and Node.js
Sadly, PhantomJS does not integrate particularly well with Node.js. A few projects have been created which try to control PhantomJS from Node.js, but they are all a bit of a kludge. Existing projects use the child process module to spawn instances of PhantomJS. Next, PhantomJS loads a special web page, which uses WebSockets to communicate with Node.js. It might not be ideal, but it works.
Two of the more popular PhantomJS Node modules are node-phantom and phantomjs-node. I recently started working on my own PhantomJS Node module named ghostbuster. Ghostbuster is similar to node-phantom, but attempts to reduce callback nesting by providing more powerful commands. Making fewer calls to PhantomJS also means less time is wasted communicating over WebSockets. Another alternative is zombie.js, a lightweight headless browser built on top of jsdom. Zombie isn’t as powerful as PhantomJS, but it is a true Node.js module.
Conclusion
After reading this article, you should have a basic grasp on PhantomJS. One of the nicest features about PhantomJS is how simple it is to use. If you’re already familiar with JavaScript, the learning curve is minimal. PhantomJS also supports a variety of other features that weren’t covered in this article. As always, I encourage you to check out the documentation. There are also a number of examples which show off PhantomJS in all its glory!
  


Debugging Unit Tests Using js-test-driver
Stephen Lum — Wed, 28 Nov 2012 09:00:25 +0000
Unit testing and Test Driven Development (TDD) are common paradigms nowadays. If you are a JavaScript developer, Google has created and open sourced a great tool called js-test-driver to help with unit testing. js-test-driver is a JavaScript unit test runner in the spirit of JUnit, and brings TDD to JavaScript.
 
Unit Testing Overview
If you have never done any unit testing before, nor entered the world of TDD, you might be asking yourself what the benefits are. There are many detailed discussions on the subject, but I’ll touch on a few of the more important points.
Unit tests are useful in regression testing. You can run unit tests after making code changes, and ensure that everything works like it used to. This is especially important in dynamic languages like JavaScript that do not give you compilation errors.
The more complex/larger the project, the more unit tests will provide you with a return on investment
A comprehensive suite of unit tests is almost as good as documentation.  With a good suite of unit tests, a developer can open a project and start running/debugging unit tests to better understand the system. This is very helpful when on-boarding a new team member.
JUnit is a popular Java test framework that was crucial in the development of Test Driven Development. Many of the existing testing frameworks follow the naming conventions and idioms of JUnit.
Configuring Your System
This tutorial will teach you how to set breakpoints and debug your unit tests from within an Integrated Development Environment (IDE). We will focus on the IntelliJ IDE. This tutorial uses a Microsoft Windows environment, but should work on most operating systems by adjusting the environment variables. You will also need to follow these instructions:
Download and install IntelliJ. You can download IntelliJ from the JetBrains website.
If you haven’t done so, download and install the Java Development Kit (JDK).
Within IntelliJ, make sure you have installed the js-test-driver plugin. If you do not know how to do this, please refer to the JetBrains instructions for installing plugins.
Download the latest js-test-driver.jar. At the time of writing, the latest version is 1.3.5. For the purposes of this tutorial, save the jar to C:\devtools\web\js\js-test-driver\1.3.5\js-test-driver-1.3.5.jar.
Add the following environment variables so that the Java runtime can be invoked from the command line.JAVA_HOME=C:\Program Files\Java\jdk1.7.0_7 (or the location of your java install)
PATH=%JAVA_HOME%\bin;%PATH%
You can verify the installation by opening a command prompt and typing java. If Java is installed correctly, you should see output similar to that shown in the screenshot below.
[image src="http://jspro.com/files/2012/11/js-test-driver-cmd-java.png"]
Create a new project in IntelliJ by going to the top menu and clicking File | New Project. I have created an IntelliJ project with a Web Module at C:\projects\js-test-driver. The IntelliJ settings are shown in the figure below.[image src="http://jspro.com/files/2012/11/js-test-driver-createproject.png"]
In TDD and unit testing, it is always a good idea to have a clean, concise separation between your production code and your test code. Create the directories src and test in the IntelliJ project root. After creating these directories, your project should look like the following screenshot.[image src="http://jspro.com/files/2012/11/js-test-driver-srctestdirs.png"]
Getting Started
We are going to add the “greeter” examples that are part of the js-test-driver project. Create a new JavaScript file named greeter.js under the src directory and add the following code.myapp = {};
myapp.Greeter = function() {};
myapp.Greeter.prototype.greet = function(name) {
  return "Hello " + name + "!";
};
Now we will create the unit test. Create the corresponding JavaScript test file greetertest.js under the test directory, and add the following code.TestCase("GreeterTest", {
  setUp:function () {
  },
  "test greet": function() {
    var greeter = new myapp.Greeter();
    assertEquals("Hello World!", greeter.greet("World"));
  },
  "test greet null": function() {
    var greeter = new myapp.Greeter();
    assertNull(greeter.greet(null));
  }
});
In greetertest.js, IntelliJ will not understand the TestCase class, and will highlight it in red. Click TestCase and you will be prompted for the JetBrains suggested intention. Next, click Add JsTestDriver assertion framework support, as shown in the following figure. Doing this will add IntelliJ IDE support for js-test-driver.[image src="http://jspro.com/files/2012/11/js-test-driver-assertframework.png"]
Create a file named js-test-driver.conf in the root of your project. For the purposes of this tutorial, the full path would be C:\projects\js-test-driver\js-test-driver.conf. Add the information shown in the following image to js-test-driver.conf.[image src="http://jspro.com/files/2012/11/js-test-driver-jstestdriver.conf_.png"]
Now let’s setup our project for debugging with a breakpoint. Set a breakpoint in the file greetertest.js within the testgreet() function. You can set a breakpoint in IntelliJ by clicking in the left hand margin.
Create a new IntelliJ Run/Debug configuration of type JavaScript Debug | JavaScript as shown below.[image src="http://jspro.com/files/2012/11/js-test-driver-debug-javascript-remote.png"]
Change the following values:URL to open: http://localhost:9876/capture
Expand the directory test and enter http://localhost:9876/test/test for Remote URL
As we have seen so far, IntelliJ provides excellent js-test-driver integration. To start the js-test-driver server from directly within IntelliJ, expand the JsTestDriver Server menu item and click the green play button, as shown below.[image src="http://jspro.com/files/2012/11/js-test-driver-server-start.png"]
Now let’s debug our JavaScript from within IntelliJ! Start the Debug Configuration we created earlier called JavascriptRemote. You can do so by selecting Run | Debug from the menu. A new browser window will open with the js-test-driver remote console runner loaded as shown below.[image src="http://jspro.com/files/2012/11/js-test-driver-browser-remote-debug.png"]
Next, open a new command prompt. cd to the root of the IntelliJ project. For the purposes of this project that directory is C:\projects\js-test-driver. Enter the following command:java -jar C:\devtools\web\js\js-test-driver\1.3.5\js-test-driver-1.3.5.jar --tests all
After a few moments, IntelliJ should be suspended at the breakpoint we set earlier. Local variables, watch expressions, and other debug goodness will now be available to us. Note: in IntelliJ, intelligent code completion is available in watch expressions![image src="http://jspro.com/files/2012/11/js-test-driver-breakpoint-suspended.png"]
Conclusion
This article has taught you to debug JavaScript unit tests with js-test-driver. You should now be able to set breakpoints from within the IntelliJ development environment. Ultimately I hope this will help you produce well tested software for your current and future projects.
Download the source code for the examples in this article!
  


Getting Started with MooTools
Avinash Zala — Mon, 29 Oct 2012 06:00:50 +0000
This tutorial introduces one of the most popular JavaScript frameworks today, MooTools. MooTools, which stands for My Object Oriented Tools, is compatible with Internet Explorer 6+, Firefox, Opera and Chrome. MooTools is designed to be compact, modular, and of course, object oriented. MooTools is designed for intermediate to expert JavaScript programmers, so make sure you have enough experience before diving in.
 
Getting MooTools
Getting MooTools is fairly simple. MooTools comes in two parts, known as Core and More. Core contains the core classes and modules of the framework, while More contains the additional classes which can be included based on an application’s needs. MooTools has powerful builder pages which can customize Core and More based on our needs. The current stable version (at the time of writing this article) of MooTools Core is 1.4.5 and More is 1.4.0.1.
Element Selectors
One of the most basic operations of any JavaScript framework is the selection of elements. MooTools uses Slick as its selector engine. MooTools supports many different types of selectors. This section covers some of the most useful and important selectors.
  
Selecting an Element by ID
If we want to select an element by ID in plain JavaScript, we need to use the long document.getElementById('id_of_element') syntax. MooTools, like many other JavaScript frameworks, shortens this by using $ to select elements. Your code ends up looking like this:
var element =  $('id_of_element');
This will create problems if you include MooTools and other libraries that use $ (e.g. jQuery) on the same page. To overcome this situation MooTools has provided document.id() as another way to select elements. Your code to select elements by id now looks like this:
var element =  document.id('id_of_element');
Selecting Elements by Class
This will return an array of elements of a certain class. To get each individual element, we need to traverse the array, as shown below.
$$('.class_name').each(function(ele){
  console.log(ele);
});
Selecting Elements by Attribute Patterns
The following examples select elements whose id and class attributes begin with a certain pattern.
$$('[id^=id_start_]').each(function(ele){
  console.log(ele);
});
$$('[class^=class_start_]').each(function(ele){
  console.log(ele);
});
Similarly, the following examples match elements whose id and class attributes end with a certain pattern.
$$('[id$=_end_id]').each(function(ele){
  console.log(ele);
});
$$('[class$=_end_class]').each(function(ele){
  console.log(ele);
});
The DomReady Event
DomReady is an event which can only be bound to the window object. DomReady executes as soon as the DOM is loaded, which can be much earlier than the window.load event, which waits for all other resources to load. I suggest reading this in depth comparison of DomReady and window.load. The following example uses DomReady to wait until the DOM loads before querying it.
window.addEvent('domready', function(){
  if(document.id('id_of_element'))
  {
    alert('Element Exists');
  }
});
Element Creation
MooTools can create new HTML elements and inject them into the DOM. Creating a new HTML element in MooTools is very simple. For example, the following code creates a new div element.
var new_div = new Element('div', {'class': 'new_div'});
The previous code creates a new element, but does not inject it into the DOM. To perform the injection, you need to call the adopt() method. The following example shows how this is done.
var new_div = new Element('div', {'class': 'new_div'});
$$('body').adopt(new_div);
When this code gets executed, you can see the new div added just before the closing body tag.
Event Binding
Event binding causes code to be executed when certain events are performed on an element. Click, double click, and hovering are examples of common events. You can also create your own custom events, but that is beyond the scope of this article. As an example of MooTools event binding, the following code adds a simple click event handler to an element.
document.id('id_of_ele').addEvent('click', function(){
  console.log('I was just clicked');
});
You can also add events to dynamically created elements. The following code adds a click handler to a dynamically created element.
var new_div = new Element('div', {'class': 'new_div'});
$$('body').adopt(new_div);
new_div.addEvent('click', function(){
  console.log('I was just clicked');
});
Browser Detection
Last, but not least, is browser detection with MooTools. This is required when you want to write conditional code based on the user’s browser. MooTools provides the Browser object, which gets populated on page load. The following example uses a switch statement to identify the current browser.
switch(Browser.name)
{
  case "safari":
    console.log('I am Safari');
    break;
  case "chrome":
    console.log('I am Chrome');
    break;
  case "firefox":
    console.log('I am FireFox');
    break;
  case "opera":
    console.log('I am Opera');
    break;
  case "ie":
    console.log('I am IE');
    break;
}
Conclusion
This article has covered a lot of the MooTools basics. There are some great resources out there for learning to use MooTools effectively. I have learned a lot from the MooTools Docs and The David Walsh Blog. You can also refer to my MooTools work.
  


Become a Modernizr Master with Learnable and Ryan Seddon
Tom Museth — Thu, 11 Oct 2012 05:41:43 +0000
Interested in learning more about Modernizr? Check out what’s happening this month over at Learnable, the web’s premier online learning destination, and part of the SitePoint network. They’ll be hosting a “live” course, where instructor Ryan Seddon and Learnable’s in-house team of experts will be standing by to answer your questions in a Q&A session. As a member, there’s no cost to participate.
Learn Modernizr
Getting Started with Modernizr with Ryan Seddon
 Starts: 10am Pacific Daylight Time, October 16, 2012
Modernizr makes it easy for you to write conditional JavaScript and CSS to handle any situation, whether a browser supports a particular feature you wish to implement or not. It’s perfect for tackling progressive enhancement easily.
If you’re a front-end whiz (or want to be) and you haven’t used this tool yet, this is the course for you.
Happy learning!
  


Using JSLint to Refine Your Code
Chee How Chua — Wed, 10 Oct 2012 06:00:55 +0000
JavaScript is an increasingly popular language thanks to the proliferation of web apps and the adoption of HTML5. Part of JavaScript’s appeal is the ease by which one can begin writing useful and fun stuff with it. There’s no need for heavyweight integrated development environments (IDEs) or third-party apps. Just open any text editor, save the file, and open it in a web browser.
JavaScript’s lure can easily turn into a trap for novice programmers. The malleability of the language can create monstrous bugs in sophisticated scripts. For example, a missing local variable declaration can mysteriously manifest itself elsewhere on the page by altering global variables.
[image src="http://jspro.com/files/2012/10/jslint1.png" href="http://jspro.com/files/2012/10/jslint1.png"]
Enter JSLint. According to its website, JSLint is a “JavaScript Code Quality Tool.” Its author, Douglas Crockford, is well known for his work on the development of JavaScript (also known as ECMAScript) and JSON. JSLint helps JavaScript programmers by making sure certain coding conventions are followed. JSLint is based on the premise of strict mode, which is available in the fifth edition of the ECMAScript standard. With strict mode, you are making your code run with a set of more restrictive rules than normal.
  
Using JSLint
Let’s run through an example usage of JSLint. We are writing a simple jQuery plugin that displays a message specified in the msg parameter with a prefix. The prefix is hidden if we pass the value false through the type parameter.
(function ($) {
    $.fn.loading = function(msg, type, cssClass){
        var prefixes = {
            warning: 'Warning: ' + msg,
            error: 'Error: ' + msg,
            info: 'Info: ' + msg,
            warning: 'Caution: ' + msg,
        };
        if (type) {
            concatMsg = prefixes[type];
        } else {
            concatMsg = msg;
        }
        $(this).each(function()  {
            var tis = $(this)
            if (msg == false) {
                tis.html('');
            } else {
                tis.html(concatMsg);
            }
        });
     }
})(jQuery);
Although this piece of code works fine as a plugin for jQuery, when you use it in Firefox or Chrome, you can see that there are some glaring mistakes and some very subtle ones. Instead of spending your mental energy digging out the problems, let’s use JSLint to help us. Copy the function code into the text area on the JSLint site and click the “JSLint” button. Some of the resulting JSLint output is shown in the figure below.
[image src="http://jspro.com/files/2012/10/jslint2.png" href="http://jspro.com/files/2012/10/jslint2.png"]
The first error pointed out by JSLint is that the "use strict" statement is missing. This error indicates that the function is not executed in strict mode. To correct this error, enable strict mode by adding the following string literal to the beginning of the function body.
    'use strict';
After enabling strict mode, click the “JSLint” button again. The reported error of the missing "use strict" should be gone. We can now move on to the next error, shown in the following figure. This error deals with whitespace, and is more cosmetic than functional. Since this is not an actual error, you can safely ignore it.
[image src="http://jspro.com/files/2012/10/jslint3.png" href="http://jspro.com/files/2012/10/jslint3.png"]
You can choose to stick with no space after the function keyword, and suppress the error message by scrolling to the bottom of the page and switching the “messy white space” option to true. For now, however, we want to keep the default behavior because this option also checks for other whitespace issues as we will see later.
Also notice that the second and third errors reported by JSLint are also on the same line but at different positions. Looks like a space between the closing parenthesis and the opening brace is also recommended by JSLint, so fix that now.
By clicking the “JSLint” button again, we see that the next problem is on line 8, at position 39. The prefixes object literal contains two identical warning properties, which is obviously a mistake. Let’s correct the problem by replacing the second occurrence of warning with caution.
[image src="http://jspro.com/files/2012/10/jslint7.png" href="http://jspro.com/files/2012/10/jslint7.png"]
Without clicking the “JSLint” button again, let’s look at the next error, shown in the following figure. The object literal contains a trailing comma. Browsers such as Chrome and Firefox may be tolerant of such mistakes but Internet Explorer does not take too kindly to such transgressions. To correct the problem, simply remove the comma.
[image src="http://jspro.com/files/2012/10/jslint8.png" href="http://jspro.com/files/2012/10/jslint8.png"]
The next two errors indicate that concatMsg was used before it was defined. When a variable is not defined in the current scope, JavaScript checks the enclosing scopes to see if it was defined elsewhere. If you are using code from a third-party source that happens to define this exact variable in the global scope, it can take you countless, hair-pulling hours to find the bug. Fortunately, with JSLint, we are able to nip the problem in the bud.
[image src="http://jspro.com/files/2012/10/jslint9.png" href="http://jspro.com/files/2012/10/jslint9.png"]
While fixing this problem, we can also refactor our code. Since the default value of concatMsg is msg, we can assign this value immediately and change it later if need be. The code for concatMsg can now be rewritten as shown below.
var concatMsg = msg;
if (type) {
    concatMsg = prefixes[type];
}
Next, we encounter the same whitespace issue as earlier, which can be corrected in the same way. Next, JSLint reports that a semicolon is missing. This message is shown below. Without the semicolon, JSLint assumes that the statement is never terminated. That is why it saw if while expecting a semicolon. While the language specification says that the ending semicolon is optional, it is good practice to include it. This is another area where sloppy coding can lead to hard-to-find bugs in large scale productions. By linting our code, we can fix such problems quickly and easily.
[image src="http://jspro.com/files/2012/10/jslint11.png" href="http://jspro.com/files/2012/10/jslint11.png"]
The following error is another good one. There are equality and strict equality checks in JavaScript. In our code, by not checking for strict equality the plugin behaves the same if either an empty string or the Boolean value false is specified as the first parameter. To correct the error, use the strict equality operator.
[image src="http://jspro.com/files/2012/10/jslint12.png" href="http://jspro.com/files/2012/10/jslint12.png"]
This is a good time for us to click the “JSLint” button again. The first error, shown below, is reported at line 10. JSLint seems to think that another best practice for writing JavaScript is to group variable declarations together. Although concatMsg is right after prefixes, JSLint prefers that you group the variable declarations in a single statement, separated by commas.
[image src="http://jspro.com/files/2012/10/jslint14.png" href="http://jspro.com/files/2012/10/jslint14.png"]
The next error is another cosmetic suggestion by JSLint. The fact that there is one more space than the expected number is pretty trivial at first glance. However, indentation problems can lead to bugs that are hard to catch in large scripts. For consistency, move the closing brace back into place by removing the extra space.
[image src="http://jspro.com/files/2012/10/jslint15.png" href="http://jspro.com/files/2012/10/jslint15.png"]
The next problem reported by JSLint is similar to what we have seen before, but it is manifested in a different form. JavaScript functions can be assigned to variables. As with any other variable assignment, JSLint expects a terminating semicolon.
[image src="http://jspro.com/files/2012/10/jslint16.png" href="http://jspro.com/files/2012/10/jslint16.png"]
Finally, two problems are reported at the last line, as shown below. The first problem is a suggestion to place the closing parentheses after the closing one behind jQuery because it leaves no ambiguity that you want the function definition to be a closure. The second problem is that in JSLint’s view, the variable jQuery is not present, although it might have been included in the web page by linking to a jQuery file. To address this issue, type jQuery into the bottom text field.
[image src="http://jspro.com/files/2012/10/jslint17.png" href="http://jspro.com/files/2012/10/jslint17.png"]
If you run JSLint again, it will detect that the function accepts three parameters. However, in this example, the third parameter is never used. There are two approaches you can take here. The first one is to remove the parameter since it is never used. The second option is to toggle the JSLint property “unused parameters” to true, as shown below. Choose this option only if you really want to keep the parameter in the function signature for some reason.
[image src="http://jspro.com/files/2012/10/jslint19.png" href="http://jspro.com/files/2012/10/jslint19.png"]
After using JSLint to improve our code, the final product is shown below.
(function ($) {
    'use strict';
    $.fn.loading = function (msg, type, cssClass) {
        var prefixes = {
            warning: 'Warning: ' + msg,
            error: 'Error: ' + msg,
            info: 'Info: ' + msg,
            caution: 'Caution: ' + msg
        }, concatMsg = msg;
        if (type) {
            concatMsg = prefixes[type];
        }
        $(this).each(function () {
            var tis = $(this);
            if (msg === false) {
                tis.html('');
            } else {
                tis.html(concatMsg);
            }
        });
    };
}(jQuery));
JSLint Directives
JSLint directives allow you to define variables and provide other options to JSLint from directly within the source code. This frees you from having to set the JSLint GUI options repeatedly. For example, the comments in the following example define a global variable named jQuery and set the “unparam” option to true.
/*global jQuery*/
/*jslint unparam: true */
(function ($) {
    ‘use strict’;
…
}(jQuery));
Conclusion
In this short example, JSLint has pointed out some critical errors and some seemingly insignificant ones. The fact that JSLint helps us catch these issues before we actually run the code is hugely beneficial in terms of developer productivity and application quality. If you are serious about writing production quality code, always run it through JSLint before pushing it to the server. JSLint is even contained in a single JS file, so you can download it use it offline too!