backbone-fundamentals.rtf

{\rtf1\ansi\deff0{\fonttbl{\f0 \fswiss Helvetica;}{\f1 Courier;}}
{\colortbl;\red255\green0\blue0;\red0\green0\blue255;}
\widowctrl\hyphauto

{\pard \qc \f0 \sa180 \li0 \fi0 \b \fs36 Developing Backbone.js Applications\par}
{\pard \qc \f0 \sa180 \li0 \fi0  Addy Osmani\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Prelude\par}
{\pard \ql \f0 \sa180 \li0 \fi0  Welcome to my (in-progress) book about the {\field{\*\fldinst{HYPERLINK "http://documentcloud.github.com/backbone/"}}{\fldrslt{\ul
Backbone.js
}}}
 framework for structuring JavaScript applications. It\u8217's released under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported {\field{\*\fldinst{HYPERLINK "http://creativecommons.org/licenses/by-nc-sa/3.0/"}}{\fldrslt{\ul
license
}}}
 meaning you can both grab a copy of the book for free or help to further {\field{\*\fldinst{HYPERLINK "https://github.com/addyosmani/backbone-fundamentals/"}}{\fldrslt{\ul
improve
}}}
 it.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 I\u8217'm very pleased to announce that this book will be out in physical form later in the year via {\field{\*\fldinst{HYPERLINK "http://oreilly.com"}}{\fldrslt{\ul
O\u8217'Reilly Media
}}}
. Readers will have the option of purchasing the latest version in either print or a number of digital formats then or can grab a recent version from this repository.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Corrections to existing material are always welcome and I hope that together we can provide the community with an up-to-date resource that is of help. My extended thanks go out to {\field{\*\fldinst{HYPERLINK "https://github.com/jashkenas"}}{\fldrslt{\ul
Jeremy Ashkenas
}}}
 for creating Backbone.js and {\field{\*\fldinst{HYPERLINK "https://github.com/addyosmani/backbone-fundamentals/contributors"}}{\fldrslt{\ul
these
}}}
 members of the community for their assistance tweaking this project.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 I hope you find this book helpful!\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Notes:}\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Items added or updated in the last month are marked with a * in the outline.\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Once you\u8217're familiar with Backbone.js, you might be interested in checking out {\field{\*\fldinst{HYPERLINK "https://github.com/addyosmani/aura"}}{\fldrslt{\ul
Aura
}}}
.\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Table Of Contents\par}
{\pard \ql \f0 \sa180 \li360 \fi-360 \bullet \tx360\tab \b \fs24 {\field{\*\fldinst{HYPERLINK "#introduction"}}{\fldrslt{\ul
Introduction
}}}
\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab MVC, Or Rather MV* Frameworks\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab What is Backbone.js?\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab When Do You Need A JavaScript MV* Framework?\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab When To Consider Using Backbone.js\sa180\par}
{\pard \ql \f0 \sa180 \li360 \fi-360 \bullet \tx360\tab \b \fs24 {\field{\*\fldinst{HYPERLINK "#fundamentals"}}{\fldrslt{\ul
Fundamentals
}}}
\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab {\field{\*\fldinst{HYPERLINK "#mvc-mvp"}}{\fldrslt{\ul
MVC, MVP & Backbone.js
}}}
\sa180\par}
{\pard \ql \f0 \sa180 \li360 \fi-360 \bullet \tx360\tab \b \fs24 {\field{\*\fldinst{HYPERLINK "#theinternals"}}{\fldrslt{\ul
The Internals
}}}
\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab {\field{\*\fldinst{HYPERLINK "#thebasics-models"}}{\fldrslt{\ul
Models
}}}
\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab {\field{\*\fldinst{HYPERLINK "#thebasics-views"}}{\fldrslt{\ul
Views
}}}
\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab {\field{\*\fldinst{HYPERLINK "#thebasics-collections"}}{\fldrslt{\ul
Collections
}}}
\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab {\field{\*\fldinst{HYPERLINK "#thebasics-events"}}{\fldrslt{\ul
Events
}}}
\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab {\field{\*\fldinst{HYPERLINK "#thebasics-routers"}}{\fldrslt{\ul
Routers
}}}
\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab {\field{\*\fldinst{HYPERLINK "#thebasics-inheritance"}}{\fldrslt{\ul
Inheritance & Mixins
}}}
 *\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab {\field{\*\fldinst{HYPERLINK "#thebasics-namespacing"}}{\fldrslt{\ul
Namespacing
}}}
\sa180\par}
{\pard \ql \f0 \sa180 \li360 \fi-360 \bullet \tx360\tab \b \fs24 {\field{\*\fldinst{HYPERLINK "#practicaltodos"}}{\fldrslt{\ul
Practical: Todos - Your First Backbone.js App
}}}
 *\par}
{\pard \ql \f0 \sa180 \li360 \fi-360 \bullet \tx360\tab \b \fs24 {\field{\*\fldinst{HYPERLINK "#backboneboilerplate"}}{\fldrslt{\ul
Backbone Boilerplate & Grunt BBB
}}}
 *\par}
{\pard \ql \f0 \sa180 \li360 \fi-360 \bullet \tx360\tab \b \fs24 {\field{\*\fldinst{HYPERLINK "#commonproblems"}}{\fldrslt{\ul
Common Problems & Solutions
}}}
 *\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab Sub-Views And Nesting\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab Managing Models In Nested Views\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab Views Triggering Other Views\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab Child Views Rendering Parent Views\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab Cleanly Disposing Views\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab Disposing Parent And Child Views\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab Appending Views\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab Better Model Property Validation *\sa180\par}
{\pard \ql \f0 \sa180 \li360 \fi-360 \bullet \tx360\tab \b \fs24 {\field{\*\fldinst{HYPERLINK "#advanced"}}{\fldrslt{\ul
Modular Development
}}}
\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab {\field{\*\fldinst{HYPERLINK "#modularjs"}}{\fldrslt{\ul
Introduction
}}}
\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab {\field{\*\fldinst{HYPERLINK "#organizingmodules"}}{\fldrslt{\ul
Organizing modules with Require.js and AMD
}}}
\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab {\field{\*\fldinst{HYPERLINK "#externaltemplates"}}{\fldrslt{\ul
Keeping your templates external
}}}
\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab {\field{\*\fldinst{HYPERLINK "#practicalrequirejs"}}{\fldrslt{\ul
Practical: A Modular App Using AMD & Require.js
}}}
\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab {\field{\*\fldinst{HYPERLINK "#optimizingrequirejs"}}{\fldrslt{\ul
Optimize Apps With The Require.js Optimizer
}}}
\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab {\field{\*\fldinst{HYPERLINK "#optimizebuild"}}{\fldrslt{\ul
Optimize Apps With Require.js Using Packages
}}}
 *\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab {\field{\*\fldinst{HYPERLINK "#decouplingbackbone"}}{\fldrslt{\ul
Decoupling Backbone With The Mediator and Facade patterns
}}}
\sa180\par}
{\pard \ql \f0 \sa180 \li360 \fi-360 \bullet \tx360\tab \b \fs24 {\field{\*\fldinst{HYPERLINK "#restfulapps"}}{\fldrslt{\ul
RESTful Applications With Backbone.js
}}}
\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab {\field{\*\fldinst{HYPERLINK "#restful"}}{\fldrslt{\ul
Building RESTful applications
}}}
\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab {\field{\*\fldinst{HYPERLINK "#stack1"}}{\fldrslt{\ul
Apps With Node.js, Express, Mongoose and MongoDB
}}}
\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab {\field{\*\fldinst{HYPERLINK "#stack2"}}{\fldrslt{\ul
Apps with Ruby, Sinatra, Haml and MongoDB
}}}
\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab {\field{\*\fldinst{HYPERLINK "#pagination"}}{\fldrslt{\ul
Paginating Backbone.js Requests & Collections
}}}
 *\sa180\par}
{\pard \ql \f0 \sa180 \li360 \fi-360 \bullet \tx360\tab \b \fs24 Mobile Applications\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab Backbone & jQuery Mobile\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab Practical: Building A Modular Mobile App With Backbone & jQuery Mobile\sa180\par}
{\pard \ql \f0 \sa180 \li360 \fi-360 \bullet \tx360\tab \b \fs24 {\field{\*\fldinst{HYPERLINK "#testing"}}{\fldrslt{\ul
Unit Testing
}}}
\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab {\field{\*\fldinst{HYPERLINK "#unittestingjasmine"}}{\fldrslt{\ul
Unit Testing Backbone Applications With Jasmine
}}}
\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab Introduction\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab Jasmine\par}
{\pard \ql \f0 \sa0 \li1080 \fi-360 \bullet \tx360\tab Suites, Specs And Spies\par}
{\pard \ql \f0 \sa0 \li1080 \fi-360 \bullet \tx360\tab TDD With Backbone\par}
{\pard \ql \f0 \sa0 \li1080 \fi-360 \bullet \tx360\tab Testing Models\par}
{\pard \ql \f0 \sa0 \li1080 \fi-360 \bullet \tx360\tab Testing Collections\par}
{\pard \ql \f0 \sa0 \li1080 \fi-360 \bullet \tx360\tab Testing Views\sa180\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab {\field{\*\fldinst{HYPERLINK "#unittestingqunit"}}{\fldrslt{\ul
Unit Testing Backbone Applications With QUnit And SinonJS
}}}
\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab Introduction\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab QUnit\par}
{\pard \ql \f0 \sa0 \li1080 \fi-360 \bullet \tx360\tab Assertions\par}
{\pard \ql \f0 \sa0 \li1080 \fi-360 \bullet \tx360\tab Adding structure to assertions\par}
{\pard \ql \f0 \sa0 \li1080 \fi-360 \bullet \tx360\tab Assertion examples\par}
{\pard \ql \f0 \sa0 \li1080 \fi-360 \bullet \tx360\tab Fixtures\par}
{\pard \ql \f0 \sa0 \li1080 \fi-360 \bullet \tx360\tab Asynchronous code\sa180\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab SinonJS\par}
{\pard \ql \f0 \sa0 \li1080 \fi-360 \bullet \tx360\tab Stubs\par}
{\pard \ql \f0 \sa0 \li1080 \fi-360 \bullet \tx360\tab Mocks\sa180\par}
{\pard \ql \f0 \sa0 \li720 \fi-360 \endash \tx360\tab Practical\par}
{\pard \ql \f0 \sa0 \li1080 \fi-360 \bullet \tx360\tab Testing Models\par}
{\pard \ql \f0 \sa0 \li1080 \fi-360 \bullet \tx360\tab Testing Collections\par}
{\pard \ql \f0 \sa0 \li1080 \fi-360 \bullet \tx360\tab Testing Views\par}
{\pard \ql \f0 \sa0 \li1080 \fi-360 \bullet \tx360\tab Testing Events\sa180\sa180\par}
{\pard \ql \f0 \sa180 \li360 \fi-360 \bullet \tx360\tab \b \fs24 {\field{\*\fldinst{HYPERLINK "#resources"}}{\fldrslt{\ul
Resources
}}}
\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs36 Introduction\par}
{\pard \ql \f0 \sa180 \li0 \fi0 When writing a Web application from scratch, it\u8217's easy to feel like we can get by simply by relying on a DOM manipulation library (like jQuery) and a handful of utility plugins. The problem with this is that it doesn\u8217't take long to get lost in a nested pile of jQuery callbacks and DOM elements without any real structure in place for our applications.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In short, we\u8217're stuck with spaghetti code. Fortunately there are modern JavaScript frameworks that can assist with bringing structure and organization to our projects, improving how easily maintainable they are in the long-run.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 What Is MVC, Or Rather MV*?\par}
{\pard \ql \f0 \sa180 \li0 \fi0 These modern frameworks provide developers an easy path to organizing their code using variations of a pattern known as MVC (Model-View-Controller). MVC separates the concerns in an application down into three parts:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Models represent the domain-specific knowledge and data in an application. Think of this as being a \u8216'type\u8217' of data you can model \u8212- like a User, Photo or Note. Models should notify anyone observing them about their current state (e.g Views).\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Views are typically considered the User-interface in an application (e.g your markup and templates), but don\u8217't have to be. They should know about the existence of Models in order to observe them, but don\u8217't directly communicate with them.\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Controllers handle the input (e.g clicks, user actions) in an application and Views can be considered as handling the output. When a Controller updates the state of a model (such as editing the caption on a Photo), it doesn\u8217't directly tell the View. This is what the observing nature of the View and Model relationship is for.\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 JavaScript \u8216'MVC\u8217' frameworks that can help us structure our code don\u8217't always strictly follow the above pattern. Some frameworks will include the responsibility of the Controller in the View (e.g Backbone.js) whilst others add their own opinionated components into the mix as they feel this is more effective.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For this reason we refer to such frameworks as following the MV* pattern, that is, you\u8217're likely to have a View and a Model, but more likely to have something else also included.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 What exactly is Backbone.js?\par}
{\pard \ql \f0 \sa0 \li0 \fi0 \par}
{\pard \ql \f0 \sa180 \li0 \fi0 Backbone.js is a lightweight JavaScript framework for adding structure to your client-side code. It makes it easy to manage and decouple concerns in your application, leaving you with code that is more maintainable in the long term.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Developers commonly use frameworks like Backbone.js to create single-page applications or SPAs. To put it simply, these apps enable the browser to react to changes in data on the client-side without the need to completely load up all your markup from the server, meaning no complete page-refreshes are necessary.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Backbone.js is a mature, popular framework at the time of writing and has both a large development community online as well as a wealth of plugins and extensions available to build upon it. It has been used to create non-trivial applications by companies such as Disqus, Walmart, SoundCloud and Foursquare.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 When Do You Need A JavaScript MV* Framework?\par}
{\pard \ql \f0 \sa180 \li0 \fi0 When building a single-page application using JavaScript, whether it involves a complex user interface or is simply trying to reduce the number of HTTP requests required for new Views, you will likely find yourself inventing many of the pieces that make up an MV* framework like Backbone or Ember.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 At the outset, it isn\u8217't terribly difficult to write an application framework that offers some opinionated way to avoid spaghetti code, however to say that it is equally as trivial to write something of the standard of Backbone would be a grossly incorrect assumption.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 There\u8217's a lot more that goes into structuring an application than tying together a DOM manipulation library, templating and routing. Mature MV* frameworks typically not only include many of the pieces you would find yourself writing, but also include solutions to problems you\u8217'll find yourself running into later on down the road. This is a time-saver that you shouldn\u8217't underestimate the value of.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 So, where will you likely need an MV* framework and where won\u8217't you?\par}
{\pard \ql \f0 \sa180 \li0 \fi0 If you\u8217're writing an application that will likely only be communicating with an API or back-end data service, where much of the heavy lifting for viewing or manipulating that data will be occurring in the browser, you may find a JavaScript MV* framework useful. Good examples of applications that fall into this category are GMail and Google Docs.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 These applications typically download a single payload containing all the scripts, stylesheets and markup users need for common tasks and then perform a lot of additional behavior in the background. It\u8217's trivial to switch between reading an email or document to writing one and you don\u8217't need to ask the application to render the whole page again at all.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 If, however, you\u8217're building an application that still relies on the server for most of the heavy-lifting of Views/pages and you\u8217're just using a little JavaScript or jQuery to make things a little more interactive, an MV framework may be overkill. There certainly are complex Web applications where the partial rendering of views can* be coupled with a single-page application effectively, but for everything else, you may find yourself better sticking to a simpler setup.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Maturity in software (framework) development isn\u8217't simply about how long a framework has been around. It\u8217's about how solid the framework is and more importantly how well it\u8217's evolved to fill its role. Has it become more effective at solving common problems? Does it continue to improve as developers build larger and more complex applications with it?\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Why should you consider using Backbone.js?\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Does the following describe you?:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 "I want something flexible which offers a minimalist solution to separating concerns in my application. It should support a persistence layer and RESTful sync, models, views (with controllers), event-driven communication, templating and routing. It should be imperative, allowing one to update the View when a model changes. I\u8217'd like some decisions about the architecture left up to me. Ideally, many large companies have used the solution to build non-trivial applications.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 As I may be building something complex, I\u8217'd like there to be an active extension community around the framework that have already tried addressing larger problems (Marionette, Chaplin, Aura, Thorax). Ideally, there are also scaffolding tools (grunt-bbb, brunch) available for the solution."\par}
{\pard \ql \f0 \sa180 \li0 \fi0 If so, continue reading.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Backbone\u8217's main benefits, regardless of your target platform or device, include helping:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Organize the structure to your application\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Simplify server-side persistence\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Decouple the DOM from your page\u8217's data\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Model data, views and routers in a succinct manner\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Provide DOM, model and collection synchronization\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 What should you expect to see in this book?\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The goal of this book is to create an authoritative and centralized repository of information that can help those developing real-world apps with Backbone. If you come across a section or topic which you think could be improved or expanded on, please feel free to submit a pull-request. It won\u8217't take long and you\u8217'll be helping other developers avoid problems you\u8217've run into before.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Topics will include MVC theory and how to build applications using Backbone\u8217's models, views, collections and routers. I\u8217'll also be taking you through advanced topics like modular development with Backbone.js and AMD (via Require.js), how to build applications using modern software stacks (like Node and Express), how to solve the routing problems with Backbone and jQuery Mobile, tips about scaffolding tools, and a lot more.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs36 Fundamentals\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In this section, we\u8217're going to explore how frameworks like Backbone.js fit in the world of JavaScript application architecture. Clasically, developers creating desktop and server-class applications have had a wealth of design patterns available for them to lean on, but it\u8217's only been in the past few years that such patterns have come to client-side development.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Before exploring any JavaScript frameworks that assist in structuring applications, it can be useful to gain a basic understanding of architectural design patterns.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 MVC, MVP & Backbone.js\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Design patterns are proven solutions to common development problems and can suggest structural approaches to help guide developers in adding some organization to their applications.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Patterns are useful because they\u8217're a set of practices that build upon the collective experience of skilled developers who have repeatedly solved similar problems. Although developers 10 or 20 years ago may not have been using the same programming languages when implementing patterns in their projects, there are many lessons we can learn from their efforts.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In this section, we\u8217're going to review two popular patterns - MVC and MVP. We\u8217'll be exploring in greater detail how Backbone.js implements these patterns shortly to better appreciate where it fits in.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 MVC\par}
{\pard \ql \f0 \sa180 \li0 \fi0 MVC (Model-View-Controller) is an architectural design pattern that encourages improved application organization through a separation of concerns. It enforces the isolation of business data (Models) from user interfaces (Views), with a third component (Controllers) traditionally present to manage logic, user-input and the coordination of models and views. The pattern was originally designed by {\field{\*\fldinst{HYPERLINK "http://en.wikipedia.org/wiki/Trygve_Reenskaug"}}{\fldrslt{\ul
Trygve Reenskaug
}}}
 while working on Smalltalk-80 (1979), where it was initially called Model-View-Controller-Editor. MVC was described in depth in {\field{\*\fldinst{HYPERLINK "http://www.amazon.co.uk/Design-patterns-elements-reusable-object-oriented/dp/0201633612"}}{\fldrslt{\ul
\u8220"Design Patterns: Elements of Reusable Object-Oriented Software\u8221"
}}}
 (The \u8220"GoF\u8221" or \u8220"Gang of Four\u8221" book) in 1994, which played a role in popularizing its use.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Smalltalk-80 MVC\par}
{\pard \ql \f0 \sa180 \li0 \fi0 It\u8217's important to understand what the original MVC pattern was aiming to solve as it has changed quite heavily since the days of its origin. Back in the 70\u8217's, graphical user-interfaces were few and far between. An approach known as {\field{\*\fldinst{HYPERLINK "http://martinfowler.com/eaaDev/uiArchs.html"}}{\fldrslt{\ul
Separated Presentation
}}}
 began to be used as a means to make a clear division between domain objects which modeled concepts in the real world (e.g a photo, a person) and the presentation objects which were rendered to the user\u8217's screen.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The Smalltalk-80 implementation of MVC took this concept further and had an objective of separating out the application logic from the user interface. The idea was that decoupling these parts of the application would also allow the reuse of models for other interfaces in the application. There are some interesting points worth noting about Smalltalk-80\u8217's MVC architecture:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab A Domain element was known as a Model and were ignorant of the user-interface (Views and Controllers)\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Presentation was taken care of by the View and the Controller, but there wasn\u8217't just a single view and controller. A View-Controller pair was required for each element being displayed on the screen and so there was no true separation between them\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab The Controller\u8217's role in this pair was handling user input (such as key-presses and click events), doing something sensible with them.\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab The Observer pattern was relied upon for updating the View whenever the Model changed\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Developers are sometimes surprised when they learn that the Observer pattern (nowadays commonly implemented as a Publish/Subscribe system) was included as a part of MVC\u8217's architecture decades ago. In Smalltalk-80\u8217's MVC, the View and Controller both observe the Model: anytime the Model changes, the Views react. A simple example of this is an application backed by stock market data - for the application to show real-time information, any change to the data in its Models should result in the View being refreshed instantly.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Martin Fowler has done an excellent job of writing about the {\field{\*\fldinst{HYPERLINK "http://martinfowler.com/eaaDev/uiArchs.html"}}{\fldrslt{\ul
origins
}}}
 of MVC over the years and if you are interested in further historical information about Smalltalk-80\u8217's MVC, I recommend reading his work.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 MVC As We Know It\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We\u8217've reviewed the 70\u8217's, but let us now return to the here and now. The MVC pattern has been applied to a diverse range of programming languages. For example, the popular Ruby on Rails is an implementation of a web application framework based on MVC for the Ruby language. JavaScript now has a number of MVC frameworks, including Ember.js, JavaScriptMVC, and of course Backbone.js. Given the importance of avoiding \u8220"spaghetti\u8221" code, a term which describes code that is very difficult to read or maintain due to its lack of structure, let\u8217's look at what the MVC pattern enables the Javascript developer to do.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 MVC is composed of three core components:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Models\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Models manage the data for an application. They are concerned with neither the user-interface nor presentation layers, but instead represent structured data that an application may require. When a model changes (e.g when it is updated), it will typically notify its observers (e.g views, a concept we will cover shortly) that a change has occurred so that they may react accordingly.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 To understand models better, let us imagine we have a JavaScript photo gallery application. In a photo gallery, a photo would merit its own model, as it represents a unique kind of domain-specific data. The Photo model may represent attributes such as a caption, image source and additional meta-data. A specific photo would be stored in an instance of a model. Here\u8217's an example of a simple Photo model implemented with Backbone.js:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var Photo = Backbone.Model.extend(\{\line
\line
    // Default attributes for the photo\line
    defaults: \{\line
      // Ensure that each photo created has an `src`.\line
      src: "placeholder.jpg",\line
      caption: "A default image",\line
      viewed: false\line
    \},\line
\line
    initialize: function() \{\line
    \}\line
\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The built-in capabilities of models vary across frameworks, however it\u8217's common for them to support validation of attributes, where attributes represent the properties of the model, such as a model identifier. When using models in real-world applications we generally also need a way of persisting models. Persistence allows us to edit and update models with the knowledge that their most recent states will be saved somewhere, for example in a web browser\u8217's localStorage data-store or synchronized with a database.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 A model may also have multiple views observing it. Imagine our Photo model contained meta-data such as the longitude and latitude where the photo was taken, a list of people present in the photo, and a list of tags. A developer could create a single view that displayed all these attributes, or might create three separate views to display each attribute. The important detail is that the Photo model doesn\u8217't care how these views are organized, it simply announces updates to its data as necessary. We\u8217'll come back to Views in more detail later.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 It is not uncommon for modern MVC/MV* frameworks to provide a means to group models together. In Backbone, these groups are called \u8220"Collections\u8221". Managing models in groups allows us to write application logic based on notifications from the group, should any model it contains change. This avoids the need to manually observe individual model instances.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Here\u8217's how we might group Photo models into a simplified Backbone Collection:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var PhotoGallery = Backbone.Collection.extend(\{\line
\line
    // Reference to this collection's model.\line
    model: Photo,\line
\line
    // Filter down the list of all photos that have been viewed\line
    viewed: function() \{\line
      return this.filter(function(photo)\{ return photo.get('viewed'); \});\line
    \},\line
\line
    // Filter down the list to only photos that have not yet been viewed\line
    unviewed: function() \{\line
      return this.without.apply(this, this.viewed());\line
    \}\line
\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 If you read older texts on MVC, you may come across a description of models as also managing application \u8216'state\u8217'. In JavaScript applications \u8220"state\u8221" has a specific meaning, typically referring to the current \u8220"state\u8221" of a view or sub-view on a user\u8217's screen at a fixed time. State is a topic which is regularly discussed when looking at Single-page applications, where the concept of state needs to be simulated.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Views\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Views are a visual representation of models that present a filtered view of their current state. A view typically observes a model and is notified when the model changes, allowing the view to update itself accordingly. Design pattern literature commonly refers to views as \u8216'dumb\u8217', given that their knowledge of models and controllers in an application is limited.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Users interact with views, which usually means reading and editing model data. For example, in our photo gallery application example, model viewing might happen in a user interface with a big image, a caption, and a list of tags. Model editing could be done through an \u8220"edit\u8221" view where a user who has selected a specific photo could edit its caption, tags, or other metadata in a form.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In MVC, the actual task of updating the Model falls to Controllers, which we\u8217'll be covering shortly.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Let\u8217's explore Views a little further using a simple JavaScript example. Below we can see a function that creates a single Photo view, consuming both a model instance and a controller instance.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We define a {\f1 render()} utility within our view which is responsible for rendering the contents of the {\f1 photoModel} using a JavaScript templating engine ({\field{\*\fldinst{HYPERLINK "http://underscorejs.org"}}{\fldrslt{\ul
Underscore
}}}
 templating) and updating the contents of our view, referenced by {\f1 photoEl}.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The {\f1 photoModel} then adds our {\f1 render()} callback as one of its subscribers, so that through the Observer pattern it can trigger the view to update when the model changes.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 You may wonder where user interaction comes into play here. When users click on any elements within the view, it\u8217's not the view\u8217's responsibility to know what to do next. A Controller makes this decision. In our sample implementation, this is achieved by adding an event listener to {\f1 photoEl} which will delegate handling the click behavior back to the controller, passing the model information along with it in case it\u8217's needed.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The benefit of this architecture is that each component plays its own separate role in making the application function as needed.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var buildPhotoView = function( photoModel, photoController )\{\line
\line
    var base        = document.createElement('div'),\line
        photoEl     = document.createElement('div');\line
\line
     base.appendChild(photoEl);\line
\line
     var render= function()\{\line
        // We use a templating library such as Underscore\line
        // templating which generates the HTML for our\line
        // photo entry\line
        photoEl.innerHTML = _.template('photoTemplate', \{src: photoModel.getSrc()\});\line
     \}\line
\line
     photoModel.addSubscriber( render );\line
\line
     photoEl.addEventListener('click', function()\{\line
        photoController.handleEvent('click', photoModel );\line
     \});\line
\line
     var show = function()\{\line
        photoEl.style.display  = '';\line
     \}\line
\line
     var hide = function()\{\line
        photoEl.style.display  = 'none';\line
     \}\line
\line
\line
     return\{\line
        showView: show,\line
        hideView: hide\line
     \}\line
\line
\}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Templating}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In the context of JavaScript frameworks that support MVC/MV*, it is worth looking more closely at JavaScript templating and its relationship to Views.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 It has long been considered bad practice (and computationally expensive) to manually create large blocks of HTML markup in-memory through string concatenation. Developers using this technique often find themselves iterating through their data, wrapping it in nested divs and using outdated techniques such as {\f1 document.write} to inject the \u8216'template\u8217' into the DOM. This approach often means keeping scripted markup inline with standard markup, which can quickly become difficult to read and maintain, especially when building large applications.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 JavaScript templating libraries (such as Handlebars.js or Mustache) are often used to define templates for views as HTML markup containing template variables. These template blocks can be either stored externally or within script tags with a custom type (e.g \u8216'text/template\u8217'). Variables are delimited using a variable syntax (e.g \{\{name\}\}). Javascript template libraries typically accept data in JSON, and the grunt work of populating templates with data is taken care of by the framework itself. This has a several benefits, particularly when opting to store templates externally as this can let applications load templates dynamically on an as-needed basis.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Let\u8217's compare two examples of HTML templates. One is implemented using the popular Handlebars.js library, and the other uses Underscore\u8217's \u8216'microtemplates\u8217'.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Handlebars.js:}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 <li class="photo">\line
  <h2>\{\{caption\}\}</h2>\line
  <img class="source" src="\{\{src\}\}"/>\line
  <div class="meta-data">\line
    \{\{metadata\}\}\line
  </div>\line
</li>\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Underscore.js Microtemplates:}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 <li class="photo">\line
  <h2><%= caption %></h2>\line
  <img class="source" src="<%= src %>"/>\line
  <div class="meta-data">\line
    <%= metadata %>\line
  </div>\line
</li>\par}
{\pard \ql \f0 \sa180 \li0 \fi0 You may also use double curly brackets (i.e {\f1 \{\{\}\}}) (or any other tag you feel comfortable with) in Microtemplates. In the case of curly brackets, this can be done by setting the Underscore {\f1 templateSettings} attribute as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 _.templateSettings = \{ interpolate : /\\\{\\\{(.+?)\\\}\\\}/g \};\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b A note on navigation and state}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 It is also worth noting that in classical web development, navigating between independent views required the use of a page refresh. In single-page JavaScript applications, however, once data is fetched from a server via Ajax, it can be dynamically rendered in a new view within the same page. Since this doesn\u8217't automatically update the URL, the role of navigation thus falls to a \u8220"router\u8221", which assists in managing application state (e.g allowing users to bookmark a particular view they have navigated to). As routers are however neither a part of MVC nor present in every MVC-like framework, I will not be going into them in greater detail in this section.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Controllers\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Controllers are an intermediary between models and views which are classically responsible for two tasks: they both update the view when the model changes and update the model when the user manipulates the view.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In our photo gallery application, a controller would be responsible for handling changes the user made to the edit view for a particular photo, updating a specific photo model when a user has finished editing.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 It\u8217's with controllers that most JavaScript MVC frameworks depart from this interpretation of the MVC pattern. The reasons for this vary, but in my opinion, Javascript framework authors likely initially looked at server-side interpretations of MVC (such as Ruby on Rails), realized that that approach didn\u8217't translate 1:1 on the client-side, and so re-interpreted the C in MVC to solve their state management problem. This was a clever approach, but it can make it hard for developers coming to MVC for the first time to understand both the classical MVC pattern and the \u8220"proper\u8221" role of controllers in other non-Javascript frameworks.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 So does Backbone.js have Controllers? Not really. Backbone\u8217's Views typically contain \u8220"controller\u8221" logic, and Routers (discussed below) are used to help manage application state, but neither are true Controllers according to classical MVC.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In this respect, contrary to what might be mentioned in the official documentation or in blog posts, Backbone is neither a truly MVC/MVP nor MVVM framework. It\u8217's in fact better to see it a member of the MV* family which approaches architecture in its own way. There is of course nothing wrong with this, but it is important to distinguish between classical MVC and MV* should you be relying on discussions of MVC to help with your Backbone projects.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Controllers in Spine.js vs Backbone.js\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Spine.js}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We now know that controllers are traditionally responsible for updating the view when the model changes (and similarly the model when the user updates the view). Since Backbone doesn\u8217't have its {\b own} explicit controllers, it\u8217's useful to review the controller from another MVC framework to appreciate the difference in implementations. Let\u8217's take a look at {\field{\*\fldinst{HYPERLINK "http://spinejs.com/"}}{\fldrslt{\ul
Spine.js
}}}
:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In this example, we\u8217're going to have a controller called {\f1 PhotosController} which will be in charge of individual photos in the application. It will ensure that when the view updates (e.g a user edited the photo meta-data) the corresponding model does too.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 (Note: We won\u8217't be delving heavily into Spine.js beyond this example, but it\u8217's worth looking at it to learn more about Javascript frameworks in general.)\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 // Controllers in Spine are created by inheriting from Spine.Controller\line
\line
var PhotosController = Spine.Controller.sub(\{\line
  init: function()\{\line
    this.item.bind("update", this.proxy(this.render));\line
    this.item.bind("destroy", this.proxy(this.remove));\line
  \},\line
\line
  render: function()\{\line
    // Handle templating\line
    this.replace($("#photoTemplate").tmpl(this.item));\line
    return this;\line
  \},\line
\line
  remove: function()\{\line
    this.$el.remove();\line
    this.release();\line
  \}\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In Spine, controllers are considered the glue for an application, adding and responding to DOM events, rendering templates and ensuring that views and models are kept in sync (which makes sense in the context of what we know to be a controller).\par}
{\pard \ql \f0 \sa180 \li0 \fi0 What we\u8217're doing in the above example is setting up listeners in the {\f1 update} and {\f1 destroy} events using {\f1 render()} and {\f1 remove()}. When a photo entry gets updated, we re-render the view to reflect the changes to the meta-data. Similarly, if the photo gets deleted from the gallery, we remove it from the view. In case you were wondering about the {\f1 tmpl()} function in the code snippet: in the {\f1 render()} function, we\u8217're using this to render a JavaScript template called #photoTemplate which simply returns an HTML string used to replace the controller\u8217's current element.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 What this provides us with is a very lightweight, simple way to manage changes between the model and the view.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Backbone.js}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Later on in this section we\u8217're going to revisit the differences between Backbone and traditional MVC, but for now let\u8217's focus on controllers.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In Backbone, controller logic is shared between Backbone.View and Backbone.Router. Earlier releases of Backbone contained something called Backbone.Controller, but it was renamed to Router to clarify its role.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 A Router\u8217's main purpose is to translate URL requests into application states. When a user browses to the URL www.example.com/photos/42, a Router could be used to show the photo with that ID, and to define what application behavior should be run in response to that request. Routers {\i can} contain traditional controller responsibilities, such as binding the events between models and views, or rendering parts of the page. However, Backbone contributor Tim Branyen has pointed out that it\u8217's possible to get away without needing Backbone.Router at all for this, so a way to think about it using the Router paradigm is probably:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var PhotoRouter = Backbone.Router.extend(\{\line
  routes: \{ "photos/:id": "route" \},\line
\line
  route: function(id) \{\line
    var item = photoCollection.get(id);\line
    var view = new PhotoView(\{ model: item \});\line
\line
    something.html( view.render().el );\line
  \}\line
\}):\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 What does MVC give us?\par}
{\pard \ql \f0 \sa180 \li0 \fi0 To summarize, the separation of concerns in MVC facilitates modularization of an application\u8217's functionality and enables:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Easier overall maintenance. When updates need to be made to the application it is clear whether the changes are data-centric, meaning changes to models and possibly controllers, or merely visual, meaning changes to views.\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Decoupling models and views means that it\u8217's straight-forward to write unit tests for business logic\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Duplication of low-level model and controller code is eliminated across the application\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Depending on the size of the application and separation of roles, this modularity allows developers responsible for core logic and developers working on the user-interfaces to work simultaneously\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Delving deeper\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Right now, you likely have a basic understanding of what the MVC pattern provides, but for the curious, we\u8217'll explore it a little further.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The GoF (Gang of Four) do not refer to MVC as a design pattern, but rather consider it a \u8220"set of classes to build a user interface\u8221". In their view, it\u8217's actually a variation of three other classical design patterns: the Observer (Pub/Sub), Strategy and Composite patterns. Depending on how MVC has been implemented in a framework, it may also use the Factory and Decorator patterns. I\u8217've covered some of these patterns in my other free book, JavaScript Design Patterns For Beginners if you would like to read into them further.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 As we\u8217've discussed, models represent application data, while views handle what the user is presented on screen. As such, MVC relies on Pub/Sub for some of its core communication (something that surprisingly isn\u8217't covered in many articles about the MVC pattern). When a model is changed it \u8220"publishes\u8221" to the rest of the application that it has been updated. The \u8220"subscriber\u8221"\u8211-generally a Controller\u8211-then updates the view accordingly. The observer-viewer nature of this relationship is what facilitates multiple views being attached to the same model.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For developers interested in knowing more about the decoupled nature of MVC (once again, depending on the implementation), one of the goals of the pattern is to help define one-to-many relationships between a topic and its observers. When a topic changes, its observers are updated. Views and controllers have a slightly different relationship. Controllers facilitate views to respond to different user input and are an example of the Strategy pattern.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Summary\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Having reviewed the classical MVC pattern, you should now understand how it allows developers to cleanly separate concerns in an application. You should also now appreciate how JavaScript MVC frameworks may differ in their interpretation of MVC, and how they share some of the fundamental concepts of the original pattern.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 When reviewing a new JavaScript MVC/MV* framework, remember - it can be useful to step back and consider how it\u8217's opted to approach Models, Views, Controllers or other alternatives, as this can better help you grok how the framework expects to be used.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 MVP\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Model-view-presenter (MVP) is a derivative of the MVC design pattern which focuses on improving presentation logic. It originated at a company named {\field{\*\fldinst{HYPERLINK "http://en.wikipedia.org/wiki/Taligent"}}{\fldrslt{\ul
Taligent
}}}
 in the early 1990s while they were working on a model for a C++ CommonPoint environment. Whilst both MVC and MVP target the separation of concerns across multiple components, there are some fundamental differences between them.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For the purposes of this summary we will focus on the version of MVP most suitable for web-based architectures.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Models, Views & Presenters\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The P in MVP stands for presenter. It\u8217's a component which contains the user-interface business logic for the view. Unlike MVC, invocations from the view are delegated to the presenter, which are decoupled from the view and instead talk to it through an interface. This allows for all kinds of useful things such as being able to mock views in unit tests.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The most common implementation of MVP is one which uses a Passive View (a view which is for all intents and purposes \u8220"dumb\u8221"), containing little to no logic. MVP models are almost identical to MVC models and handle application data. The presenter acts as a mediator which talks to both the view and model, however both of these are isolated from each other. They effectively bind models to views, a responsibility held by Controllers in MVC. Presenters are at the heart of the MVP pattern and as you can guess, incorporate the presentation logic behind views.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Solicited by a view, presenters perform any work to do with user requests and pass data back to them. In this respect, they retrieve data, manipulate it and determine how the data should be displayed in the view. In some implementations, the presenter also interacts with a service layer to persist data (models). Models may trigger events but it\u8217's the presenter\u8217's role to subscribe to them so that it can update the view. In this passive architecture, we have no concept of direct data binding. Views expose setters which presenters can use to set data.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The benefit of this change from MVC is that it increases the testability of your application and provides a more clean separation between the view and the model. This isn\u8217't however without its costs as the lack of data binding support in the pattern can often mean having to take care of this task separately.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Although a common implementation of a {\field{\*\fldinst{HYPERLINK "http://martinfowler.com/eaaDev/PassiveScreen.html"}}{\fldrslt{\ul
Passive View
}}}
 is for the view to implement an interface, there are variations on it, including the use of events which can decouple the View from the Presenter a little more. As we don\u8217't have the interface construct in JavaScript, we\u8217're using it more and more a protocol than an explicit interface here. It\u8217's technically still an API and it\u8217's probably fair for us to refer to it as an interface from that perspective.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 There is also a {\field{\*\fldinst{HYPERLINK "http://martinfowler.com/eaaDev/SupervisingPresenter.html"}}{\fldrslt{\ul
Supervising Controller
}}}
 variation of MVP, which is closer to the MVC and {\field{\*\fldinst{HYPERLINK "http://en.wikipedia.org/wiki/Model_View_ViewModel"}}{\fldrslt{\ul
MVVM
}}}
 patterns as it provides data-binding from the Model directly from the View. Key-value observing (KVO) plugins (such as Derick Bailey\u8217's Backbone.ModelBinding plugin) introduce this idea of a Supervising Controller to Backbone.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 MVP or MVC?\par}
{\pard \ql \f0 \sa180 \li0 \fi0 MVP is generally used most often in enterprise-level applications where it\u8217's necessary to reuse as much presentation logic as possible. Applications with very complex views and a great deal of user interaction may find that MVC doesn\u8217't quite fit the bill here as solving this problem may mean heavily relying on multiple controllers. In MVP, all of this complex logic can be encapsulated in a presenter, which can simplify maintenance greatly.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 As MVP views are defined through an interface and the interface is technically the only point of contact between the system and the view (other than a presenter), this pattern also allows developers to write presentation logic without needing to wait for designers to produce layouts and graphics for the application.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Depending on the implementation, MVP may be more easy to automatically unit test than MVC. The reason often cited for this is that the presenter can be used as a complete mock of the user-interface and so it can be unit tested independent of other components. In my experience this really depends on the languages you are implementing MVP in (there\u8217's quite a difference between opting for MVP for a JavaScript project over one for say, ASP.NET).\par}
{\pard \ql \f0 \sa180 \li0 \fi0 At the end of the day, the underlying concerns you may have with MVC will likely hold true for MVP given that the differences between them are mainly semantic. As long as you are cleanly separating concerns into models, views and controllers (or presenters) you should be achieving most of the same benefits regardless of the pattern you opt for.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 MVC, MVP and Backbone.js\par}
{\pard \ql \f0 \sa180 \li0 \fi0 There are very few, if any architectural JavaScript frameworks that claim to implement the MVC or MVP patterns in their classical form as many JavaScript developers don\u8217't view MVC and MVP as being mutually exclusive (we are actually more likely to see MVP strictly implemented when looking at web frameworks such as ASP.NET or GWT). This is because it\u8217's possible to have additional presenter/view logic in your application and yet still consider it a flavor of MVC.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Backbone contributor {\field{\*\fldinst{HYPERLINK "http://ireneros.com/"}}{\fldrslt{\ul
Irene Ros
}}}
 subscribes to this way of thinking as when she separates Backbone views out into their own distinct components, she needs something to actually assemble them for her. This could either be a controller route (such as a {\f1 Backbone.Router}, covered later in the book) or a callback in response to data being fetched.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 That said, some developers do however feel that Backbone.js better fits the description of MVP than it does MVC . Their view is that:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab The presenter in MVP better describes the {\f1 Backbone.View} (the layer between View templates and the data bound to it) than a controller does\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab The model fits {\f1 Backbone.Model} (it isn\u8217't that different from the classical MVC \u8220"Model\u8221")\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab The views best represent templates (e.g Handlebars/Mustache markup templates)\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 A response to this could be that the view can also just be a View (as per MVC) because Backbone is flexible enough to let it be used for multiple purposes. The V in MVC and the P in MVP can both be accomplished by {\f1 Backbone.View} because they\u8217're able to achieve two purposes: both rendering atomic components and assembling those components rendered by other views.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We\u8217've also seen that in Backbone the responsibility of a controller is shared with both the Backbone.View and Backbone.Router and in the following example we can actually see that aspects of that are certainly true.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Here, our Backbone {\f1 PhotoView} uses the Observer pattern to \u8216'subscribe\u8217' to changes to a View\u8217's model in the line {\f1 this.model.on('change',...)}. It also handles templating in the {\f1 render()} method, but unlike some other implementations, user interaction is also handled in the View (see {\f1 events}).\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var PhotoView = Backbone.View.extend(\{\line
\line
    //... is a list tag.\line
    tagName:  "li",\line
\line
    // Pass the contents of the photo template through a templating\line
    // function, cache it for a single photo\line
    template: _.template($('#photo-template').html()),\line
\line
    // The DOM events specific to an item.\line
    events: \{\line
      "click img" : "toggleViewed"\line
    \},\line
\line
    // The PhotoView listens for changes to its model, re-rendering. Since there's\line
    // a one-to-one correspondence between a **Photo** and a **PhotoView** in this\line
    // app, we set a direct reference on the model for convenience.\line
\line
    initialize: function() \{\line
      _.bindAll(this, 'render');\line
      this.model.on('change', this.render);\line
      this.model.on('destroy', this.remove);\line
    \},\line
\line
    // Re-render the photo entry\line
    render: function() \{\line
      this.$el.html(this.template(this.model.toJSON()));\line
      return this;\line
    \},\line
\line
    // Toggle the `"viewed"` state of the model.\line
    toggleViewed: function() \{\line
      this.model.viewed();\line
    \}\line
\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Another (quite different) opinion is that Backbone more closely resembles {\field{\*\fldinst{HYPERLINK "http://martinfowler.com/eaaDev/uiArchs.html#ModelViewController"}}{\fldrslt{\ul
Smalltalk-80 MVC
}}}
, which we went through earlier.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 As regular Backbone user Derick Bailey has {\field{\*\fldinst{HYPERLINK "http://lostechies.com/derickbailey/2011/12/23/backbone-js-is-not-an-mvc-framework/"}}{\fldrslt{\ul
written
}}}
, it\u8217's ultimately best not to force Backbone to fit any specific design patterns. Design patterns should be considered flexible guides to how applications may be structured and in this respect, Backbone doesn\u8217't fit either MVC nor MVP perfectly. Instead, it borrows some of the best concepts from multiple architectural patterns and creates a flexible framework that just works well. Call it {\b the Backbone way}, MV* or whatever helps reference its flavor of application architecture.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 It {\i is} however worth understanding where and why these concepts originated, so I hope that my explanations of MVC and MVP have been of help. Most structural JavaScript frameworks will adopt their own take on classical patterns, either intentionally or by accident, but the important thing is that they help us develop applications which are organized, clean and can be easily maintained.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Fast facts\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Backbone.js\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Core components: Model, View, Collection, Router. Enforces its own flavor of MV*\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Good documentation, with more improvements on the way\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Used by large companies such as SoundCloud and Foursquare to build non-trivial applications\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Event-driven communication between views and models. As we\u8217'll see, it\u8217's relatively straight-forward to add event listeners to any attribute in a model, giving developers fine-grained control over what changes in the view\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Supports data bindings through manual events or a separate Key-value observing (KVO) library\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Great support for RESTful interfaces out of the box, so models can be easily tied to a backend\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Extensive eventing system. It\u8217's {\field{\*\fldinst{HYPERLINK "http://lostechies.com/derickbailey/2011/07/19/references-routing-and-the-event-aggregator-coordinating-views-in-backbone-js/"}}{\fldrslt{\ul
trivial
}}}
 to add support for pub/sub in Backbone\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Prototypes are instantiated with the {\f1 new} keyword, which some developers prefer\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Agnostic about templating frameworks, however Underscore\u8217's micro-templating is available by default. Backbone works well with libraries like Handlebars\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Doesn\u8217't support deeply nested models, though there are Backbone plugins such as {\field{\*\fldinst{HYPERLINK "https://github.com/PaulUithol/Backbone-relational"}}{\fldrslt{\ul
this
}}}
 which can help\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Clear and flexible conventions for structuring applications. Backbone doesn\u8217't force usage of all of its components and can work with only those needed.\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs36 The Internals\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In this section, you\u8217'll learn the essentials of Backbone\u8217's models, views, collections and routers, as well as about using namespacing to organize your code. This isn\u8217't meant as a replacement for the official documentation, but it will help you understand many of the core concepts behind Backbone before you start building applications with it.\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Models\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Collections\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Routers\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Views\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Namespacing\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Models\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Backbone models contain interactive data for an application as well as the logic around this data. For example, we can use a model to represent the concept of a photo object including its attributes like tags, titles and a location.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Models can be created by extending {\f1 Backbone.Model} as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var Photo = Backbone.Model.extend(\{\line
    defaults: \{\line
        src: 'placeholder.jpg',\line
        title: 'an image placeholder',\line
        coordinates: [0,0]\line
    \},\line
    initialize: function()\{\line
        this.on("change:src", function()\{\line
            var src = this.get("src");\line
            console.log('Image source updated to ' + src);\line
        \});\line
    \},\line
    changeSrc: function( source )\{\line
        this.set(\{ src: source \});\line
    \}\line
\});\line
\line
var somePhoto = new Photo(\{ src: "test.jpg", title:"testing"\});\line
somePhoto.changeSrc("magic.jpg"); // which triggers "change:src" and logs an update message to the console.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Initialization\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The {\f1 initialize()} method is called when a new instance of a model is created. Its use is optional, however you\u8217'll see why it\u8217's good practice to use it below.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var Photo = Backbone.Model.extend(\{\line
    initialize: function()\{\line
        console.log('this model has been initialized');\line
    \}\line
\});\line
\line
// We can then create our own instance of a photo as follows:\line
var myPhoto = new Photo();\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Getters & Setters\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Model.get()}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 Model.get()} provides easy access to a model\u8217's attributes. Attributes which are passed through to the model on instantiation are instantly available for retrieval.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var myPhoto = new Photo(\{ title: "My awesome photo",\line
                          src:"boston.jpg",\line
                          location: "Boston",\line
                          tags:['the big game', 'vacation']\}),\line
\line
    title = myPhoto.get("title"), //My awesome photo\line
    location = myPhoto.get("location"), //Boston\line
    tags = myPhoto.get("tags"), // ['the big game','vacation']\line
    photoSrc = myPhoto.get("src"); //boston.jpg\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Alternatively, if you wish to directly access all of the attributes in a model\u8217's instance directly, you can achieve this as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var myAttributes = myPhoto.attributes;\line
console.log(myAttributes);\par}
{\pard \ql \f0 \sa180 \li0 \fi0 It is best practice to use {\f1 Model.set()} or direct instantiation to set the values of a model\u8217's attributes.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Accessing {\f1 Model.attributes} directly is generally discouraged. Instead, should you need to read or clone data, {\f1 Model.toJSON()} is recommended for this purpose. If you would like to access or copy a model\u8217's attributes for purposes such as JSON stringification (e.g.\u160?for serialization prior to being passed to a view), this can be achieved using Model.toJSON(). Remember that this will return an object and JSON.stringify() should be used to get a string representation of the data:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var myAttributes = myPhoto.toJSON();\line
console.log(JSON.stringify(myattributes));\line
/* this returns:\line
 \{ title: "My awesome photo",\line
   src:"boston.jpg",\line
   location: "Boston",\line
   tags:['the big game', 'vacation']\}\line
*/\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Model.set()\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 Model.set()} allows us to pass attributes into an instance of our model. Attributes can either be set during initialization or at any time afterwards. It\u8217's important to avoid trying to set a Model\u8217's attributes directly (for example, {\f1 Model.caption = 'A new caption'}). Backbone uses Model.set() to know when to broadcast that a model\u8217's data has changed.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var Photo = Backbone.Model.extend(\{\line
    initialize: function()\{\line
        console.log('this model has been initialized');\line
    \}\line
\});\line
\line
// Setting the value of attributes via instantiation\line
var myPhoto = new Photo(\{ title: 'My awesome photo', location: 'Boston' \});\line
\line
var myPhoto2 = new Photo();\line
\line
// Setting the value of attributes through Model.set()\line
myPhoto2.set(\{ title:'Vacation in Florida', location: 'Florida' \});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Default values}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 There are times when you want your model to have a set of default values (e.g.\u160?in a scenario where a complete set of data isn\u8217't provided by the user). This can be set using a property called {\f1 defaults} in your model.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var Photo = Backbone.Model.extend(\{\line
    defaults: \{\line
        title: 'Another photo!',\line
        tags:  ['untagged'],\line
        location: 'home',\line
        src: 'placeholder.jpg'\line
    \},\line
    initialize: function()\{\line
    \}\line
\});\line
\line
var myPhoto = new Photo(\{ location: "Boston",\line
                          tags:['the big game', 'vacation']\}),\line
    title   = myPhoto.get("title"), //Another photo!\line
    location = myPhoto.get("location"), //Boston\line
    tags = myPhoto.get("tags"), // ['the big game','vacation']\line
    photoSrc = myPhoto.get("src"); //placeholder.jpg\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Listening for changes to your model}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Any and all of the attributes in a Backbone model can have listeners bound to them which detect when their values change. Listeners can be added to the {\f1 initialize()} function:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 this.on('change', function()\{\line
    console.log('values for this model have changed');\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In the following example, we log a message whenever a specific attribute (the title of our Photo model) is altered.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var Photo = Backbone.Model.extend(\{\line
    defaults: \{\line
        title: 'Another photo!',\line
        tags:  ['untagged'],\line
        location: 'home',\line
        src: 'placeholder.jpg'\line
    \},\line
    initialize: function()\{\line
        console.log('this model has been initialized');\line
        this.on("change:title", function()\{\line
            var title = this.get("title");\line
            console.log("My title has been changed to.. " + title);\line
        \});\line
    \},\line
\line
    setTitle: function(newTitle)\{\line
        this.set(\{ title: newTitle \});\line
    \}\line
\});\line
\line
var myPhoto = new Photo(\{ title:"Fishing at the lake", src:"fishing.jpg"\});\line
myPhoto.setTitle('Fishing at sea');\line
//logs 'My title has been changed to.. Fishing at sea'\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Validation}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Backbone supports model validation through {\f1 Model.validate()}, which allows checking the attribute values for a model prior to them being set.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Validation functions can be as simple or complex as necessary. If the attributes provided are valid, nothing should be returned from {\f1 .validate()}. If they are invalid, a custom error can be returned instead.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 A basic example for validation can be seen below:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var Photo = Backbone.Model.extend(\{\line
    validate: function(attribs)\{\line
        if(attribs.src === undefined)\{\line
            return "Remember to set a source for your image!";\line
        \}\line
    \},\line
\line
    initialize: function()\{\line
        console.log('this model has been initialized');\line
        this.on("error", function(model, error)\{\line
            console.log(error);\line
        \});\line
    \}\line
\});\line
\line
var myPhoto = new Photo();\line
myPhoto.set(\{ title: "On the beach" \});\line
//logs Remember to set a source for your image!\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Note}: Backbone passes the {\f1 attributes} object by shallow copy to the {\f1 validate} function using the Underscore {\f1 _.extend} method. This means that it is not possible to change any {\f1 Number}, {\f1 String} or {\f1 Boolean} attribute by reference in the way that one might expect a JavaScript object to behave. As shallow copy doesn\u8217't copy objects by implicitly copying them, but rather, by reference, one ca change the attributes on those objects.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 An example of this (by @fivetanley) is available {\field{\*\fldinst{HYPERLINK "http://jsfiddle.net/2NdDY/7/"}}{\fldrslt{\ul
here
}}}
.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Views\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Views in Backbone don\u8217't contain the markup for your application, but rather they are there to support models by defining the logic for how they should be represented to the user. This is usually achieved using JavaScript templating (e.g.\u160?Mustache, jQuery-tmpl, etc.). A view\u8217's {\f1 render()} function can be bound to a model\u8217's {\f1 change()} event, allowing the view to always be up to date without requiring a full page refresh.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Creating new views\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Similar to the previous sections, creating a new view is relatively straight-forward. To create a new View, simply extend {\f1 Backbone.View}. I\u8217'll explain this code in detail below:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var PhotoSearch = Backbone.View.extend(\{\line
    el: $('#results'),\line
    render: function( event )\{\line
        var compiled_template = _.template( $("#results-template").html() );\line
        this.$el.html( compiled_template(this.model.toJSON()) );\line
        return this; //recommended as this enables calls to be chained.\line
    \},\line
    events: \{\line
        "submit #searchForm":  "search",\line
        "click .reset": "reset",\line
        "click .advanced": "switchContext"\line
    \},\line
    search: function( event )\{\line
        //executed when a form '#searchForm' has been submitted\line
    \},\line
    reset: function( event )\{\line
        //executed when an element with class "reset" has been clicked.\line
    \},\line
    switchContext: function( event )\{\line
        //executed when an element with class "advanced" has been clicked.\line
    \}\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 What is {\f1 el}?\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 el} is basically a reference to a DOM element and all views must have one. It allows for all of the contents of a view to be inserted into the DOM at once, which makes for faster rendering because the browser performs the minimum required reflows and repaints.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 There are two ways to attach a DOM element to a view: the element already exists in the page or a new element is created for the view and added manually by the developer. If the element already exists in the page, you can set {\f1 el} as either a CSS selector that matches the element or a simple reference to the DOM element.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 el: '#footer',\line
// OR\line
el: document.getElementById( 'footer' )\par}
{\pard \ql \f0 \sa180 \li0 \fi0 If you want to create a new element for your view, set any combination of the following view\u8217's properties: {\f1 tagName}, {\f1 id} and {\f1 className}. A new element will be created for you by the framework and a reference to it will be available at the {\f1 el} property.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 tagName: 'p', // required, but defaults to 'div' if not set\line
className: 'container', // optional, you can assign multiple classes to this property like so 'container homepage'\line
id: 'header', // optional\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The above code creates the {\f1 DOMElement} below but doesn\u8217't append it to the DOM.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 <p id="header" class="container"></p>\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Understanding {\f1 render()}}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 render()} is an optional function that defines the logic for rendering a template. We\u8217'll use Underscore\u8217's micro-templating in these examples, but remember you can use other templating frameworks if you prefer.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The {\f1 _.template} method in Underscore compiles JavaScript templates into functions which can be evaluated for rendering. In the above view, I\u8217'm passing the markup from a template with id {\f1 results-template} to {\f1 _.template()} to be compiled. Next, I set the html of the {\f1 el} DOM element to the output of processing a JSON version of the model associated with the view through the compiled template.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Presto! This populates the template, giving you a data-complete set of markup in just a few short lines of code.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b The {\f1 events} attribute}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The Backbone {\f1 events} attribute allows us to attach event listeners to either custom selectors, or directly to {\f1 el} if no selector is provided. An event takes the form {\f1 \{"eventName selector": "callbackFunction"\}} and a number of DOM event-types are supported, including {\f1 click}, {\f1 submit}, {\f1 mouseover}, {\f1 dblclick} and more.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 What isn\u8217't instantly obvious is that under the bonnet, Backbone uses jQuery\u8217's {\f1 .delegate()} to provide instant support for event delegation but goes a little further, extending it so that {\f1 this} always refers to the current view object. The only thing to really keep in mind is that any string callback supplied to the events attribute must have a corresponding function with the same name within the scope of your view.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Collections\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Collections are sets of Models and are created by extending {\f1 Backbone.Collection}.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Normally, when creating a collection you\u8217'll also want to pass through a property specifying the model that your collection will contain, as well as any instance properties required.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In the following example, we create a PhotoCollection that will contain our Photo models:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var PhotoCollection = Backbone.Collection.extend(\{\line
    model: Photo\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Getters and Setters}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 There are a few different ways to retrieve a model from a collection. The most straight-forward is to use {\f1 Collection.get()} which accepts a single id as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var skiingEpicness = PhotoCollection.get(2);\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Sometimes you may also want to get a model based on its client id. The client id is a property that Backbone automatically assigns models that have not yet been saved. You can get a model\u8217's client id from its {\f1 .cid} property.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var mySkiingCrash = PhotoCollection.getByCid(456);\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Backbone Collections don\u8217't have setters as such, but do support adding new models via {\f1 .add()} and removing models via {\f1 .remove()}.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var a = new Backbone.Model(\{ title: 'my vacation'\}),\line
    b = new Backbone.Model(\{ title: 'my holiday'\});\line
\line
var photoCollection = new PhotoCollection([a,b]);\line
photoCollection.remove([a,b]);\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Listening for events}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 As collections represent a group of items, we\u8217're also able to listen for {\f1 add} and {\f1 remove} events for when new models are added or removed from the collection. Here\u8217's an example:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var PhotoCollection = new Backbone.Collection();\line
PhotoCollection.on("add", function(photo) \{\line
  console.log("I liked " + photo.get("title") + ' it\\'s this one, right? '  + photo.get("src"));\line
\});\line
\line
PhotoCollection.add([\line
  \{title: "My trip to Bali", src: "bali-trip.jpg"\},\line
  \{title: "The flight home", src: "long-flight-oofta.jpg"\},\line
  \{title: "Uploading pix", src: "too-many-pics.jpg"\}\line
]);\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In addition, we\u8217're able to bind a {\f1 change} event to listen for changes to models in the collection.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 PhotoCollection.on("change:title", function()\{\line
    console.log("there have been updates made to this collection's titles");\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Fetching models from the server}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 Collections.fetch()} retrieves a default set of models from the server in the form of a JSON array. When this data returns, the current collection\u8217's contents will be replaced with the contents of the array.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var PhotoCollection = new Backbone.Collection;\line
PhotoCollection.url = '/photos';\line
PhotoCollection.fetch();\par}
{\pard \ql \f0 \sa180 \li0 \fi0 During configuration, Backbone sets a variable to denote if extended HTTP methods are supported by the server. Another setting controls if the server understands the correct MIME type for JSON:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 Backbone.emulateHTTP = false;\line
Backbone.emulateJSON = false;\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The Backbone.sync method that uses these values is actually an integral part of Backbone.js. A jQuery-like ajax method is assumed, so HTTP parameters are organised based on jQuery\u8217's API. Searching through the code for calls to the sync method show it\u8217's used whenever a model is saved, fetched, or deleted (destroyed).\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Under the covers, {\f1 Backbone.sync} is the function called every time Backbone tries to read or save models to the server. It uses jQuery or Zepto\u8217's ajax implementations to make these RESTful requests, however this can be overridden as per your needs. :\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The sync function may be overriden globally as Backbone.sync, or at a finer-grained level, by adding a sync function to a Backbone collection or to an individual model.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 There\u8217's no fancy plugin API for adding a persistence layer \u8211- simply override Backbone.sync with the same function signature:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 Backbone.sync = function(method, model, options) \{\line
\};\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The default methodMap is useful for working out what the method argument does:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var methodMap = \{\line
  'create': 'POST',\line
  'update': 'PUT',\line
  'delete': 'DELETE',\line
  'read':   'GET'\line
\};\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In the above example if we wanted to log an event when {\f1 .sync()} was called, we could do this:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var id_counter = 1;\line
Backbone.sync = function(method, model) \{\line
  console.log("I've been passed " + method + " with " + JSON.stringify(model));\line
  if(method === 'create')\{ model.set('id', id_counter++); \}\line
\};\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Resetting/Refreshing Collections}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Rather than adding or removing models individually, you might occasionally wish to update an entire collection at once. {\f1 Collection.reset()} allows us to replace an entire collection with new models as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 PhotoCollection.reset([\line
  \{title: "My trip to Scotland", src: "scotland-trip.jpg"\},\line
  \{title: "The flight from Scotland", src: "long-flight.jpg"\},\line
  \{title: "Latest snap of Loch Ness", src: "lochness.jpg"\}]);\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Note that using {\f1 Collection.reset()} doesn\u8217't fire any {\f1 add} or {\f1 remove} events. A {\f1 reset} event is fired instead.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Underscore utility functions\par}
{\pard \ql \f0 \sa180 \li0 \fi0 As Backbone requires Underscore as a hard dependency, we\u8217're able to use many of the utilities it has to offer to aid with our application development. Here\u8217's an example of how Underscore\u8217's {\f1 sortBy()} method can be used to sort a collection of photos based on a particular attribute.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var sortedByAlphabet = PhotoCollection.sortBy(function (photo) \{\line
    return photo.get("title").toLowerCase();\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The complete list of what Underscore can do is beyond the scope of this guide, but can be found in its official {\field{\*\fldinst{HYPERLINK "http://documentcloud.github.com/underscore/"}}{\fldrslt{\ul
docs
}}}
.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Chainable API\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Speaking of utility methods, another bit of sugar in Backbone is the support for Underscore\u8217's chain method. This works by calling the original method with the current array of models and returning the result. In case you haven\u8217't seen it before, the chainable API looks like this:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var collection = new Backbone.Collection([\line
  \{ name: 'Tim', age: 5 \},\line
  \{ name: 'Ida', age: 26 \},\line
  \{ name: 'Rob', age: 55 \}\line
]);\line
\line
collection.chain()\line
  .filter(function(item) \{ return item.get('age') > 10; \})\line
  .map(function(item) \{ return item.get('name'); \})\line
  .value();\line
\line
// Will return ['Ida', 'Rob']\line
Some of the Backbone-specific method will return this, which means they can be chained as well:\line
\line
var collection = new Backbone.Collection();\line
\line
collection\line
    .add(\{ name: 'John', age: 23 \})\line
    .add(\{ name: 'Harry', age: 33 \})\line
    .add(\{ name: 'Steve', age: 41 \});\line
\line
collection.pluck('name');\line
// ['John', 'Harry', 'Steve']\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Events\par}
{\pard \ql \f0 \sa180 \li0 \fi0 As we\u8217've covered, Backbone\u8217's objects are designed to be inherited from and every single one of the following objects inherits from {\f1 Backbone.Events}:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Backbone.Model\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Backbone.Collection\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Backbone.Router\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Backbone.History\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Backbone.View\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Events are the standard way to deal with user interface actions, through the declarative event bindings on views, and also model and collection changes. Mastering events is one of the quickest ways to become more productive with Backbone.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 Backbone.Events} also has the ability to give any object a way to bind and trigger custom events. We can mix this module into any object easily and there isn\u8217't a requirement for events to be declared prior to them being bound.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Example:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var ourObject = \{\};\line
\line
// Mixin\line
_.extend(ourObject, Backbone.Events);\line
\line
// Add a custom event\line
ourObject.on("dance", function(msg)\{\line
  console.log("We triggered " + msg);\line
\});\line
\line
// Trigger the custom event\line
ourObject.trigger("dance", "our event");\par}
{\pard \ql \f0 \sa180 \li0 \fi0 If you\u8217're familiar with jQuery custom events or the concept of Publish/Subscribe, {\f1 Backbone.Events} provides a system that is very similar with {\f1 on} being analogous to {\f1 subscribe} and {\f1 trigger} being similar to {\f1 publish}.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 on} basically allows us to bind a callback function to any object, as we\u8217've done with {\f1 dance} in the above example. Whenever the event is fired, our callback is invoked.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The official Backbone.js documentation recommends namespacing event names using colons if you end up using quite a few of these on your page. e.g:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 ourObject.on("dance:tap", ...);\par}
{\pard \ql \f0 \sa180 \li0 \fi0 A special {\f1 all} event is made available in case you would like an event to be triggered when any event occurs (e.g if you would like to screen events in a single location). The {\f1 all} event can be used as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 ourObject.on("all", function(eventName)\{\line
  console.log("The name of the event passed was " + eventName);\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 off} allows us to remove a callback function that has previously been bound from an object. Going back to our Publish/Subscribe comparison, think of it as an {\f1 unsubscribe} for custom events.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 To remove the {\f1 dance} event we previously bound to {\f1 myObject}, we would simply do:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 myObject.off("dance");\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This will remove all callbacks for the {\f1 dance} event. If we wish to remove just a callback by a specific name, we can do:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 myObject.off("dance", callbackName);\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Finally, {\f1 trigger} triggers a callback for a specified event (or a space-separated listof events). e.g:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 // Single event\line
myObject.trigger("dance");\line
\line
// Multiple events\line
myObject.trigger("dance jump skip");\par}
{\pard \ql \f0 \sa180 \li0 \fi0 It is also possible to pass along additional arguments to each (or all) of these events via a second argument supported by {\f1 trigger}. e.g:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 myObject.trigger("dance", \{duration: "5 minutes"\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Routers\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In Backbone, routers are used to help manage application state and for connecting URLs to application events. This is achieved using hash-tags with URL fragments, or using the browser\u8217's pushState and History API. Some examples of routes may be seen below:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 http://unicorns.com/#whatsup\line
http://unicorns.com/#search/seasonal-horns/page2\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Note: An application will usually have at least one route mapping a URL route to a function that determines what happens when a user reaches that particular route. This relationship is defined as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 "route" : "mappedFunction"\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Let us now define our first controller by extending {\f1 Backbone.Router}. For the purposes of this guide, we\u8217're going to continue pretending we\u8217're creating a photo gallery application that requires a GalleryRouter.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Note the inline comments in the code example below as they continue the rest of the lesson on routers.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var GalleryRouter = Backbone.Router.extend(\{\line
    /* define the route and function maps for this router */\line
    routes: \{\line
        "about" : "showAbout",\line
        /*Sample usage: http://unicorns.com/#about*/\line
\line
        "photos/:id" : "getPhoto",\line
        /*This is an example of using a ":param" variable which allows us to match\line
        any of the components between two URL slashes*/\line
        /*Sample usage: http://unicorns.com/#photos/5*/\line
\line
        "search/:query" : "searchPhotos",\line
        /*We can also define multiple routes that are bound to the same map function,\line
        in this case searchPhotos(). Note below how we're optionally passing in a\line
        reference to a page number if one is supplied*/\line
        /*Sample usage: http://unicorns.com/#search/lolcats*/\line
\line
        "search/:query/p:page" : "searchPhotos",\line
        /*As we can see, URLs may contain as many ":param"s as we wish*/\line
        /*Sample usage: http://unicorns.com/#search/lolcats/p1*/\line
\line
        "photos/:id/download/*imagePath" : "downloadPhoto",\line
        /*This is an example of using a *splat. splats are able to match any number of\line
        URL components and can be combined with ":param"s*/\line
        /*Sample usage: http://unicorns.com/#photos/5/download/files/lolcat-car.jpg*/\line
\line
        /*If you wish to use splats for anything beyond default routing, it's probably a good\line
        idea to leave them at the end of a URL otherwise you may need to apply regular\line
        expression parsing on your fragment*/\line
\line
        "*other"    : "defaultRoute"\line
        /*This is a default route that also uses a *splat. Consider the\line
        default route a wildcard for URLs that are either not matched or where\line
        the user has incorrectly typed in a route path manually*/\line
        /*Sample usage: http://unicorns.com/#anything*/\line
\line
    \},\line
\line
    showAbout: function()\{\line
    \},\line
\line
    getPhoto: function(id)\{\line
        /*\line
        Note that the id matched in the above route will be passed to this function\line
        */\line
        console.log("You are trying to reach photo " + id);\line
    \},\line
\line
    searchPhotos: function(query, page)\{\line
        var page_number = page || 1;\line
        console.log("Page number: " + page_number + " of the results for " + query);\line
    \},\line
\line
    downloadPhoto: function(id, path)\{\line
    \},\line
\line
    defaultRoute: function(other)\{\line
        console.log("Invalid. You attempted to reach:" + other);\line
    \}\line
\});\line
\line
/* Now that we have a router setup, remember to instantiate it*/\line
\line
var myGalleryRouter = new GalleryRouter();\par}
{\pard \ql \f0 \sa180 \li0 \fi0 As of Backbone 0.5+, it\u8217's possible to opt-in for HTML5 pushState support via {\f1 window.history.pushState}. This permits you to define routes such as http://www.scriptjunkie.com/just/an/example. This will be supported with automatic degradation when a user\u8217's browser doesn\u8217't support pushState. For the purposes of this tutorial, we\u8217'll use the hashtag method.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Is there a limit to the number of routers I should be using?\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Andrew de Andrade has pointed out that DocumentCloud themselves usually only use a single router in most of their applications. You\u8217're very likely to not require more than one or two routers in your own projects as the majority of your application routing can be kept organized in a single controller without it getting unwieldy.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Backbone.history\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Next, we need to initialize {\f1 Backbone.history} as it handles {\f1 hashchange} events in our application. This will automatically handle routes that have been defined and trigger callbacks when they\u8217've been accessed.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The {\f1 Backbone.history.start()} method will simply tell Backbone that it\u8217's OK to begin monitoring all {\f1 hashchange} events as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 Backbone.history.start();\line
Router.navigate();\par}
{\pard \ql \f0 \sa180 \li0 \fi0 As an aside, if you would like to save application state to the URL at a particular point you can use the {\f1 .navigate()} method to achieve this. It simply updates your URL fragment without the need to trigger the {\f1 hashchange} event:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 /*Lets imagine we would like a specific fragment for when a user zooms into a photo*/\line
zoomPhoto: function(factor)\{\line
    this.zoom(factor); //imagine this zooms into the image\line
    this.navigate("zoom/" + factor); //updates the fragment for us, but doesn't trigger the route\line
\}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 It is also possible for {\f1 Router.navigate()} to trigger the route as well as updating the URL fragment.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 zoomPhoto: function(factor)\{\line
    this.zoom(factor); //imagine this zooms into the image\line
    this.navigate("zoom/" + factor, true); //updates the fragment for us and triggers the route\line
\}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Backbone\u8217's Sync API\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The Backbone.sync method is intended to be overridden to support other backends. The built-in method is tailed to a certain breed of RESTful JSON APIs \u8211- Backbone was originally extracted from a Ruby on Rails application, which uses HTTP methods like PUT the same way.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The way this works is the model and collection classes have a sync method that calls Backbone.sync. Both will call this.sync internally when fetching, saving, or deleting items.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The sync method is called with three parameters:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab method: One of create, update, delete, read\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab model: The Backbone model object\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab options: May include success and error methods\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Implementing a new sync method can use the following pattern:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 Backbone.sync = function(method, model, options) \{\line
  var requestContent = \{\}, success, error;\line
\line
  function success(result) \{\line
    // Handle results from MyAPI\line
    if (options.success) \{\line
      options.success(result);\line
    \}\line
  \}\line
\line
  function error(result) \{\line
    // Handle results from MyAPI\line
    if (options.error) \{\line
      options.error(result);\line
    \}\line
  \}\line
\line
  options || (options = \{\});\line
\line
  switch (method) \{\line
    case 'create':\line
      requestContent['resource'] = model.toJSON();\line
      return MyAPI.create(model, success, error);\line
\line
    case 'update':\line
      requestContent['resource'] = model.toJSON();\line
      return MyAPI.update(model, success, error);\line
\line
    case 'delete':\line
      return MyAPI.destroy(model, success, error);\line
\line
    case 'read':\line
      if (model.attributes[model.idAttribute]) \{\line
        return MyAPI.find(model, success, error);\line
      \} else \{\line
        return MyAPI.findAll(model, success, error);\line
      \}\line
  \}\line
\};\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This pattern delegates API calls to a new object, which could be a Backbone-style class that supports events. This can be safely tested separately, and potentially used with libraries other than Backbone.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 There are quite a few sync implementations out there:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Backbone localStorage\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Backbone offline\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Backbone Redis\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab backbone-parse\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab backbone-websql\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Backbone Caching Sync\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Conflict Management\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Like most client-side projects, Backbone.js wraps everything in an immediately-invoked function expression:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 (function()\{\line
  // Backbone.js\line
\}).call(this);\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Several things happen during this configuration stage. A Backbone \u8220"namespace\u8221" is created, and multiple versions of Backbone on the same page are supported through the noConflict mode:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var root = this;\line
var previousBackbone = root.Backbone;\line
\line
Backbone.noConflict = function() \{\line
  root.Backbone = previousBackbone;\line
  return this;\line
\};\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Multiple versions of Backbone can be used on the same page by calling noConflict like this:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var Backbone19 = Backbone.noConflict();\line
// Backbone19 refers to the most recently loaded version,\line
// and `window.Backbone` will be restored to the previously\line
// loaded version\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This initial configuration code also supports CommonJS modules so Backbone can be used in Node projects:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var Backbone;\line
if (typeof exports !== 'undefined') \{\line
  Backbone = exports;\line
\} else \{\line
  Backbone = root.Backbone = \{\};\line
\}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Inheritance & Mixins\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For its inheritance, Backbone internally uses an {\f1 inherits} function inspired by {\f1 goog.inherits}, Google\u8217's implementation from the Closure Library. It\u8217's basically a function to correctly setup the prototype chain.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1  var inherits = function(parent, protoProps, staticProps) \{\line
      ...\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The only major difference here is that Backbone\u8217's API accepts two objects containing \u8220"instance\u8221" and \u8220"static\u8221" methods.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Following on from this, for inheritance purposes all of Backbone\u8217's objects contain an {\f1 extend} method as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 Model.extend = Collection.extend = Router.extend = View.extend = extend;\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Most development with Backbone is based around inheriting from these objects, and they\u8217're designed to mimic a classical object-oriented implementation.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 If this sounds familiar, it\u8217's because {\f1 extend} is an Underscore.js utility, although Backbone itself does a lot more with this. See below for Underscore\u8217's {\f1 extend}:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 each(slice.call(arguments, 1), function(source) \{\line
  for (var prop in source) \{\line
    obj[prop] = source[prop];\line
  \}\line
\});\line
return obj;\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The above isn\u8217't quite the same as ES5\u8217's {\f1 Object.create}, as it\u8217's actually copying properties (methods and values) from one object to another. As this isn\u8217't enough to support Backbone\u8217's inheritance and class model, the following steps are performed:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab The instance methods are checked to see if there\u8217's a constructor property. If so, the class\u8217's constructor is used, otherwise the parent\u8217's constructor is used (i.e., Backbone.Model)\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Underscore\u8217's extend method is called to add the parent class\u8217's methods to the new child class\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab The {\f1 prototype} property of a blank constructor function is assigned with the parent\u8217's prototype, and a new instance of this is set to the child\u8217's {\f1 prototype} property Underscore\u8217's extend method is called twice to add the static and instance methods to the child class\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab The child\u8217's prototype\u8217's constructor and a {\f1 __super__} property are assigned\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab This pattern is also used for classes in CoffeeScript, so Backbone classes are compatible with CoffeeScript classes.\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 extend} can be used for a great deal more and developers who are fans of mixins will like that it can be used for this too. You can define functionality on any custom object, and then quite literally copy & paste all of the methods and attributes from that object to a Backbone one:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For example:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1  var MyMixin = \{\line
  foo: "bar",\line
  sayFoo: function()\{alert(this.foo);\}\line
\}\line
\line
var MyView = Backbone.View.extend(\{\line
 // ...\line
\});\line
\line
_.extend(MyView.prototype, MyMixin);\line
\line
myView = new MyView();\line
myView.sayFoo(); //=> "bar"\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We can take this further and also apply it to View inheritance. The following is an example of how to extend one View using another:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var Panel = Backbone.View.extend(\{\line
\});\line
\line
var PanelAdvanced = Panel.extend(\{\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 However, if you have an {\f1 initialize()} method in Panel, then it won\u8217't be called if you also have an {\f1 initialize()} method in PanelAdvanced, so you would have to call Panel\u8217's initialize method explicitly:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var Panel = Backbone.View.extend(\{\line
   initialize: function(options)\{\line
      console.log('Panel initialized');\line
      this.foo = 'bar';\line
   \}\line
\});\line
\line
var PanelAdvanced = Panel.extend(\{\line
   initialize: function(options)\{\line
      this.constructor.__super__.initialize.apply(this, [options])\line
      console.log('PanelAdvanced initialized');\line
      console.log(this.foo); // Log: bar\line
   \}\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This isn\u8217't the most elegant of solutions because if you have a lot of Views that inherit from Panel, then you\u8217'll have to remember to call Panel\u8217's initialize from all of them.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 It\u8217's worth noting that if Panel doesn\u8217't have an initialize method now but you choose to add it in the future, then you\u8217'll need to go to all of the inherited classes in the future and make sure they call Panel\u8217's initialize.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 So here\u8217's an alternative way to define Panel so that your inherited views don\u8217't need to call Panel\u8217's initialize method:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var Panel = function (options) \{\line
\line
    // put all of Panel's initialization code here\line
    console.log('Panel initialized');\line
    this.foo = 'bar';\line
\line
    Backbone.View.apply(this, [options]);\line
\};\line
\line
_.extend(Panel.prototype, Backbone.View.prototype, \{\line
\line
    // put all of Panel's methods here. For example:\line
    sayHi: function () \{\line
        console.log('hello from Panel');\line
    \}\line
\});\line
\line
Panel.extend = Backbone.View.extend;\line
\line
\line
// other classes then inherit from Panel like this:\line
var PanelAdvanced = Panel.extend(\{\line
\line
    initialize: function (options) \{\line
        console.log('PanelAdvanced initialized');\line
        console.log(this.foo);\line
    \}\line
\});\line
\line
var PanelAdvanced = new PanelAdvanced(); //Log: Panel initialized, PanelAdvanced initialized, bar\line
PanelAdvanced.sayHi(); // Log: hello from Panel\par}
{\pard \ql \f0 \sa180 \li0 \fi0 When used appropriately, Backbone\u8217's {\f1 extend} method can save a great deal of time and effort writing redundant code.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 (Thanks to {\field{\*\fldinst{HYPERLINK "http://dailyjs.com"}}{\fldrslt{\ul
Alex Young
}}}
, {\field{\*\fldinst{HYPERLINK "http://stackoverflow.com/users/93448/derick-bailey"}}{\fldrslt{\ul
Derick Bailey
}}}
 and {\field{\*\fldinst{HYPERLINK "http://stackoverflow.com/users/188740/johnnyo"}}{\fldrslt{\ul
JohnnyO
}}}
 for the heads up about these tips).\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Namespacing\par}
{\pard \ql \f0 \sa180 \li0 \fi0 When learning how to use Backbone, an important and commonly overlooked area by tutorials is namespacing. If you already have experience with namespacing in JavaScript, the following section will provide some advice on how to specifically apply concepts you know to Backbone, however I will also be covering explanations for beginners to ensure everyone is on the same page.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 What is namespacing?\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The basic idea around namespacing is to avoid collisions with other objects or variables in the global namespace. They\u8217're important as it\u8217's best to safeguard your code from breaking in the event of another script on the page using the same variable names as you are. As a good \u8216'citizen\u8217' of the global namespace, it\u8217's also imperative that you do your best to similarly not prevent other developer\u8217's scripts executing due to the same issues.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 JavaScript doesn\u8217't really have built-in support for namespaces like other languages, however it does have closures which can be used to achieve a similar effect.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In this section we\u8217'll be taking a look shortly at some examples of how you can namespace your models, views, routers and other components specifically. The patterns we\u8217'll be examining are:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Single global variables\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Object Literals\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Nested namespacing\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Single global variables}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 One popular pattern for namespacing in JavaScript is opting for a single global variable as your primary object of reference. A skeleton implementation of this where we return an object with functions and properties can be found below:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var myApplication = (function()\{\line
    function()\{\line
      // ...\line
    \},\line
    return \{\line
      // ...\line
    \}\line
\})();\par}
{\pard \ql \f0 \sa180 \li0 \fi0 You\u8217've probably seen this technique before. A Backbone-specific example might look like this:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var myViews = (function()\{\line
    return \{\line
        PhotoView: Backbone.View.extend(\{ .. \}),\line
        GalleryView: Backbone.View.extend(\{ .. \}),\line
        AboutView: Backbone.View.extend(\{ .. \});\line
        //etc.\line
    \};\line
\})();\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Here we can return a set of views, but the same technique could return an entire collection of models, views and routers depending on how you decide to structure your application. Although this works for certain situations, the biggest challenge with the single global variable pattern is ensuring that no one else has used the same global variable name as you have in the page.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 One solution to this problem, as mentioned by Peter Michaux, is to use prefix namespacing. It\u8217's a simple concept at heart, but the idea is you select a common prefix name (in this example, {\f1 myApplication_}) and then define any methods, variables or other objects after the prefix.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var myApplication_photoView = Backbone.View.extend(\{\}),\line
myApplication_galleryView = Backbone.View.extend(\{\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This is effective from the perspective of trying to lower the chances of a particular variable existing in the global scope, but remember that a uniquely named object can have the same effect. This aside, the biggest issue with the pattern is that it can result in a large number of global objects once your application starts to grow.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For more on Peter\u8217's views about the single global variable pattern, read his {\field{\*\fldinst{HYPERLINK "http://michaux.ca/articles/javascript-namespacing"}}{\fldrslt{\ul
excellent post on them
}}}
.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Note: There are several other variations on the single global variable pattern out in the wild, however having reviewed quite a few, I felt the prefixing approach applied best to Backbone.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Object Literals}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Object Literals have the advantage of not polluting the global namespace but assist in organizing code and parameters logically. They\u8217're beneficial if you wish to create easily readable structures that can be expanded to support deep nesting. Unlike simple global variables, Object Literals often also take into account tests for the existence of a variable by the same name, which helps reduce the chances of collision.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This example demonstrates two ways you can check to see if a namespace already exists before defining it. I commonly use Option 2.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 /*Doesn't check for existence of myApplication*/\line
var myApplication = \{\};\line
\line
/*\line
Does check for existence. If already defined, we use that instance.\line
Option 1:   if(!myApplication) myApplication = \{\};\line
Option 2:   var myApplication = myApplication || \{\};\line
We can then populate our object literal to support models, views and collections (or any data, really):\line
*/\line
\line
var myApplication = \{\line
    models : \{\},\line
    views : \{\line
        pages : \{\}\line
    \},\line
    collections : \{\}\line
\};\par}
{\pard \ql \f0 \sa180 \li0 \fi0 One can also opt for adding properties directly to the namespace (such as your views, in the following example):\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var myGalleryViews = myGalleryViews || \{\};\line
myGalleryViews.photoView = Backbone.View.extend(\{\});\line
myGalleryViews.galleryView = Backbone.View.extend(\{\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The benefit of this pattern is that you\u8217're able to easily encapsulate all of your models, views, routers etc. in a way that clearly separates them and provides a solid foundation for extending your code.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This pattern has a number of benefits. It\u8217's often a good idea to decouple the default configuration for your application into a single area that can be easily modified without the need to search through your entire codebase just to alter it. Here\u8217's an example of a hypothetical object literal that stores application configuration settings:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var myConfig = \{\line
    language: 'english',\line
    defaults: \{\line
        enableGeolocation: true,\line
        enableSharing: false,\line
        maxPhotos: 20\line
    \},\line
    theme: \{\line
        skin: 'a',\line
        toolbars: \{\line
            index: 'ui-navigation-toolbar',\line
            pages: 'ui-custom-toolbar'\line
        \}\line
    \}\line
\}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Note that there are really only minor syntactical differences between the Object Literal pattern and a standard JSON data set. If for any reason you wish to use JSON for storing your configurations instead (e.g.\u160?for simpler storage when sending to the back-end), feel free to.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For more on the Object Literal pattern, I recommend reading Rebecca Murphey\u8217's {\field{\*\fldinst{HYPERLINK "http://rmurphey.com/blog/2009/10/15/using-objects-to-organize-your-code"}}{\fldrslt{\ul
excellent article on the topic
}}}
.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Nested namespacing}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 An extension of the Object Literal pattern is nested namespacing. It\u8217's another common pattern used that offers a lower risk of collision due to the fact that even if a top-level namespace already exists, it\u8217's unlikely the same nested children do. For example, Yahoo\u8217's YUI uses the nested object namespacing pattern extensively:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 YAHOO.util.Dom.getElementsByClassName('test');\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Yahoo\u8217's YUI uses the nested object namespacing pattern regularly and even DocumentCloud (the creators of Backbone) use the nested namespacing pattern in their main applications. A sample implementation of nested namespacing with Backbone may look like this:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var galleryApp =  galleryApp || \{\};\line
\line
// perform similar check for nested children\line
galleryApp.routers = galleryApp.routers || \{\};\line
galleryApp.model = galleryApp.model || \{\};\line
galleryApp.model.special = galleryApp.model.special || \{\};\line
\line
// routers\line
galleryApp.routers.Workspace   = Backbone.Router.extend(\{\});\line
galleryApp.routers.PhotoSearch = Backbone.Router.extend(\{\});\line
\line
// models\line
galleryApp.model.Photo   = Backbone.Model.extend(\{\});\line
galleryApp.model.Comment = Backbone.Model.extend(\{\});\line
\line
// special models\line
galleryApp.model.special.Admin = Backbone.Model.extend(\{\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This is readable, clearly organized, and is a relatively safe way of namespacing your Backbone application. The only real caveat however is that it requires your browser\u8217's JavaScript engine to first locate the galleryApp object, then dig down until it gets to the function you\u8217're calling. However, developers such as Juriy Zaytsev (kangax) have tested and found the performance differences between single object namespacing vs the \u8216'nested\u8217' approach to be quite negligible.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Recommendation}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Reviewing the namespace patterns above, the option that I prefer when writing Backbone applications is nested object namespacing with the object literal pattern.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Single global variables may work fine for applications that are relatively trivial. However, larger codebases requiring both namespaces and deep sub-namespaces require a succinct solution that\u8217's both readable and scalable. I feel this pattern achieves both of these objectives and is a good choice for most Backbone development.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs36 Practical: Todos - Your First Backbone.js App\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Now that we\u8217've journeyed through the fundamentals, let\u8217's move on to writing our first Backbone.js app - a Todo List application. Building a Todo List is a great way to learn about Backbone\u8217's conventions. It\u8217's a simple enough app, but contains enough interesting problems to be useful, such as binding, persisting model data, routing and template rendering.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For this chapter, we\u8217're going to learn how to create the Backbone.js Todo app listed on {\field{\*\fldinst{HYPERLINK "http://todomvc.com"}}{\fldrslt{\ul
TodoMVC.com
}}}
.\par}
{\pard \ql \f0 \sa0 \li0 \fi0 \par}
{\pard \ql \f0 \sa180 \li0 \fi0 Let\u8217's think about what we need from a high level architectural standpoint.\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab A {\f1 Todo} model to describe individual todo items\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab A {\f1 TodoList} collection to store and persist todos\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab A way of creating todos\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Listing todos\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Editing existing todos\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Completing todos\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Deleting todos\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab A way to bookmark the items that have been completed or are remaining\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Basically your classic {\field{\*\fldinst{HYPERLINK "http://en.wikipedia.org/wiki/Create,_read,_update_and_delete"}}{\fldrslt{\ul
CRUD
}}}
 methods. Let\u8217's get started!\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Index\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The first step is to setup the basic application dependencies, which in this case will be: {\field{\*\fldinst{HYPERLINK "http://jquery.com"}}{\fldrslt{\ul
jQuery
}}}
, {\field{\*\fldinst{HYPERLINK "http://underscorejs.org"}}{\fldrslt{\ul
Underscore
}}}
, Backbone.js and the {\field{\*\fldinst{HYPERLINK "https://github.com/jeromegn/Backbone.localStorage"}}{\fldrslt{\ul
Backbone LocalStorage adapter
}}}
. These will be loaded in our main (and only) HTML file, index.html:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 \line
<!doctype html>\line
<html lang="en">\line
<head>\line
  <meta charset="utf-8">\line
  <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">\line
  <title>Backbone.js \u8226? TodoMVC</title>\line
  <link rel="stylesheet" href="../../assets/base.css">\line
</head>\line
<body>\line
  <script src="../../assets/base.js"></script>\line
  <script src="../../assets/jquery.min.js"></script>\line
  <script src="js/lib/underscore-min.js"></script>\line
  <script src="js/lib/backbone-min.js"></script>\line
  <script src="js/lib/backbone-localstorage.js"></script>\line
  <script src="js/models/todo.js"></script>\line
  <script src="js/collections/todos.js"></script>\line
  <script src="js/views/todos.js"></script>\line
  <script src="js/views/app.js"></script>\line
  <script src="js/routers/router.js"></script>\line
  <script src="js/app.js"></script>\line
</body>\line
</html>\par}
{\pard \ql \f0 \sa180 \li0 \fi0 To help demonstrate how the various parts of our application can be split up, individual concerns are cleanly organized into folders representing our models, views, collections and routers. An app.js file is used to kick everything off.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Application HTML\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Now let\u8217's take a look at our application\u8217's static HTML. We\u8217're going to need an {\f1 <input>} for creating new todos, a {\f1 <ul id="todo-list" />} for listing the actual todos, and a section containing some operations, such as clearing completed todos.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1   <section id="todoapp">\line
    <header id="header">\line
      <h1>todos</h1>\line
      <input id="new-todo" placeholder="What needs to be done?" autofocus>\line
    </header>\line
    <section id="main">\line
      <input id="toggle-all" type="checkbox">\line
      <label for="toggle-all">Mark all as complete</label>\line
      <ul id="todo-list"></ul>\line
    </section>\line
    <footer id="footer"></footer>\line
  </section>\line
  <div id="info">\line
    <p>Double-click to edit a todo</p>\line
    <p>Written by <a href="https://github.com/addyosmani">Addy Osmani</a></p>\line
    <p>Part of <a href="http://todomvc.com">TodoMVC</a></p>\line
  </div>\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We\u8217'll be populating our todo-list and adding a statistics section with details about what items are left to be completed later on.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 So far so good. Now in order to tie this into our Backbone Todo app, we\u8217're going to have to go back to the fundamentals - a Todo model.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Todo model\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The {\f1 Todo} model is remarkably straightforward. Firstly a todo has two attributes, a {\f1 title} and a {\f1 completed} status that indicates whether it\u8217's been completed. These attributes are passed as defaults, as you can see in the example below:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 \line
var app = app || \{\};\line
\line
  // Todo Model\line
  // ----------\line
  // Our basic **Todo** model has `title`, `order`, and `completed` attributes.\line
\line
  app.Todo = Backbone.Model.extend(\{\line
\line
    // Default attributes for the todo\line
    // and ensure that each todo created has `title` and `completed` keys.\line
    defaults: \{\line
      title: '',\line
      completed: false\line
    \},\line
\line
    // Toggle the `completed` state of this todo item.\line
    toggle: function() \{\line
      this.save(\{\line
        completed: !this.get('completed')\line
      \});\line
    \}\line
\line
  \});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We also have a {\f1 toggle()} function which allows to set whether a Todo item has been completed.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Todo collection\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Next we have our {\f1 TodoList} collection used to group our models. The collection is being extended by localStorage which automatically persists Todo records to HTML5 Local Storage via the Backbone LocalStorage adapter, so they\u8217're saved between page requests.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We\u8217've then got some static methods, {\f1 completed()} and {\f1 remaining()}, which return an array of unfinished and finished todos respectively.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Finally we have a {\f1 nextOrder()} function, that keeps our Todo items in sequential order as well as a {\f1 comparator()} used to sort items by their insertion order.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 \line
  // Todo Collection\line
  // ---------------\line
\line
  // The collection of todos is backed by *localStorage* instead of a remote\line
  // server.\line
  var TodoList = Backbone.Collection.extend(\{\line
\line
    // Reference to this collection's model.\line
    model: app.Todo,\line
\line
    // Save all of the todo items under the `"todos"` namespace.\line
    localStorage: new Store('todos-backbone'),\line
\line
    // Filter down the list of all todo items that are finished.\line
    completed: function() \{\line
      return this.filter(function( todo ) \{\line
        return todo.get('completed');\line
      \});\line
    \},\line
\line
    // Filter down the list to only todo items that are still not finished.\line
    remaining: function() \{\line
      return this.without.apply( this, this.completed() );\line
    \},\line
\line
    // We keep the Todos in sequential order, despite being saved by unordered\line
    // GUID in the database. This generates the next order number for new items.\line
    nextOrder: function() \{\line
      if ( !this.length ) \{\line
        return 1;\line
      \}\line
      return this.last().get('order') + 1;\line
    \},\line
\line
    // Todos are sorted by their original insertion order.\line
    comparator: function( todo ) \{\line
      return todo.get('order');\line
    \}\line
  \});\line
\line
  // Create our global collection of **Todos**.\line
  app.Todos = new TodoList();\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Application View\par}
{\pard \ql \f0 \sa180 \li0 \fi0 So let\u8217's look at the core of the application\u8217's logic, the views. Since each todo has a fair bit of logic associated with it, such as edit in place, we\u8217're going to use the element controller pattern - a pattern which consists of two views, one that controls a collection of items, and the other deals with each individual item.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In other words, we\u8217're going to have one view {\f1 AppView}, which will be in charge creating new todos, and rendering the initial todo list. Then we\u8217'll have another view called TodoView instances of which will be associated with an individual Todo record. Todo instances will be in charge of editing, updating and destroying their associated todo.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 To keep thing simple, we\u8217'll keep things \u8216'read-only\u8217' at the moment, and won\u8217't provide any functionality for creating, editing or deleting todos:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 \line
  // The Application\line
  // ---------------\line
\line
  // Our overall **AppView** is the top-level piece of UI.\line
  app.AppView = Backbone.View.extend(\{\line
\line
    // Instead of generating a new element, bind to the existing skeleton of\line
    // the App already present in the HTML.\line
    el: '#todoapp',\line
\line
    // Our template for the line of statistics at the bottom of the app.\line
    statsTemplate: _.template( $('#stats-template').html() ),\line
\line
    // At initialization we bind to the relevant events on the `Todos`\line
    // collection, when items are added or changed. Kick things off by\line
    // loading any preexisting todos that might be saved in *localStorage*.\line
    initialize: function() \{\line
      this.input = this.$('#new-todo');\line
      this.allCheckbox = this.$('#toggle-all')[0];\line
      this.$footer = this.$('#footer');\line
      this.$main = this.$('#main');\line
\line
      window.app.Todos.on( 'add', this.addAll, this );\line
      window.app.Todos.on( 'reset', this.addAll, this );\line
      window.app.Todos.on( 'all', this.render, this );\line
\line
      app.Todos.fetch();\line
    \},\line
\line
    // Re-rendering the App just means refreshing the statistics -- the rest\line
    // of the app doesn't change.\line
    render: function() \{\line
      var completed = app.Todos.completed().length;\line
      var remaining = app.Todos.remaining().length;\line
\line
      if ( app.Todos.length ) \{\line
        this.$main.show();\line
        this.$footer.show();\line
\line
        this.$footer.html(this.statsTemplate(\{\line
          completed: completed,\line
          remaining: remaining\line
        \}));\line
\line
      \} else \{\line
        this.$main.hide();\line
        this.$footer.hide();\line
      \}\line
\line
      this.allCheckbox.checked = !remaining;\line
    \},\line
\line
    // Add a single todo item to the list by creating a view for it, and\line
    // appending its element to the `<ul>`.\line
    addOne: function( todo ) \{\line
      var view = new app.TodoView(\{ model: todo \});\line
      $('#todo-list').append( view.render().el );\line
    \},\line
\line
    // Add all items in the **Todos** collection at once.\line
    addAll: function() \{\line
      this.$('#todo-list').html('');\line
      app.Todos.each(this.addOne, this);\line
    \}\line
\line
  \});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 You can see we\u8217've got a couple of things going on, an el (element), a {\f1 statsTemplate}, a constructor function and several view specific methods. On the left of the el: key is a DOM element selector for the element with ID {\f1 todoapp}. The value of this is just a string and Backbone will create a reference pointing to any element matching the selector #todoapp, where here it will be the {\f1 <section id=\u8221"todoapp />} element, defined in the HTML section earlier.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In a nutshell this means we can now refer to this.el in our controller, which points to the {\f1 <section class="todoapp" />} element. As you can see, we\u8217're referring to el in the {\f1 addOne()} function, appending an element to the list.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Now let\u8217's take a look at the constructor function. It\u8217's binding to several events on the Todo model, such as add, reset and all. Since we\u8217're delegating handling of updates and deletes to the {\f1 TodoView} view, we don\u8217't need to to worry about that here. The two pieces of logic are:\par}
{\pard \ql \f0 \sa180 \li360 \fi-360 \bullet \tx360\tab When a new todo is created, the {\f1 add} event will be fired, calling {\f1 addAll()}. This iterates over all of the Todos currently in our collection and fires {\f1 addOne()} for each item.\par}
{\pard \ql \f0 \sa180 \li360 \fi-360 \bullet \tx360\tab {\f1 addOne()} instantiates the TodoView view, rendering it and appending the resultant element to our Todo list.\par}
{\pard \ql \f0 \sa180 \li360 \fi-360 \bullet \tx360\tab When a {\f1 reset} event is called (i.e.\u160?we wish to update the collection in bulk such as when the Todos have been loaded from Local Storage), {\f1 addAll()} is similarly called again.\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We can then add in the logic for creating new todos, editing them and filtering them based on whether they are complete.\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab events: We define an events hash containing declarative callbacks for our DOM events.\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\f1 createOnEnter()}: When a user hits return inside the {\f1 <input/>} field, this creates a new Todo item and resets the main {\f1 <input/>} field value to prepare it for the next entry.\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\f1 clearCompleted()}: Removes the items in the todo list that have been marked as completed\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\f1 toggleAllComplete()}: Allows a user to set all of the items in the todo list to completed.\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\f1 initialize()}: We bind a callback for a change:completed event, letting us know a change has been made as well to an existing todo item We also bind a callback for a filter event, which works a little similar to addOne() and addAll(). It\u8217's responsibility is to toggle what todo items are visible based on the filter currently selected in the UI (all, completed or remaining) through filterOne() and filterAll().\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\f1 render()}: We add some conditional CSS styling based on the filter currently selected so that the route that has been selected is highlighted\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\f1 createOnEnter()}: Creates a new Todo model which persists in localStorage when a user hits return. This creates the model via newAttributes(), which is an object literal composed of the title, order and completed state of the new item being added.\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\f1 clearCompleted()}: Clears all the todo items that have been marked as complete\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 \line
// The Application\line
  // ---------------\line
\line
  // Our overall **AppView** is the top-level piece of UI.\line
  app.AppView = Backbone.View.extend(\{\line
\line
    // Instead of generating a new element, bind to the existing skeleton of\line
    // the App already present in the HTML.\line
    el: '#todoapp',\line
\line
    // Our template for the line of statistics at the bottom of the app.\line
    statsTemplate: _.template( $('#stats-template').html() ),\line
\line
    // Delegated events for creating new items, and clearing completed ones.\line
    events: \{\line
      'keypress #new-todo': 'createOnEnter',\line
      'click #clear-completed': 'clearCompleted',\line
      'click #toggle-all': 'toggleAllComplete'\line
    \},\line
\line
    // At initialization we bind to the relevant events on the `Todos`\line
    // collection, when items are added or changed. Kick things off by\line
    // loading any preexisting todos that might be saved in *localStorage*.\line
    initialize: function() \{\line
      this.input = this.$('#new-todo');\line
      this.allCheckbox = this.$('#toggle-all')[0];\line
      this.$footer = this.$('#footer');\line
      this.$main = this.$('#main');\line
\line
      window.app.Todos.on( 'add', this.addAll, this );\line
      window.app.Todos.on( 'reset', this.addAll, this );\line
      window.app.Todos.on('change:completed', this.filterOne, this);\line
      window.app.Todos.on("filter", this.filterAll, this);\line
\line
      window.app.Todos.on( 'all', this.render, this );\line
\line
      app.Todos.fetch();\line
    \},\line
\line
    // Re-rendering the App just means refreshing the statistics -- the rest\line
    // of the app doesn't change.\line
    render: function() \{\line
      var completed = app.Todos.completed().length;\line
      var remaining = app.Todos.remaining().length;\line
\line
      if ( app.Todos.length ) \{\line
        this.$main.show();\line
        this.$footer.show();\line
\line
        this.$footer.html(this.statsTemplate(\{\line
          completed: completed,\line
          remaining: remaining\line
        \}));\line
\line
        this.$('#filters li a')\line
          .removeClass('selected')\line
          .filter('[href="#/' + ( app.TodoFilter || '' ) + '"]')\line
          .addClass('selected');\line
      \} else \{\line
        this.$main.hide();\line
        this.$footer.hide();\line
      \}\line
\line
      this.allCheckbox.checked = !remaining;\line
    \},\line
\line
    // Add a single todo item to the list by creating a view for it, and\line
    // appending its element to the `<ul>`.\line
    addOne: function( todo ) \{\line
      var view = new app.TodoView(\{ model: todo \});\line
      $('#todo-list').append( view.render().el );\line
    \},\line
\line
    // Add all items in the **Todos** collection at once.\line
    addAll: function() \{\line
      this.$('#todo-list').html('');\line
      app.Todos.each(this.addOne, this);\line
    \},\line
\line
    filterOne : function (todo) \{\line
      todo.trigger("visible");\line
    \},\line
\line
    filterAll : function () \{\line
      app.Todos.each(this.filterOne, this);\line
    \},\line
\line
    // Generate the attributes for a new Todo item.\line
    newAttributes: function() \{\line
      return \{\line
        title: this.input.val().trim(),\line
        order: app.Todos.nextOrder(),\line
        completed: false\line
      \};\line
    \},\line
\line
    // If you hit return in the main input field, create new **Todo** model,\line
    // persisting it to *localStorage*.\line
    createOnEnter: function( e ) \{\line
      if ( e.which !== ENTER_KEY || !this.input.val().trim() ) \{\line
        return;\line
      \}\line
\line
      app.Todos.create( this.newAttributes() );\line
      this.input.val('');\line
    \},\line
\line
    // Clear all completed todo items, destroying their models.\line
    clearCompleted: function() \{\line
      _.each( window.app.Todos.completed(), function( todo ) \{\line
        todo.destroy();\line
      \});\line
\line
      return false;\line
    \},\line
\line
    toggleAllComplete: function() \{\line
      var completed = this.allCheckbox.checked;\line
\line
      app.Todos.each(function( todo ) \{\line
        todo.save(\{\line
          'completed': completed\line
        \});\line
      \});\line
    \}\line
  \});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Setup\par}
{\pard \ql \f0 \sa180 \li0 \fi0 So now we have two views: {\f1 AppView} and {\f1 TodoView}. The former needs to get instantiated when the page loads, so some code actually gets run. You can do this simply enough, by using jQuery\u8217's {\f1 ready()} utility, which will execute a function when the DOM\u8217's loaded.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 \line
var app = app || \{\};\line
var ENTER_KEY = 13;\line
\line
$(function() \{\line
\line
  // Kick things off by creating the **App**.\line
  new app.AppView();\line
\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Creating new todos\par}
{\pard \ql \f0 \sa180 \li0 \fi0 It\u8217's all very good creating todos from the console, but we can hardly expect our users to do that. Let\u8217's hook up the todo creation section to provide a better interface. All the HTML is already there (in index.html); all we have to do is add some event listeners to that section, creating some todos.\par}
{\pard \ql \f0 \sa0 \li0 \fi0 \par}
{\pard \ql \f0 \sa180 \li0 \fi0 Let\u8217's look at the {\f1 TodoView} view. This will be in charge of individual Todo records, making sure the view updates then the todo does.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 \line
  // Todo Item View\line
  // --------------\line
\line
  // The DOM element for a todo item...\line
  app.TodoView = Backbone.View.extend(\{\line
\line
    //... is a list tag.\line
    tagName:  'li',\line
\line
    // Cache the template function for a single item.\line
    template: _.template( $('#item-template').html() ),\line
\line
    // The DOM events specific to an item.\line
    events: \{\line
      'dblclick label': 'edit',\line
      'keypress .edit': 'updateOnEnter',\line
      'blur .edit':   'close'\line
    \},\line
\line
    // The TodoView listens for changes to its model, re-rendering. Since there's\line
    // a one-to-one correspondence between a **Todo** and a **TodoView** in this\line
    // app, we set a direct reference on the model for convenience.\line
    initialize: function() \{\line
      this.model.on( 'change', this.render, this );\line
    \},\line
\line
    // Re-render the titles of the todo item.\line
    render: function() \{\line
      this.$el.html( this.template( this.model.toJSON() ) );\line
      this.input = this.$('.edit');\line
      return this;\line
    \},\line
\line
    // Switch this view into `"editing"` mode, displaying the input field.\line
    edit: function() \{\line
      this.$el.addClass('editing');\line
      this.input.focus();\line
    \},\line
\line
    // Close the `"editing"` mode, saving changes to the todo.\line
    close: function() \{\line
      var value = this.input.val().trim();\line
\line
      if ( value ) \{\line
        this.model.save(\{ title: value \});\line
      \}\line
\line
      this.$el.removeClass('editing');\line
    \},\line
\line
    // If you hit `enter`, we're through editing the item.\line
    updateOnEnter: function( e ) \{\line
      if ( e.which === ENTER_KEY ) \{\line
        this.close();\line
      \}\line
    \}\line
  \});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In the {\f1 initialize()} constructor, we\u8217're setting up a listener to the todo model\u8217's change event. In other words, when the todo updates, we want to re-render the view to reflect its changes.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In the {\f1 render()} method, we\u8217're rendering an Underscore.js JavaScript template, called {\f1 #item-template}, which we\u8217've previously compiled into this.template using Underscore\u8217's {\f1 _.template()} method. This returns a piece of HTML that we\u8217're using to replace the view\u8217's current element. In other words, the rendered template is now present under {\f1 this.el}, and can be appended to the todo list.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Our events hash includes three callbacks:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\f1 edit()}: Changes the current view into editing mode when a user double-clicks on an existing item in the todo list. This allows them to change the existing value of the item\u8217's title attribute\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\f1 updateOnEnter()}: checks that the user has hit the return/enter key and executes the close() function.\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\f1 close()}: This trims the value of the current text in our {\f1 <input/>} field, ensuring that we don\u8217't process it further if it contains no text (e.g \u8216'\u8217'). If a valid value has been provided, we save the changes to the current todo model and close editing mode, by removing the corresponding CSS class.\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 In action\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Now we\u8217've gone far enough without checking that things work as they should. Open up index.html and, if everything\u8217's going to plan, you shouldn\u8217't see any errors in the console. The todo list will be blank (we haven\u8217't created any todos yet), and the todo-list won\u8217't work, as we haven\u8217't yet hooked it up. However, we can create a Todo from the console.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Type in: {\f1 window.app.Todos.create(\{ title: \u8216'My first Todo item\});} and hit return.\par}
{\pard \ql \f0 \sa0 \li0 \fi0 \par}
{\pard \ql \f0 \sa180 \li0 \fi0 Once you\u8217've run the above in the console, we should be looking at a brand new todo in the list of todos. Notice that if you refresh the page, the todo still persists using Local Storage.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Templates\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The {\f1 #item-template} used in the {\f1 TodoView} view needs defining, so let\u8217's do that. One way of including templates in the page is by using custom script tags. These don\u8217't get evaluated by the browser, which just interprets them as plain text. Underscore micro-templating can then access the templates, rendering pieces of HTML.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1   <script type="text/template" id="item-template">\line
    <div class="view">\line
      <input class="toggle" type="checkbox" <%= completed ? 'checked' : '' %>>\line
      <label><%- title %></label>\line
      <button class="destroy"></button>\line
    </div>\line
    <input class="edit" value="<%- title %>">\line
  </script>\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The template tags demonstrated above, such as {\f1 <%=} , are specific to Underscore.js, and documented on the Underscore site. In your own applications, you have a choice of template libraries, such as Mustache or Handlebars. Use whichever you prefer, Backbone doesn\u8217't mind.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Now when {\f1 _.template( $('#item-template').html() )} is called in the {\f1 TodoView} view our template will render correctly.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We also need to define #stats-template template we use to display how many items have been completed, as well as allowing the user to clear these items.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1   <script type="text/template" id="stats-template">\line
    <span id="todo-count"><strong><%= remaining %></strong> <%= remaining === 1 ? 'item' : 'items' %> left</span>\line
    <ul id="filters">\line
      <li>\line
        <a class="selected" href="#/">All</a>\line
      </li>\line
      <li>\line
        <a href="#/active">Active</a>\line
      </li>\line
      <li>\line
        <a href="#/completed">Completed</a>\line
      </li>\line
    </ul>\line
    <% if (completed) \{ %>\line
    <button id="clear-completed">Clear completed (<%= completed %>)</button>\line
    <% \} %>\line
  </script>\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 In action\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Now refresh index.html to see the fruits of our labour. We should be able to type a todo name, and press return to submit the form, creating a new todo.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\cf1 [image: img/todocompleted.png]\cf0}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Excellent, we\u8217're making great progress, but how about completing and deleting todos?\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Completing & deleting todos\par}
{\pard \ql \f0 \sa180 \li0 \fi0 So the next part of our tutorial is going to cover completing and deleting todos. These two actions are specific to each Todo item, so we need to add this functionality to the TodoView view.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The key part of this is the two event handlers we\u8217've added, a togglecompleted event on the todo\u8217's checkbox, and a click event on the todo\u8217's {\f1 <button class="destroy" />} button.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The checkbox\u8217's togglecompleted event invokes the toggle() function, which toggles the todos\u8217's completed status, then resaving the todo - very straightforward! The button\u8217's click event invokes {\f1 clear()}, which will simply destroy the todo.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 That\u8217's all there is to it. Since we\u8217're binding to the change event, whenever the todo changes the view will automatically be re-rendered, checking or un-checking the checkbox as appropriate. Similarly, when the todo is destroyed, the model\u8217's {\f1 destroy()} function will be called, removing the todo from the view as we\u8217're binding to the destroy event too.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 One more piece to mention is that we\u8217've also binded to a visible event to handle the visibility state of the todo item. This is used in conjunction with the filtering in our routes and collections so that we only display an item if its completed state falls in line with the current filter.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This tutorial is long enough as is, so we won\u8217't go into in-place editing or updating. If you want an example of that, see the {\field{\*\fldinst{HYPERLINK "https://github.com/addyosmani/todomvc/tree/master/architecture-examples/backbone/"}}{\fldrslt{\ul
complete source
}}}
.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 \line
  // Todo Item View\line
  // --------------\line
\line
  // The DOM element for a todo item...\line
  app.TodoView = Backbone.View.extend(\{\line
\line
    //... is a list tag.\line
    tagName:  'li',\line
\line
    // Cache the template function for a single item.\line
    template: _.template( $('#item-template').html() ),\line
\line
    // The DOM events specific to an item.\line
    events: \{\line
      'click .toggle':  'togglecompleted',\line
      'dblclick label': 'edit',\line
      'click .destroy': 'clear',\line
      'keypress .edit': 'updateOnEnter',\line
      'blur .edit':   'close'\line
    \},\line
\line
    // The TodoView listens for changes to its model, re-rendering. Since there's\line
    // a one-to-one correspondence between a **Todo** and a **TodoView** in this\line
    // app, we set a direct reference on the model for convenience.\line
    initialize: function() \{\line
      this.model.on( 'change', this.render, this );\line
      this.model.on( 'destroy', this.remove, this );\line
      this.model.on( 'visible', this.toggleVisible, this );\line
    \},\line
\line
    // Re-render the titles of the todo item.\line
    render: function() \{\line
      this.$el.html( this.template( this.model.toJSON() ) );\line
      this.$el.toggleClass( 'completed', this.model.get('completed') );\line
\line
      this.toggleVisible();\line
      this.input = this.$('.edit');\line
      return this;\line
    \},\line
\line
    toggleVisible : function () \{\line
      this.$el.toggleClass( 'hidden',  this.isHidden());\line
    \},\line
\line
    isHidden : function () \{\line
      var isCompleted = this.model.get('completed');\line
      return ( // hidden cases only\line
        (!isCompleted && app.TodoFilter === 'completed')\line
        || (isCompleted && app.TodoFilter === 'active')\line
      );\line
    \},\line
\line
    // Toggle the `"completed"` state of the model.\line
    togglecompleted: function() \{\line
      this.model.toggle();\line
    \},\line
\line
    // Switch this view into `"editing"` mode, displaying the input field.\line
    edit: function() \{\line
      this.$el.addClass('editing');\line
      this.input.focus();\line
    \},\line
\line
    // Close the `"editing"` mode, saving changes to the todo.\line
    close: function() \{\line
      var value = this.input.val().trim();\line
\line
      if ( value ) \{\line
        this.model.save(\{ title: value \});\line
      \} else \{\line
        this.clear();\line
      \}\line
\line
      this.$el.removeClass('editing');\line
    \},\line
\line
    // If you hit `enter`, we're through editing the item.\line
    updateOnEnter: function( e ) \{\line
      if ( e.which === ENTER_KEY ) \{\line
        this.close();\line
      \}\line
    \},\line
\line
    // Remove the item, destroy the model from *localStorage* and delete its view.\line
    clear: function() \{\line
      this.model.destroy();\line
    \}\line
  \});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Todo routing\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Finally, we move on to routing, which will allow us to easily bookmark the list of items that are active as well as those which have been completed. We\u8217'll be supporting the following routes:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 #/ (all - default)\line
#/active\line
#/completed\par}
{\pard \ql \f0 \sa0 \li0 \fi0 \par}
{\pard \ql \f0 \sa180 \li0 \fi0 When the route changes the todo list will be filtered on a model level and the selected class on the filter links will be toggled. When an item is updated while in a filtered state, it will be updated accordingly. E.g. if the filter is active and the item is checked, it will be hidden. The active filter is persisted on reload.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 \line
  // Todo Router\line
  // ----------\line
\line
  var Workspace = Backbone.Router.extend(\{\line
    routes:\{\line
      '*filter': 'setFilter'\line
    \},\line
\line
    setFilter: function( param ) \{\line
      // Set the current filter to be used\line
      window.app.TodoFilter = param.trim() || '';\line
\line
      // Trigger a collection filter event, causing hiding/unhiding\line
      // of Todo view items\line
      window.app.Todos.trigger('filter');\line
    \}\line
  \});\line
\line
  app.TodoRouter = new Workspace();\line
  Backbone.history.start();\par}
{\pard \ql \f0 \sa180 \li0 \fi0 As we can see in the line {\f1 window.app.Todos.trigger('filter')}, once a string filter has been set, we simply trigger our filter at a collection level to toggle which items are displayed and which of those are hidden.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Finally, we call {\f1 Backbone.history.start()} to route the initial URL during page load.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Conclusions\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We\u8217've now learned how to build our first complete Backbone.js application. The app can be viewed online at any time and the sources are readily available via {\field{\*\fldinst{HYPERLINK "http://www.todomvc.com"}}{\fldrslt{\ul
TodoMVC
}}}
.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Later on in the book, we\u8217'll learn how to further modularize this application using Require.js, swap out our persistence layer to a database back-end and finally unit test the application with a few different testing frameworks.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs36 Backbone Boilerplate And Grunt-BBB\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\field{\*\fldinst{HYPERLINK "https://github.com/tbranyen/backbone-boilerplate/"}}{\fldrslt{\ul
Backbone Boilerplate
}}}
 is an excellent set of best practices and utilities for building Backbone.js applications, created by Backbone contributor {\field{\*\fldinst{HYPERLINK "https://github.com/tbranyen"}}{\fldrslt{\ul
Tim Branyen
}}}
. He organized this boilerplate out of the gotchas, pitfalls and common tasks he ran into over a year of heavily using Backbone to build apps at Bocoup. This includes apps such {\field{\*\fldinst{HYPERLINK "http://startupdatatrends"}}{\fldrslt{\ul
StartupDataTrends.com
}}}
.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 With scaffolding and built in build tasks that take care of minification, concatentation, server, template compilation and more, Backbone Boilerplate (and sister project {\field{\*\fldinst{HYPERLINK "https://github.com/backbone-boilerplate/grunt-bbb"}}{\fldrslt{\ul
Grunt-BBB
}}}
) are an excellent choice for developers of all levels. I heavily recommend using them as they will give you an enormous start when it comes to getting setup for development. They also have some great inline documentation which is also another excellent time-saver.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 By default, Backbone Boilerplate provides you with:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Backbone, {\field{\*\fldinst{HYPERLINK "https://github.com/bestiejs/lodash"}}{\fldrslt{\ul
Lodash
}}}
 (an {\field{\*\fldinst{HYPERLINK "http://underscorejs.org/"}}{\fldrslt{\ul
Underscore.js
}}}
 alternative) and {\field{\*\fldinst{HYPERLINK "http://jquery.com"}}{\fldrslt{\ul
jQuery
}}}
 with an {\field{\*\fldinst{HYPERLINK "http://html5boilerplate.com"}}{\fldrslt{\ul
HTML5 Boilerplate
}}}
 foundation\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Boilerplate module code\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab A Windows/Mac/Linux build tool for template precompilation and, concatenation & minification of all your libraries, application code and CSS\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Scaffolding support (via grunt-bbb - [B]ackbone [B]oilerplate [B]uild) so you have to spend minimal time writing boilerplate for modules, collections and so on.\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab A Lightweight node.js webserver\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Numerous other Backbone.js snippets for making your life easier\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Getting Started\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Backbone Boilerplate\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We can use Boilerplate to easily begin creating an application, but first, we\u8217'll need to install it. This can be done by grabbing the latest version of it by cloning the Boilerplate repo directly:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 $ git clone git://github.com/tbranyen/backbone-boilerplate.git\par}
{\pard \ql \f0 \sa180 \li0 \fi0 or alternatively, just fetching the latest tarball as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 curl -C - -O https://github.com/tbranyen/backbone-boilerplate/zipball/master\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Grunt-BBB\par}
{\pard \ql \f0 \sa180 \li0 \fi0 As Tim covers in the Boilerplate docs, we have to install {\field{\*\fldinst{HYPERLINK "http://gruntjs.org"}}{\fldrslt{\ul
Grunt
}}}
 if we want to use the build tools and grunt-bbb helpers he recommends.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Grunt is an excellent Node-based JavaScript build tool by another {\field{\*\fldinst{HYPERLINK "http://bocoup.com"}}{\fldrslt{\ul
Bocoup
}}}
 developer ({\field{\*\fldinst{HYPERLINK "http://benalman.com"}}{\fldrslt{\ul
Ben Alman
}}}
). Think of it as similar to {\field{\*\fldinst{HYPERLINK "http://ant.apache.org/"}}{\fldrslt{\ul
Ant
}}}
 or {\field{\*\fldinst{HYPERLINK "https://github.com/jimweirich/rake"}}{\fldrslt{\ul
Rake
}}}
. The grunt-bbb helper is also useful to have as it provides several Backbone-specific utilities for scaffolding out your project, without the need to write boilerplate yourself.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 To install grunt and grunt-bbb via NPM:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 # first run\line
$ npm install -g grunt\line
\line
# followed by\line
$ npm install -g bbb\line
\line
# Create a new project\line
bbb init\par}
{\pard \ql \f0 \sa180 \li0 \fi0 That\u8217's it. We should now be good to go.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 A typical workflow for using grunt-bbb, which we can use later on is:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Initialize a new project ({\f1 bbb init})\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Add new modules and templates ({\f1 bbb init:module})\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Develop using the built in server ({\f1 bbb server})\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Run the build tool ({\f1 bbb build})\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Deploy and map to production assets (using {\f1 bbb release})\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Creating a new project\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Let\u8217's create a new folder for our project and run {\f1 bbb init} to kick things off. If everything has been correctly installed, this will sub out some project directories and files for us. Let\u8217's review what is generated.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 index.html\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This is a fairly standard stripped-down HTML5 Boilerplate foundation with the notable exception of including {\field{\*\fldinst{HYPERLINK "http://requirejs.org"}}{\fldrslt{\ul
Require.js
}}}
 at the bottom of the page.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 <!doctype html>\line
<html lang="en">\line
<head>\line
  <meta charset="utf-8">\line
  <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">\line
  <meta name="viewport" content="width=device-width,initial-scale=1">\line
\line
  <title>Backbone Boilerplate</title>\line
\line
  <!-- Application styles. -->\line
  <link rel="stylesheet" href="/assets/css/index.css">\line
</head>\line
\line
<body>\line
  <!-- Main container. -->\line
  <div role="main" id="main"></div>\line
\line
  <!-- Application source. -->\line
  <script data-main="/app/config" src="/assets/js/libs/require.js"></script>\line
</body>\line
</html>\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Require.js is an {\field{\*\fldinst{HYPERLINK "https://github.com/amdjs/amdjs-api/wiki/AMD"}}{\fldrslt{\ul
AMD
}}}
 (Asynchronous Module Definition) module and script loader, which will assist us with managing the modules in our application. We\u8217'll be covering it in a lot more detail later on in the book, but for now, let\u8217's cover at a high-level what this particular block does:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 <script data-main="app/config" src="/assets/js/libs/require.js"></script>\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The {\f1 data-main} attribute is used to inform Require.js to load {\f1 app/config.js} (a configuration object) after it has finished loading itself. You\u8217'll notice that we\u8217've omitted the {\f1 .js} extension here as require.js can automatically add this for us, however it will respect your paths if we do choose to include it regardless. Let\u8217's now look at the config file being referenced.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 config.js\par}
{\pard \ql \f0 \sa180 \li0 \fi0 A Require.js configuration object allows us to specify aliases and paths for dependencies we\u8217're likely to reference often (e.g jQuery), bootstrap properties like our base application URL and {\f1 shim} libraries that don\u8217't support AMD natively.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This is what the config file in Backbone Boilerplate looks like:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 // Set the require.js configuration for your application.\line
require.config(\{\line
\line
  // Initialize the application with the main application file.\line
  deps: ["main"],\line
\line
  paths: \{\line
    // JavaScript folders.\line
    libs: "../assets/js/libs",\line
    plugins: "../assets/js/plugins",\line
\line
    // Libraries.\line
    jquery: "../assets/js/libs/jquery",\line
    lodash: "../assets/js/libs/lodash",\line
    backbone: "../assets/js/libs/backbone"\line
  \},\line
\line
  shim: \{\line
    // Backbone library depends on lodash and jQuery.\line
    backbone: \{\line
      deps: ["lodash", "jquery"],\line
      exports: "Backbone"\line
    \},\line
\line
    // Backbone.LayoutManager depends on Backbone.\line
    "plugins/backbone.layoutmanager": ["backbone"]\line
  \}\line
\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The first option defined in the above config is {\f1 deps: ["main"]}. This informs Require.js to load up our main.js file, which is considered the entry point for our application. You may notice that we haven\u8217't specified any other path information for {\f1 main}.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This is because as we haven\u8217't overridden the path to our scripts using the {\f1 baseUrl} option, Require will infer this using the path from our {\f1 data-main} attribute in index.html. In other words, our {\f1 baseUrl} is {\f1 app/} and any scripts we require will be loaded relative to this location.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The next block is {\f1 paths}, which we can use to specify paths relative to the {\f1 baseUrl} as well as the paths/aliases to dependencies we\u8217're likely to regularly reference.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1   paths: \{\line
    // JavaScript folders.\line
    libs: "../assets/js/libs",\line
    plugins: "../assets/js/plugins",\line
\line
    // Libraries.\line
    jquery: "../assets/js/libs/jquery",\line
    lodash: "../assets/js/libs/lodash",\line
    backbone: "../assets/js/libs/backbone"\line
  \},\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Next we have the {\f1 shim} config:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1   shim: \{\line
    // Backbone library depends on lodash and jQuery.\line
    backbone: \{\line
      deps: ["lodash", "jquery"],\line
      exports: "Backbone"\line
    \},\line
\line
    // Backbone.LayoutManager depends on Backbone.\line
    "plugins/backbone.layoutmanager": ["backbone"]\line
  \}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 shim} is an important part of our Require.js configuration which allows us to load libraries which are not AMD compliant. The basic idea here is that rather than requiring all libraries to implement support for AMD, the {\f1 shim} takes care of the hard work for us.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For example, in the block below, we state that Backbone.js is dependent on Lodash (a fork of Underscore.js) and jQuery being loaded before it. Once they\u8217've been loaded, we then use the global export {\f1 Backbone} as the module value.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1     backbone: \{\line
      deps: ["lodash", "jquery"],\line
      exports: "Backbone"\line
    \}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Finally, we inform Require.js that the Backbone {\field{\*\fldinst{HYPERLINK "https://github.com/tbranyen/backbone.layoutmanager"}}{\fldrslt{\ul
LayoutManager
}}}
 plugin (a template and layout manager, also included) requires that Backbone be loaded before it should be.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1     // Backbone.LayoutManager depends on Backbone.\line
    "plugins/backbone.layoutmanager": ["backbone"]\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This entire setup ensures that our scripts correctly get loaded in the order in which we expect.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 main.js\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Next, we have {\f1 main.js}, which defines the entry point for our application. We use a global {\f1 require()} method to load an array any other scripts needed, such as our application {\f1 app.js} and our main router {\f1 router.js}. Note that most of the time, we will only use {\f1 require()} for bootstrapping an application and a similar method called {\f1 define()} for all other purposes.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The function defined after our array of dependencies is a callback which doesn\u8217't fire until these scripts have loaded. Notice howe we\u8217're able to locally alias references to \u8220"app\u8221" and \u8220"router\u8221" as {\f1 app} and {\f1 Router} for convenience.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 require([\line
  // Application.\line
  "app",\line
\line
  // Main Router.\line
  "router"\line
],\line
\line
function(app, Router) \{\line
\line
  // Define your master router on the application namespace and trigger all\line
  // navigation from this instance.\line
  app.router = new Router();\line
\line
  // Trigger the initial route and enable HTML5 History API support, set the\line
  // root folder to '/' by default.  Change in app.js.\line
  Backbone.history.start(\{ pushState: true, root: app.root \});\line
\line
  // All navigation that is relative should be passed through the navigate\line
  // method, to be processed by the router. If the link has a `data-bypass`\line
  // attribute, bypass the delegation completely.\line
  $(document).on("click", "a:not([data-bypass])", function(evt) \{\line
    // Get the absolute anchor href.\line
    var href = $(this).attr("href");\line
\line
    // If the href exists and is a hash route, run it through Backbone.\line
    if (href && href.indexOf("#") === 0) \{\line
      // Stop the default event to ensure the link will not cause a page\line
      // refresh.\line
      evt.preventDefault();\line
\line
      // `Backbone.history.navigate` is sufficient for all Routers and will\line
      // trigger the correct events. The Router's internal `navigate` method\line
      // calls this anyways.  The fragment is sliced from the root.\line
      Backbone.history.navigate(href, true);\line
    \}\line
  \});\line
\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Inline, Backbone Boilerplate includes boilerplate code for initializing our router with HTML5 History API support and handling other navigation scenarios, so we don\u8217't have to.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 app.js\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Let us now look at our {\f1 app.js} module. Typically, in non-Backbone Boilerplate applications, an {\f1 app.js} file may contain the core logic or module references needed to kick start an app.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In this case however, this file is used to define templating and layout configuration options as well as utilities for consuming layouts. To a beginner, this might look like a lot of code to comprehend, but the good news is that for basic apps, you\u8217're unlikely to need to heavily modify this. Instead, you\u8217'll be more concerned with modules for your app, which we\u8217'll look at next.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 define([\line
\line
  // Libraries.\line
  "jquery",\line
  "lodash",\line
  "backbone",\line
\line
  // Plugins.\line
  "plugins/backbone.layoutmanager"\line
\line
],\line
\line
function($, _, Backbone) \{\line
\line
  // Provide a global location to place configuration settings and module\line
  // creation.\line
  var app = \{\line
    // The root path to run the application.\line
    root: "/"\line
  \};\line
\line
  // Localize or create a new JavaScript Template object.\line
  var JST = window.JST = window.JST || \{\};\line
\line
  // Configure LayoutManager with Backbone Boilerplate defaults.\line
  Backbone.LayoutManager.configure(\{\line
    paths: \{\line
      layout: "app/templates/layouts/",\line
      template: "app/templates/"\line
    \},\line
\line
    fetch: function(path) \{\line
      path = path + ".html";\line
\line
      if (!JST[path]) \{\line
        $.ajax(\{ url: app.root + path, async: false \}).then(function(contents) \{\line
          JST[path] = _.template(contents);\line
        \});\line
      \}\line
\line
      return JST[path];\line
    \}\line
  \});\line
\line
  // Mix Backbone.Events, modules, and layout management into the app object.\line
  return _.extend(app, \{\line
    // Create a custom object with a nested Views object.\line
    module: function(additionalProps) \{\line
      return _.extend(\{ Views: \{\} \}, additionalProps);\line
    \},\line
\line
    // Helper for using layouts.\line
    useLayout: function(name) \{\line
      // If already using this Layout, then don't re-inject into the DOM.\line
      if (this.layout && this.layout.options.template === name) \{\line
        return this.layout;\line
      \}\line
\line
      // If a layout already exists, remove it from the DOM.\line
      if (this.layout) \{\line
        this.layout.remove();\line
      \}\line
\line
      // Create a new Layout.\line
      var layout = new Backbone.Layout(\{\line
        template: name,\line
        className: "layout " + name,\line
        id: "layout"\line
      \});\line
\line
      // Insert into the DOM.\line
      $("#main").empty().append(layout.el);\line
\line
      // Render the layout.\line
      layout.render();\line
\line
      // Cache the reference.\line
      this.layout = layout;\line
\line
      // Return the reference, for chainability.\line
      return layout;\line
    \}\line
  \}, Backbone.Events);\line
\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Creating Backbone Boilerplate Modules\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Not to be confused with simply being just an AMD module, a Backbone Boilerplate {\f1 module} is a script composed of a:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Model\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Collection\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Views (optional)\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We can easily create a new Boilerplate module using {\f1 grunt-bbb} once again using {\f1 init}:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 # Create a new module\line
bbb init:module\line
\line
# Grunt prompt\line
Please answer the following:\line
[?] Module Name foo\line
[?] Do you need to make any changes to the above before continuing? (y/N) n\line
\line
Writing app/modules/foo.js...OK\line
\line
Initialized from template "module".\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This will generate a module {\f1 foo.js} as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 define([\line
  // Application.\line
  "app"\line
],\line
\line
// Map dependencies from above array.\line
function(app) \{\line
\line
  // Create a new module.\line
  var Foo = app.module();\line
\line
  // Default model.\line
  Foo.Model = Backbone.Model.extend(\{\line
\line
  \});\line
\line
  // Default collection.\line
  Foo.Collection = Backbone.Collection.extend(\{\line
    model: Foo.Model\line
  \});\line
\line
  // Return the module for AMD compliance.\line
  return Foo;\line
\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Notice how boilerplate code for our model and collection has already been written for us, as well as code for consuming the layout utilities defined in {\f1 app.js}.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Now, you may be wondering where or how Views fit into this setup. Although Backbone Boilerplate doesn\u8217't include Views in its generated modules by default, we can easily add them ourselves as needed.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 e.g:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 define([\line
  // Application.\line
  "app",\line
\line
  // Views\line
  "modules/foo/views"\line
],\line
\line
// Map dependencies from above array.\line
function(app, Views) \{\line
\line
  // Create a new module.\line
  var Foo = app.module();\line
\line
  // Default model.\line
  Foo.Model = Backbone.Model.extend(\{\line
\line
  \});\line
\line
  // Default collection.\line
  Foo.Collection = Backbone.Collection.extend(\{\line
    model: Foo.Model\line
  \});\line
\line
  // Default views\line
  Foo.Views = Views;\line
\line
  // Return the module for AMD compliance.\line
  return Foo;\line
\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Optionally, we may also wish to include references to plugins such as the Backbone LocalStorage or Offline adapters. One clean way of including a plugin in the above boilerplate could be:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 define([\line
  "app",\line
\line
  // Libs\line
  "backbone",\line
\line
  // Plugins\line
  "plugins/backbone-localstorage"\line
],\line
\line
function(app, Backbone, Views) \{\line
  // Create a new module.\line
  var Foo = app.module();\line
\line
  // Default model.\line
  Foo.Model = Backbone.Model.extend(\{\line
\line
  \});\line
\line
  // Default collection.\line
  Foo.Collection = Backbone.Collection.extend(\{\line
    model: Foo.Model,\line
\line
    // Save all of the items under the `"foo"` namespace.\line
    localStorage: new Store("foo-backbone"),\line
  \});\line
\line
  // Default views\line
  Foo.Views = Views;\line
\line
  // Return the module for AMD compliance.\line
  return Foo;\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 You may have spotted that in our module sample we\u8217're using the plural, \u8220"Views\u8221", rather than just View. This is because a View module can contain references to as many Views as needed. In the above, our {\f1 /modules/foo/views.js} file may look as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 define([\line
  "app",\line
\line
  // Libs\line
  "backbone"\line
],\line
\line
function(app, Backbone) \{\line
\line
  var Views = \{\};\line
\line
  Views.Foo = Backbone.View.extend(\{\line
    template: "foo/bar",\line
    tagName: "li",\line
    ...\line
   \});\line
\line
  Views.Baz = Backbone.View.extend(\{\line
    template: "foo/baz",\line
    tagName: "li",\line
    ...\line
   \});\line
\line
   return Views;\line
\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Where the {\f1 template} references in our Views, correspond to files in the {\f1 app/templates} directory. e.g {\f1 foo/bar} is located at {\f1 app/templates/foo/bar.html} and is a HTML template that can contain Lodash/Underscore.js Micro-templating logic.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 router.js\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Finally, let\u8217's look at our application router, used for handling navigation. The default router Backbone Boilerplate generates for us inclues sane defaults for no routes being specified.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 define([\line
  // Application.\line
  "app"\line
],\line
\line
function(app) \{\line
\line
  // Defining the application router, you can attach sub routers here.\line
  var Router = Backbone.Router.extend(\{\line
    routes: \{\line
      "": "index"\line
    \},\line
\line
    index: function() \{\line
\line
    \}\line
  \});\line
\line
  return Router;\line
\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 If however we would like to execute some module-specific logic, when the page loads (i.e when a user hits the default route), we can pull in a module as a dependency and optionally use the Backbone LayoutManager to attach Views to our layout as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 define([\line
  // Application.\line
  "app",\line
\line
  // Modules\line
  "modules/foo"\line
],\line
\line
function(app, Foo) \{\line
\line
  // Defining the application router, you can attach sub routers here.\line
  var Router = Backbone.Router.extend(\{\line
    routes: \{\line
      "": "index"\line
    \},\line
\line
    index: function() \{\line
            // Create a new Collection\line
            var collection = new Foo.Collection();\line
\line
            // Use and configure a "main" layout\line
            app.useLayout("main").setViews(\{\line
                    // Attach the bar View into the content View\line
                    ".bar": new Foo.Views.Bar(\{\line
                            collection: collection\line
                    \})\line
             \}).render();\line
    \}\line
  \});\line
\line
  // Fetch data (e.g from localStorage)\line
  collection.fetch();\line
\line
  return Router;\line
\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Conclusions\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In this section we reviewed Backbone Boilerplate and learned how to use the BBB tool to help us scaffold out our application.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 If you would like to learn more about how this project helps structure your app, BBB includes some built-in boilerplate sample apps that can be easily generated for review.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 These include a boilerplate tutorial project ({\f1 bbb init:tutorial}) and an implementation of my {\field{\*\fldinst{HYPERLINK "http://todomvc"}}{\fldrslt{\ul
TodoMVC
}}}
 project ({\f1 bbb init:todomvc}). I recommend checking these out as they\u8217'll provide you with a more complete picture of how Backbone Boilerplate, its templates and so on fit into the overall setup for a web app.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For more about Grunt-BBB, remember to take a look at the official project {\field{\*\fldinst{HYPERLINK "https://github.com/backbone-boilerplate/grunt-bbb"}}{\fldrslt{\ul
repositoryy
}}}
. There is also a related {\field{\*\fldinst{HYPERLINK "https://dl.dropbox.com/u/79007/talks/Modern_Web_Applications/slides/index.html"}}{\fldrslt{\ul
slide-deck
}}}
 available for those interested in reading more.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Related Tools & Projects\par}
{\pard \ql \f0 \sa180 \li0 \fi0 As we\u8217've seen, scaffolding tools can assist in expediting how quickly you can begin a new application by creating the basic files required for a project automatically. If you appreciate such tools, I\u8217'm happy to also recommend checking out {\field{\*\fldinst{HYPERLINK "http://yeoman.io"}}{\fldrslt{\ul
Yeoman
}}}
 (one of my upcoming projects) and {\field{\*\fldinst{HYPERLINK "https://github.com/brunch/brunch"}}{\fldrslt{\ul
Brunch
}}}
.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Brunch works very well with Backbone, Underscore, jQuery and CoffeeScript and is even used by companies such as Red Bull and Jim Beam. You may have to update any third party dependencies (e.g.\u160?latest jQuery or Zepto) when using it, but other than that it should be fairly stable to use right out of the box.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Brunch can be installed via the nodejs package manager and is easy to get started with. If you happen to use Vim or Textmate as your editor of choice, you\u8217'll be happy to know that there are Brunch bundles available for both.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs36 Common Problems & Solutions\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In this section, we will review a number of common problems developers often experience once they\u8217've started to work on relatively non-trivial projects using Backbone.js, as well as present potential solutions.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Perhaps the most frequent of these questions surround how to do more with Views. If you are interested in discovering how to work with nested Views, learn about view disposal and inheritance, this section will hopefully have you covered.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Nesting: What is the best approach for rendering and appending Sub-Views in Backbone.js?\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Nesting is generally considered a good way to maintain hierarchal views for writing maintainable code. As a beginner, one might try writing a very simple setup with sub-views (e.g inner views) as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 \line
// Where we have previously defined a View, SubView\line
// in a parent View we could do:\line
\line
...\line
initialize : function () \{\line
\line
    this.innerView1 = new Subview(\{options\});\line
    this.innerView2 = new Subview(\{options\});\line
\},\line
\line
render : function () \{\line
\line
    this.$el.html(this.template());\line
\line
    this.innerView1.setElement('.some-element').render();\line
    this.innerView2.setElement('.some-element').render();\line
\}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This works in that one doesn\u8217't need to worry about maintaining the order of your DOM elements when appending. Views are initialized early and the render() method doesn\u8217't need to take on too many responsibilities at once. Unfortunately, a downside is that you don\u8217't have the ability to set the {\f1 tagName} of elements and events need to be re-delegated.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 An alternative approach which doesn\u8217't suffer from the re-delegation problem could be written as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 \line
initialize : function () \{\line
\line
\},\line
\line
render : function () \{\line
\line
    this.$el.empty();\line
\line
    this.innerView1 = new Subview(\{options\});\line
    this.innerView2 = new Subview(\{options\});\line
\line
\line
    this.$el.append(this.innerView1.render().el, this.innerView2.render().el);\line
\}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In this version, we also don\u8217't require a template containing empty placeholders and the issue with {\f1 tagName}s is solved as they are defined by the view once again.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Yet another variation which moves logic into an {\f1 onRender} event, could be written with only a few subtle changes:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 \line
initialize : function () \{\line
    this.on('render', this.onRender);\line
\},\line
\line
render : function () \{\line
\line
    this.$el.html(this.template);\line
\line
    // more logic\line
\line
    return this.trigger('render');\line
\},\line
\line
onRender : function () \{\line
    this.innerView1 = new Subview();\line
    this.innerView2 = new Subview();\line
    this.innerView1.setElement('.some-element').render();\line
    this.innerView2.setElement('.some-element').render();\line
\}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 If you find yourself nesting views in your application, there are more optimal approaches possible for initializing, rendering and appending your sub-views. One such solution could be written:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 \line
var OuterView = Backbone.View.extend(\{\line
    initialize: function() \{\line
        this.inner = new InnerView();\line
    \},\line
\line
    render: function() \{\line
        this.$el.html(template); // or this.$el.empty() if you have no template\line
        this.$el.append(this.inner.$el);\line
        this.inner.render();\line
    \}\line
\});\line
\line
var InnerView = Backbone.View.extend(\{\line
    render: function() \{\line
        this.$el.html(template);\line
        this.delegateEvents();\line
    \}\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This tackles a few specific design decisions:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab The order in which you append the sub-elements matters\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab The OuterView doesn\u8217't contain the HTML elements to be set in the InnerView(s), meaning that we can still specify tagName in the InnerView\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab render() is called after the InnerView element has been placed into the DOM. This is useful if your InnerViews render() method is sizing itself on the page based on the dimensions of another element. This is a common use case.\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 A second potential solution is this, which may appear cleaner but in reality has a tendency to affect performance:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 \line
var OuterView = Backbone.View.extend(\{\line
    initialize: function() \{\line
        this.render();\line
    \},\line
\line
    render: function() \{\line
        this.$el.html(template); // or this.$el.empty() if you have no template\line
        this.inner = new InnerView();\line
        this.$el.append(this.inner.$el);\line
    \}\line
\});\line
\line
var InnerView = Backbone.View.extend(\{\line
    initialize: function() \{\line
        this.render();\line
    \},\line
\line
    render: function() \{\line
        this.$el.html(template);\line
    \}\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Generally speaking, more developers opt for the first solution as:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab The majority of their views may already rely on being in the DOM in their render() method\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab When the OuterView is re-rendered, views don\u8217't have to be re-initialized where re-initialization has the potential to cause memory leaks and issues with existing bindings\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 (Thanks to {\field{\*\fldinst{HYPERLINK "http://stackoverflow.com/users/299189/lukas"}}{\fldrslt{\ul
Lukas
}}}
 and {\field{\*\fldinst{HYPERLINK "http://stackoverflow.com/users/154765/ian-storm-taylor"}}{\fldrslt{\ul
Ian Taylor
}}}
 for these tips).\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 What is the best way to manage models in nested Views?\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In order to reach attributes on related models in a nested setup, the models involved need to have some prior knowledge about which models this refers to. Backbone.js doesn\u8217't implicitly handle relations or nesting, meaning it\u8217's up to us to ensure models have a knowledge of each other.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 One approach is to make sure each child model has a \u8216'parent\u8217' attribute. This way you can traverse the nesting first up to the parent and then down to any siblings that you know of. So, assuming we have models modelA, modelB and modelC:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 \line
// When initializing modelA, I would suggest setting a link to the parent\line
// model when doing this, like this:\line
\line
ModelA = Backbone.Model.extend(\{\line
\line
    initialize: function()\{\line
        this.modelB = new modelB();\line
        this.modelB.parent = this;\line
        this.modelC = new modelC();\line
        this.modelC.parent = this;\line
    \}\line
\}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This allows you to reach the parent model in any child model function by calling this.parent.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 When you have a need to nest Backbone.js views, you might find it easier to let each view represent a single HTML tag using the tagName option of the View. This may be written as:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 ViewA = Backbone.View.extend(\{\line
\line
    tagName: "div",\line
    id: "new",\line
\line
    initialize: function()\{\line
       this.viewB = new ViewB();\line
       this.viewB.parentView = this;\line
       $(this.el).append(this.viewB.el);\line
    \}\line
\});\line
\line
ViewB = Backbone.View.extend(\{\line
\line
    tagName: "h1",\line
\line
    render: function()\{\line
        $(this.el).html("Header text"); // or use this.options.headerText or equivalent\line
    \},\line
\line
    funcB1: function()\{\line
        this.model.parent.doSomethingOnParent();\line
        this.model.parent.modelC.doSomethingOnSibling();\line
        $(this.parentView.el).shakeViolently();\line
    \}\line
\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Then in your application initialization code , you would initiate ViewA and place its element inside the body element.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 An alternative approach is to use an extension called {\field{\*\fldinst{HYPERLINK "https://github.com/powmedia/backbone-forms"}}{\fldrslt{\ul
Backbone-Forms
}}}
. Using a similar schema to what we wrote earlier, nesting could be achieved as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var ModelB = Backbone.Model.extend(\{\line
    schema: \{\line
        attributeB1: 'Text',\line
        attributeB2: 'Text'\line
    \}\line
\});\line
\line
var ModelC = Backbone.Model.extend(\{\line
    schema: \{\line
        attributeC: 'Text',\line
    \}\line
\});\line
\line
var ModelA = Backbone.Model.extend(\{\line
    schema: \{\line
        attributeA1: 'Text',\line
        attributeA2: 'Text',\line
        refToModelB: \{ type: 'NestedModel', model: ModelB, template: 'templateB' \},\line
        refToModelC: \{ type: 'NestedModel', model: ModelC, template: 'templateC' \}\line
    \}\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 There is more information about this technique available on {\field{\*\fldinst{HYPERLINK "https://github.com/powmedia/backbone-forms#customising-templates"}}{\fldrslt{\ul
GitHub
}}}
.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 (Thanks to {\field{\*\fldinst{HYPERLINK "http://stackoverflow.com/users/100952/jens-alm"}}{\fldrslt{\ul
Jens Alm
}}}
 and {\field{\*\fldinst{HYPERLINK "http://stackoverflow.com/users/801466/artem-oboturov"}}{\fldrslt{\ul
Artem Oboturov
}}}
 for these tips)\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Is it possible to have one Backbone.js View trigger updates in other Views?\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The Mediator pattern is an excellent option for implementing a solution to this problem.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Without going into too much detail about the pattern, it can effectively be used an event manager that lets you to subscribe to and publish events. So an ApplicationViewA could subscribe to an event, i.e. \u8216'selected\u8217' and then the ApplicationViewB would publish the \u8216'selected\u8217' event.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The reason I like this is it allows you to send events between views, without the views being directly bound together.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For Example:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 \line
// See http://addyosmani.com/largescalejavascript/#mediatorpattern\line
// for an implementation or alternatively for a more thorough one\line
// http://thejacklawson.com/Mediator.js/\line
\line
var mediator = new Mediator();\line
\line
var ApplicationViewB = Backbone.View.extend(\{\line
    toggle_select: function() \{\line
        ...\line
        mediator.publish('selected', any, data, you, want);\line
        return this;\line
    \}\line
\});\line
\line
var ApplicationViewA = Backbone.View.extend(\{\line
    initialize: function() \{\line
        mediator.subscribe('selected', this.delete_selected)\line
    \},\line
\line
    delete_selected: function(any, data, you, want) \{\line
        ... do something ...\line
    \},\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This way your ApplicationViewA doesn\u8217't care if it is an ApplicationViewB or FooView that publishes the \u8216'selected\u8217' event, only that the event occurred. As a result, you may find it a maintainable way to manage events between parts of your application, not just views.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 (Thanks to {\field{\*\fldinst{HYPERLINK "http://stackoverflow.com/users/937577/john-mckim"}}{\fldrslt{\ul
John McKim
}}}
 for this tip and for referencing my Large Scale JavaScript Patterns article).\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 How would one render a Parent View from one of its Children?\par}
{\pard \ql \f0 \sa180 \li0 \fi0 If you say, have a view which contains another view (e.g a main view containing a modal view) and would like to render or re-render the parent view from the child, this is extremely straight-forward.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In such a scenario, you would most likely want to execute the rendering when a particular event has occurred. For the sake of example, let us call this event \u8216'somethingHappened\u8217'. The parent view can bind notifications on the child view to know when the event has occurred. It can then render itself.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 On the parent view:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 // Parent initialize\line
this.childView.on('somethingHappened', this.render, this);\line
\line
// Parent removal\line
this.childView.off('somethingHappened', this.render, this);\par}
{\pard \ql \f0 \sa180 \li0 \fi0 On the child view:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 \line
// After the event has occurred\line
this.trigger('somethingHappened');\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The child will trigger a \u8220"somethingHappened\u8221" event and the parent\u8217's render function will be called.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 (Thanks to Tal {\field{\*\fldinst{HYPERLINK "http://stackoverflow.com/users/269666/tal-bereznitskey"}}{\fldrslt{\ul
Bereznitskey
}}}
 for this tip)\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 How do you cleanly dispose Views to avoid memory leaks?\par}
{\pard \ql \f0 \sa180 \li0 \fi0 As your application grows, keeping live views around which aren\u8217't being used can quickly become difficult to maintain. Instead, you may find it more optimal to destroy views that are no longer required and simply create new ones as the necessity arises.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 A solution to help with this is to create a BaseView from which the rest of your views inherit from. The idea here is that your view will maintain a reference to all of the events to which its subscribed to so that when it is time to dispose of a view, all of those bindings will be automatically unbound.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Here is a sample implementation of this:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var BaseView = function (options) \{\line
\line
    this.bindings = [];\line
    Backbone.View.apply(this, [options]);\line
\};\line
\line
_.extend(BaseView.prototype, Backbone.View.prototype, \{\line
\line
    bindTo: function (model, ev, callback) \{\line
\line
        model.bind(ev, callback, this);\line
        this.bindings.push(\{ model: model, ev: ev, callback: callback \});\line
    \},\line
\line
    unbindFromAll: function () \{\line
        _.each(this.bindings, function (binding) \{\line
            binding.model.unbind(binding.ev, binding.callback);\line
        \});\line
        this.bindings = [];\line
    \},\line
\line
    dispose: function () \{\line
        this.unbindFromAll(); // this will unbind all events that this view has bound to\line
        this.unbind(); // this will unbind all listeners to events from this view. This is probably not necessary because this view will be garbage collected.\line
        this.remove(); // uses the default Backbone.View.remove() method which removes this.el from the DOM and removes DOM events.\line
    \}\line
\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 BaseView.extend = Backbone.View.extend;\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Then, whenever a view has the need to bind to an event on a model or a collection, you would use the bindTo method. e.g:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var SampleView = BaseView.extend(\{\line
\line
    initialize: function()\{\line
        this.bindTo(this.model, 'change', this.render);\line
        this.bindTo(this.collection, 'reset', this.doSomething);\line
    \}\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 When you remove a view, simply call the dispose() method which will clean everything up for you automatically:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var sampleView = new SampleView(\{model: some_model, collection: some_collection\});\line
sampleView.dispose();\par}
{\pard \ql \f0 \sa180 \li0 \fi0 (Thanks to {\field{\*\fldinst{HYPERLINK "http://stackoverflow.com/users/188740/johnnyo"}}{\fldrslt{\ul
JohnnyO
}}}
 for this tip).\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 How does one handle View disposal on a Parent or Child View?\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In the last question, we looked at how to effectively dispose views to decreases memory usage (analogous to a type of garbage collection).\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Where your application is setup with multiple Parent and Child Views, it is also common to desire removing any DOM elements associated with such views as well as unbinding any event handlers tied to child elements when you no longer require them.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The solution in the last question should be enough to handle this use-case, but if you require a more-explicit example that handles children, we can see one below:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 Backbone.View.prototype.close = function() \{\line
    if (this.onClose) \{\line
        this.onClose();\line
    \}\line
    this.remove();\line
    this.unbind();\line
\};\line
\line
NewView = Backbone.View.extend(\{\line
    initialize: function() \{\line
       this.childViews = [];\line
    \},\line
    renderChildren: function(item) \{\line
        var itemView = new NewChildView(\{ model: item \});\line
        $(this.el).prepend(itemView.render());\line
        this.childViews.push(itemView);\line
    \},\line
    onClose: function() \{\line
      _(this.childViews).each(function(view) \{\line
        view.close();\line
      \});\line
    \}\line
\});\line
\line
NewChildView = Backbone.View.extend(\{\line
    tagName: 'li',\line
    render: function() \{\line
    \}\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Here, a close() method for views is implemented which disposes of a view when it is no longer needed or needs to be reset. In most cases the view removal should be done at a view layer so that it won\u8217't affect any of our models.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For example, if you are working on a blogging application and you remove a view with comments, perhaps another view in your app shows a selection of comments and resetting the collection would affect those views too.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 (Thanks to {\field{\*\fldinst{HYPERLINK "http://stackoverflow.com/users/906136/dira"}}{\fldrslt{\ul
dira
}}}
 for this tip)\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 What\u8217's the best way to combine or append Views to each other?\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Let us say you have a Collection, where each item in the Collection could itself be a Collection. You can render each item in the Collection, and indeed can render any items which themselves are Collections. The problem you might have is how to render this structure where the HTML reflects the hierarchical nature of the data structure.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The most straight-forward way to approach this problem is to use a framework like Derick Baileys {\field{\*\fldinst{HYPERLINK "https://github.com/derickbailey/backbone.marionette"}}{\fldrslt{\ul
Backbone.Marionette
}}}
. In this framework is a type of view called a CompositeView.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The basic idea of a CompositeView is that it can render a model and a collection within the same view.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 It can render a single model with a template. It can also take a collection from that model and for each model in that collection, render a view. By default it uses the same composite view type that you\u8217've defined, to render each of the models in the collection. All you have to do is tell the view instance where the collection is, via the initialize method, and you\u8217'll get a recursive hierarchy rendered.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 There is a working demo of this in action available {\field{\*\fldinst{HYPERLINK "http://jsfiddle.net/derickbailey/AdWjU/"}}{\fldrslt{\ul
online
}}}
.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 And you can get the source code and documentation for {\field{\*\fldinst{HYPERLINK "https://github.com/derickbailey/backbone.marionette"}}{\fldrslt{\ul
Marionette
}}}
 too.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs36 Better Model Property Validation\par}
{\pard \ql \f0 \sa180 \li0 \fi0 As we learned earlier in the book, the {\f1 validate} method on a Model is called before {\f1 set} and {\f1 save}, and is passed the model attributes updated with the values from these methods.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 By default, where we define a custom {\f1 validate} method, Backbone passes all of a Model\u8217's attributes through this validation each time, regardless of which model attributes are being set.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This means that it can be a challenge to determine which specific fields are being set or validated without being concerned about the others that aren\u8217't being set at the same time.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 To illustrate this problem better, let us look at a typical registration form use case that:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Validates form fields using the blur event\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Validates each field regardless of whether other model attributes (aka other form data) are valid or not.\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Here is one example of a desired use case:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We have a form where a user focuses and blurs first name, last name, and email HTML input boxes without entering any data. A \u8220"this field is required\u8221" message should be presented next to each form field.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 HTML:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 <!doctype html>\line
<html>\line
<head>\line
  <meta charset=utf-8>\line
  <title>Form Validation - Model#validate</title>\line
  <script src='http://code.jquery.com/jquery.js'></script>\line
  <script src='http://underscorejs.org/underscore.js'></script>\line
  <script src='http://backbonejs.org/backbone.js'></script>\line
</head>\line
<body>\line
  <form>\line
    <label>First Name</label>\line
    <input name='firstname'>\line
    <span data-msg='firstname'></span>\line
    <br>\line
    <label>Last Name</label>\line
    <input name='lastname'>\line
    <span data-msg='lastname'></span>\line
    <br>\line
    <label>Email</label>\line
    <input name='email'>\line
    <span data-msg='email'></span>\line
  </form>\line
</body>\line
</html>\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Some simple validation that could be written using the current Backbone {\f1 validate} method to work with this form could be implemented using something like:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 validate: function(attrs) \{\line
\line
    if(!attrs.firstname) return 'first name is empty';\line
    if(!attrs.lastname) return 'last name is empty';\line
    if(!attrs.email) return 'email is empty';\line
\line
\}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Unfortunately, this method would trigger a first name error each time any of the fields were blurred and only an error message next to the first name field would be presented.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 One potential solution to the problem could be to validate all fields and return all of the errors:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 validate: function(attrs) \{\line
\line
  var errors = \{\};\line
\line
  if (!attrs.firstname) errors.firstname = 'first name is empty';\line
  if (!attrs.lastname) errors.lastname = 'last name is empty';\line
  if (!attrs.email) errors.email = 'email is empty';\line
\line
  if (!_.isEmpty(errors)) return errors;\line
\line
\}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This can be adapted into a complete solution that defines a Field model for each input in our form and works within the parameters of our use-case as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 \line
$(function($) \{\line
\line
  var User = Backbone.Model.extend(\{\line
\line
    validate: function(attrs) \{\line
\line
      var errors = this.errors = \{\};\line
\line
      if (!attrs.firstname) errors.firstname = 'firstname is required';\line
      if (!attrs.lastname) errors.lastname = 'lastname is required';\line
      if (!attrs.email) errors.email = 'email is required';\line
\line
      if (!_.isEmpty(errors)) return errors;\line
\line
    \}\line
\line
  \});\line
\line
  var Field = Backbone.View.extend(\{\line
\line
    events: \{blur: 'validate'\},\line
\line
    initialize: function() \{\line
\line
      this.name = this.$el.attr('name');\line
      this.$msg = $('[data-msg=' + this.name + ']');\line
\line
    \},\line
\line
    validate: function() \{\line
\line
      this.model.set(this.name, this.$el.val());\line
      this.$msg.text(this.model.errors[this.name] || '');\line
\line
    \}\line
\line
  \});\line
\line
  var user = new User;\line
\line
  $('input').each(function() \{\line
\line
    new Field(\{el: this, model: user\});\line
\line
  \});\line
\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This works great as the solution checks the validation for each attribute individually and sets the message for the correct blurred field.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Note}: A {\field{\*\fldinst{HYPERLINK "http://jsbin.com/afetez/2/edit"}}{\fldrslt{\ul
demo
}}}
 of the above solution by {\field{\*\fldinst{HYPERLINK "http://github.com/braddunbar"}}{\fldrslt{\ul
@braddunbar
}}}
 is also available.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Unfortunately, this solution forces each form field to be validated every time a blur event is fired. If we have multiple client-side validation methods with our particular use case, we may not want to have to call each validation method on every attribute every time, so this solution might not be ideal for everyone.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 A potentially better alternative to the above solution is to use {\field{\*\fldinst{HYPERLINK "http://github.com/gfranko"}}{\fldrslt{\ul
@gfranko
}}}
\u8217's {\field{\*\fldinst{HYPERLINK "https://github.com/gfranko/Backbone.validateAll"}}{\fldrslt{\ul
Backbone.validateAll
}}}
 plugin, which was specifically created to provide an option to validate only Model properties that are currently being set/saved.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Here is how we would setup a partial User Model and validate method using this plugin, that caters to our use-case:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 \line
// Create a new User Model\line
var User = Backbone.Model.extend(\{\line
\line
  // RegEx Patterns\line
  patterns: \{\line
\line
    specialCharacters: "[^a-zA-Z 0-9]+",\line
\line
    digits: "[0-9]",\line
\line
    email: "^[a-zA-Z0-9._-]+@[a-zA-Z0-9][a-zA-Z0-9.-]*[.]\{1\}[a-zA-Z]\{2,6\}$"\line
  \},\line
\line
  // Validators\line
  validators: \{\line
\line
    minLength: function(value, minLength) \{\line
\line
      return value.length >= minLength;\line
\line
    \},\line
\line
    maxLength: function(value, maxLength) \{\line
\line
      return value.length <= maxLength;\line
\line
    \},\line
\line
    isEmail: function(value) \{\line
\line
      return User.prototype.validators.pattern(value, User.prototype.patterns.email);\line
\line
    \},\line
\line
    hasSpecialCharacter: function(value) \{\line
\line
      return User.prototype.validators.pattern(value, User.prototype.patterns.specialCharacters);\line
\line
    \},\line
    ...\line
\line
    // We can determine which properties are getting validated by\line
    // checking to see if properties are equal to null\line
\line
    validate: function(attrs) \{\line
\line
      var errors = this.errors = \{\};\line
\line
      if(attrs.firstname != null) \{\line
\line
        if (!attrs.firstname) errors.firstname = 'firstname is required';\line
        else if(!this.validators.minLength(attrs.firstname, 2)) errors.firstname = 'firstname is too short';\line
        else if(!this.validators.maxLength(attrs.firstname, 15)) errors.firstname = 'firstname is too large';\line
        else if(this.validators.hasSpecialCharacter(attrs.firstname)) errors.firstname = 'firstname cannot contain special characters';\line
\line
      \}\line
\line
      if(attrs.lastname != null) \{\line
\line
        if (!attrs.lastname) errors.lastname = 'lastname is required';\line
        else if(!this.validators.minLength(attrs.lastname, 2)) errors.lastname = 'lastname is too short';\line
        else if(!this.validators.maxLength(attrs.lastname, 15)) errors.lastname = 'lastname is too large';\line
        else if(this.validators.hasSpecialCharacter(attrs.lastname)) errors.lastname = 'lastname cannot contain special characters';\line
\line
      \}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This allows the logic inside of our validate methods to determine which form fields are currently being set/validated, and does not care about the other model properties that are not trying to be set.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Note}: A {\field{\*\fldinst{HYPERLINK "http://jsbin.com/afetez/11/edit"}}{\fldrslt{\ul
demo
}}}
 of the above solution by {\field{\*\fldinst{HYPERLINK "http://github.com/gfranko"}}{\fldrslt{\ul
@gfranko
}}}
 is also available.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 It\u8217's fairly straight-forward to use as well. We can simply define a new Model instance and then set the data on our model using the {\f1 validateAll} option to use the behavior defined by the plugin:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var user = new User();\line
user.set(\{ "firstname": "Greg" \}, \{validateAll: false\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 That\u8217's it!\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The Backbone.validateAll logic doesn\u8217't override the default Backbone logic by default and so it\u8217's perfectly capable of being used for scenarios where you might care more about field-validation {\field{\*\fldinst{HYPERLINK "http://jsperf.com/backbone-validateall"}}{\fldrslt{\ul
performance
}}}
 as well as those where you don\u8217't. Both solutions presented in this section should work fine however.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs36 RESTful Applications\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Building RESTful applications with Backbone\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In this section of the book, we\u8217're going to take a look at developing RESTful applications using Backbone.js and modern technology stacks. When the data for your back-end is exposed through a purely RESTful API, tasks such as retrieving (GET), creating (POST), updating (PUT) and deleting (DELETE) models are made easy through Backbone\u8217's Model API. This API is so intuitive in fact that switching from storing records in a local data-store (e.g localStorage) to a database/noSQL data-store is a lot simpler than you may think.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Stack 1: Building A Backbone App With Node.js, Express, Mongoose and MongoDB\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The first stack we\u8217'll be looking at is:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\field{\*\fldinst{HYPERLINK "nodejs.org"}}{\fldrslt{\ul
Node.js
}}}
\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\field{\*\fldinst{HYPERLINK "http://expressjs.com/"}}{\fldrslt{\ul
Express
}}}
\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\field{\*\fldinst{HYPERLINK "http://mongoosejs.com/"}}{\fldrslt{\ul
Mongoose
}}}
\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab and {\field{\*\fldinst{HYPERLINK "http://www.mongodb.org/"}}{\fldrslt{\ul
MongoDB
}}}
\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 with {\field{\*\fldinst{HYPERLINK "http://jade-lang.com/"}}{\fldrslt{\ul
Jade
}}}
 used optionally as a view/templating engine.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Reviewing the stack\par}
{\pard \ql \f0 \sa180 \li0 \fi0 As you may know, node.js is an event-driven platform (built on the {\field{\*\fldinst{HYPERLINK "http://code.google.com/apis/v8/design.html"}}{\fldrslt{\ul
V8
}}}
 runtime), designed for writing fast, scalable network applications. It\u8217's reasonably lightweight, efficient and great for real-time applications that are data-intensive.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Express is a small web-development framework written with node.js, based on {\field{\*\fldinst{HYPERLINK "http://www.sinatrarb.com/"}}{\fldrslt{\ul
Sinatra
}}}
. It supports a number of useful features such as intuitive views, robust routing and a focus on high performance.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Next on the list are MongoDB and Mongoose. MongoDB is an open-source, document-oriented database store designed with scalability and agility in mind. As a {\field{\*\fldinst{HYPERLINK "http://en.wikipedia.org/wiki/NoSQL"}}{\fldrslt{\ul
noSQL
}}}
 database, rather than storing data in tables and rows (something we\u8217're very used to doing with relational databases), with MongoDB we instead store JSON-like documents using dynamic schemas. One of the goals of Mongo is to try bridging the gap between key-value stores (speed, scalability) and {\field{\*\fldinst{HYPERLINK "http://en.wikipedia.org/wiki/Relational_database"}}{\fldrslt{\ul
relational
}}}
 databases (rich functionality).\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Mongoose is a JavaScript library that simplifies how we interact with Mongo. Like Express, it\u8217's designed to work within the node.js environment and tries to solve some of the complexities with asynchronous data storage by offering a more user-friendly API. It also adds chaining features into the mix, allowing for a slightly more expressive way of dealing with our data.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Jade is a template engine influenced by Haml (which we\u8217'll be looking at later). It\u8217's implemented with JavaScript (and also runs under node). In addition to supporting Express out of the box, it boasts a number of useful features including support for mixins, includes, caching, template inheritance and much more. Whilst abstractions like Jade certainly aren\u8217't for everyone, our practical will cover working both with and without it.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Practical\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For this practical, we\u8217're going to once again look at extending the popular Backbone Todo application. Rather than relying on localStorage for data persistence, we\u8217're going to switch to storing Todos in a MongoDB document-store instead. The code for this practical can be found in {\f1 practicals\\stacks\\option2}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b app.js}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 (See {\field{\*\fldinst{HYPERLINK "https://github.com/addyosmani/backbone-boilerplates/blob/master/option2/app.js"}}{\fldrslt{\ul
here
}}}
 for the source)\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We must first include the node dependencies required by our application. These are Express, Mongoose and Path (a module containing utilities for dealing with file paths).\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var application_root = __dirname,\line
  express = require("express"),\line
  path = require("path"),\line
  mongoose = require('mongoose');\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Next, create a new Express server. {\f1 express.createServer()} is a simple way of creating an instance of express.HTTPServer, which we\u8217'll be using to pass in our routes.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var app = express.createServer();\par}
{\pard \ql \f0 \sa180 \li0 \fi0 After this, connect Mongoose up to a database (in our case, localhost should suffice). Should you require the ability to pass in authentication information, here\u8217's a sample containing all of the supported URL parameters: {\f1 mongodb://[username:password@]host1[:port1][,host2[:port2],...[,hostN[:portN]]][/[database][?options]]}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 mongoose.connect('mongodb://localhost/my_database');\par}
{\pard \ql \f0 \sa180 \li0 \fi0 A Mongoose model for any Todo item can now be easily defined by passing a schema instance to {\f1 mongoose.model}. In our case the schema covers a Todo item\u8217's {\f1 text} content, its {\f1 done} state and {\f1 order} position in the overall Todo list.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var Todo = mongoose.model('Todo', new mongoose.Schema(\{\line
  text: String,\line
  done: Boolean,\line
  order: Number\line
\}));\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The {\f1 configure()} methods allows us to setup what we need for the current environment with our Express server. Note that lower down in the configuration are two view/view related lines. The last one explicitly sets the viewing/templating engine to be used as Jade {\f1 app.set('view engine', 'jade')}. We can avoid these if we wish to use plain HTML/JS for our templates instead.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 app.configure(function()\{\line
  // the bodyParser middleware parses JSON request bodies\line
  app.use(express.bodyParser());\line
  app.use(express.methodOverride());\line
  app.use(app.router);\line
  app.use(express.static(path.join(application_root, "public")));\line
  app.use(express.errorHandler(\{ dumpExceptions: true, showStack: true \}));\line
  app.set('views', path.join(application_root, "views"));\line
  app.set('view engine', 'jade')\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Should you prefer to switch out Jade for an alternative view engine, this can be done fairly trivially. See the section under \u8216'Templating\u8217' here: https://github.com/joyent/node/wiki/modules. For example, to switch to EJS, you would simply write {\f1 app.set('view engine', 'ejs')}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Express makes use of common HTTP verbs (get, put, post etc.) to provide easy to use, expressive routing API based on CRUD (Create, Read, Update and Delete). Below for example, we can define what happens when the browser requests the root \u8216'/\u8217'. As a trivial route in this application, it doesn\u8217't do anything particularly exciting, however getters typically read or retrieve data.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 app.get('/', function(req, res)\{\line
  res.send('Hello World');\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Onto something a little more useful and in our next route, navigating to \u8216'/todo\u8217' will actually render our Jade view \u8216'todo.jade\u8217', as seen in the callback. Additional configuration values can be passed as the second parameter, such as the custom title specified below.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 app.get('/todo', function(req, res)\{\line
  res.render('todo', \{title: "Our sample application"\});\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Next, we can see the first of our \u8216'/api/\u8217' routes.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 app.get('/api/todos', function(req, res)\{\line
  return Todo.find(function(err, todos) \{\line
    return res.send(todos);\line
  \});\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The callback to our next route supports querying for todos based on a specific ID. The route string itself (once compiled) will be converted from \u8216'/api/todos/:id\u8217' to a regular expression. As you might have guessed, this is a hint that routes can also be regular expression literals if we wished to do something more complex.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 app.get('/api/todos/:id', function(req, res)\{\line
  return Todo.findById(req.params.id, function(err, todo) \{\line
    if (!err) \{\line
      return res.send(todo);\line
    \}\line
  \});\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Similarly, we want to support updating todos based on a specific ID as well. The following allows us to query a todo by ID and then update the values of its three attributes (text, done, order) easily.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 app.put('/api/todos/:id', function(req, res)\{\line
  return Todo.findById(req.params.id, function(err, todo) \{\line
    todo.text = req.body.text;\line
    todo.done = req.body.done;\line
    todo.order = req.body.order;\line
    return todo.save(function(err) \{\line
      if (!err) \{\line
        console.log("updated");\line
      \}\line
      return res.send(todo);\line
    \});\line
  \});\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We\u8217've so far covered requesting todos and updating them, but a core part of the application requires us to insert (or add) new todos to our data-store. Below we can create new Todo models and simply save them.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 app.post('/api/todos', function(req, res)\{\line
  var todo;\line
  todo = new Todo(\{\line
    text: req.body.text,\line
    done: req.body.done,\line
    order: req.body.order\line
  \});\line
  todo.save(function(err) \{\line
    if (!err) \{\line
      return console.log("created");\line
    \}\line
  \});\line
  return res.send(todo);\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We of course also want to support deleting todos (e.g if a todo has been \u8216'cleared\u8217', it should be deleted). This also works based on a specific todo ID.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 app.delete('/api/todos/:id', function(req, res)\{\line
  return Todo.findById(req.params.id, function(err, todo) \{\line
    return todo.remove(function(err) \{\line
      if (!err) \{\line
        console.log("removed");\line
        return res.send('')\line
      \}\line
    \});\line
  \});\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Finally, this last line is to ensure we\u8217're only listening on the port app.js is running.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 app.listen(3000);\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b script.js - updating our Backbone.js app}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In the {\f1 /public/js} folder of options 1 (HTML templates) and 2 (Jade) for the practical, you\u8217'll find a version of the Backbone Todo app originally by Jerome Gravel-Niquet. Let\u8217's pay attention to {\field{\*\fldinst{HYPERLINK "https://github.com/addyosmani/backbone-boilerplates/blob/master/option2/public/js/script.js"}}{\fldrslt{\ul
script.js
}}}
. In order to change the application to work with our new back-end, we\u8217'll need to make some very minor changes to this.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Reviewing {\f1 window.TodoList} (a Backbone Collection), you\u8217'll notice that it has a property called {\f1 localStorage}, which uses the Backbone {\field{\*\fldinst{HYPERLINK "https://github.com/jeromegn/Backbone.localStorage"}}{\fldrslt{\ul
localStorage
}}}
 adapter in order to facilitate storing data using the browser\u8217's localStorage features.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 window.TodoList = Backbone.Collection.extend(\{\line
\line
    // Reference to this collection's model.\line
    model: Todo,\line
\line
    // Save all of the todo items under the `"todos"` namespace.\line
    // Typically, this should be a unique name within your application\line
    localStorage: new Store("todos"),\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In order to switch it over to our RESTful backend, we\u8217're going to make use of the {\f1 url} property or function on a collection to reference its location on the server. Models inside of a collection then use {\f1 url} to construct URLs of their own. As all of the CRUD for our RESTful API works on the base route \u8216'/api/todos\u8217', this is the value we set {\f1 url} to.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1     // localStorage: new Store("todos"),\line
    url: '/api/todos',\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This is the only change necessary to our existing Backbone application in order to get things working. Pretty easy, right?\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b todo.jade}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The Jade templates for our application cover declarative markup for both the index (layout.jade) of the application and the main Todo container (todo.jade). It also covers the script-tag templates used for rendering each new Todo item that\u8217's added.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 // Todo App Interface\line
\line
#todoapp\line
  .title\line
    h1 Todos\line
  .content\line
    #create-todo\line
      input#new-todo(placeholder="What needs to be done?", type="text")\line
      span.ui-tooltip-top(style="display:none;") Press Enter to save this task\line
    #todos\line
      ul#todo-list\line
    #todo-stats\line
\line
\line
// Templates\line
script#item-template(type="text/template")\line
  <div class="todo <%= done ? 'done' : '' %>">\line
  .display\line
    <input class="check" type="checkbox" <%= done ? 'checked="checked"' : '' %> />\line
    .todo-text\line
    span#todo-destroy\line
  .edit\line
    input.todo-input(type="text", "value"="")\line
  </div>\line
\line
script#stats-template(type="text/template")\line
  <% if (total) \{ %>\line
  span.todo-count\line
    span.number <%= remaining %>\line
    span.word <%= remaining == 1 ? 'item' : 'items' %>\line
    |  left.\line
  <% \} %>\line
  <% if (done) \{ %>\line
  span.todo-clear\line
    a(href="#")\line
      |  Clear\line
      span.number-done <%= done %>\line
      |  completed\line
      span.word-done <%= done == 1 ? 'item' : 'items' %>\line
  <% \} %>\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b layout.jade}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 head\line
  meta(charset="utf-8")\line
  meta(http-equiv="X-UA-Compatible", content="IE=edge,chrome=1")\line
\line
  title=title\line
  meta(name="description", content="")\line
  meta(name="author", content="")\line
  meta(name="viewport", content="width=device-width,initial-scale=1")\line
\line
  // CSS concatenated and minified via ant build script\line
  link(rel="stylesheet", href="css/style.css")\line
  // end CSS\line
\line
  script(src="js/libs/modernizr-2.0.6.min.js")\line
body\line
\line
  #container\line
    header\line
    #main(role="main")!=body\line
    footer\line
  //! end of #container\line
\line
  script(src="//ajax.googleapis.com/ajax/libs/jquery/1.8.0/jquery.min.js")\line
  script\line
    window.jQuery || document.write('<script src="js/libs/jquery-1.6.2.min.js"><\\\\/script>')\line
\line
  // scripts concatenated and minified via ant build script\line
  script(src="js/mylibs/underscore.js")\line
  script(src="js/mylibs/backbone.js")\line
  script(defer, src="js/plugins.js")\line
  script(defer, src="js/script.js")\line
  // end scripts\line
\line
  // Change UA-XXXXX-X to be your site's ID\line
  script\line
    window._gaq = [['_setAccount','UAXXXXXXXX1'],['_trackPageview'],['_trackPageLoadTime']];\line
    Modernizr.load(\{load: ('https:' == location.protocol ? '//ssl' : '//www') + '.google-analytics.com/ga.js'\});\line
\line
  //if lt IE 7\line
    script(src="//ajax.googleapis.com/ajax/libs/chrome-frame/1.0.3/CFInstall.min.js")\line
    script\line
      window.attachEvent('onload',function()\{CFInstall.check(\{mode:'overlay'\})\})\line
</html>\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b static.html}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Alternatively, a static version of our index which doesn\u8217't rely on Jade can be put together as follows. See {\field{\*\fldinst{HYPERLINK "https://github.com/addyosmani/backbone-boilerplates/blob/master/option1/public/static.html"}}{\fldrslt{\ul
here
}}}
 for the complete file or below for a sample.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 <div id="container">\line
    <div id="main" role="main">\line
\line
      <!-- Todo App Interface-->\line
\line
      <div id="todoapp">\line
        <div class="title">\line
          <h1>Todos</h1>\line
        </div>\line
\line
        <div class="content">\line
          <div id="create-todo">\line
            <input id="new-todo" placeholder="What needs to be done?" type=\line
            "text" /><span style="display:none;" class="ui-tooltip-top">Press Enter to\line
            save this task</span>\line
          </div>\line
\line
          <div id="todos">\line
            <ul id="todo-list"></ul>\line
          </div>\line
\line
          <div id="todo-stats"></div>\line
        </div>\line
      </div>\line
\line
\line
    <!-- Templates-->\line
\line
      <script id="item-template" type="text/template">\line
      <div class="todo <%= done ? 'done' : '' %>">\line
      <div class="display"><input class="check" type="checkbox" <%= done ? 'checked="checked"' : '' %> />\line
      <div class="todo-text"></div><span id="todo-destroy"></span></div><div class="edit"><input type="text" value="" class="todo-input"/></div></div>\line
      </script>\line
\line
      <script id="stats-template" type="text/template">\line
      <% if (total) \{ %>\line
      <span class="todo-count"><span class="number"><%= remaining %> </span><span class="word"><%= remaining == 1 ? 'item' : 'items' %></span> left.\line
      </span><% \} %>\line
      <% if (done) \{ %>\line
      <span class="todo-clear"><a href="#"> Clear\line
      <span class="number-done"><%= done %></span> completed\line
      <span class="word-done"><%= done == 1 ? 'item' : 'items' %></span></a></span><% \} %>\line
      </script>\line
\line
    </div>\line
  </div>\line
\line
  <!--! end of #container-->\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Practical Setup\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We\u8217've now gone through the major points of developing a RESTful backend using Node.js, Express and Mongoose. Next, let\u8217's make sure you can get your environment setup to run the updated Todo app.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 MongoDB\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Once you\u8217've downloaded {\field{\*\fldinst{HYPERLINK "http://www.mongodb.org/downloads"}}{\fldrslt{\ul
MongoDB
}}}
, you\u8217'll need to complete two steps to get it up and running.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Data directories}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 MongoDB stores data in the bin/data/db folder but won\u8217't actually create this directory for you. Navigate to where you\u8217've downloaded and extracted MongoDB and run the following from terminal:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 sudo mkdir -p /data/db/\line
sudo chown `id -u` /data/db\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Running and connecting to your server}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Once this is done, open up two terminal windows.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In the first, {\f1 cd} to your MongoDB bin directory or type in the complete path to it. You\u8217'll need to start {\f1 mongod}.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 $ ./bin/mongod\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Next, in the second terminal, start the {\f1 mongo} shell which will connect up to localhost by default.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 $ ./bin/mongo\par}
{\pard \ql \f0 \sa180 \li0 \fi0 That\u8217's it!.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Express and Mongoose\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Option 1 (HTML) and Option 2 (Jade) of the practical download both come with an install.sh bash script. This allows you to easily install Express, Mongoose, Jade (and optionally MongoDB if you prefer to) through npm (the node package manager).\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Make sure you have Node.js installed. If not, you can grab it {\field{\*\fldinst{HYPERLINK "http://nodejs.org/#download"}}{\fldrslt{\ul
here
}}}
\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Next run {\f1 $ ./install.sh} at the terminal to install the rest of our dependencies. To see the exact contents of the install.sh file, see below:\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b install.sh}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 #!/bin/bash\line
npm install express\line
npm install mongodb --mongodb:native\line
npm install mongoose\line
npm install jade\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab After you\u8217've installed all of the dependencies for the stack, we can get to cloning the repo containing our practicals and running them. Start by running the below lines:\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 git clone git://github.com/addyosmani/backbone-boilerplates.git\line
cd option2\line
node app.js\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For option1 (without Jade), simply cd into option1 and run {\f1 node app.js} from there.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Finally, either of the example apps can now be accessed by navigating to:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Option 1: {\f1 http://localhost:3000/static.html}\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Option 2: {\f1 http://localhost:3000/todo}\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 That\u8217's it! Whilst there\u8217's a lot more than can be done to expand on the concepts covered so far, the base we\u8217're reviewed should be enough to get you up and running with this stack if you wish to use it with Backbone.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs36 Building Backbone.js Apps With Ruby, Sinatra, MongoDB and Haml\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Introduction\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In this chapter we\u8217're going to explore writing Backbone.js applications with a Ruby back-end. To assist with this, we\u8217're going to use {\field{\*\fldinst{HYPERLINK "http://www.sinatrarb.com/"}}{\fldrslt{\ul
Sinatra
}}}
 - a DSL (domain specific language) for rapidly creating web applications in Ruby. Similar to the {\field{\*\fldinst{HYPERLINK "https://github.com/addyosmani/backbone-fundamentals/#stack1"}}{\fldrslt{\ul
section
}}}
 on writing an application with Node.js, our server-side language (Ruby) will be used to power an API whilst Backbone.js will be the client consuming it.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 What Is Sinatra?\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In the past, you\u8217've likely come across or used {\field{\*\fldinst{HYPERLINK "http://rubyonrails.org"}}{\fldrslt{\ul
Ruby on Rails
}}}
 (RoR) - a popular web application framework for the Ruby programming language that helps organize applications using the MVC pattern. Sinatra is a much smaller, more light-weight alternative to it.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Whilst a very basic Rails application may require a more strict project structure (such as requiring the use of controllers, views and routing etc.), Sinatra doesn\u8217't require as many of these dependencies, sacrificing the helpers needed to connect to databases, tools to create forms or any of the other utilities Rails comes with out of the box.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 What Sinatra does have is a {\b minimal} set of features most useful for tying specific URLs and RESTful HTTP actions to blocks of Ruby code and returning this code\u8217's output as a response. Sinatra is particularly useful for getting projects up and running quickly where we don\u8217't have a need for the extra pieces RoR provides.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For those who are familiar with more Rails, you probably know that it requires a separate routes file to define how an application should be responding to requests. These are then piped into the relevant models and controllers as needed.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Sinatra takes a more straight-forward approach, providing us with the most simple path to handling routing. By declaring {\f1 get},{\f1 post}, {\f1 put} or {\f1 delete} actions, we can inform Sinatra to add a new route, which we can then have respond to requests.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The framework is particularly useful for writing APIs, widgets and small-scale applications that can power the backend of a client-heavy application. As mentioned, we will be using it to power our API.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Getting Started With Sinatra\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Let\u8217's review how to write and run a very basic Sinatra application. As most programming languages and frameworks typically start with some variation of \u8220"Hello World\u8221", we\u8217'll start with a similar example.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Note: Before beginning this section, I recommend installing Sinatra on your system. A guide to doing this can be found in the {\field{\*\fldinst{HYPERLINK "#preq"}}{\fldrslt{\ul
prerequisites
}}}
 section lower down in the article.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Routes\par}
{\pard \ql \f0 \sa180 \li0 \fi0 As mentioned, Sinatra allows us to define new routes using HTTP actions. Semantically, a route follows quite a simple structure:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 <a HTTP action> <the desired route> do\line
   # some behaviour\line
end\par}
{\pard \ql \f0 \sa180 \li0 \fi0 A tiny route that outputs a \u8220"Hello World\u8221"-like message when we attempt to \u8220"get\u8221" the root could thus be written as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 require 'sinatra'\line
\line
get '/' do\line
   "Hello World! Is it me you're looking for?"\line
end\par}
{\pard \ql \f0 \sa180 \li0 \fi0 To run this snippet, we can can simply save it to a local \u8217'.rb\u8217' file and execute it as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 ruby -rubygems example.rb\par}
{\pard \ql \f0 \sa180 \li0 \fi0 If we now navigated to http://localhost:4567 in our browser we could now see the application running successfully.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The HTTP verbs we commonly work with when writing RESTful web services are: {\f1 get}, {\f1 post}, {\f1 delete} and {\f1 put}. As we now know, all Sinatra routes are basically HTTP actions ({\f1 get} etc.) that are paired with a URL-matching pattern. We associate a pair of an action and route with code we would like sent back to the browser (executed)if the route is reached. Sinatra doesn\u8217't enforce much in the way of architectural structure, instead relying on simplicity to supporting writing powerful APIs.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Here\u8217's an example of a skeleton service we could put together supporting four common HTTP actions:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 get '/items' do\line
  # list all items available\line
end\line
\line
get '/item/:id' do\line
  # get a single item\line
end\line
\line
post '/item' do\line
  # create a new item\line
end\line
\line
put '/item/:id' do\line
  # update an existing item\line
end\line
\line
delete '/item/:id' do\line
  # delete an item\line
end\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Sinatra\u8217's routing is both easy for beginners to get started with but is also flexible enough for those wishing to define more complex routes. As you probably noticed in the above example, routes can include named parameters (e.g {\f1 /item/:id}). We can actually access the content of these routes using the {\f1 params} hash as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 get '/item/:id' do\line
  # this matches "GET /item/10" and "GET /item/11"\line
  # params[:id] is "10" or "11"\line
  "You reached #\{params[:id]\}"\line
end\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Sinatra also supports route matching via splats, wildcards and regular expressions. For more information on this I recommend reading the official {\field{\*\fldinst{HYPERLINK "http://www.sinatrarb.com/documentation"}}{\fldrslt{\ul
docs
}}}
. Let\u8217's now take a look at handlers.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Sinatra includes convenient handler methods for tasks such as redirection, halting and passing.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Redirection\par}
{\pard \ql \f0 \sa180 \li0 \fi0 A simple route supporting redirection which returns a 302 response can be written as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 get '/items' do\line
      redirect '/items/welcome'\line
end\par}
{\pard \ql \f0 \sa180 \li0 \fi0 And if we wish to pass additional parameters such as arguments we can do so like this: redirect \u8216'http://site.com/\u8217', \u8216'Oops! I think we have a problem!\u8217'\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Halting\par}
{\pard \ql \f0 \sa180 \li0 \fi0 To immediately stop a request (halting) we can use \u8216'halt\u8217'. Heres an example of halting a request where we specify the message body:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 halt "who goes there!?"}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Passing\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \u8216'Passing\u8217' is the concept of deferring processing of a block to the next matching route. We do this using {\f1 pass}. In the following example if a parameter isnt the username we expect (rick-astley) we simply pass it on:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 get '/members/:username' do\line
 pass unless params[:username] == 'rick-astley'\line
 'Never gonna give you up, never gonna let you down'\line
end\line
\line
get '/members/*' do\line
 'Welcome!'\line
end\par}
{\pard \ql \f0 \sa180 \li0 \fi0 There are also handler methods that can assist with sessions (specifically, cookie-based session handling). To use Sinatra\u8217's session handling, first enable it in your application with:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 enable :sessions\par}
{\pard \ql \f0 \sa180 \li0 \fi0 You can then use the session handling capabilities as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 get '/items' do\line
  session['visitCounter'] ||= 0;\line
  session['visitCounter'] += 1;\line
  "This page has been accessed #\{session['visitCounter']\} times"\line
end\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Note: By default enable:sessions will store all data in cookies. If this is not desired, you can not call this and instead use some Rack middleware instead. For more on this see {\field{\*\fldinst{HYPERLINK "http://www.sinatrarb.com/intro#Using%20Sessions"}}{\fldrslt{\ul
here
}}}
.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This only touches the surface of what can be done using routes and handlers, but is sufficient for us to write the Sinatra-powered API service we require in the practical section of this chapter.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Templating And HAML\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Let\u8217's now discuss templating.Out of the box, we can begin using templates in our Sinatra applications with ERB. ERB is included with Ruby and allows Ruby code to be added to any plain text document for the purpose of generating information or flow control. In the following example using an ERB template, note that views are by default located in the {\f1 views} directory of our application.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 get '/items' do\line
  erb :default\line
  # renders views/default.erb\line
end\par}
{\pard \ql \f0 \sa180 \li0 \fi0 A useful Sinatra convention worth noting is how layouts are handled. Layouts automatically search for a views/layout template which is rendered before any other views are loaded. With ERB, our views/layout.erb file could look as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 <html>\line
  <head></head>\line
  <body>\line
    <%= data %>\line
  </body>\line
</html>\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Haml is a popular alternative to ERB which offers an abstract syntax for writing application templates. It has been said to be:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Straight-forward to learn\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Very easy to read and use for visually expressing a hierarchy of DOM elements\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Popular with web designers as it builds on top of CSS syntax\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Well documented with a large community backing it\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Almost as fast as ERB\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For the purpose of comparison, below we can see an ERB template compared to its Haml equivalent.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 ERB\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 <div class="todo" id="content">\line
  <h2 class="entry_title"><%= h @todo.title %></h2>\line
  <div class="entry_link"><%= link_to('link', @todo.link) %></div>\line
</div>\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Haml\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 .todo#content\line
  %h2.entry_title= @todo.title\line
  .entry_link= link_to('link', @todo.link)\par}
{\pard \ql \f0 \sa180 \li0 \fi0 One of the first things we notice is that the Haml snippet looks significantly more like CSS than it does traditional markup. It\u8217's much easier to read and we no longer need to be concerned with divs, spans, closing tags or other semantic rules that usually mean more keystrokes. The approach taken to making whitespace a part of the syntax also means it can be much easier to compare changes between multiple documents (especially if you\u8217're doing a diff).\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In the list of Haml features, we briefly mentioned web designers. As developers, we regularly need to communicate and work with designers, but we always have to remember that at the end of the day, they are not programmers. They\u8217're usually more concerned with the look and the feel of an application, but if we want them to write mark-up as a part of the templates or skins they create, Haml is a simpler option that has worked well for teams at a number of companies.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 %h1 This is some h1 text\line
%h2 This is some h2 text.\line
\line
%p Now we have a line containing a single instance variable: @content\line
%p= @content\line
\line
%p Embedding Ruby code in the middle of a line can be done using ==.\line
%p== Here is an example: #\{@foobar\}\line
\line
%p We can also add attributes using \{\}\line
%p\{:style => "color:green"\} We just made this paragraph green!\line
\line
%p You'll want to apply classes and ids to your DOM, too.\line
%p.foo This has the foo class\line
%p.bar This has the bar class\line
%p#foobar This has the foobar id\line
%p.foo#foobar Or you can combine them!\line
\line
%p Nesting can be done like this\line
%p\line
  Or even like this\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Note: Haml is whitespace sensitive and will not correctly work if it isn\u8217't indented by an even number of spaces. This is due to whitespace being used for nesting in place of the classic HTML markup approach of closing tags.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs36 MongoDB Ruby Driver\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Getting started\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Once the MongoDB Ruby driver is installed, we can begin to use it to connect to a Mongo database. To create a connection using localhost, we simply specify the driver as a dependency. Assuming we\u8217're using the default port we can then connect as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 require 'mongo'\line
\line
# where 'learning-mongo' is the name of our database:\line
db = Connection.new.db('learning-mongo');\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We probably also want to place some data into \u8216'learning-mongo\u8217'. It could be as simple as a note, so why don\u8217't we go ahead and begin a notes collection?:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 ruby notes = db.collection('notes')} Something interesting worth noting is that at this point, we haven\u8217't actually created the database nor the collection we\u8217're referencing above.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Neither of these items exist in Mongo (just yet) but as we\u8217're working with a new database but they will once we insert some real data.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 A new note could be defined using key/value pairs as follows and then inserted into \u8216'learning-mongo\u8217' using {\f1 collection.insert()}:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 our_note = \{ :text => 'Remember the milk', :remindInterval => 'weekly'\}\line
note_id = notes.insert(our_note)\par}
{\pard \ql \f0 \sa180 \li0 \fi0 What is returned from inserting a note into the notes collection is an {\f1 ObjectId} reference for the note from Mongo. This is useful as we can re-use it to locate the same document in our database.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 note = notes.find( :id => note_id ).first\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This can also be used in conjunction with Mongo\u8217's {\f1 collection.update()} method and {\field{\*\fldinst{HYPERLINK "http://www.mongodb.org/display/DOCS/Updating"}}{\fldrslt{\ul
query
}}}
 operators (i.e {\f1 $set}) to replace fields in an existing document.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We might update an entire document as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 note = notes.find( :id => note_id ).first\line
note[:text] = 'Remember the bread'\line
notes.update(\{ :_id => note_id \}, note)\par}
{\pard \ql \f0 \sa180 \li0 \fi0 or using {\f1 $set}, update an existing document without overwriting the entire object as like this:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 notes.update(\{ :_id => note_id \}, '$set' => \{ :text = > 'Remember the bread' \})\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Useful to know: Almost each MongoDB document has an _id field as its first attribute. This can normally be of any type, however a special BSON datatype is provided for object ids. It\u8217's a 12-byte binary value that has a high probability of being unique when allocated.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Note: Whilst we opted for the MongoDB Ruby Driver for this stack, you may also be interested in {\b DataMapper} - a solution which allows us to use the same API to talk to a number of different datastores. This works well for both relational and non-relational databases and more information is available on the official {\field{\*\fldinst{HYPERLINK "http://datamapper.org/why.html"}}{\fldrslt{\ul
project page
}}}
. {\field{\*\fldinst{HYPERLINK "http://sinatra-book.gittr.com/#datamapper"}}{\fldrslt{\ul
Sinatra: The Book
}}}
 also contains a brief tutorial on DataMapper for anyone interested in exploring it further.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs36 Practical\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We\u8217're going to use Sinatra in a similar manner to how we used Express in the last chapter. It will power a RESTful API supporting CRUD operations. Together with a MongoDB data store, this will allow us to easily persist data (todo items) whilst ensuring they are stored in a database. If you\u8217've read the previous chapter or have gone through any of the Todo examples covered so far, you will find this surprisingly straight-forward.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Remember that the default Todo example included with Backbone.js already persists data, although it does this via a localStorage adapter. Luckily there aren\u8217't a great deal of changes needed to switch over to using our Sinatra-based API. Let\u8217's briefly review the code that will be powering the CRUD operations for this sections practical, as we won\u8217't be starting off with a near-complete base for most of our real world applications.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Installing The Prerequisites\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Ruby\par}
{\pard \ql \f0 \sa180 \li0 \fi0 If using OSX or Linux, Ruby may be one of a number of open-source packages that come pre-installed and you can skip over to the next paragraph. In case you would like to check if check if you have Ruby installed, open up the terminal prompt and type:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 $ ruby -v}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The output of this will either be the version of Ruby installed or an error complaining that Ruby wasn\u8217't found.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Should you need to install Ruby manually (e.g for an operating system such as Windows), you can do so by downloading the latest version from http://www.ruby-lang.org/en/downloads/. Alternatively, {\field{\*\fldinst{HYPERLINK "http://beginrescueend.com/rvm/install/"}}{\fldrslt{\ul
RVM
}}}
 (Ruby Version Manager) is a command-line tool that allows you to easily install and manage multiple ruby environments with ease.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Ruby Gems\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Next, we will need to install Ruby Gems. Gems are a standard way to package programs or libraries written in Ruby and with Ruby Gems it\u8217's possible to install additional dependencies for Ruby applications very easily.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 On OSX, Linux or Windows go to {\field{\*\fldinst{HYPERLINK "http://rubyforge.org/projects/rubygems"}}{\fldrslt{\ul
http://rubyforge.org/projects/rubygems
}}}
 and download the latest version of Ruby Gems. Once downloaded, open up a terminal, navigate to the folder where this resides and enter:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 $> tar xzvf rubygems.tgz\line
$> cd rubygems\line
$> sudo ruby setup.rb\par}
{\pard \ql \f0 \sa180 \li0 \fi0 There will likely be a version number included in your download and you should make sure to include this when tying the above. Finally, a symlink (symbolic link) to tie everything togther should be run as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 $ sudo ln -s /usr/bin/gem1.8.17 /usr/bin/gem}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 To check that Ruby Gems has been correctly installed, type the following into your terminal:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 $ gem -v\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Sinatra\par}
{\pard \ql \f0 \sa180 \li0 \fi0 With Ruby Gems setup, we can now easily install Sinatra. For Linux or OSX type this in your terminal:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 $ sudo gem install sinatra}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 and if you\u8217're on Windows, enter the following at a command prompt:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 c:\\> gem install sinatra}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Haml\par}
{\pard \ql \f0 \sa180 \li0 \fi0 As with other DSLs and frameworks, Sinatra supports a wide range of different templating engines. {\field{\*\fldinst{HYPERLINK "http://www.ruby-doc.org/stdlib/libdoc/erb/rdoc/classes/ERB.html"}}{\fldrslt{\ul
ERB
}}}
 is the one most often recommended by the Sinatra camp, however as a part of this chapter, we\u8217're going to explore the use of {\field{\*\fldinst{HYPERLINK "http://haml.hamptoncatlin.com/"}}{\fldrslt{\ul
Haml
}}}
 to define our application templates.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Haml stands for HTML Abstractional Markup Language and is a lightweight markup language abstraction that can be used to describe HTML without the need to use traditional markup language semantics (such as opening and closing tags).\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Installing Haml can be done in just a line using Ruby Gems as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 $ gem install haml}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 MongoDB\par}
{\pard \ql \f0 \sa180 \li0 \fi0 If you haven\u8217't already downloaded and installed MongoDB from an earlier chapter, please {\field{\*\fldinst{HYPERLINK "http://www.mongodb.org/downloads"}}{\fldrslt{\ul
do so
}}}
 now. With Ruby Gems, Mongo can be installed in just one line:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 $ gem install mongodb}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We now require two further steps to get everything up and running.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs20 1.Data directories\par}
{\pard \ql \f0 \sa180 \li0 \fi0 MongoDB stores data in the bin/data/db folder but won\u8217't actually create this directory for you. Navigate to where you\u8217've downloaded and extracted Mongo and run the following from terminal:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 sudo mkdir -p /data/db/\line
sudo chown `id -u` /data/db\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs20 2.Running and connecting to your server\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Once this is done, open up two terminal windows.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In the first, cd to your MongoDB bin directory or type in the complete path to it. You\u8217'll need to start mongod.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 $ ./bin/mongod\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Finally, in the second terminal, start the mongo shell which will connect up to localhost by default.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 $ ./bin/mongo\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 MongoDB Ruby Driver\par}
{\pard \ql \f0 \sa180 \li0 \fi0 As we\u8217'll be using the {\field{\*\fldinst{HYPERLINK "https://github.com/mongodb/mongo-ruby-driver"}}{\fldrslt{\ul
MongoDB Ruby Driver
}}}
, we\u8217'll also require the following gems:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The gem for the driver itself:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 $ gem install mongo\par}
{\pard \ql \f0 \sa180 \li0 \fi0 and the driver\u8217's other prerequisite, bson:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 $ gem install bson_ext\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This is basically a collection of extensions used to increase serialization speed.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 That\u8217's it for our prerequisites!.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Tutorial\par}
{\pard \ql \f0 \sa180 \li0 \fi0 To get started, let\u8217's get a local copy of the practical application working on our system.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Application Files\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Clone {\field{\*\fldinst{HYPERLINK "http://github.com/addyosmani/backbone-fundamentals"}}{\fldrslt{\ul
this
}}}
 repository and navigate to {\f1 /practicals/stacks/option3}. Now run the following lines at the terminal:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 ruby app.rb\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Finally, navigate to http://localhost:4567/todo to see the application running successfully.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Note:} The Haml layout files for Option 3 can be found in the /views folder.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The directory structure for our practical application is as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 --public\line
----css\line
----img\line
----js\line
-----script.js\line
----test\line
--views\line
app.rb\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The {\f1 public} directory contains the scripts and stylesheets for our application and uses HTML5 Boilerplate as a base. You can find the Models, Views and Collections for this section within {\f1 public/js/scripts.js} (however, this can of course be expanded into sub-directories for each component if desired).\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 scripts.js} contains the following Backbone component definitions:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 --Models\line
----Todo\line
\line
--Collections\line
----TodoList\line
\line
--Views\line
---TodoView\line
---AppView\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 app.rb} is the small Sinatra application that powers our backend API.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Lastly, the {\f1 views} directory hosts the Haml source files for our application\u8217's index and templates, both of which are compiled to standard HTML markup at runtime.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 These can be viewed along with other note-worthy snippets of code from the application below.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Backbone\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Views\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In our main application view (AppView), we want to load any previously stored Todo items in our Mongo database when the view initializes. This is done below with the line {\f1 Todos.fetch()} in the {\f1 initialize()} method where we also bind to the relevant events on the {\f1 Todos} collection for when items are added or changed.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 // Our overall **AppView** is the top-level piece of UI.\line
var AppView = Backbone.View.extend(\{\line
\line
    // Instead of generating a new element, bind to the existing skeleton of\line
    // the App already present in the HTML.\line
    el: $("#todoapp"),\line
\line
    // Our template for the line of statistics at the bottom of the app.\line
    statsTemplate: _.template($('#stats-template').html()),\line
\line
    // Delegated events for creating new items, and clearing completed ones.\line
    events: \{\line
      "keypress #new-todo":  "createOnEnter",\line
      "keyup #new-todo":     "showTooltip",\line
      "click .todo-clear a": "clearCompleted"\line
    \},\line
\line
    // At initialization\line
    initialize: function() \{\line
      this.input    = this.$("#new-todo");\line
\line
      Todos.on('add',   this.addOne, this);\line
      Todos.on('reset', this.addAll, this);\line
      Todos.on('all',   this.render, this);\line
\line
      Todos.fetch();\line
    \},\line
\line
    // Re-rendering the App just means refreshing the statistics -- the rest\line
    // of the app doesn't change.\line
    render: function() \{\line
      this.$('#todo-stats').html(this.statsTemplate(\{\line
        total:      Todos.length,\line
        done:\line
 \u8230?.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Collections\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In the TodoList collection below, we\u8217've set the {\f1 url} property to point to {\f1 /api/todos} to reference the collection\u8217's location on the server. When we attempt to access this from our Sinatra-backed API, it should return a list of all the Todo items that have been previously stored in Mongo.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For the sake of thoroughness, our API will also support returning the data for a specific Todo item via {\f1 /api/todos/itemID}. We\u8217'll take a look at this again when writing the Ruby code powering our backend.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1  // Todo Collection\line
\line
  var TodoList = Backbone.Collection.extend(\{\line
\line
    // Reference to this collection's model.\line
    model: Todo,\line
\line
    // Save all of the todo items under the `"todos"` namespace.\line
    // localStorage: new Store("todos"),\line
    url: '/api/todos',\line
\line
    // Filter down the list of all todo items that are finished.\line
    done: function() \{\line
      return this.filter(function(todo)\{ return todo.get('done'); \});\line
    \},\line
\line
    // Filter down the list to only todo items that are still not finished.\line
    remaining: function() \{\line
      return this.without.apply(this, this.done());\line
    \},\line
\line
    // We keep the Todos in sequential order, despite being saved by unordered\line
    // GUID in the database. This generates the next order number for new items.\line
    nextOrder: function() \{\line
      if (!this.length) return 1;\line
      return this.last().get('order') + 1;\line
    \},\line
\line
    // Todos are sorted by their original insertion order.\line
    comparator: function(todo) \{\line
      return todo.get('order');\line
    \}\line
\line
  \});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Model\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The model for our Todo application remains largely unchanged from the versions previously covered in this book. It is however worth noting that calling the function {\f1 model.url()} within the below would return the relative URL where a specific Todo item could be located on the server.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 \line
  // Our basic **Todo** model has `text`, `order`, and `done` attributes.\line
  var Todo = Backbone.Model.extend(\{\line
    idAttribute: "_id",\line
\line
    // Default attributes for a todo item.\line
    defaults: function() \{\line
      return \{\line
        done:  false,\line
        order: Todos.nextOrder()\line
      \};\line
    \},\line
\line
    // Toggle the `done` state of this todo item.\line
    toggle: function() \{\line
      this.save(\{done: !this.get("done")\});\line
    \}\line
  \});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Ruby/Sinatra\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Now that we\u8217've defined our main models, views and collections let\u8217's get the CRUD operations required by our Backbone application supported in our Sinatra API.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We want to make sure that for any operations changing underlying data (create, update, delete) that our Mongo data store correctly reflects these.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 app.rb\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For {\f1 app.rb}, we first define the dependencies required by our application. These include Sinatra, Ruby Gems, the MongoDB Ruby driver and the JSON gem.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 require 'rubygems'\line
require 'sinatra'\line
require 'mongo'\line
require 'json'\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Next, we create a new connection to Mongo, specifying any custom configuration desired. If running a multi-threaded application, setting the \u8216'pool_size\u8217' allows us to specify a maximum pool size and \u8216'timeout\u8217' a maximum timeout for waiting for old connections to be released to the pool.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 DB = Mongo::Connection.new.db("mydb", :pool_size => 5, :timeout => 5)\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Finally we define the routes to be supported by our API. Note that in the first two blocks - one for our application root ({\f1 /}) and the other for our todo items route {\f1 /todo} - we\u8217're using Haml for template rendering.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 class TodoApp < Sinatra::Base\line
\line
    get '/' do\line
      haml :index, :attr_wrapper => '"', :locals => \{:title => 'hello'\}\line
    end\line
\line
    get '/todo' do\line
      haml :todo, :attr_wrapper => '"', :locals => \{:title => 'Our Sinatra Todo app'\}\line
    end\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 haml :index} instructs Sinatra to use the {\f1 views/index.haml} for the application index, whilst {\f1 attr_wrapper} is simply defining the values to be used for any local variables defined inside the template. This similarly applies Todo items with the template `views/todo.haml\u8217'.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The rest of our routes make use of the {\f1 params} hash and a number of useful helper methods included with the MongoDB Ruby driver. For more details on these, please read the comments I\u8217've made inline below:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 get '/api/:thing' do\line
  # query a collection :thing, convert the output to an array, map the _id\line
  # to a string representation of the object's _id and finally output to JSON\line
  DB.collection(params[:thing]).find.to_a.map\{|t| from_bson_id(t)\}.to_json\line
end\line
\line
get '/api/:thing/:id' do\line
  # get the first document with the id :id in the collection :thing as a single document (rather\line
  # than a Cursor, the standard output) using find_one(). Our bson utilities assist with\line
  # ID conversion and the final output returned is also JSON\line
  from_bson_id(DB.collection(params[:thing]).find_one(to_bson_id(params[:id]))).to_json\line
end\line
\line
post '/api/:thing' do\line
  # parse the post body of the content being posted, convert to a string, insert into\line
  # the collection #thing and return the ObjectId as a string for reference\line
  oid = DB.collection(params[:thing]).insert(JSON.parse(request.body.read.to_s))\line
  "\{\\"_id\\": \\"#\{oid.to_s\}\\"\}"\line
end\line
\line
delete '/api/:thing/:id' do\line
  # remove the item with id :id from the collection :thing, based on the bson\line
  # representation of the object id\line
  DB.collection(params[:thing]).remove('_id' => to_bson_id(params[:id]))\line
end\line
\line
put '/api/:thing/:id' do\line
  # collection.update() when used with $set (as covered earlier) allows us to set single values\line
  # in this case, the put request body is converted to a string, rejecting keys with the name '_id' for security purposes\line
  DB.collection(params[:thing]).update(\{'_id' => to_bson_id(params[:id])\}, \{'$set' => JSON.parse(request.body.read.to_s).reject\{|k,v| k == '_id'\}\})\line
end\line
\line
# utilities for generating/converting MongoDB ObjectIds\line
def to_bson_id(id) BSON::ObjectId.from_string(id) end\line
def from_bson_id(obj) obj.merge(\{'_id' => obj['_id'].to_s\}) end\line
\line
end\par}
{\pard \ql \f0 \sa180 \li0 \fi0 That\u8217's it. The above is extremely lean for an entire API, but does allow us to read and write data to support the functionality required by our client-side application.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For more on what MongoDB and the MongoDB Ruby driver are capable of, please do feel free to read their documentation for more information.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 If you\u8217're a developer wishing to take this example further, why not try to add some additional capabilities to the service:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Validation: improved validation of data in the API. What more could be done to ensure data sanitization?\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Search: search or filter down Todo items based on a set of keywords or within a certain date range\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Pagination: only return the Nth number of Todo items or items from a start and end-point\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Haml/Templates\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Finally, we move on to the Haml files that define our application index (layout.haml) and the template for a specific Todo item (todo.haml). Both of these are largely self-explanatory, but it\u8217's useful to see the differences between the Jade approach we reviewed in the last chapter vs.\u160?using Haml for this implementation.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Note: In our Haml snippets below, the forward slash character is used to indicate a comment. When this character is placed at the beginning of a line, it wraps all of the text after it into a HTML comment. e.g\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 / These are templates}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 compiles to:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 <!-- These are templates -->}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 index.haml\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 %head\line
  %meta\{'charset' => 'utf-8'\}/\line
  %title=title\line
  %meta\{'name' => 'description', 'content' => ''\}/\line
  %meta\{'name' => 'author', 'content' => ''\}/\line
  %meta\{'name' => 'viewport', 'content' => 'width=device-width,initial-scale=1'\}/\line
\line
  / CSS concatenated and minified via ant build script\line
  %link\{'rel' => 'stylesheet', 'href' => 'css/style.css'\}/\line
  / end CSS\line
\line
  %script\{'src' => 'js/libs/modernizr.min.js'\}\line
%body\line
  %div#container\line
    %header\line
    %div#main\line
      = yield\line
    %footer\line
  /! end of #container\line
\line
  %script\{'src' => 'http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js'\}\line
\line
  / scripts concatenated and minified via ant build script\line
  %script\{'src' => 'js/mylibs/underscore.js'\}\line
  %script\{'src' => 'js/mylibs/backbone.js'\}\line
  %script\{'defer' => true, 'src' => 'js/plugins.js'\}\line
  %script\{'defer' => true, 'src' => 'js/script.js'\}\line
  / end scripts\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 todo.haml\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 %div#todoapp\line
  %div.title\line
    %h1\line
      Todos\line
      %div.content\line
        %div#create-todo\line
          %input#new-todo\{"placeholder" => "What needs to be done?", "type" => "text"\}/\line
          %span.ui-tooltip-top\{"style" => "display:none;"\} Press Enter to save this task\line
        %div#todos\line
          %ul#todo-list\line
        %div#todo-stats\line
\line
/ Templates\line
\line
%script#item-template\{"type" => "text/template"\}\line
  <div class="todo <%= done ? 'done' : '' %>">\line
  %div.display\line
    <input class="check" type="checkbox" <%= done ? 'checked="checked"' : '' %> />\line
    %div.todo-text\line
    %span#todo-destroy\line
  %div.edit\line
    %input.todo-input\{"type" => "text", "value" =>""\}/\line
  </div>\line
\line
%script#stats-template\{"type" => "text/template"\}\line
  <% if (total) \{ %>\line
  %span.todo-count\line
    %span.number <%= remaining %>\line
    %span.word <%= remaining == 1 ? 'item' : 'items' %>\line
    left.\line
  <% \} %>\line
  <% if (done) \{ %>\line
  %span.todo-clear\line
    %a\{"href" => "#"\}\line
      Clear\line
      %span.number-done <%= done %>\line
      completed\line
      %span.word-done <%= done == 1 ? 'item' : 'items' %>\line
  <% \} %>\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Conclusions\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In this chapter, we looked at creating a Backbone application backed by an API powered by Ruby, Sinatra, Haml, MongoDB and the MongoDB driver. I personally found developing APIs with Sinatra a relatively painless experience and one which I felt was on-par with the effort required for the Node/Express implementation of the same application.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This section is by no means the most comprehensive guide on building complex apps using all of the items in this particular stack. I do however hope it was an introduction sufficient enough to help you decide on what stack to try out for your next project.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs36 Modular Development\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Introduction\par}
{\pard \ql \f0 \sa180 \li0 \fi0 When we say an application is modular, we generally mean it\u8217's composed of a set of highly decoupled, distinct pieces of functionality stored in modules. As you probably know, loose coupling facilitates easier maintainability of apps by removing dependencies where possible. When this is implemented efficiently, its quite easy to see how changes to one part of a system may affect another.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Unlike some more traditional programming languages however, the current iteration of JavaScript (ECMA-262) doesn\u8217't provide developers with the means to import such modules of code in a clean, organized manner. It\u8217's one of the concerns with specifications that haven\u8217't required great thought until more recent years where the need for more organized JavaScript applications became apparent.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Instead, developers at present are left to fall back on variations of the module or object literal patterns. With many of these, module scripts are strung together in the DOM with namespaces being described by a single global object where it\u8217's still possible to incur naming collisions in your architecture. There\u8217's also no clean way to handle dependency management without some manual effort or third party tools.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Whilst native solutions to these problems will be arriving in ES Harmony, the good news is that writing modular JavaScript has never been easier and you can start doing it today.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In this next part of the book, we\u8217're going to look at how to use AMD modules and Require.js for cleanly wrapping units of code in your application into manageable modules.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Organizing modules with Require.js and AMD\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In case you haven\u8217't used it before, {\field{\*\fldinst{HYPERLINK "http://requirejs.org"}}{\fldrslt{\ul
Require.js
}}}
 is a popular script loader written by James Burke - a developer who has been quite instrumental in helping shape the AMD module format, which we\u8217'll discuss more shortly. Some of Require.js\u8217's capabilities include helping to load multiple script files, helping define modules with or without dependencies and loading in non-script dependencies such as text files.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 So, why use Require.js with Backbone? Although Backbone is excellent when it comes to providing a sanitary structure to your applications, there are a few key areas where some additional help could be used:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 1)\tx360\tab Backbone doesn\u8217't endorse a particular approach to modular-development. Although this means it\u8217's quite open-ended for developers to opt for classical patterns like the module-pattern or Object Literals for structuring their apps (which both work fine), it also means developers aren\u8217't sure of what works best when other concerns come into play, such as dependency management.\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Require.js is compatible with the AMD (Asynchronous Module Definition) format, a format which was born from a desire to write something better than the \u8216'write lots of script tags with implicit dependencies and manage them manually\u8217' approach to development. In addition to allowing you to clearly declare dependencies, AMD works well in the browser, supports string IDs for dependencies, declaring multiple modules in the same file and gives you easy-to-use tools to avoid polluting the global namespace.\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 2)\tx360\tab Let\u8217's discuss dependency management a little more as it can actually be quite challenging to get right if you\u8217're doing it by hand. When we write modules in JavaScript, we ideally want to be able to handle the reuse of code units intelligently and sometimes this will mean pulling in other modules at run-time whilst at other times you may want to do this dynamically to avoid a large pay-load when the user first hits your application.\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Think about the GMail web-client for a moment. When users initially load up the page on their first visit, Google can simply hide widgets such as the chat module until a user has indicated (by clicking \u8216'expand\u8217') that they wish to use it. Through dynamic dependency loading, Google could load up the chat module only then, rather than forcing all users to load it when the page first initializes. This can improve performance and load times and can definitely prove useful when building larger applications.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 I\u8217've previously written {\field{\*\fldinst{HYPERLINK "http://addyosmani.com/writing-modular-js"}}{\fldrslt{\ul
a detailed article
}}}
 covering both AMD and other module formats and script loaders in case you\u8217'd like to explore this topic further. The takeaway is that although it\u8217's perfectly fine to develop applications without a script loader or clean module format in place, it can be of significant benefit to consider using these tools in your application development.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Writing AMD modules with Require.js\par}
{\pard \ql \f0 \sa180 \li0 \fi0 As discussed above, the overall goal for the AMD format is to provide a solution for modular JavaScript that developers can use today. The two key concepts you need to be aware of when using it with a script-loader are a {\f1 define()} method for facilitating module definition and a {\f1 require()} method for handling dependency loading. {\f1 define()} is used to define named or unnamed modules based on the proposal using the following signature:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 define(\line
    module_id /*optional*/,\line
    [dependencies] /*optional*/,\line
    definition function /*function for instantiating the module or object*/\line
);\par}
{\pard \ql \f0 \sa180 \li0 \fi0 As you can tell by the inline comments, the {\f1 module_id} is an optional argument which is typically only required when non-AMD concatenation tools are being used (there may be some other edge cases where it\u8217's useful too). When this argument is left out, we call the module \u8216'anonymous\u8217'. When working with anonymous modules, the idea of a module\u8217's identity is DRY, making it trivial to avoid duplication of filenames and code.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Back to the define signature, the dependencies argument represents an array of dependencies which are required by the module you are defining and the third argument (\u8216'definition function\u8217') is a function that\u8217's executed to instantiate your module. A barebone module (compatible with Require.js) could be defined using {\f1 define()} as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 // A module ID has been omitted here to make the module anonymous\line
\line
define(['foo', 'bar'],\line
    // module definition function\line
    // dependencies (foo and bar) are mapped to function parameters\line
    function ( foo, bar ) \{\line
        // return a value that defines the module export\line
        // (i.e the functionality we want to expose for consumption)\line
\line
        // create your module here\line
        var myModule = \{\line
            doStuff:function()\{\line
                console.log('Yay! Stuff');\line
            \}\line
        \}\line
\line
        return myModule;\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Alternate syntax\par}
{\pard \ql \f0 \sa180 \li0 \fi0 There is also a {\field{\*\fldinst{HYPERLINK "http://requirejs.org/docs/whyamd.html#sugar"}}{\fldrslt{\ul
sugared version
}}}
 of {\f1 define()} available that allows you to declare your dependencies as local variables using {\f1 require()}. This will feel familiar to anyone who\u8217's used node, and can be easier to add or remove dependencies. Here is the previous snippet using the alternate syntax:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 // A module ID has been omitted here to make the module anonymous\line
\line
define(function(require)\{\line
        // module definition function\line
    // dependencies (foo and bar) are defined as local vars\line
    var foo = require('foo'),\line
        bar = require('bar');\line
\line
        // return a value that defines the module export\line
        // (i.e the functionality we want to expose for consumption)\line
\line
        // create your module here\line
        var myModule = \{\line
            doStuff:function()\{\line
                console.log('Yay! Stuff');\line
            \}\line
        \}\line
\line
        return myModule;\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The {\f1 require()} method is typically used to load code in a top-level JavaScript file or within a module should you wish to dynamically fetch dependencies. An example of its usage is:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 // Consider 'foo' and 'bar' are two external modules\line
// In this example, the 'exports' from the two modules loaded are passed as\line
// function arguments to the callback (foo and bar)\line
// so that they can similarly be accessed\line
\line
require(['foo', 'bar'], function ( foo, bar ) \{\line
        // rest of your code here\line
        foo.doSomething();\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Wrapping modules, views and other components with AMD}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Now that we\u8217've taken a look at how to define AMD modules, let\u8217's review how to go about wrapping components like views and collections so that they can also be easily loaded as dependencies for any parts of your application that require them. At it\u8217's simplest, a Backbone model may just require Backbone and Underscore.js. These are considered its dependencies and so, to write an AMD model module, we would simply do this:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 define(['underscore', 'backbone'], function(_, Backbone) \{\line
  var myModel = Backbone.Model.extend(\{\line
\line
    // Default attributes\line
    defaults: \{\line
      content: "hello world",\line
    \},\line
\line
    // A dummy initialization method\line
    initialize: function() \{\line
    \},\line
\line
    clear: function() \{\line
      this.destroy();\line
      this.view.remove();\line
    \}\line
\line
  \});\line
  return myModel;\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Note how we alias Underscore.js\u8217's instance to {\f1 _} and Backbone to just {\f1 Backbone}, making it very trivial to convert non-AMD code over to using this module format. For a view which might require other dependencies such as jQuery, this can similarly be done as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 define([\line
  'jquery',\line
  'underscore',\line
  'backbone',\line
  'collections/mycollection',\line
  'views/myview'\line
  ], function($, _, Backbone, myCollection, myView)\{\line
\line
  var AppView = Backbone.View.extend(\{\line
  ...\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Aliasing to the dollar-sign ({\f1 $}), once again makes it very easy to encapsulate any part of an application you wish using AMD.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Keeping Your Templates External Using Require.js And The Text Plugin\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Moving your [Underscore/Mustache/Handlebars] templates to external files is actually quite straight-forward. As this application makes use of Require.js, I\u8217'll discuss how to implement external templates using this specific script loader.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Require.js has a special plugin called text.js which is used to load in text file dependencies. To use the text plugin, simply follow these simple steps:\par}
{\pard \ql \f0 \sa180 \li360 \fi-360 1.\tx360\tab Download the plugin from http://requirejs.org/docs/download.html#text and place it in either the same directory as your application\u8217's main JS file or a suitable sub-directory.\par}
{\pard \ql \f0 \sa180 \li360 \fi-360 2.\tx360\tab Next, include the text.js plugin in your initial Require.js configuration options. In the code snippet below, we assume that Require.js is being included in our page prior to this code snippet being executed. Any of the other scripts being loaded are just there for the sake of example.\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 require.config( \{\line
    paths: \{\line
        'backbone':         'libs/AMDbackbone-0.5.3',\line
        'underscore':       'libs/underscore-1.2.2',\line
        'text':             'libs/require/text',\line
        'jquery':           'libs/jQuery-1.7.1',\line
        'json2':            'libs/json2',\line
        'datepicker':       'libs/jQuery.ui.datepicker',\line
        'datepickermobile': 'libs/jquery.ui.datepicker.mobile',\line
        'jquerymobile':     'libs/jquery.mobile-1.0'\line
    \},\line
    baseUrl: 'app'\line
\} );\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 3.\tx360\tab When the {\f1 text!} prefix is used for a dependency, Require.js will automatically load the text plugin and treat the dependency as a text resource. A typical example of this in action may look like..\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 require(['js/app', 'text!templates/mainView.html'],\line
    function(app, mainView)\{\line
        // the contents of the mainView file will be\line
        // loaded into mainView for usage.\line
    \}\line
);\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 4.\tx360\tab Finally we can use the text resource that\u8217's been loaded for templating purposes. You\u8217're probably used to storing your HTML templates inline using a script with a specific identifier.\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 With Underscore.js\u8217's micro-templating (and jQuery) this would typically be:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 HTML:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 <script type="text/template" id="mainViewTemplate">\line
    <% _.each( person, function( person_item )\{ %>\line
        <li><%= person_item.get("name") %></li>\line
    <% \}); %>\line
</script>\par}
{\pard \ql \f0 \sa180 \li0 \fi0 JS:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var compiled_template = _.template( $('#mainViewTemplate').html() );\par}
{\pard \ql \f0 \sa180 \li0 \fi0 With Require.js and the text plugin however, it\u8217's as simple as saving your template into an external text file (say, {\f1 mainView.html}) and doing the following:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 require(['js/app', 'text!templates/mainView.html'],\line
    function(app, mainView)\{\line
\line
        var compiled_template = _.template( mainView );\line
    \}\line
);\par}
{\pard \ql \f0 \sa180 \li0 \fi0 That\u8217's it! Now you can apply your template to a view in Backbone with something like:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 collection.someview.$el.html( compiled_template( \{ results: collection.models \} ) );\par}
{\pard \ql \f0 \sa180 \li0 \fi0 All templating solutions will have their own custom methods for handling template compilation, but if you understand the above, substituting Underscore\u8217's micro-templating for any other solution should be fairly trivial.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Note:} You may also be interested in looking at {\field{\*\fldinst{HYPERLINK "https://github.com/ZeeAgency/requirejs-tpl"}}{\fldrslt{\ul
Require.js tpl
}}}
. It\u8217's an AMD-compatible version of the Underscore templating system that also includes support for optimization (pre-compiled templates) which can lead to better performance and no evals. I have yet to use it myself, but it comes as a recommended resource.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Optimizing Backbone apps for production with the Require.js Optimizer\par}
{\pard \ql \f0 \sa180 \li0 \fi0 As experienced developers may know, an essential final step when writing both small and large JavaScript web applications is the build process. The majority of non-trivial apps are likely to consist of more than one or two scripts and so optimizing, minimizing and concatenating your scripts prior to pushing them to production will require your users to download a reduced number (if not just one) script file.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Note: If you haven\u8217't looked at build processes before and this is your first time hearing about them, you might find {\field{\*\fldinst{HYPERLINK "http://addyosmani.com/blog/client-side-build-process/"}}{\fldrslt{\ul
my post and screencast on this topic
}}}
 useful.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 With some other structural JavaScript frameworks, my recommendation would normally be to implicitly use YUI Compressor or Google\u8217's closure compiler tools, but we have a slightly more elegant method available, when it comes to Backbone if you\u8217're using Require.js. Require.js has a command line optimization tool called r.js which has a number of capabilities, including:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Concatenating specific scripts and minifying them using external tools such as UglifyJS (which is used by default) or Google\u8217's Closure Compiler for optimal browser delivery, whilst preserving the ability to dynamically load modules\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Optimizing CSS and stylesheets by inlining CSS files imported using @import, stripping out comments etc.\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab The ability to run AMD projects in both Node and Rhino (more on this later)\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 You\u8217'll notice that I mentioned the word \u8216'specific\u8217' in the first bullet point. The Require.js optimizer only concatenates module scripts that have been specified in arrays of string literals passed to top-level (i.e non-local) require and define calls. As clarified by the {\field{\*\fldinst{HYPERLINK "http://requirejs.org/docs/optimization.html"}}{\fldrslt{\ul
optimizer docs
}}}
 this means that Backbone modules defined like this:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 define(['jquery','backbone','underscore', 'collections/sample','views/test'],\line
    function($,Backbone, _, Sample, Test)\{\line
        //...\line
    \});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 will combine fine, however inline dependencies such as:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var models = someCondition ? ['models/ab','models/ac'] : ['models/ba','models/bc'];\par}
{\pard \ql \f0 \sa180 \li0 \fi0 will be ignored. This is by design as it ensures that dynamic dependency/module loading can still take place even after optimization.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Although the Require.js optimizer works fine in both Node and Java environments, it\u8217's strongly recommended to run it under Node as it executes significantly faster there. In my experience, it\u8217's a piece of cake to get setup with either environment, so go for whichever you feel most comfortable with.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 To get started with r.js, grab it from the {\field{\*\fldinst{HYPERLINK "http://requirejs.org/docs/download.html#rjs"}}{\fldrslt{\ul
Require.js download page
}}}
 or {\field{\*\fldinst{HYPERLINK "http://requirejs.org/docs/optimization.html#download"}}{\fldrslt{\ul
through NPM
}}}
. Now, the Require.js optimizer works absolutely fine for single script and CSS files, but for most cases you\u8217'll want to actually optimize an entire Backbone project. You {\i could} do this completely from the command-line, but a cleaner option is using build profiles.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Below is an example of a build file taken from the modular jQuery Mobile app referenced later in this book. A {\b build profile} (commonly named {\f1 app.build.js}) informs Require.js to copy all of the content of {\f1 appDir} to a directory defined by {\f1 dir} (in this case {\f1 ../release}). This will apply all of the necessary optimizations inside the release folder. The {\f1 baseUrl} is used to resolve the paths for your modules. It should ideally be relative to {\f1 appDir}.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Near the bottom of this sample file, you\u8217'll see an array called {\f1 modules}. This is where you specify the module names you wish to have optimized. In this case we\u8217're optimizing the main application called \u8216'app\u8217', which maps to {\f1 appDir/app.js}. If we had set the {\f1 baseUrl} to \u8216'scripts\u8217', it would be mapped to {\f1 appDir/scripts/app.js}.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 (\{\line
    appDir: "./",\line
    baseUrl: "./",\line
    dir: "../release",\line
    paths: \{\line
       'backbone':          'libs/AMDbackbone-0.5.3',\line
        'underscore':       'libs/underscore-1.2.2',\line
        'jquery':           'libs/jQuery-1.7.1',\line
        'json2':            'libs/json2',\line
        'datepicker':       'libs/jQuery.ui.datepicker',\line
        'datepickermobile': 'libs/jquery.ui.datepicker.mobile',\line
        'jquerymobile':     'libs/jquery.mobile-1.0'\line
    \},\line
    optimize: "uglify",\line
    modules: [\line
        \{\line
            name: "app",\line
            exclude: [\line
                // If you prefer not to include certain libs exclude them here\line
            ]\line
        \}\line
    ]\line
\})\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The way the build system in r.js works is that it traverses app.js (whatever modules you\u8217've passed) and resolved dependencies, concatenating them into the final {\f1 release}(dir) folder. CSS is treated the same way.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The build profile is usually placed inside the \u8216'scripts\u8217' or \u8216'js\u8217' directory of your project. As per the docs, this file can however exist anywhere you wish, but you\u8217'll need to edit the contents of your build profile accordingly.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Finally, to run the build, execute the following command once inside your {\f1 appDir} or {\f1 appDir/scripts} directory:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 node ../../r.js -o app.build.js\par}
{\pard \ql \f0 \sa180 \li0 \fi0 That\u8217's it. As long as you have UglifyJS/Closure tools setup correctly, r.js should be able to easily optimize your entire Backbone project in just a few key-strokes. If you would like to learn more about build profiles, James Burke has a {\field{\*\fldinst{HYPERLINK "https://github.com/jrburke/r.js/blob/master/build/example.build.js"}}{\fldrslt{\ul
heavily commented sample file
}}}
 with all the possible options available.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Optimize and Build a Backbone.js JavaScript application with Require.JS using Packages\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\i Contributed by {\field{\*\fldinst{HYPERLINK "https://github.com/pixelhandler"}}{\fldrslt{\ul
Bill Heaton
}}}
}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 When a JavaScript application is too complex or large to build in a single file, grouping the application\u8217's components into packages allows for script dependencies to download in parallel, and facilitates only loading {\b packaged} and other modular code as the site experience requires the specific set of dependencies.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Require.JS, the (JavaScript) module loading library, has an {\field{\*\fldinst{HYPERLINK "http://requirejs.org/docs/optimization.html"}}{\fldrslt{\ul
optimizer
}}}
 to build a JavaScript-based application and provides various options. A build profile is the recipe for your build, much like a build.xml file is used to build a project with ANT. The benefit of building with {\b r.js} not only results in speedy script loading with minified code, but also provides a way to package components of your application.\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\field{\*\fldinst{HYPERLINK "http://requirejs.org/docs/optimization.html#onejs"}}{\fldrslt{\ul
Optimizing one JavaScript file
}}}
\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\field{\*\fldinst{HYPERLINK "http://requirejs.org/docs/optimization.html#wholeproject"}}{\fldrslt{\ul
Optimizing a whole project
}}}
\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\field{\*\fldinst{HYPERLINK "http://requirejs.org/docs/faq-optimization.html#priority"}}{\fldrslt{\ul
Optimizing a project in layers or packages
}}}
\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In a complex application, organizing code into {\i packages} is an attractive build strategy. The build profile in this article is based on an test application currently under development (files list below). The application framework is built with open source libraries. The main objective in this build profile is to optimize an application developed with {\field{\*\fldinst{HYPERLINK "http://documentcloud.github.com/backbone/"}}{\fldrslt{\ul
Backbone.js
}}}
 using modular code, following the {\field{\*\fldinst{HYPERLINK "https://github.com/amdjs/amdjs-api/wiki/AMD"}}{\fldrslt{\ul
Asynchronous Module Definition (AMD)
}}}
 format. AMD and Require.JS provide the structure for writing modular code with dependencies. Backbone.js provides the code organization for developing models, views and collections and also interactions with a RESTful API.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Below is an outline of the applications file organization, followed by the build profile to build modular (or packaged) layers a JavaScript driven application.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 File organization\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Assume the following directories and file organization, with app.build.js as the build profile (a sibling to both source and release directories). Note that the files in the list below named {\i section} can be any component of the application, e.g. {\i header}, {\i login})\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 .-- app.build.js\line
|-- app-release\line
`-- app-src\line
    |-- collections\line
    |   |-- base.js\line
    |   |-- sections-segments.js\line
    |   `-- sections.js\line
    |-- docs\line
    |   `--docco.css\line
    |-- models\line
    |   |-- base.js\line
    |   |-- branding.js\line
    |   `-- section.js\line
    |-- packages\line
    |   |-- header\line
    |   |   |-- models\line
    |   |   |   |-- nav.js\line
    |   |   |   `-- link.js\line
    |   |   |-- templates\line
    |   |   |   |-- branding.js\line
    |   |   |   |-- nav.js\line
    |   |   |   `-- links.js\line
    |   |   `-- views\line
    |   |       |-- nav.js\line
    |   |       |-- branding.js\line
    |   |       `-- link.js\line
    |   |-- header.js\line
    |   `-- ... more packages here e.g. cart, checkout ...\line
    |-- syncs\line
    |   |-- rest\line
    |   |   `-- sections.js\line
    |   |-- factory.js\line
    |   `-- localstorage.js\line
    |-- test\line
    |   |-- fixtures\line
    |   |   `-- sections.json\line
    |   |-- header\line
    |   |   |-- index.html\line
    |   |   `-- spec.js\line
    |   |-- lib\line
    |   |   `-- Jasmine\line
    |   |-- models\line
    |   |-- utils\line
    |   |-- global-spec.js\line
    |-- utils\line
    |   |-- ajax.js\line
    |   |-- baselib.js\line
    |   |-- debug.js\line
    |   |-- localstorage.js\line
    |   `-- shims.js\line
    |-- vendor\line
    |-- |-- backbone-min.js\line
    |   |-- jquery.min.js\line
    |   |-- jquery.mobile-1.0.min.js\line
    |   |-- json2.js\line
    |   |-- modernizr.min.js\line
    |   |-- mustache.js\line
    |   |-- require.js\line
    |   |-- text.js\line
    |   `-- underscore.js\line
    |-- views\line
    |   |-- base.js\line
    |   `-- collection.js\line
    |-- application.js\line
    |-- collections.js\line
    |-- index.html\line
    |-- main.js\line
    |-- models.js\line
    |-- syncs.js\line
    |-- utils.js\line
    |-- vendor.js\line
    `-- views.js\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Build profile to optimize modular dependencies with code organized in packages\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The build profile can be organized to {\field{\*\fldinst{HYPERLINK "http://requirejs.org/docs/faq-optimization.html#priority"}}{\fldrslt{\ul
divide parallel downloads for various sections of the application
}}}
.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This strategy demonstrated builds common or site-wide groups of (core) {\i models}, {\i views}, collections which are extended from a base.js constructor which extends the appropriate backbone method, e.g.\u160?Backbone.Model. The {\i packages} directory organizes code by section / responsibility, e.g.\u160?cart, checkout, etc. Notice that within the example {\i header} package the directory structure is similar to the app root directory file structure. A {\i package} (of modularized code) has dependencies from the common libraries in your application and also has specific code for the packages execution alone; other packages should not require another packages dependencies. A {\i utils} directory has shims, helpers, and common library code to support the application. A {\i syncs} directory to define persistence with your RESTful api and/or localStorage. The {\i vendor} libraries folder will not be built, there is no need to do so, you may decide to use a CDN (then set these paths to : {\i {\field{\*\fldinst{HYPERLINK "http://requirejs.org/docs/optimization.html#empty"}}{\fldrslt{\ul
empty:
}}}
}). And finally a {\i test} directory for {\field{\*\fldinst{HYPERLINK "http://pivotal.github.com/jasmine/"}}{\fldrslt{\ul
Jasmine
}}}
 unit test specs, which may be ignored in the build as well if you choose.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Also notice the there are .js files named the same as the directories, these are the files listed in the paths. these are strategic to group sets of files to build, examples follow the build profile below.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 (\{\line
    appDir: './app-src',\line
    baseUrl: './',\line
    dir: './app-build',\line
    optimize: 'uglify',\line
    paths: \{\line
        // will not build 3rd party code, it's already built\line
        'text'         : 'vendor/text',\line
        'json2'        : 'vendor/json2.min',\line
        'modernizr'    : 'vendor/modernizr.min',\line
        'jquery'       : 'vendor/jquery-1.7.1',\line
        'jquerymobile' : 'vendor/jquery.mobile.min.js',\line
        'underscore'   : 'vendor/underscore',\line
        'mustache'     : 'vendor/mustache',\line
        'backbone'     : 'vendor/backbone',\line
        // files that define dependencies...\line
        // ignore vendor libraries, but need a group to do so\line
        'vendor'       : 'vendor',\line
        // application modules/packages these files define dependencies\line
        // and may also group modules into objects if needed to require\line
        // by groups rather than individual files\line
        'utils'        : 'utils',\line
        'models'       : 'models',\line
        'views'        : 'views',\line
        'collections'  : 'collections',\line
        // packages to build\line
        'header'       : 'packages/header'\line
        //... more packages\line
    \},\line
    modules: [\line
        // Common libraries, Utilities, Syncs, Models, Views, Collections\line
        \{\line
            name: 'utils',\line
            exclude: ['vendor']\line
        \},\line
        \{\line
            name: 'syncs',\line
            exclude: ['vendor', 'utils']\line
        \},\line
        \{\line
            name: 'models',\line
            exclude: ['vendor', 'utils', 'syncs']\line
        \},\line
        \{\line
            name: 'views',\line
            exclude: ['vendor', 'utils', 'syncs', 'models']\line
        \},\line
        \{\line
            name: 'collections',\line
            exclude: ['vendor', 'utils', 'syncs', 'models', 'views']\line
        \},\line
        // Packages\line
        \{\line
            name: 'header',\line
            exclude: ['vendor', 'utils', 'syncs', 'models', 'views', 'collections']\line
        \}\line
        // ... and so much more ...\line
    ]\line
\})\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The above build profile is designed for balancing scalability and performance.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Examples of the grouped sets of code dependencies}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The contents of the vendor.js which is not built into a package may use some {\i no conflict} calls as well.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 // List of vendor libraries, e.g. jQuery, Underscore, Backbone, etc.\line
// this module is used with the r.js optimizer tool during build\line
// @see <http://requirejs.org/docs/faq-optimization.html>\line
define([ "jquery", "underscore", "backbone", "modernizr", "mustache" ],\line
function ($,        _,            Backbone,   Modernizr,   Mustache) \{\line
    // call no conflicts so if needed you can use multiple versions of $\line
    $.noConflict();\line
    _.noConflict();\line
    Backbone.noConflict();\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For your application common library code.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 // List of utility libraries,\line
define([ "utils/ajax", "utils/baselib", "utils/localstorage", "utils/debug", "utils/shims" ],\line
function (ajax,         baselib,         localstorage,         debug) \{\line
    return \{\line
        "ajax" : ajax,\line
        "baselib" : baselib,\line
        "localstorage" : localstorage,\line
        "debug" : debug\line
    \};\line
    // the shim only extend JavaScript when needed, e.g. Object.create\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 An example where you intend to use require the common models in another package file.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 // List of models\line
// models in this directory are intended for site-wide usage\line
// grouping site-wide models in this module (object)\line
// optimizes the performance and keeps dependencies organized\line
// when the (build) optimizer is run.\line
define([ "models/branding", "models/section" ],\line
function (Branding,          Section) \{\line
    return \{\line
        "Branding" : Branding,\line
        "Section"  : Section\line
    \};\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 A quick note on code standards\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Notice that in the above examples the parameters may begin with lower or upper case characters. The variable names uses in the parameters that begin with {\i Uppercase} are {\i Constructors} and the {\i lowercase} variable names are not, they may be instances created by a constructor, or perhaps an object or function that is not meant to used with {\i new}.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The convention recommended is to use Upper CamelCase for constructors and lower camelCase for others.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Common Pitfall when organizing code in modules\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Be careful not define circular dependencies. For example, in a common {\i models} package (models.js) dependencies are listed for the files in your models directory\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 define([ "models/branding", "models/section" ], function (branding, section)\line
// ...\line
return \{ "branding" : branding, "section", section \}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Then when another packages requires a common model you can access the models objects returned from your common models.js file like so\u8230?\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 define([ "models", "utils" ], function (models, utils) \{\line
var branding = models.branding, debug = utils.debug;\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Perhaps after using the model a few times you get into the habit of requiring \u8220"model\u8221". Later you need add another common model with extends a model you already defined. So the pitfall begins, you add a new model inside your models directory and add a reference this same model in the model.js:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 define([ "models/branding", "models/section", "models/section-b" ], function (branding, section)\line
// ...\line
return \{ "branding" : branding, "section", section, "section-b" : section-b \}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 However in your {\i models/section-b.js} file you define a dependency using the model.js which returns the models in an object like so\u8230?\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 define([ "models" ], function (models, utils) \{\line
var section = models.section;\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Above is the mistake in models.js a dependency was added for models/section-b and in section-b a dependency is defined for model. The new models/section-b.js requires {\i model} and model.js requires {\i models/section-b.js} - a circular dependency. This should result in a load timeout error from require.js, but not tell you about the circular dependency.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For other common mistakes see the {\field{\*\fldinst{HYPERLINK "http://requirejs.org/docs/errors.html"}}{\fldrslt{\ul
COMMON ERRORS
}}}
 page on the Require.js site.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Executing the Build with r.js\par}
{\pard \ql \f0 \sa180 \li0 \fi0 If you intalled r.js with Node\u8217's npm (package manager) like so\u8230?\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 > npm install requirejs\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \u8230?you can execute the build on the command line:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 > r.js -o app.build.js\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Practical: Building a modular Backbone app with AMD & Require.js\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In this chapter, we\u8217'll look at our first practical Backbone & Require.js project - how to build a modular Todo application. The application will allow us to add new todos, edit new todos and clear todo items that have been marked as completed. For a more advanced practical, see the section on mobile Backbone development.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The complete code for the application can can be found in the {\f1 practicals/modular-todo-app} folder of this repo (thanks to Thomas Davis and J\u233?r\u244?me Gravel-Niquet). Alternatively grab a copy of my side-project {\field{\*\fldinst{HYPERLINK "https://github.com/addyosmani/todomvc"}}{\fldrslt{\ul
TodoMVC
}}}
 which contains the sources to both AMD and non-AMD versions.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Note:} Thomas may be covering a practical on this exercise in more detail on {\field{\*\fldinst{HYPERLINK "http://backbonetutorials.com"}}{\fldrslt{\ul
backbonetutorials.com
}}}
 at some point soon, but for this section I\u8217'll be covering what I consider the core concepts.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Overview\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Writing a \u8216'modular\u8217' Backbone application can be a straight-forward process. There are however, some key conceptual differences to be aware of if opting to use AMD as your module format of choice:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab As AMD isn\u8217't a standard native to JavaScript or the browser, it\u8217's necessary to use a script loader (such as Require.js or curl.js) in order to support defining components and modules using this module format. As we\u8217've already reviewed, there are a number of advantages to using the AMD as well as Require.js to assist here.\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Models, views, controllers and routers need to be encapsulated {\i using} the AMD-format. This allows each component of our Backbone application to cleanly manage dependencies (e.g collections required by a view) in the same way that AMD allows non-Backbone modules to.\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Non-Backbone components/modules (such as utilities or application helpers) can also be encapsulated using AMD. I encourage you to try developing these modules in such a way that they can both be used and tested independent of your Backbone code as this will increase their ability to be re-used elsewhere.\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Now that we\u8217've reviewed the basics, let\u8217's take a look at developing our application. For reference, the structure of our app is as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 index.html\line
...js/\line
    main.js\line
    .../models\line
            todo.js\line
    .../views\line
            app.js\line
            todos.js\line
    .../collections\line
            todos.js\line
    .../templates\line
            stats.html\line
            todos.html\line
    ../libs\line
        .../backbone\line
        .../jquery\line
        .../underscore\line
        .../require\line
                require.js\line
                text.js\line
...css/\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Markup\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The markup for the application is relatively simple and consists of three primary parts: an input section for entering new todo items ({\f1 create-todo}), a list section to display existing items (which can also be edited in-place) ({\f1 todo-list}) and finally a section summarizing how many items are left to be completed ({\f1 todo-stats}).\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 <div id="todoapp">\line
\line
      <div class="content">\line
\line
        <div id="create-todo">\line
          <input id="new-todo" placeholder="What needs to be done?" type="text" />\line
          <span class="ui-tooltip-top">Press Enter to save this task</span>\line
        </div>\line
\line
        <div id="todos">\line
          <ul id="todo-list"></ul>\line
        </div>\line
\line
        <div id="todo-stats"></div>\line
\line
      </div>\line
\line
</div>\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The rest of the tutorial will now focus on the JavaScript side of the practical.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Configuration options\par}
{\pard \ql \f0 \sa180 \li0 \fi0 If you\u8217've read the earlier chapter on AMD, you may have noticed that explicitly needing to define each dependency a Backbone module (view, collection or other module) may require with it can get a little tedious. This can however be improved.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In order to simplify referencing common paths the modules in our application may use, we use a Require.js {\field{\*\fldinst{HYPERLINK "http://requirejs.org/docs/api.html#config"}}{\fldrslt{\ul
configuration object
}}}
, which is typically defined as a top-level script file. Configuration objects have a number of useful capabilities, the most useful being mode name-mapping. Name-maps are basically a key:value pair, where the key defines the alias you wish to use for a path and the value represents the true location of the path.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In the code-sample below, you can see some typical examples of common name-maps which include: {\f1 backbone}, {\f1 underscore}, {\f1 jquery} and depending on your choice, the RequireJS {\f1 text} plugin, which assists with loading text assets like templates.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b main.js}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 require.config(\{\line
  baseUrl:'../',\line
  paths: \{\line
    jquery: 'libs/jquery/jquery-min',\line
    underscore: 'libs/underscore/underscore-min',\line
    backbone: 'libs/backbone/backbone-optamd3-min',\line
    text: 'libs/require/text'\line
  \}\line
\});\line
\line
require(['views/app'], function(AppView)\{\line
  var app_view = new AppView;\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The {\f1 require()} at the end of our main.js file is simply there so we can load and instantiate the primary view for our application ({\f1 views/app.js}). You\u8217'll commonly see both this and the configuration object included in most top-level script files for a project.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In addition to offering name-mapping, the configuration object can be used to define additional properties such as {\f1 waitSeconds} - the number of seconds to wait before script loading times out and {\f1 locale}, should you wish to load up i18n bundles for custom languages. The {\f1 baseUrl} is simply the path to use for module lookups.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For more information on configuration objects, please feel free to check out the excellent guide to them in the {\field{\*\fldinst{HYPERLINK "http://requirejs.org/docs/api.html#config"}}{\fldrslt{\ul
RequireJS docs
}}}
.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Modularizing our models, views and collections\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Before we dive into AMD-wrapped versions of our Backbone components, let\u8217's review a sample of a non-AMD view. The following view listens for changes to its model (a Todo item) and re-renders if a user edits the value of the item.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var TodoView = Backbone.View.extend(\{\line
\line
    //... is a list tag.\line
    tagName:  "li",\line
\line
    // Cache the template function for a single item.\line
    template: _.template($('#item-template').html()),\line
\line
    // The DOM events specific to an item.\line
    events: \{\line
      "click .check"              : "toggleDone",\line
      "dblclick div.todo-content" : "edit",\line
      "click span.todo-destroy"   : "clear",\line
      "keypress .todo-input"      : "updateOnEnter"\line
    \},\line
\line
    // The TodoView listens for changes to its model, re-rendering. Since there's\line
    // a one-to-one correspondence between a **Todo** and a **TodoView** in this\line
    // app, we set a direct reference on the model for convenience.\line
    initialize: function() \{\line
      this.model.on('change', this.render, this);\line
      this.model.view = this;\line
    \},\line
    ...\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Note how for templating the common practice of referencing a script by an ID (or other selector) and obtaining its value is used. This of course requires that the template being accessed is implicitly defined in our markup. The following is the \u8216'embedded\u8217' version of our template being referenced above:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 <script type="text/template" id="item-template">\line
      <div class="todo <%= done ? 'done' : '' %>">\line
        <div class="display">\line
          <input class="check" type="checkbox" <%= done ? 'checked="checked"' : '' %> />\line
          <div class="todo-content"></div>\line
          <span class="todo-destroy"></span>\line
        </div>\line
        <div class="edit">\line
          <input class="todo-input" type="text" value="" />\line
        </div>\line
      </div>\line
</script>\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Whilst there is nothing wrong with the template itself, once we begin to develop larger applications requiring multiple templates, including them all in our markup on page-load can quickly become both unmanageable and come with performance costs. We\u8217'll look at solving this problem in a minute.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Let\u8217's now take a look at the AMD-version of our view. As discussed earlier, the \u8216'module\u8217' is wrapped using AMD\u8217's {\f1 define()} which allows us to specify the dependencies our view requires. Using the mapped paths to \u8216'jquery\u8217' etc. simplifies referencing common dependencies and instances of dependencies are themselves mapped to local variables that we can access (e.g \u8216'jquery\u8217' is mapped to {\f1 $}).\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b views/todos.js}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 define([\line
  'jquery',\line
  'underscore',\line
  'backbone',\line
  'text!templates/todos.html'\line
  ], function($, _, Backbone, todosTemplate)\{\line
  var TodoView = Backbone.View.extend(\{\line
\line
    //... is a list tag.\line
    tagName:  "li",\line
\line
    // Cache the template function for a single item.\line
    template: _.template(todosTemplate),\line
\line
    // The DOM events specific to an item.\line
    events: \{\line
      "click .check"              : "toggleDone",\line
      "dblclick div.todo-content" : "edit",\line
      "click span.todo-destroy"   : "clear",\line
      "keypress .todo-input"      : "updateOnEnter"\line
    \},\line
\line
    // The TodoView listens for changes to its model, re-rendering. Since there's\line
    // a one-to-one correspondence between a **Todo** and a **TodoView** in this\line
    // app, we set a direct reference on the model for convenience.\line
    initialize: function() \{\line
      this.model.on('change', this.render, this);\line
      this.model.view = this;\line
    \},\line
\line
    // Re-render the contents of the todo item.\line
    render: function() \{\line
      this.$el.html(this.template(this.model.toJSON()));\line
      this.setContent();\line
      return this;\line
    \},\line
\line
    // Use `jQuery.text` to set the contents of the todo item.\line
    setContent: function() \{\line
      var content = this.model.get('content');\line
      this.$('.todo-content').text(content);\line
      this.input = this.$('.todo-input');\line
      this.input.on('blur', this.close);\line
      this.input.val(content);\line
    \},\line
    ...\par}
{\pard \ql \f0 \sa180 \li0 \fi0 From a maintenance perspective, there\u8217's nothing logically different in this version of our view, except for how we approach templating.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Using the Require.js text plugin (the dependency marked {\f1 text}), we can actually store all of the contents for the template we looked at earlier in an external file (todos.html).\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b templates/todos.html}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 <div class="todo <%= done ? 'done' : '' %>">\line
    <div class="display">\line
      <input class="check" type="checkbox" <%= done ? 'checked="checked"' : '' %> />\line
      <div class="todo-content"></div>\line
      <span class="todo-destroy"></span>\line
    </div>\line
    <div class="edit">\line
      <input class="todo-input" type="text" value="" />\line
    </div>\line
</div>\par}
{\pard \ql \f0 \sa180 \li0 \fi0 There\u8217's no longer a need to be concerned with IDs for the template as we can map its contents to a local variable (in this case {\f1 todosTemplate}). We then simply pass this to the Underscore.js templating function {\f1 _.template()} the same way we normally would have the value of our template script.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Next, let\u8217's look at how to define models as dependencies which can be pulled into collections. Here\u8217's an AMD-compatible model module, which has two default values: a {\f1 content} attribute for the content of a Todo item and a boolean {\f1 done} state, allowing us to trigger whether the item has been completed or not.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b models/todo.js}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 define(['underscore', 'backbone'], function(_, Backbone) \{\line
  var TodoModel = Backbone.Model.extend(\{\line
\line
    // Default attributes for the todo.\line
    defaults: \{\line
      // Ensure that each todo created has `content`.\line
      content: "empty todo...",\line
      done: false\line
    \},\line
\line
    initialize: function() \{\line
    \},\line
\line
    // Toggle the `done` state of this todo item.\line
    toggle: function() \{\line
      this.save(\{done: !this.get("done")\});\line
    \},\line
\line
    // Remove this Todo from *localStorage* and delete its view.\line
    clear: function() \{\line
      this.destroy();\line
      this.view.remove();\line
    \}\line
\line
  \});\line
  return TodoModel;\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 As per other types of dependencies, we can easily map our model module to a local variable (in this case {\f1 Todo}) so it can be referenced as the model to use for our {\f1 TodosCollection}. This collection also supports a simple {\f1 done()} filter for narrowing down Todo items that have been completed and a {\f1 remaining()} filter for those that are still outstanding.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b collections/todos.js}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 define([\line
  'underscore',\line
  'backbone',\line
  'libs/backbone/localstorage',\line
  'models/todo'\line
  ], function(_, Backbone, Store, Todo)\{\line
\line
    var TodosCollection = Backbone.Collection.extend(\{\line
\line
    // Reference to this collection's model.\line
    model: Todo,\line
\line
    // Save all of the todo items under the `"todos"` namespace.\line
    localStorage: new Store("todos"),\line
\line
    // Filter down the list of all todo items that are finished.\line
    done: function() \{\line
      return this.filter(function(todo)\{ return todo.get('done'); \});\line
    \},\line
\line
    // Filter down the list to only todo items that are still not finished.\line
    remaining: function() \{\line
      return this.without.apply(this, this.done());\line
    \},\line
    ...\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In addition to allowing users to add new Todo items from views (which we then insert as models in a collection), we ideally also want to be able to display how many items have been completed and how many are remaining. We\u8217've already defined filters that can provide us this information in the above collection, so let\u8217's use them in our main application view.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b views/app.js}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 define([\line
  'jquery',\line
  'underscore',\line
  'backbone',\line
  'collections/todos',\line
  'views/todos',\line
  'text!templates/stats.html'\line
  ], function($, _, Backbone, Todos, TodoView, statsTemplate)\{\line
\line
  var AppView = Backbone.View.extend(\{\line
\line
    // Instead of generating a new element, bind to the existing skeleton of\line
    // the App already present in the HTML.\line
    el: $("#todoapp"),\line
\line
    // Our template for the line of statistics at the bottom of the app.\line
    statsTemplate: _.template(statsTemplate),\line
\line
    // ...events, initialize() etc. can be seen in the complete file\line
\line
    // Re-rendering the App just means refreshing the statistics -- the rest\line
    // of the app doesn't change.\line
    render: function() \{\line
      var done = Todos.done().length;\line
      this.$('#todo-stats').html(this.statsTemplate(\{\line
        total:      Todos.length,\line
        done:       Todos.done().length,\line
        remaining:  Todos.remaining().length\line
      \}));\line
    \},\line
    ...\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Above, we map the second template for this project, {\f1 templates/stats.html} to {\f1 statsTemplate} which is used for rendering the overall {\f1 done} and {\f1 remaining} states. This works by simply passing our template the length of our overall Todos collection ({\f1 Todos.length} - the number of Todo items created so far) and similarly the length (counts) for items that have been completed ({\f1 Todos.done().length}) or are remaining ({\f1 Todos.remaining().length}).\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The contents of our {\f1 statsTemplate} can be seen below. It\u8217's nothing too complicated, but does use ternary conditions to evaluate whether we should state there\u8217's \u8220"1 item\u8221" or \u8220"2 items\u8221" in a particular state.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 <% if (total) \{ %>\line
        <span class="todo-count">\line
          <span class="number"><%= remaining %></span>\line
          <span class="word"><%= remaining == 1 ? 'item' : 'items' %></span> left.\line
        </span>\line
      <% \} %>\line
      <% if (done) \{ %>\line
        <span class="todo-clear">\line
          <a href="#">\line
            Clear <span class="number-done"><%= done %></span>\line
            completed <span class="word-done"><%= done == 1 ? 'item' : 'items' %></span>\line
          </a>\line
        </span>\line
      <% \} %>\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The rest of the source for the Todo app mainly consists of code for handling user and application events, but that rounds up most of the core concepts for this practical.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 To see how everything ties together, feel free to grab the source by cloning this repo or browse it {\field{\*\fldinst{HYPERLINK "https://github.com/addyosmani/backbone-fundamentals/tree/master/practicals/modular-todo-app"}}{\fldrslt{\ul
online
}}}
 to learn more. I hope you find it helpful!.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Note:} While this first practical doesn\u8217't use a build profile as outlined in the chapter on using the Require.js optimizer, we will be using one in the section on building mobile Backbone applications.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Decoupling Backbone with the Mediator and Facade patterns\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In this section we\u8217'll discuss applying some of the concepts I cover in my article on {\field{\*\fldinst{HYPERLINK "http://addyosmani.com/largescalejavascript"}}{\fldrslt{\ul
Large-scale JavaScript Application development
}}}
 to Backbone.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\i After, you may be interested in taking a look At {\field{\*\fldinst{HYPERLINK "http://github.com/addyosmani/aura"}}{\fldrslt{\ul
Aura
}}}
 - my popular widget-based Backbone.js extension framework based on many of the concepts we will be covering in this section.}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Summary\par}
{\pard \ql \f0 \sa180 \li0 \fi0 At a high-level, one architecture that works for such applications is something which is:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b Highly decoupled}: encouraging modules to only publish and subscribe to events of interest rather than directly communicating with each other. This helps us to build applications who\u8217's units of code aren\u8217't highly tied (coupled) together and can thus be reused more easily.\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b Supports module-level security}: whereby modules are only able to execute behavior they\u8217've been permitted to. Application security is an area which is often overlooked in JavaScript applications, but can be quite easily implemented in a flexible manner.\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b Supports failover}: allowing an application continuing to function even if particular modules fail. The typical example I give of this is the GMail chat widget. Imagine being able to build applications in a way that if one widget on the page fails (e.g chat), the rest of your application (mail) can continue to function without being affected.\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This is an architecture which has been implemented by a number of different companies in the past, including Yahoo! (for their modularized homepage - which Nicholas Zakas has {\field{\*\fldinst{HYPERLINK "http://www.youtube.com/watch?v=vXjVFPosQHw"}}{\fldrslt{\ul
spoken
}}}
 about) and AOL for some of our upcoming projects.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The three design patterns that make this architecture possible are the:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b Module pattern}: used for encapsulating unique blocks of code, where functions and variables can be kept either public or private. (\u8216'private\u8217' in the simulation of privacy sense, as of course don\u8217't have true privacy in JavaScript)\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b Mediator pattern}: used when the communication between modules may be complex, but is still well defined. If it appears a system may have too many relationships between modules in your code, it may be time to have a central point of control, which is where the pattern fits in.\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b Facade pattern}: used for providing a convenient higher-level interface to a larger body of code, hiding its true underlying complexity\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Their specific roles in this architecture can be found below.\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b Modules}: There are almost two concepts of what defines a module. As AMD is being used as a module wrapper, technically each model, view and collection can be considered a module. We then have the concept of modules being distinct blocks of code outside of just MVC/MV*. For the latter, these types of \u8216'modules\u8217' are primarily concerned with broadcasting and subscribing to events of interest rather than directly communicating with each other.They are made possible through the Mediator pattern.\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b Mediator}: The mediator has a varying role depending on just how you wish to implement it. In my article, I mention using it as a module manager with the ability to start and stop modules at will, however when it comes to Backbone, I feel that simplifying it down to the role of a central \u8216'controller\u8217' that provides pub/sub capabilities should suffice. One can of course go all out in terms of building a module system that supports module starting, stopping, pausing etc, however the scope of this is outside of this chapter.\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b Facade}: This acts as a secure middle-layer that both abstracts an application core (Mediator) and relays messages from the modules back to the Mediator so they don\u8217't touch it directly. The Facade also performs the duty of application security guard; it checks event notifications from modules against a configuration (permissions.js, which we will look at later) to ensure requests from modules are only processed if they are permitted to execute the behavior passed.\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Practical\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For the practical section of this chapter, we\u8217'll be extending the well-known Backbone Todo application using the three patterns mentioned above.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The application is broken down into AMD modules that cover everything from Backbone models through to application-level modules. The views publish events of interest to the rest of the application and modules can then subscribe to these event notifications.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 All subscriptions from modules go through a facade (or sandbox). What this does is check against the subscriber name and the \u8216'channel/notification\u8217' it\u8217's attempting to subscribe to. If a channel {\i doesn\u8217't} have permissions to be subscribed to (something established through permissions.js), the subscription isn\u8217't permitted.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Mediator}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Found in {\f1 aura/mediator.js}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Below is a very simple AMD-wrapped implementation of the mediator pattern, based on prior work by Ryan Florence. It accepts as its input an object, to which it attaches {\f1 publish()} and {\f1 subscribe()} methods. In a larger application, the mediator can contain additional utilities, such as handlers for initializing, starting and stopping modules, but for demonstration purposes, these two methods should work fine for our needs.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 define([], function(obj)\{\line
\line
  var channels = \{\};\line
  if (!obj) obj = \{\};\line
\line
  obj.subscribe = function (channel, subscription) \{\line
    if (!channels[channel]) channels[channel] = [];\line
    channels[channel].push(subscription);\line
  \};\line
\line
  obj.publish = function (channel) \{\line
    if (!channels[channel]) return;\line
    var args = [].slice.call(arguments, 1);\line
    for (var i = 0, l = channels[channel].length; i < l; i++) \{\line
      channels[channel][i].apply(this, args);\line
    \}\line
  \};\line
\line
  return obj;\line
\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Facade}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Found in {\f1 aura/facade.js}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Next, we have an implementation of the facade pattern. Now the classical facade pattern applied to JavaScript would probably look a little like this:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 \line
var module = (function() \{\line
    var _private = \{\line
        i:5,\line
        get : function() \{\line
            console.log('current value:' + this.i);\line
        \},\line
        set : function( val ) \{\line
            this.i = val;\line
        \},\line
        run : function() \{\line
            console.log('running');\line
        \},\line
        jump: function()\{\line
            console.log('jumping');\line
        \}\line
    \};\line
    return \{\line
        facade : function( args ) \{\line
            _private.set(args.val);\line
            _private.get();\line
            if ( args.run ) \{\line
                _private.run();\line
            \}\line
        \}\line
    \}\line
\}());\line
\line
module.facade(\{run: true, val:10\});\line
//outputs current value: 10, running\par}
{\pard \ql \f0 \sa180 \li0 \fi0 It\u8217's effectively a variation of the module pattern, where instead of simply returning an interface of supported methods, your API can completely hide the true implementation powering it, returning something simpler. This allows the logic being performed in the background to be as complex as necessary, whilst all the end-user experiences is a simplified API they pass options to (note how in our case, a single method abstraction is exposed). This is a beautiful way of providing APIs that can be easily consumed.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 That said, to keep things simple, our implementation of an AMD-compatible facade will act a little more like a proxy. Modules will communicate directly through the facade to access the mediator\u8217's {\f1 publish()} and {\f1 subscribe()} methods, however, they won\u8217't as such touch the mediator directly.This enables the facade to provide application-level validation of any subscriptions and publications made.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 It also allows us to implement a simple, but flexible, permissions checker (as seen below) which will validate subscriptions made against a permissions configuration to see whether it\u8217's permitted or not.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 define([ "../aura/mediator" , "../aura/permissions" ], function (mediator, permissions) \{\line
\line
    var facade = facade || \{\};\line
\line
    facade.subscribe = function(subscriber, channel, callback)\{\line
\line
        // Note: Handling permissions/security is optional here\line
        // The permissions check can be removed\line
        // to just use the mediator directly.\line
\line
        if(permissions.validate(subscriber, channel))\{\line
            mediator.subscribe( channel, callback );\line
        \}\line
    \}\line
\line
    facade.publish = function(channel)\{\line
        mediator.publish( channel );\line
    \}\line
    return facade;\line
\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Permissions}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Found in {\f1 aura/permissions.js}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In our simple permissions configuration, we support checking against subscription requests to establish whether they are allowed to clear. This enforces a flexible security layer for the application.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 To visually see how this works, consider changing say, permissions -> renderDone -> todoCounter to be false. This will completely disable the application from from rendering or displaying the counts component for Todo items left (because they aren\u8217't allowed to subscribe to that event notification). The rest of the Todo app can still however be used without issue.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 It\u8217's a very dumbed down example of the potential for application security, but imagine how powerful this might be in a large app with a significant number of visual widgets.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 define([], function () \{\line
\line
    // Permissions\line
\line
    // A permissions structure can support checking\line
    // against subscriptions prior to allowing them\line
    // to clear. This enforces a flexible security\line
    // layer for your application.\line
\line
    var permissions = \{\line
\line
        newContentAvailable: \{\line
            contentUpdater:true\line
        \},\line
\line
        endContentEditing:\{\line
            todoSaver:true\line
        \},\line
\line
        beginContentEditing:\{\line
            editFocus:true\line
        \},\line
\line
        addingNewTodo:\{\line
            todoTooltip:true\line
        \},\line
\line
        clearContent:\{\line
            garbageCollector:true\line
        \},\line
\line
        renderDone:\{\line
            todoCounter:true //switch to false to see what happens :)\line
        \},\line
\line
        destroyContent:\{\line
            todoRemover:true\line
        \},\line
\line
        createWhenEntered:\{\line
            keyboardManager:true\line
        \}\line
\line
    \};\line
\line
    permissions.validate = function(subscriber, channel)\{\line
        var test = permissions[channel][subscriber];\line
        return test===undefined? false: test;\line
    \};\line
\line
    return permissions;\line
\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Subscribers}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Found in {\f1 subscribers.js}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Subscriber \u8216'modules\u8217' communicate through the facade back to the mediator and perform actions when a notification event of a particular name is published.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For example, when a user enters in a new piece of text for a Todo item and hits \u8216'enter\u8217' the application publishes a notification saying two things: a) a new Todo item is available and b) the text content of the new item is X. It\u8217's then left up to the rest of the application to do with this information whatever it wishes.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In order to update your Backbone application to primarily use pub/sub, a lot of the work you may end up doing will be moving logic coupled inside of specific views to modules outside of it which are reactionary.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Take the {\f1 todoSaver} for example - its responsibility is saving new Todo items to models once the a {\f1 notificationName} called \u8216'newContentAvailable\u8217' has fired. If you take a look at the permissions structure in the last code sample, you\u8217'll notice that \u8216'newContentAvailable\u8217' is present there. If I wanted to prevent subscribers from being able to subscribe to this notification, I simply set it to a boolean value of {\f1 false}.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Again, this is a massive oversimplification of how advanced your permissions structures could get, but it\u8217's certainly one way of controlling what parts of your application can or can\u8217't be accessed by specific modules at any time.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 define(["jquery", "underscore", "aura/facade"],\line
function ($, _, facade) \{\line
\line
    // Subscription 'modules' for our views. These take the\line
    // the form facade.subscribe( subscriberName, notificationName , callBack )\line
\line
    // Update view with latest todo content\line
    // Subscribes to: newContentAvailable\line
\line
    facade.subscribe('contentUpdater', 'newContentAvailable', function (context) \{\line
        var content = context.model.get('content');\line
        context.$('.todo-content').text(content);\line
        context.input = context.$('.todo-input');\line
        context.input.bind('blur', context.close);\line
        context.input.val(content);\line
    \});\line
\line
\line
    // Save models when a user has finishes editing\line
    // Subscribes to: endContentEditing\line
    facade.subscribe('todoSaver','endContentEditing', function (context) \{\line
        try \{\line
            context.model.save(\{\line
                content: context.input.val()\line
            \});\line
            context.$el.removeClass("editing");\line
        \} catch (e) \{\line
            //console.log(e);\line
        \}\line
    \});\line
\line
\line
    // Delete a todo when the user no longer needs it\line
    // Subscribes to: destroyContent\line
    facade.subscribe('todoRemover','destroyContent', function (context) \{\line
        try \{\line
            context.model.clear();\line
        \} catch (e) \{\line
            //console.log(e);\line
        \}\line
    \});\line
\line
\line
    // When a user is adding a new entry, display a tooltip\line
    // Subscribes to: addingNewTodo\line
    facade.subscribe('todoTooltip','addingNewTodo', function (context, todo) \{\line
        var tooltip = context.$(".ui-tooltip-top");\line
        var val = context.input.val();\line
        tooltip.fadeOut();\line
        if (context.tooltipTimeout) clearTimeout(context.tooltipTimeout);\line
        if (val == '' || val == context.input.attr('placeholder')) return;\line
        var show = function () \{\line
                tooltip.show().fadeIn();\line
            \};\line
        context.tooltipTimeout = _.delay(show, 1000);\line
    \});\line
\line
\line
    // Update editing UI on switching mode to editing content\line
    // Subscribes to: beginContentEditing\line
    facade.subscribe('editFocus','beginContentEditing', function (context) \{\line
        context.$el.addClass("editing");\line
        context.input.focus();\line
    \});\line
\line
\line
    // Create a new todo entry\line
    // Subscribes to: createWhenEntered\line
    facade.subscribe('keyboardManager','createWhenEntered', function (context, e, todos) \{\line
        if (e.keyCode != 13) return;\line
        todos.create(context.newAttributes());\line
        context.input.val('');\line
    \});\line
\line
\line
\line
    // A Todo and remaining entry counter\line
    // Subscribes to: renderDone\line
    facade.subscribe('todoCounter','renderDone', function (context, Todos) \{\line
        var done = Todos.done().length;\line
        context.$('#todo-stats').html(context.statsTemplate(\{\line
            total: Todos.length,\line
            done: Todos.done().length,\line
            remaining: Todos.remaining().length\line
        \}));\line
    \});\line
\line
\line
    // Clear all completed todos when clearContent is dispatched\line
    // Subscribes to: clearContent\line
    facade.subscribe('garbageCollector','clearContent', function (Todos) \{\line
        _.each(Todos.done(), function (todo) \{\line
            todo.clear();\line
        \});\line
    \});\line
\line
\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 That\u8217's it for this section. If you\u8217've been intrigued by some of the concepts covered, I encourage you to consider taking a look at my {\field{\*\fldinst{HYPERLINK "http://addyosmani.com/blog/large-scale-javascript-application-architecture/"}}{\fldrslt{\ul
slides
}}}
 on Large-scale JS from the jQuery Summit or my longer post on the topic {\field{\*\fldinst{HYPERLINK "http://addyosmani.com/largescalejavascript"}}{\fldrslt{\ul
here
}}}
 for more information.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Paginating Backbone.js Requests & Collections\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Pagination is a ubiquitous problem we often find ourselves needing to solve on the web. Perhaps most predominantly when working with back-end APIs and JavaScript-heavy clients which consume them.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 On this topic, we\u8217're going to go through a set of {\b pagination components} I wrote for Backbone.js, which should hopefully come in useful if you\u8217're working on applications which need to tackle this problem. They\u8217're part of an extension called {\field{\*\fldinst{HYPERLINK "http://github.com/addyosmani/backbone-paginator"}}{\fldrslt{\ul
Backbone.Paginator
}}}
.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 When working with a structural framework like Backbone.js, the three types of pagination we are most likely to run into are:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Requests to a service layer (API)}- e.g query for results containing the term \u8216'Brendan\u8217' - if 5,000 results are available only display 20 results per page (leaving us with 250 possible result pages that can be navigated to).\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This problem actually has quite a great deal more to it, such as maintaining persistence of other URL parameters (e.g sort, query, order) which can change based on a user\u8217's search configuration in a UI. One also had to think of a clean way of hooking views up to this pagination so you can easily navigate between pages (e.g First, Last, Next, Previous, 1,2,3), manage the number of results displayed per page and so on.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Further client-side pagination of data returned -} e.g we\u8217've been returned a JSON response containing 100 results. Rather than displaying all 100 to the user, we only display 20 of these results within a navigatable UI in the browser.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Similar to the request problem, client-pagination has its own challenges like navigation once again (Next, Previous, 1,2,3), sorting, order, switching the number of results to display per page and so on.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Infinite results} - with services such as Facebook, the concept of numeric pagination is instead replaced with a \u8216'Load More\u8217' or \u8216'View More\u8217' button. Triggering this normally fetches the next \u8216'page\u8217' of N results but rather than replacing the previous set of results loaded entirely, we simply append to them instead.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 A request pager which simply appends results in a view rather than replacing on each new fetch is effectively an \u8216'infinite\u8217' pager.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Let\u8217's now take a look at exactly what we\u8217're getting out of the box:}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\i Paginator is a set of opinionated components for paginating collections of data using Backbone.js. It aims to provide both solutions for assisting with pagination of requests to a server (e.g an API) as well as pagination of single-loads of data, where we may wish to further paginate a collection of N results into M pages within a view.}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Paginator\u8217's pieces\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Backbone.Paginator supports two main pagination components:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b Backbone.Paginator.requestPager}: For pagination of requests between a client and a server-side API\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b Backbone.Paginator.clientPager}: For pagination of data returned from a server which you would like to further paginate within the UI (e.g 60 results are returned, paginate into 3 pages of 20)\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Live Examples\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Live previews of both pagination components using the Netflix API can be found below. Fork the repository to experiment with these examples further.\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\field{\*\fldinst{HYPERLINK "http://addyosmani.github.com/backbone.paginator/examples/netflix-request-paging/index.html"}}{\fldrslt{\ul
Backbone.Paginator.requestPager()
}}}
\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\field{\*\fldinst{HYPERLINK "http://addyosmani.github.com/backbone.paginator/examples/netflix-client-paging/index.html"}}{\fldrslt{\ul
Backbone.Paginator.clientPager()
}}}
\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\field{\*\fldinst{HYPERLINK "http://addyosmani.github.com/backbone.paginator/examples/netflix-infinite-paging/index.html"}}{\fldrslt{\ul
Infinite Pagination (Backbone.Paginator.requestPager())
}}}
\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\field{\*\fldinst{HYPERLINK "http://addyosmani.github.com/backbone.paginator/examples/google-diacritic/index.html"}}{\fldrslt{\ul
Diacritic Plugin
}}}
\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Paginator.requestPager\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In this section we\u8217're going to walkthrough actually using the requestPager.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 1. Create a new Paginated collection\par}
{\pard \ql \f0 \sa180 \li0 \fi0 First, we define a new Paginated collection using {\f1 Backbone.Paginator.requestPager()} as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 javascript var PaginatedCollection = Backbone.Paginator.requestPager.extend(\{} ####2: Set the model for the collection as normal\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Within our collection, we then (as normal) specify the model to be used with this collection followed by the URL (or base URL) for the service providing our data (e.g the Netflix API).\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 javascript         model: model,} ####3. Configure the base URL and the type of the request\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We need to set a base URL. The {\f1 type} of the request is {\f1 GET} by default, and the {\f1 dataType} is {\f1 jsonp} in order to enable cross-domain requests.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1     paginator_core: \{\line
      // the type of the request (GET by default)\line
      type: 'GET',\line
\line
      // the type of reply (jsonp by default)\line
      dataType: 'jsonp',\line
\line
      // the URL (or base URL) for the service\line
      url: 'http://odata.netflix.com/Catalog/People(49446)/TitlesActedIn?'\line
    \},\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 4. Configure how the library will show the results\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We need to tell the library how many items per page would we like to see, etc\u8230?\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1     paginator_ui: \{\line
      // the lowest page index your API allows to be accessed\line
      firstPage: 0,\line
\line
      // which page should the paginator start from\line
      // (also, the actual page the paginator is on)\line
      currentPage: 0,\line
\line
      // how many items per page should be shown\line
      perPage: 3,\line
\line
      // a default number of total pages to query in case the API or\line
      // service you are using does not support providing the total\line
      // number of pages for us.\line
      // 10 as a default in case your service doesn't return the total\line
      totalPages: 10\line
    \},\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 5. Configure the parameters we want to send to the server\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Only the base URL won\u8217't be enough for most cases, so you can pass more parameters to the server. Note how you can use functions insead of hardcoded values, and you can also reffer to the values you specified in {\f1 paginator_ui}.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1     server_api: \{\line
      // the query field in the request\line
      '$filter': '',\line
\line
      // number of items to return per request/page\line
      '$top': function() \{ return this.perPage \},\line
\line
      // how many results the request should skip ahead to\line
      // customize as needed. For the Netflix API, skipping ahead based on\line
      // page * number of results per page was necessary.\line
      '$skip': function() \{ return this.currentPage * this.perPage \},\line
\line
      // field to sort by\line
      '$orderby': 'ReleaseYear',\line
\line
      // what format would you like to request results in?\line
      '$format': 'json',\line
\line
      // custom parameters\line
      '$inlinecount': 'allpages',\line
      '$callback': 'callback'\line
    \},\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 6. Finally, configure Collection.parse() and we\u8217're done\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The last thing we need to do is configure our collection\u8217's {\f1 parse()} method. We want to ensure we\u8217're returning the correct part of our JSON response containing the data our collection will be populated with, which below is {\f1 response.d.results} (for the Netflix API).\par}
{\pard \ql \f0 \sa180 \li0 \fi0 You might also notice that we\u8217're setting {\f1 this.totalPages} to the total page count returned by the API. This allows us to define the maximum number of (result) pages available for the current/last request so that we can clearly display this in the UI. It also allows us to infuence whether clicking say, a \u8216'next\u8217' button should proceed with a request or not.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1         parse: function (response) \{\line
            // Be sure to change this based on how your results\line
            // are structured (e.g d.results is Netflix specific)\line
            var tags = response.d.results;\line
            //Normally this.totalPages would equal response.d.__count\line
            //but as this particular NetFlix request only returns a\line
            //total count of items for the search, we divide.\line
            this.totalPages = Math.floor(response.d.__count / this.perPage);\line
            return tags;\line
        \}\line
    \});\line
\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Convenience methods:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For your convenience, the following methods are made available for use in your views to interact with the {\f1 requestPager}:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b Collection.goTo( n, options )} - go to a specific page\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b Collection.requestNextPage( options )} - go to the next page\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b Collection.requestPreviousPage( options )} - go to the previous page\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b Collection.howManyPer( n )} - set the number of items to display per page\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b requestPager} collection\u8217's methods {\f1 .goTo()}, {\f1 .requestNextPage()} and {\f1 .requestPreviousPage()} are all extension of the original {\field{\*\fldinst{HYPERLINK "http://documentcloud.github.com/backbone/#Collection-fetch"}}{\fldrslt{\ul
Backbone Collection.fetch() method
}}}
. As so, they all can take the same option object as parameter.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This option object can use {\f1 success} and {\f1 error} parameters to pass a function to be executed after server answer.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 Collection.goTo(n, \{\line
  success: function( collection, response ) \{\line
    // called is server request success\line
  \},\line
  error: function( collection, response ) \{\line
    // called if server request fail\line
  \}\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 To manage callback, you could also use the {\field{\*\fldinst{HYPERLINK "http://api.jquery.com/jQuery.ajax/#jqXHR"}}{\fldrslt{\ul
jqXHR
}}}
 returned by these methods to manage callback.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 Collection\line
  .requestNextPage()\line
  .done(function( data, textStatus, jqXHR ) \{\line
    // called is server request success\line
  \})\line
  .fail(function( data, textStatus, jqXHR ) \{\line
    // called if server request fail\line
  \})\line
  .always(function( data, textStatus, jqXHR ) \{\line
    // do something after server request is complete\line
  \});\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 If you\u8217'd like to add the incoming models to the current collection, instead of replacing the collection\u8217's contents, pass {\f1 \{add: true\}} as an option to these methods.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 Collection.requestPreviousPage(\{ add: true \});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Paginator.clientPager\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The {\f1 clientPager} works similar to the {\f1 requestPager}, except that our configuration values influence the pagination of data already returned at a UI-level. Whilst not shown (yet) there is also a lot more UI logic that ties in with the {\f1 clientPager}. An example of this can be seen in \u8216'views/clientPagination.js\u8217'.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 1. Create a new paginated collection with a model and URL\par}
{\pard \ql \f0 \sa180 \li0 \fi0 As with {\f1 requestPager}, let\u8217's first create a new Paginated {\f1 Backbone.Paginator.clientPager} collection, with a model:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1     var PaginatedCollection = Backbone.Paginator.clientPager.extend(\{\line
\line
        model: model,\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 2. Configure the base URL and the type of the request\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We need to set a base URL. The {\f1 type} of the request is {\f1 GET} by default, and the {\f1 dataType} is {\f1 jsonp} in order to enable cross-domain requests.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1     paginator_core: \{\line
      // the type of the request (GET by default)\line
      type: 'GET',\line
\line
      // the type of reply (jsonp by default)\line
      dataType: 'jsonp',\line
\line
      // the URL (or base URL) for the service\line
      url: 'http://odata.netflix.com/v2/Catalog/Titles?&'\line
    \},\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 3. Configure how the library will show the results\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We need to tell the library how many items per page would we like to see, etc\u8230?\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1     paginator_ui: \{\line
      // the lowest page index your API allows to be accessed\line
      firstPage: 1,\line
\line
      // which page should the paginator start from\line
      // (also, the actual page the paginator is on)\line
      currentPage: 1,\line
\line
      // how many items per page should be shown\line
      perPage: 3,\line
\line
      // a default number of total pages to query in case the API or\line
      // service you are using does not support providing the total\line
      // number of pages for us.\line
      // 10 as a default in case your service doesn't return the total\line
      totalPages: 10\line
    \},\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 4. Configure the parameters we want to send to the server\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Only the base URL won\u8217't be enough for most cases, so you can pass more parameters to the server. Note how you can use functions insead of hardcoded values, and you can also reffer to the values you specified in {\f1 paginator_ui}.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1     server_api: \{\line
      // the query field in the request\line
      '$filter': 'substringof(\\'america\\',Name)',\line
\line
      // number of items to return per request/page\line
      '$top': function() \{ return this.perPage \},\line
\line
      // how many results the request should skip ahead to\line
      // customize as needed. For the Netflix API, skipping ahead based on\line
      // page * number of results per page was necessary.\line
      '$skip': function() \{ return this.currentPage * this.perPage \},\line
\line
      // field to sort by\line
      '$orderby': 'ReleaseYear',\line
\line
      // what format would you like to request results in?\line
      '$format': 'json',\line
\line
      // custom parameters\line
      '$inlinecount': 'allpages',\line
      '$callback': 'callback'\line
    \},\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 5. Finally, configure Collection.parse() and we\u8217're done\par}
{\pard \ql \f0 \sa180 \li0 \fi0 And finally we have our {\f1 parse()} method, which in this case isn\u8217't concerned with the total number of result pages available on the server as we have our own total count of pages for the paginated data in the UI.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1     parse: function (response) \{\line
            var tags = response.d.results;\line
            return tags;\line
        \}\line
\line
    \});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Convenience methods:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 As mentioned, your views can hook into a number of convenience methods to navigate around UI-paginated data. For {\f1 clientPager} these include:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b Collection.goTo(n)} - go to a specific page\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b Collection.previousPage()} - go to the previous page\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b Collection.nextPage()} - go to the next page\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b Collection.howManyPer(n)} - set how many items to display per page\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b Collection.setSort(sortBy, sortDirection)} - update sort on the current view. Sorting will automatically detect if you\u8217're trying to sort numbers (even if they\u8217're strored as strings) and will do the right thing.\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b Collection.setFilter(filterFields, filterWords)} - filter the current view. Filtering supports multiple words without any specific order, so you\u8217'll basically get a full-text search ability. Also, you can pass it only one field from the model, or you can pass an array with fields and all of them will get filtered. Last option is to pass it an object containing a comparison method and rules. Currently, only {\f1 levenshtein} method is available.\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1   this.collection.setFilter(\line
    \{'Name': \{cmp_method: 'levenshtein', max_distance: 7\}\}\line
    , "Amreican P" // Note the switched 'r' and 'e', and the 'P' from 'Pie'\line
  );\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Also note that the levenshtein plugin should be loaded and enabled using the {\f1 useLevenshteinPlugin} variable.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Last but not less important: Performing Levenshtein comparison returns the {\f1 distance} between to strings. It won\u8217't let you {\i search} lenghty text.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The distance between two strings means the number of characters that should be added, removed or moved to the left or to the right so the strings get equal.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 That means that comparing \u8220"Something\u8221" in \u8220"This is a test that could show something\u8221" will return 32, which is bigger than comparing \u8220"Something\u8221" and \u8220"ABCDEFG\u8221" (9).\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Use levenshtein only for short texts (titles, names, etc).\par}
{\pard \ql \f0 \sa180 \li360 \fi-360 \bullet \tx360\tab {\b Collection.doFakeFilter(filterFields, filterWords)} - returns the models count after fake-applying a call to {\f1 Collection.setFilter}.\par}
{\pard \ql \f0 \sa180 \li360 \fi-360 \bullet \tx360\tab {\b Collection.setFieldFilter(rules)} - filter each value of each model according to {\f1 rules} that you pass as argument. Example: You have a collection of books with \u8216'release year\u8217' and \u8216'author\u8217'. You can filter only the books that were released between 1999 and 2003. And then you can add another {\f1 rule} that will filter those books only to authors who\u8217's name start with \u8216'A\u8217'. Possible rules: function, required, min, max, range, minLength, maxLength, rangeLength, oneOf, equalTo, pattern.\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 \line
  my_collection.setFieldFilter([\line
    \{field: 'release_year', type: 'range', value: \{min: '1999', max: '2003'\}\},\line
    \{field: 'author', type: 'pattern', value: new RegExp('A*', 'igm')\}\line
  ]);\line
\line
  //Rules:\line
  //\line
  //var my_var = 'green';\line
  //\line
  //\{field: 'color', type: 'equalTo', value: my_var\}\line
  //\{field: 'color', type: 'function', value: function(field_value)\{ return field_value == my_var; \} \}\line
  //\{field: 'color', type: 'required'\}\line
  //\{field: 'number_of_colors', type: 'min', value: '2'\}\line
  //\{field: 'number_of_colors', type: 'max', value: '4'\}\line
  //\{field: 'number_of_colors', type: 'range', value: \{min: '2', max: '4'\} \}\line
  //\{field: 'color_name', type: 'minLength', value: '4'\}\line
  //\{field: 'color_name', type: 'maxLength', value: '6'\}\line
  //\{field: 'color_name', type: 'rangeLength', value: \{min: '4', max: '6'\}\}\line
  //\{field: 'color_name', type: 'oneOf', value: ['green', 'yellow']\}\line
  //\{field: 'color_name', type: 'pattern', value: new RegExp('gre*', 'ig')\}\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b Collection.doFakeFieldFilter(rules)} - returns the models count after fake-applying a call to {\f1 Collection.setFieldFilter}.\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Implementation notes:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 You can use some variables in your {\f1 View} to represent the actual state of the paginator.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 totalUnfilteredRecords} - Contains the number of records, including all records filtered in any way. (Only available in {\f1 clientPager})\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 totalRecords} - Contains the number of records\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 currentPage} - The actual page were the paginator is at.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 perPage} - The number of records the paginator will show per page.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 totalPages} - The number of total pages.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 startRecord} - The posicion of the first record shown in the current page (eg 41 to 50 from 2000 records) (Only available in {\f1 clientPager})\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 endRecord} - The posicion of the last record shown in the current page (eg 41 to 50 from 2000 records) (Only available in {\f1 clientPager})\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Plugins\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Diacritic.js}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 A plugin for Backbone.Paginator that replaces diacritic characters ({\f1 \u180?}, {\f1 \u733?}, {\f1 \u783?}, {\f1 \u730?},{\f1 ~} etc.) with characters that match them most closely. This is particularly useful for filtering.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 To enable the plugin, set {\f1 this.useDiacriticsPlugin} to true, as can be seen in the example below:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 Paginator.clientPager = Backbone.Collection.extend(\{\line
\line
    // Default values used when sorting and/or filtering.\line
    initialize: function()\{\line
      this.useDiacriticsPlugin = true; // use diacritics plugin if available\line
    ...\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Backbone & jQuery Mobile\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Resolving the routing conflicts\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The first major hurdle developers typically run into when building Backbone applications with jQuery Mobile is that both frameworks have their own opinions about how to handle application navigation.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Backbone\u8217's routers offer an explicit way to define custom navigation routes through {\f1 Backbone.Router}, whilst jQuery Mobile encourages the use of URL hash fragments to reference separate \u8216'pages\u8217' or views in the same document. jQuery Mobile also supports automatically pulling in external content for links through XHR calls meaning that there can be quite a lot of inter-framework confusion about what a link pointing at \u8216'#photo/id\u8217' should actually be doing.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Some of the solutions that have been previously proposed to work-around this problem included manually patching Backbone or jQuery Mobile. I discourage opting for these techniques as it becomes necessary to manually patch your framework builds when new releases get made upstream.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 There\u8217's also {\field{\*\fldinst{HYPERLINK "https://github.com/azicchetti/jquerymobile-router"}}{\fldrslt{\ul
jQueryMobile router
}}}
, which tries to solve this problem differently, however I think my proposed solution is both simpler and allows both frameworks to cohabit quite peacefully without the need to extend either. What we\u8217're after is a way to prevent one framework from listening to hash changes so that we can fully rely on the other (e.g. {\f1 Backbone.Router}) to handle this for us exclusively.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Using jQuery Mobile this can be done by setting:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 $.mobile.hashListeningEnabled = false;\par}
{\pard \ql \f0 \sa180 \li0 \fi0 prior to initializing any of your other code.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 I discovered this method looking through some jQuery Mobile commits that didn\u8217't make their way into the official docs, but am happy to see that they are now covered here http://jquerymobile.com/test/docs/api/globalconfig.html in more detail.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The next question that arises is, if we\u8217're preventing jQuery Mobile from listening to URL hash changes, how can we still get the benefit of being able to navigate to other sections in a document using the built-in transitions and effects supported? Good question. This can now be solve by simply calling {\f1 $.mobile.changePage()} as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var url = '#about',\line
    effect = 'slideup',\line
    reverse = false,\line
    changeHash = false;\line
\line
$.mobile.changePage( url , \{ transition: effect\}, reverse, changeHash );\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In the above sample, {\f1 url} can refer to a URL or a hash identifier to navigate to, {\f1 effect} is simply the transition effect to animate the page in with and the final two parameters decide the direction for the transition ({\f1 reverse}) and whether or not the hash in the address bar should be updated ({\f1 changeHash}). With respect to the latter, I typically set this to false to avoid managing two sources for hash updates, but feel free to set this to true if you\u8217're comfortable doing so.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Note:} For some parallel work being done to explore how well the jQuery Mobile Router plugin works with Backbone, you may be interested in checking out {\field{\*\fldinst{HYPERLINK "https://github.com/Filirom1/jquery-mobile-backbone-requirejs"}}{\fldrslt{\ul
https://github.com/Filirom1/jquery-mobile-backbone-requirejs
}}}
.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Practical: A Backbone, Require.js/AMD app with jQuery Mobile\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Note:} The code for this practical can be found in {\f1 practicals/modular-mobile-app}.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Getting started\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Once you feel comfortable with the {\field{\*\fldinst{HYPERLINK "http://msdn.microsoft.com/en-us/scriptjunkie/hh377172.aspx"}}{\fldrslt{\ul
Backbone fundamentals
}}}
 and you\u8217've put together a rough wireframe of the app you may wish to build, start to think about your application architecture. Ideally, you\u8217'll want to logically separate concerns so that it\u8217's as easy as possible to maintain the app in the future.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Namespacing}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For this application, I opted for the nested namespacing pattern. Implemented correctly, this enables you to clearly identify if items being referenced in your app are views, other modules and so on. This initial structure is a sane place to also include application defaults (unless you prefer maintaining those in a separate file).\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 window.mobileSearch = window.mobileSearch || \{\line
    views: \{\line
        appview: new AppView()\line
    \},\line
    routers:\{\line
        workspace:new Workspace()\line
    \},\line
    utils: utils,\line
    defaults: \{\line
        resultsPerPage: 16,\line
        safeSearch: 2,\line
        maxDate:'',\line
        minDate:'01/01/1970'\line
    \}\line
\}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Models}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In the Flickly application, there are at least two unique types of data that need to be modeled - search results and individual photos, both of which contain additional meta-data like photo titles. If you simplify this down, search results are actually groups of photos in their own right, so the application only requires:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab A single model (a photo or \u8216'result\u8217' entry)\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab A result collection (containing a group of result entries) for search results\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab A photo collection (containing one or more result entries) for individual photos or photos with more than one image\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Views}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The views we\u8217'll need include an application view, a search results view and a photo view. Static views or pages of the single-page application which do not require a dynamic element to them (e.g an \u8216'about\u8217' page) can be easily coded up in your document\u8217's markup, independent of Backbone.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Routers}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 A number of possible routes need to be taken into consideration:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Basic search queries {\f1 #search/kiwis}\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Search queries with additional parameters (e.g sort, pagination) {\f1 #search/kiwis/srelevance/p7}\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Queries for specific photos {\f1 #photo/93839}\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab A default route (no parameters passed)\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This tutorial will be expanded shortly to fully cover the demo application. In the mean time, please see the practicals folder for the completed application that demonstrates the router resolution discussed earlier between Backbone and jQuery Mobile.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 jQuery Mobile: Going beyond mobile application development\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The majority of jQM apps I\u8217've seen in production have been developed for the purpose of providing an optimal experience to users on mobile devices. Given that the framework was developed for this purpose, there\u8217's nothing fundamentally wrong with this, but many developers forget that jQM is a UI framework not dissimilar to jQuery UI. It\u8217's using the widget factory and is capable of being used for a lot more than we give it credit for.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 If you open up Flickly in a desktop browser, you\u8217'll get an image search UI that\u8217's modeled on Google.com, however, review the components (buttons, text inputs, tabs) on the page for a moment. The desktop UI doesn\u8217't look anything like a mobile application yet I\u8217'm still using jQM for theming mobile components; the tabs, date-picker, sliders - everything in the desktop UI is re-using what jQM would be providing users on mobile devices. Thanks to some media queries, the desktop UI can make optimal use of whitespace, expanding component blocks out and providing alternative layouts whilst still making use of jQM as a component framework.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The benefit of this is that I don\u8217't need to go pulling in jQuery UI separately to be able to take advantage of these features. Thanks to the recent ThemeRoller my components can look pretty much exactly how I would like them to and users of the app can get a jQM UI for lower-resolutions and a jQM-ish UI for everything else.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The takeaway here is just to remember that if you\u8217're not (already) going through the hassle of conditional script/style loading based on screen-resolution (using matchMedia.js etc), there are simpler approaches that can be taken to cross-device component theming.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs36 Unit Testing\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Unit Testing Backbone Applications With Jasmine\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Introduction\par}
{\pard \ql \f0 \sa180 \li0 \fi0 One definition of unit testing is the process of taking the smallest piece of testable code in an application, isolating it from the remainder of your codebase and determining if it behaves exactly as expected. In this section, we\u8217'll be taking a look at how to unit test Backbone applications using a popular JavaScript testing framework called {\field{\*\fldinst{HYPERLINK "http://pivotal.github.com/jasmine/"}}{\fldrslt{\ul
Jasmine
}}}
 from Pivotal Labs.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For an application to be considered \u8216'well\u8217'-tested, distinct functionality should ideally have its own separate unit tests where it\u8217's tested against the different conditions you expect it to work under. All tests must pass before functionality is considered \u8216'complete\u8217'. This allows developers to both modify a unit of code and its dependencies with a level of confidence about whether these changes have caused any breakage.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 As a basic example of unit testing is where a developer may wish to assert whether passing specific values through to a sum function results in the correct output being returned. For an example more relevant to this book, we may wish to assert whether a user adding a new Todo item to a list correctly adds a Model of a specific type to a Todos Collection.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 When building modern web-applications, it\u8217's typically considered best-practice to include automated unit testing as a part of your development process. Whilst we\u8217'll be focusing on Jasmine as a solution for this, there are a number of other alternatives worth considering, including QUnit.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Jasmine\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Jasmine describes itself as a behavior-driven development (BDD) framework for testing JavaScript code. Before we jump into how the framework works, it\u8217's useful to understand exactly what {\field{\*\fldinst{HYPERLINK "http://en.wikipedia.org/wiki/Behavior_Driven_Development"}}{\fldrslt{\ul
BDD
}}}
 is.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 BDD is a second-generation testing approach first described by {\field{\*\fldinst{HYPERLINK "http://dannorth.net/introducing-bdd/"}}{\fldrslt{\ul
Dan North
}}}
 (the authority on BDD) which attempts to test the behavior of software. It\u8217's considered second-generation as it came out of merging ideas from Domain driven design (DDD) and lean software development, helping teams to deliver high quality software by answering many of the more confusing questions early on in the agile process. Such questions commonly include those concerning documentation and testing.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 If you were to read a book on BDD, it\u8217's likely to also be described as being \u8216'outside-in and pull-based\u8217'. The reason for this is that it borrows the idea of pulling features from Lean manufacturing which effectively ensures that the right software solutions are being written by a) focusing on expected outputs of the system and b) ensuring these outputs are achieved.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 BDD recognizes that there are usually multiple stakeholders in a project and not a single amorphous user of the system. These different groups will be affected by the software being written in differing ways and will have a varying opinion of what quality in the system means to them. It\u8217's for this reason that it\u8217's important to understand who the software will be bringing value you and exactly what in it will be valuable to them.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Finally, BDD relies on automation. Once you\u8217've defined the quality expected, your team will likely want to check on the functionality of the solution being built regularly and compare it to the results they expect. In order to facilitate this efficiently, the process has to be automated. BDD relies heavily on the automation of specification-testing and Jasmine is a tool which can assist with this.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 BDD helps both developers and non-technical stakeholders:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Better understand and represent the models of the problems being solved\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Explain supported tests cases in a language that non-developers can read\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Focus on minimizing translation of the technical code being written and the domain language spoken by the business\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 What this means is that developers should be able to show Jasmine unit tests to a project stakeholder and (at a high level, thanks to a common vocabulary being used) they\u8217'll ideally be able to understand what the code supports.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Developers often implement BDD in unison with another testing paradigm known as {\field{\*\fldinst{HYPERLINK "http://en.wikipedia.org/wiki/Test-driven_development"}}{\fldrslt{\ul
TDD
}}}
 (test-driven development). The main idea behind TDD is:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Write unit tests which describe the functionality you would like your code to support\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Watch these tests fail (as the code to support them hasn\u8217't yet been written)\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Write code to make the tests pass\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Rinse, repeat and refactor\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In this chapter we\u8217're going to use both BDD (with TDD) to write unit tests for a Backbone application.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b {\i Note:}} I\u8217've seen a lot of developers also opt for writing tests to validate behavior of their code after having written it. While this is fine, note that it can come with pitfalls such as only testing for behavior your code currently supports, rather than behavior the problem needs to be supported.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Suites, Specs & Spies\par}
{\pard \ql \f0 \sa180 \li0 \fi0 When using Jasmine, you\u8217'll be writing suites and specifications (specs). Suites basically describe scenarios whilst specs describe what can be done in these scenarios.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Each spec is a JavaScript function, described with a call to {\f1 it()} using a description string and a function. The description should describe the behaviour the particular unit of code should exhibit and keeping in mind BDD, it should ideally be meaningful. Here\u8217's an example of a basic spec:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 it('should be incrementing in value', function()\{\line
    var counter = 0;\line
    counter++;\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 On its own, a spec isn\u8217't particularly useful until expectations are set about the behavior of the code. Expectations in specs are defined using the {\f1 expect()} function and an {\field{\*\fldinst{HYPERLINK "https://github.com/pivotal/jasmine/wiki/Matchers"}}{\fldrslt{\ul
expectation matcher
}}}
 (e.g {\f1 toEqual()}, {\f1 toBeTruthy()}, {\f1 toContain()}). A revised example using an expectation matcher would look like:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 it('should be incrementing in value', function()\{\line
    var counter = 0;\line
    counter++;\line
    expect(counter).toEqual(1);\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The above code passes our behavioral expectation as {\f1 counter} equals 1. Notice how easy this was to read the expectation on the last line (you probably grokked it without any explanation).\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Specs are grouped into suites which we describe using Jasmine\u8217's {\f1 describe()} function, again passing a string as a description and a function. The name/description for your suite is typically that of the component or module you\u8217're testing.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Jasmine will use it as the group name when it reports the results of the specs you\u8217've asked it to run. A simple suite containing our sample spec could look like:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 describe('Stats', function()\{\line
    it('can increment a number', function()\{\line
        ...\line
    \});\line
\line
    it('can subtract a number', function()\{\line
        ...\line
    \});\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Suites also share a functional scope and so it\u8217's possible to declare variables and functions inside a describe block which are accessible within specs:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 describe('Stats', function()\{\line
    var counter = 1;\line
\line
    it('can increment a number', function()\{\line
        // the counter was = 1\line
        counter = counter + 1;\line
        expect(counter).toEqual(2);\line
    \});\line
\line
    it('can subtract a number', function()\{\line
        // the counter was = 2\line
        counter = counter - 1;\line
        expect(counter).toEqual(1);\line
    \});\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b {\i Note:}} Suites are executed in the order in which they are described, which can be useful to know if you would prefer to see test results for specific parts of your application reported first.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Jasmine also supports {\b spies} - a way to mock, spy and fake behavior in our unit tests. Spies replace the function they\u8217're spying on, allowing us to simulate behavior we would like to mock (i.e test free of the actual implementation).\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In the below example, we\u8217're spying on the {\f1 setComplete} method of a dummy Todo function to test that arguments can be passed to it as expected.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var Todo = function()\{\line
\};\line
\line
Todo.prototype.setComplete = function (arg)\{\line
    return arg;\line
\}\line
\line
describe('a simple spy', function()\{\line
    it('should spy on an instance method of a Todo', function()\{\line
        var myTodo = new Todo();\line
        spyOn(myTodo, 'setComplete');\line
        myTodo.setComplete('foo bar');\line
\line
        expect(myTodo.setComplete).toHaveBeenCalledWith('foo bar');\line
\line
        var myTodo2 = new Todo();\line
        spyOn(myTodo2, 'setComplete');\line
\line
        expect(myTodo2.setComplete).not.toHaveBeenCalled();\line
\line
    \});\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 What you\u8217're more likely to use spies for is testing {\field{\*\fldinst{HYPERLINK "http://en.wikipedia.org/wiki/Asynchronous_communication"}}{\fldrslt{\ul
asynchronous
}}}
 behavior in your application such as AJAX requests. Jasmine supports:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Writing tests which can mock AJAX requests using spies. This allows us to test code which runs before an AJAX request and right after. It\u8217's also possible to mock/fake responses the server can return and the benefit of this type of testing is that it\u8217's faster as no real calls are being made to a server\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Asynchronous tests which don\u8217't rely on spies\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For the first kind of test, it\u8217's possible to both fake an AJAX request and verify that the request was both calling the correct URL and executed a callback where one was provided.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 it("the callback should be executed on success", function () \{\line
    spyOn($, "ajax").andCallFake(function(options) \{\line
        options.success();\line
    \});\line
\line
    var callback = jasmine.createSpy();\line
    getTodo(15, callback);\line
\line
    expect($.ajax.mostRecentCall.args[0]["url"]).toEqual("/todos/15");\line
    expect(callback).toHaveBeenCalled();\line
\});\line
\line
function getTodo(id, callback) \{\line
    $.ajax(\{\line
        type: "GET",\line
        url: "/todos/" + id,\line
        dataType: "json",\line
        success: callback\line
    \});\line
\}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 If you feel lost having seen matchers like {\f1 andCallFake()} and {\f1 toHaveBeenCalled()}, don\u8217't worry. All of these are Spy-specific matchers and are documented on the Jasmine {\field{\*\fldinst{HYPERLINK "https://github.com/pivotal/jasmine/wiki/Spies"}}{\fldrslt{\ul
wiki
}}}
.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For the second type of test (asynchronous tests), we can take the above further by taking advantage of three other methods Jasmine supports:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab runs(function) - a block which runs as if it was directly called\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab waits(timeout) - a native timeout before the next block is run\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab waitsFor(function, optional message, optional timeout) - a way to pause specs until some other work has completed. Jasmine waits until the supplied function returns true here before it moves on to the next block.\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 it("should make an actual AJAX request to a server", function () \{\line
\line
    var callback = jasmine.createSpy();\line
    getTodo(16, callback);\line
\line
    waitsFor(function() \{\line
        return callback.callCount > 0;\line
    \});\line
\line
    runs(function() \{\line
        expect(callback).toHaveBeenCalled();\line
    \});\line
\});\line
\line
function getTodo(id, callback) \{\line
    $.ajax(\{\line
        type: "GET",\line
        url: "todos.json",\line
        dataType: "json",\line
        success: callback\line
    \});\line
\}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b {\i Note:}} It\u8217's useful to remember that when making real requests to a web server in your unit tests, this has the potential to massively slow down the speed at which tests run (due to many factors including server latency). As this also introduces an external dependency that can (and should) be minimized in your unit testing, it is strongly recommended that you opt for spies to remove the need for a web server to be used here.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 beforeEach and afterEach()\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Jasmine also supports specifying code that can be run before each ({\f1 beforeEach()}) and after each ({\f1 afterEach}) test. This is useful for enforcing consistent conditions (such as resetting variables that may be required by specs). In the following example, {\f1 beforeEach()} is used to create a new sample Todo model specs can use for testing attributes.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 beforeEach(function()\{\line
   this.todo = new Backbone.Model(\{\line
      text: "Buy some more groceries",\line
      done: false\line
   \});\line
\});\line
\line
it("should contain a text value if not the default value", function()\{\line
   expect(this.todo.get('text')).toEqual("Buy some more groceries");\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Each nested {\f1 describe()} in your tests can have their own {\f1 beforeEach()} and {\f1 afterEach()} methods which support including setup and teardown methods relevant to a particular suite. We\u8217'll be using {\f1 beforeEach()} in practice a little later.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Shared scope\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In the previous section you may have noticed that we initially declared a variable {\f1 this.todo} in our {\f1 beforeEach()} call and were then able to continue using this in {\f1 afterEach()}. This is thanks to a powerful feature of Jasmine known as shared functional scope. Shared scope allows {\f1 this} properties to be common to all blocks (including {\f1 runs()}), but not declared variables (i.e {\f1 var}s).\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Getting setup\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Now that we\u8217've reviewed some fundamentals, let\u8217's go through downloading Jasmine and getting everything setup to write tests.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 A standalone release of Jasmine can be {\field{\*\fldinst{HYPERLINK "http://pivotal.github.com/jasmine/download.html"}}{\fldrslt{\ul
downloaded
}}}
 from the official release page.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 You\u8217'll need a file called SpecRunner.html in addition to the release. It can be downloaded from https://github.com/pivotal/jasmine/tree/master/lib/jasmine-core/example or as part of a download of the complete Jasmine {\field{\*\fldinst{HYPERLINK "https://github.com/pivotal/jasmine/zipball/master"}}{\fldrslt{\ul
repo
}}}
.Alternatively, you can {\f1 git clone} the main Jasmine repository from https://github.com/pivotal/jasmine.git.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Let\u8217's review {\field{\*\fldinst{HYPERLINK "https://github.com/pivotal/jasmine/blob/master/lib/jasmine-core/example/SpecRunner.html"}}{\fldrslt{\ul
SpecRunner.html
}}}
:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 It first includes both Jasmine and the necessary CSS required for reporting:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 <link rel="stylesheet" type="text/css" href="lib/jasmine-1.1.0.rc1/jasmine.css"/>\line
<script type="text/javascript" src="lib/jasmine-1.1.0.rc1/jasmine.js"></script>\line
<script type="text/javascript" src="lib/jasmine-1.1.0.rc1/jasmine-html.js"></script>\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Next, some sample tests are included:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 <script type="text/javascript" src="spec/SpecHelper.js"></script>\line
<script type="text/javascript" src="spec/PlayerSpec.js"></script>\par}
{\pard \ql \f0 \sa180 \li0 \fi0 And finally the sources being tested:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 <script type="text/javascript" src="src/Player.js"></script>\line
<script type="text/javascript" src="src/Song.js"></script>\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b {\i Note:}} Below this section of SpecRunner is code responsible for running the actual tests. Given that we won\u8217't be covering modifying this code, I\u8217'm going to skip reviewing it. I do however encourage you to take a look through {\field{\*\fldinst{HYPERLINK "https://github.com/pivotal/jasmine/blob/master/lib/jasmine-core/example/spec/PlayerSpec.js"}}{\fldrslt{\ul
PlayerSpec.js
}}}
 and {\field{\*\fldinst{HYPERLINK "https://github.com/pivotal/jasmine/blob/master/lib/jasmine-core/example/spec/SpecHelper.js"}}{\fldrslt{\ul
SpecHelper.js
}}}
. They\u8217're a useful basic example to go through how a minimal set of tests might work.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 TDD With Backbone\par}
{\pard \ql \f0 \sa180 \li0 \fi0 When developing applications with Backbone, it can be necessary to test both individual modules of code as well as modules, views, collections and routers. Taking a TDD approach to testing, let\u8217's review some specs for testing these Backbone components using the popular Backbone {\field{\*\fldinst{HYPERLINK "https://github.com/addyosmani/todomvc/tree/master/todo-example/backbone"}}{\fldrslt{\ul
Todo
}}}
 application. For this section we will be using a modified version of Larry Myers Backbone Koans project, which can be found in the {\f1 practicals\\jasmine-koans} folder.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Models\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The complexity of Backbone models can vary greatly depending on what your application is trying to achieve. In the following example, we\u8217're going to test default values, attributes, state changes and validation rules.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 First, we begin our suite for model testing using {\f1 describe()}:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 describe('Tests for Todo', function() \{\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Models should ideally have default values for attributes. This helps ensure that when creating instances without a value set for any specific attribute, a default one (e.g \u8220"\u8221") is used instead. The idea here is to allow your application to interact with models without any unexpected behavior.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In the following spec, we create a new Todo without any attributes passed then check to find out what the value of the {\f1 text} attribute is. As no value has been set, we expect a default value of {\f1 ""} to be returned.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 it('Can be created with default values for its attributes.', function() \{\line
    var todo = new Todo();\line
    expect(todo.get('text')).toBe("");\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 If testing this spec before your models have been written, you\u8217'll incur a failing test, as expected. What\u8217's required for the spec to pass is a default value for the attribute {\f1 text}. We can implement this default value with some other useful defaults (which we\u8217'll be using shortly) in our Todo model as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 \line
window.Todo = Backbone.Model.extend(\{\line
\line
    defaults: \{\line
      text: "",\line
      done:  false,\line
      order: 0\line
    \}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Next, we want to test that our model will pass attributes that are set such that retrieving the value of these attributes after initialization will be what we expect. Notice that here, in addition to testing for an expected value for {\f1 text}, we\u8217're also testing the other default values are what we expect them to be.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 it('Will set passed attributes on the model instance when created.', function() \{\line
    var todo = new Todo(\{ text: 'Get oil change for car.' \});\line
\line
    // what are the values expected here for each of the\line
    // attributes in our Todo?\line
\line
    expect(todo.get('text')).toBe("Get oil change for car.");\line
    expect(todo.get('done')).toBe(false);\line
    expect(todo.get('order')).toBe(0);\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Backbone models support a model.change() event which is triggered when the state of a model changes. In the following example, by \u8216'state\u8217' I\u8217'm referring to the value of a Todo model\u8217's attributes. The reason changes of state are important to test are that there may be state-dependent events in your application e.g you may wish to display a confirmation view once a Todo model has been updated.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 it('Fires a custom event when the state changes.', function() \{\line
\line
    var spy = jasmine.createSpy('-change event callback-');\line
\line
    var todo = new Todo();\line
\line
    // how do we monitor changes of state?\line
    todo.on('change', spy);\line
\line
    // what would you need to do to force a change of state?\line
    todo.set(\{ text: 'Get oil change for car.' \});\line
\line
    expect(spy).toHaveBeenCalled();\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 It\u8217's common to include validation logic in your models to ensure both the input passed from users (and other modules) in the application are \u8216'valid\u8217'. A Todo app may wish to validate the text input supplied in case it contains rude words. Similarly if we\u8217're storing the {\f1 done} state of a Todo item using booleans, we need to validate that truthy/falsy values are passed and not just any arbitrary string.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In the following spec, we take advantage of the fact that validations which fail model.validate() trigger an \u8220"error\u8221" event. This allows us to test if validations are correctly failing when invalid input is supplied.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We create an errorCallback spy using Jasmine\u8217's built in {\f1 createSpy()} method which allows us to spy on the error event as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 it('Can contain custom validation rules, and will trigger an error event on failed validation.', function() \{\line
\line
    var errorCallback = jasmine.createSpy('-error event callback-');\line
\line
    var todo = new Todo();\line
\line
    todo.on('error', errorCallback);\line
\line
    // What would you need to set on the todo properties to\line
    // cause validation to fail?\line
\line
    todo.set(\{done:'a non-integer value'\});\line
\line
    var errorArgs = errorCallback.mostRecentCall.args;\line
\line
    expect(errorArgs).toBeDefined();\line
    expect(errorArgs[0]).toBe(todo);\line
    expect(errorArgs[1]).toBe('Todo.done must be a boolean value.');\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The code to make the above failing test support validation is relatively simple. In our model, we override the validate() method (as recommended in the Backbone docs), checking to make sure a model both has a \u8216'done\u8217' property and is a valid boolean before allowing it to pass.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 validate: function(attrs) \{\line
    if (attrs.hasOwnProperty('done') && !_.isBoolean(attrs.done)) \{\line
        return 'Todo.done must be a boolean value.';\line
    \}\line
\}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 If you would like to review the final code for our Todo model, you can find it below:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var NAUGHTY_WORDS = /crap|poop|hell|frogs/gi;\line
\line
function sanitize(str) \{\line
    return str.replace(NAUGHTY_WORDS, 'rainbows');\line
\}\line
\line
window.Todo = Backbone.Model.extend(\{\line
\line
    defaults: \{\line
      text: '',\line
      done:  false,\line
      order: 0\line
    \},\line
\line
    initialize: function() \{\line
        this.set(\{text: sanitize(this.get('text'))\}, \{silent: true\});\line
    \},\line
\line
    validate: function(attrs) \{\line
        if (attrs.hasOwnProperty('done') && !_.isBoolean(attrs.done)) \{\line
            return 'Todo.done must be a boolean value.';\line
        \}\line
    \},\line
\line
    toggle: function() \{\line
        this.save(\{done: !this.get("done")\});\line
    \}\line
\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Collections\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We now need to define specs to tests a Backbone collection of Todo models (a TodoList). Collections are responsible for a number of list tasks including managing order and filtering.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 A few specific specs that come to mind when working with collections are:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Making sure we can add new Todo models as both objects and arrays\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Attribute testing to make sure attributes such as the base URL of the collection are values we expect\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Purposefully adding items with a status of {\f1 done:true} and checking against how many items the collection thinks have been completed vs.\u160?those that are remaining\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In this section we\u8217're going to cover the first two of these with the third left as an extended exercise I recommend trying out.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Testing Todo models can be added to a collection as objects or arrays is relatively trivial. First, we initialize a new TodoList collection and check to make sure its length (i.e the number of Todo models it contains) is 0. Next, we add new Todos, both as objects and arrays, checking the length property of the collection at each stage to ensure the overall count is what we expect:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 describe('Tests for TodoList', function() \{\line
\line
    it('Can add Model instances as objects and arrays.', function() \{\line
        var todos = new TodoList();\line
\line
        expect(todos.length).toBe(0);\line
\line
        todos.add(\{ text: 'Clean the kitchen' \});\line
\line
        // how many todos have been added so far?\line
        expect(todos.length).toBe(1);\line
\line
        todos.add([\line
            \{ text: 'Do the laundry', done: true \},\line
            \{ text: 'Go to the gym'\}\line
        ]);\line
\line
        // how many are there in total now?\line
        expect(todos.length).toBe(3);\line
    \});\line
...\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Similar to model attributes, it\u8217's also quite straight-forward to test attributes in collections. Here we have a spec that ensures the collection.url (i.e the url reference to the collection\u8217's location on the server) is what we expect it to be:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 it('Can have a url property to define the basic url structure for all contained models.', function() \{\line
        var todos = new TodoList();\line
\line
        // what has been specified as the url base in our model?\line
        expect(todos.url).toBe('/todos/');\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For the third spec, it\u8217's useful to remember that the implementation for our collection will have methods for filtering how many Todo items are done and how many are remaining - we can call these {\f1 done()} and {\f1 remaining()}. Consider writing a spec which creates a new collection and adds one new model that has a preset {\f1 done} state of {\f1 true} and two others that have the default {\f1 done} state of {\f1 false}. Testing the length of what\u8217's returned using {\f1 done()} and {\f1 remaining()} should allow us to know whether the state management in our application is working or needs a little tweaking.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The final implementation for our TodoList collection can be found below:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1  window.TodoList = Backbone.Collection.extend(\{\line
\line
        model: Todo,\line
\line
        url: '/todos/',\line
\line
        done: function() \{\line
            return this.filter(function(todo) \{ return todo.get('done'); \});\line
        \},\line
\line
        remaining: function() \{\line
            return this.without.apply(this, this.done());\line
        \},\line
\line
        nextOrder: function() \{\line
            if (!this.length) \{\line
                return 1;\line
            \}\line
\line
            return this.last().get('order') + 1;\line
        \},\line
\line
        comparator: function(todo) \{\line
            return todo.get('order');\line
        \}\line
\line
    \});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Views\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Before we take a look at testing Backbone views, let\u8217's briefly review a jQuery plugin that can assist with writing Jasmine specs for them.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b The Jasmine jQuery Plugin}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 As we know our Todo application will be using jQuery for DOM manipulation, there\u8217's a useful jQuery plugin called {\field{\*\fldinst{HYPERLINK "https://github.com/velesin/jasmine-jquery"}}{\fldrslt{\ul
jasmine-jquery
}}}
 we can use to help simplify BDD testing rendered elements that our views may produce.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The plugin provides a number of additional Jasmine {\field{\*\fldinst{HYPERLINK "https://github.com/pivotal/jasmine/wiki/Matchers"}}{\fldrslt{\ul
matchers
}}}
 to help test jQuery wrapped sets such as:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\f1 toBe(jQuerySelector)} e.g {\f1 expect($('<div id="some-id"></div>')).toBe('div#some-id')}\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\f1 toBeChecked()} e.g {\f1 expect($('<input type="checkbox" checked="checked"/>')).toBeChecked()}\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\f1 toBeSelected()} e.g {\f1 expect($('<option selected="selected"></option>')).toBeSelected()}\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 and {\field{\*\fldinst{HYPERLINK "https://github.com/velesin/jasmine-jquery"}}{\fldrslt{\ul
many others
}}}
. The complete list of matchers supported can be found on the project homepage. It\u8217's useful to know that similar to the standard Jasmine matchers, the custom matchers above can be inverted using the .not prefix (i.e {\f1 expect(x).not.toBe(y)}):\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 expect($('<div>I am an example</div>')).not.toHaveText(/other/)\par}
{\pard \ql \f0 \sa180 \li0 \fi0 jasmine-jquery also includes a fixtures model, allowing us to load in arbitrary HTML content we may wish to use in our tests. Fixtures can be used as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Include some HTML in an external fixtures file:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 some.fixture.html: {\f1 <div id="sample-fixture">some HTML content</div>}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Next, inside our actual test we would load it as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 loadFixtures('some.fixture.html')\line
$('some-fixture').myTestedPlugin();\line
expect($('#some-fixture')).to<the rest of your matcher would go here>\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The jasmine-jquery plugin is by default setup to load fixtures from a specific directory: spec/javascripts/fixtures. If you wish to configure this path you can do so by initially setting {\f1 jasmine.getFixtures().fixturesPath = 'your custom path'}.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Finally, jasmine-jquery includes support for spying on jQuery events without the need for any extra plumbing work. This can be done using the {\f1 spyOnEvent()} and {\f1 assert(eventName).toHaveBeenTriggered(selector)} functions. An example of usage may look as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 spyOnEvent($('#el'), 'click');\line
$('#el').click();\line
expect('click').toHaveBeenTriggeredOn($('#el'));\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b View testing}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In this section we will review three dimensions to writing specs for Backbone Views: initial setup, view rendering and finally templating. The latter two of these are the most commonly tested, however we\u8217'll review shortly why writing specs for the initialization of your views can also be of benefit.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Initial setup\par}
{\pard \ql \f0 \sa180 \li0 \fi0 At their most basic, specs for Backbone views should validate that they are being correctly tied to specific DOM elements and are backed by valid data models. The reason to consider doing this is that failures to such specs can trip up more complex tests later on and they\u8217're fairly simple to write, given the overall value offered.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 To help ensure a consistent testing setup for our specs, we use {\f1 beforeEach()} to append both an empty {\f1 UL} (#todoList) to the DOM and initialize a new instance of a TodoView using an empty Todo model. {\f1 afterEach()} is used to remove the previous #todoList {\f1 UL} as well as the previous instance of the view.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 describe('Tests for TodoView', function() \{\line
\line
    beforeEach(function() \{\line
        $('body').append('<ul id="todoList"></ul>');\line
        this.todoView = new TodoView(\{ model: new Todo() \});\line
    \});\line
\line
\line
    afterEach(function() \{\line
        this.todoView.remove();\line
        $('#todoList').remove();\line
    \});\line
\line
...\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The first spec useful to write is a check that the TodoView we\u8217've created is using the correct {\f1 tagName} (element or className). The purpose of this test is to make sure it\u8217's been correctly tied to a DOM element when it was created.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Backbone views typically create empty DOM elements once initialized, however these elements are not attached to the visible DOM in order to allow them to be constructed without an impact on the performance of rendering.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 it('Should be tied to a DOM element when created, based off the property provided.', function() \{\line
    //what html element tag name represents this view?\line
    expect(todoView.el.tagName.toLowerCase()).toBe('li');\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Once again, if the TodoView has not already been written, we will experience failing specs. Thankfully, solving this is as simple as creating a new Backbone.View with a specific {\f1 tagName}.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var todoView = Backbone.View.extend(\{\line
    tagName:  "li"\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 If instead of testing against the {\f1 tagName} you would prefer to use a className instead, we can take advantage of jasmine-jquery\u8217's {\f1 toHaveClass()} matcher to cater for this.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 it('Should have a class of "todos"'), function()\{\line
   expect(this.view.$el).toHaveClass('todos');\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The {\f1 toHaveClass()} matcher operates on jQuery objects and if the plugin hadn\u8217't been used, an exception would have been incurred (it is of course also possible to test for the className by accessing el.className if not opting to use jasmine-jquery).\par}
{\pard \ql \f0 \sa180 \li0 \fi0 You may have noticed that in {\f1 beforeEach()}, we passed our view an initial (albeit unfilled) Todo model. Views should be backed by a model instance which provides data. As this is quite important to our view\u8217's ability to function, we can write a spec to ensure a model is both defined (using the {\f1 toBeDefined()} matcher) and then test attributes of the model to ensure defaults both exist and are the value we expect them to be.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 it('Is backed by a model instance, which provides the data.', function() \{\line
\line
    expect(todoView.model).toBeDefined();\line
\line
    // what's the value for Todo.get('done') here?\line
    expect(todoView.model.get('done')).toBe(false); //or toBeFalsy()\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 View rendering\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Next we\u8217're going to take a look at writing specs for view rendering. Specifically, we want to test that our TodoView elements are actually rendering as expected.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In smaller applications, those new to BDD might argue that visual confirmation of view rendering could replace unit testing of views. The reality is that when dealing with applications that might grow to multiple-views, it often makes sense to automate this process as much as possible from the get-go. There are also aspects of rendering that require verification beyond what is visually presented on-screen (which we\u8217'll see very shortly).\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We\u8217're going to begin testing views by writing two specs. The first spec will check that the view\u8217's {\f1 render()} method is correctly returning the view instance, which is necessary for chaining. Our second spec will check that the HTML produced is exactly what we expect based on the properties of the model instance that\u8217's been associated with our TodoView.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Unlike some of the previous specs we\u8217've covered, this section will make greater use of {\f1 beforeEach()} to both demonstrate how to use nested suites and also ensure a consistent set of conditions for our specs. In our first view spec for TodoView, we\u8217're simply going to create a sample model (based on Todo) and instantiate a TodoView which associates it with the model.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 describe("TodoView", function() \{\line
\line
  beforeEach(function() \{\line
    this.model = new Backbone.Model(\{\line
      text: "My Todo",\line
      order: 1,\line
      done: false\line
    \});\line
    this.view = new TodoView(\{model:this.model\});\line
  \});\line
\line
  describe("Rendering", function() \{\line
\line
    it("returns the view object", function() \{\line
      expect(this.view.render()).toEqual(this.view);\line
    \});\line
\line
    it("produces the correct HTML", function() \{\line
      this.view.render();\line
\line
      //let's use jasmine-jquery's toContain() to avoid\line
      //testing for the complete content of a todo's markup\line
      expect(this.view.el.innerHTML)\line
        .toContain('<label class="todo-content">My Todo</label>');\line
    \});\line
\line
  \});\line
\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Once these specs are run, only the second one (\u8216'produces the correct HTML\u8217') fails. Our first spec (\u8216'returns the view object\u8217'), which is testing that the TodoView instance is returned from {\f1 render()}, only passed as this is Backbone\u8217's default behavior. We haven\u8217't yet overwritten the {\f1 render()} method with our own version.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\b Note:} For the purposes of maintaining readability, all template examples in this section will use a minimal version of the following Todo view template. As it\u8217's relatively trivial to expand this, please feel free to refer to this sample if needed:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 <div class="todo <%= done ? 'done' : '' %>">\line
        <div class="display">\line
          <input class="check" type="checkbox" <%= done ? 'checked="checked"' : '' %> />\line
          <label class="todo-content"><%= text %></label>\line
          <span class="todo-destroy"></span>\line
        </div>\line
        <div class="edit">\line
          <input class="todo-input" type="text" value="<%= content %>" />\line
        </div>\line
</div>\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The second spec fails with the following message:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 Expected '' to contain '<label class="todo-content">My Todo</label>'.}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The reason for this is the default behavior for render() doesn\u8217't create any markup. Let\u8217's write a replacement for render() which fixes this:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 render: function() \{\line
  var template = '<label class="todo-content"><%= text %></label>';\line
  var output = template\line
    .replace("<%= text %>", this.model.get('text'));\line
  this.$el.html(output);\line
  return this;\line
\}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The above specifies an inline string template and replaces fields found in the template within the \u8220"<% %>\u8221" blocks with their corresponding values from the associated model. As we\u8217're now also returning the TodoView instance from the method, the first spec will also pass. It\u8217's worth noting that there are serious drawbacks to using HTML strings in your specs to test against like this. Even minor changes to your template (a simple tab or whitespace) would cause your spec to fail, despite the rendered output being the same. It\u8217's also more time consuming to maintain as most templates in real-world applications are significantly more complex. A better option for testing rendered output is using jQuery to both select and inspect values.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 With this in mind, let\u8217's re-write the specs, this time using some of the custom matchers offered by jasmine-jquery:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 describe("Template", function() \{\line
\line
  beforeEach(function() \{\line
    this.view.render();\line
  \});\line
\line
  it("has the correct text content", function() \{\line
    expect(this.view.$('.todo-content'))\line
      .toHaveText('My Todo');\line
  \});\line
\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 It would be impossible to discuss unit testing without mentioning fixtures. Fixtures typically contain test data (e.g HTML) that is loaded in when needed (either locally or from an external file) for unit testing. So far we\u8217've been establishing jQuery expectations based on the view\u8217's el property. This works for a number of cases, however, there are instances where it may be necessary to render markup into the document. The most optimal way to handle this within specs is through using fixtures (another feature brought to us by the jasmine-jquery plugin).\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Re-writing the last spec to use fixtures would look as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 describe("TodoView", function() \{\line
\line
  beforeEach(function() \{\line
    ...\line
    setFixtures('<ul class="todos"></ul>');\line
  \});\line
\line
  ...\line
\line
  describe("Template", function() \{\line
\line
    beforeEach(function() \{\line
      $('.todos').append(this.view.render().el);\line
    \});\line
\line
    it("has the correct text content", function() \{\line
      expect($('.todos').find('.todo-content'))\line
        .toHaveText('My Todo');\line
    \});\line
\line
  \});\line
\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 What we\u8217're now doing in the above spec is appending the rendered todo item into the fixture. We then set expectations against the fixture, which may be something desirable when a view is setup against an element which already exists in the DOM. It would be necessary to provide both the fixture and test the {\f1 el} property correctly picking up the element expected when the view is instantiated.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Rendering with a templating system\par}
{\pard \ql \f0 \sa180 \li0 \fi0 JavaScript templating systems (such as Handlebars, Mustache and even Underscore\u8217's own Micro-templating) support conditional logic in template strings. What this effectively means is that we can add if/else/ternery expressions inline which can then be evaluated as needed, allowing us to build even more powerful templates.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In our case, when a user sets a Todo item to be complete (done), we may wish to provide them with visual feedback (such as a striked line through the text) to differentiate the item from those that are remaining. This can be done by attaching a new class to the item. Let\u8217's begin by writing a test we would ideally like to work:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 describe("When a todo is done", function() \{\line
\line
  beforeEach(function() \{\line
    this.model.set(\{done: true\}, \{silent: true\});\line
    $('.todos').append(this.view.render().el);\line
  \});\line
\line
  it("has a done class", function() \{\line
    expect($('.todos .todo-content:first-child'))\line
      .toHaveClass("done");\line
  \});\line
\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This will fail with the following message:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\f1 Expected '<label class="todo-content">My Todo</label>' to have class 'done'.}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 which can be fixed in the existing render() method as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 render: function() \{\line
  var template = '<label class="todo-content">' +\line
    '<%= text %></label>';\line
  var output = template\line
    .replace("<%= text %>", this.model.get('text'));\line
  this.$el.html(output);\line
  if (this.model.get('done')) \{\line
    this.$(".todo-content").addClass("done");\line
  \}\line
  return this;\line
\}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This can however get unwieldily fairly quickly. As the logic in our templates increases, so does the complexity involved. This is where templates libraries can help. As mentioned earlier, there are a number of popular options available, but for the purposes of this chapter we\u8217're going to stick to using Underscore\u8217's built-in Microtemplating. Whilst there are more advanced options you\u8217're free to explore, the benefit of this is that no additional files are required and we can easily change the existing Jasmine specs without too much adjustment.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The TodoView object modified to use Underscore templating would look as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var TodoView = Backbone.View.extend(\{\line
\line
  tagName: "li",\line
\line
  initialize: function(options) \{\line
    this.template = _.template(options.template || "");\line
  \},\line
\line
  render: function() \{\line
    this.$el.html(this.template(this.model.toJSON()));\line
    return this;\line
  \},\line
\line
  ...\line
\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Above, the initialize() method compiles a supplied Underscore template (using the _.template() function) in the instantiation. A more common way of referencing templates is placing them in a script tag using a custom script type (e.g type=\u8220"text/template\u8221"). As this isn\u8217't a script type any browser understands, it\u8217's simply ignored, however referencing the script by an id attribute allows the template to be kept separate to other parts of the page which wish to use it. In real world applications, it\u8217's preferable to either do this or load in templates stored in external files for testing.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For testing purposes, we\u8217're going to continue using the string injection approach to keep things simple. There is however a useful trick that can be applied to automatically create or extend templates in the Jasmine scope for each test. By creating a new directory (say, \u8216'templates\u8217') in the \u8216'spec\u8217' folder and adding a new script file with the following contents, to jasmine.yml or SpecRunner.html, we can add a todo property which contains the Underscore template we wish to use:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 beforeEach(function() \{\line
  this.templates = _.extend(this.templates || \{\}, \{\line
    todo: '<label class="todo-content">' +\line
            '<%= text %>' +\line
          '</label>'\line
  \});\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 To finish this off, we simply update our existing spec to reference the template when instantiating the TodoView object:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 describe("TodoView", function() \{\line
\line
  beforeEach(function() \{\line
    ...\line
    this.view = new TodoView(\{\line
      model: this.model,\line
      template: this.templates.todo\line
    \});\line
  \});\line
\line
  ...\line
\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The existing specs we\u8217've looked at would continue to pass using this approach, leaving us free to adjust the template with some additional conditional logic for Todos with a status of \u8216'done\u8217':\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 beforeEach(function() \{\line
  this.templates = _.extend(this.templates || \{\}, \{\line
    todo: '<label class="todo-content <%= done ? 'done' : '' %>"' +\line
            '<%= text %>' +\line
          '</label>'\line
  \});\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 This will now also pass without any issues. Remember that jasmine-jquery also supports loading external fixtures into your specs easily using its build in {\f1 loadFixtures()} and {\f1 readFixtures()} methods. For more information, consider reading the official jasmine-jquery {\field{\*\fldinst{HYPERLINK "https://github.com/velesin/jasmine-jquery"}}{\fldrslt{\ul
docs
}}}
.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Conclusions\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We have now covered how to write Jasmine tests for models, views and collections with Backbone.js. Whilst testing routing can at times be desirable, some developers feel it can be more optimal to leave this to third-party tools such as Selenium, so do keep this in mind.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 James Newbery was kind enough to help me with writing the Views section above and his articles on {\field{\*\fldinst{HYPERLINK "http://tinnedfruit.com/2011/04/26/testing-backbone-apps-with-jasmine-sinon-3.html"}}{\fldrslt{\ul
Testing Backbone Apps With SinonJS
}}}
 were of great inspiration (you\u8217'll actually find some Handlebars examples of the view specs in part 3 of his article). If you would like to learn more about writing spies and mocks for Backbone using {\field{\*\fldinst{HYPERLINK "http://sinonjs.org"}}{\fldrslt{\ul
SinonJS
}}}
 as well as how to test Backbone routers, do consider reading his series.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Exercise\par}
{\pard \ql \f0 \sa180 \li0 \fi0 As an exercise, I recommend now trying the Jasmine Koans in {\f1 practicals\\jasmine-joans} and trying to fix some of the purposefully failing tests it has to offer. This is an excellent way of not just learning how Jasmine specs and suites work, but working through the examples (without peeking back) will also put your Backbone skills to test too.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Further reading\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\field{\*\fldinst{HYPERLINK "http://japhr.blogspot.com/2011/11/jasmine-backbonejs-revisited.html"}}{\fldrslt{\ul
Jasmine + Backbone Revisited
}}}
\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\field{\*\fldinst{HYPERLINK "http://japhr.blogspot.com/2011/12/phantomjs-and-backbonejs-and-requirejs.html"}}{\fldrslt{\ul
Backbone, PhantomJS and Jasmine
}}}
\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Unit Testing Backbone Applications With QUnit And SinonJS\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Introduction\par}
{\pard \ql \f0 \sa180 \li0 \fi0 QUnit is a powerful JavaScript test suite written by jQuery team member {\field{\*\fldinst{HYPERLINK "http://bassistance.de/"}}{\fldrslt{\ul
J\u246?rn Zaefferer
}}}
 and used by many large open-source projects (such as jQuery and Backbone.js) to test their code. It\u8217's both capable of testing standard JavaScript code in the browser as well as code on the server-side (where environments supported include Rhino, V8 and SpiderMonkey). This makes it a robust solution for a large number of use-cases.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Quite a few Backbone.js contributors feel that QUnit is a better introductory framework for testing if you don\u8217't wish to start off with Jasmine and BDD right away. As we\u8217'll see later on in this chapter, QUnit can also be combined with third-party solutions such as SinonJS to produce an even more powerful testing solution supporting spies and mocks, which some say is preferable over Jasmine.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 My personal recommendation is that it\u8217's worth comparing both frameworks and opting for the solution that you feel the most comfortable with.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs36 QUnit\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Getting Setup\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Luckily, getting QUnit setup is a fairly straight-forward process that will take less than 5 minutes.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We first setup a testing environment composed of three files:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab A HTML {\b structure} for displaying test results,\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab The {\b qunit.js} file composing the testing framework and,\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab The {\b qunit.css} file for styling test results.\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The latter two of these can be downloaded from the {\field{\*\fldinst{HYPERLINK "http://qunitjs.com"}}{\fldrslt{\ul
QUnit website
}}}
.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 If you would prefer, you can use a hosted version of the QUnit source files for testing purposes. The hosted URLs can be found at [http://github.com/jquery/qunit/raw/master/qunit/].\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Sample HTML with QUnit-compatible markup:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 <!DOCTYPE html>\line
<html>\line
<head>\line
    <title>QUnit Test Suite</title>\line
\line
     <link rel="stylesheet" href="qunit.css">\line
     <script src="qunit.js"></script>\line
\line
     <!-- Your application -->\line
     <script src="app.js"></script>\line
\line
     <!-- Your tests -->\line
     <script src="tests.js"></script>\line
</head>\line
<body>\line
    <h1 id="qunit-header">QUnit Test Suite</h1>\line
    <h2 id="qunit-banner"></h2>\line
    <div id="qunit-testrunner-toolbar"></div>\line
    <h2 id="qunit-userAgent"></h2>\line
    <ol id="qunit-tests">test markup, hidden.</ol>\line
</body>\line
</html>\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Let\u8217's go through the elements above with qunit mentioned in their ID. When QUnit is running:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b qunit-header} shows the name of the test suite\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b qunit-banner} shows up as red if a test fails and green if all tests pass\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b qunit-testrunner-toolbar} contains additional options for configuring the display of tests\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b qunit-userAgent} displays the navigator.userAgent property\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b qunit-tests} is a container for our test results\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 When running correctly, the above test runner looks as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\cf1 [image: img/7d4de12.png]\cf0}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The numbers of the form (a, b, c) after each test name correspond to a) failed asserts, b) passed asserts and c) total asserts. Clicking on a test name expands it to display all of the assertions for that test case. Assertions in green have successfully passed.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\cf1 [image: img/9df4.png]\cf0}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 If however any tests fail, the test gets highlighted (and the qunit-banner at the top switches to red):\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\cf1 [image: img/3e5545.png]\cf0}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Assertions\par}
{\pard \ql \f0 \sa180 \li0 \fi0 QUnit supports a number of basic {\b assertions}, which are used in testing to verify that the result being returned by our code is what we expect. If an assertion fails, we know that a bug exists.Similar to Jasmine, QUnit can be used to easily test for regressions. Specifically, when a bug is found one can write an assertion to test the existence of the bug, write a patch and then commit both. If subsequent changes to the code break the test you\u8217'll know what was responsible and be able to address it more easily.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Some of the supported QUnit assertions we\u8217're going to look at first are:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\f1 ok ( state, message )} - passes if the first argument is truthy\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\f1 equal ( actual, expected, message )} - a simple comparison assertion with type coercion\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\f1 notEqual ( actual, expected, message )} - the opposite of the above\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\f1 expect( amount )} - the number of assertions expected to run within each test\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\f1 strictEqual( actual, expected, message)} - offers a much stricter comparison than {\f1 equal()} and is considered the preferred method of checking equality as it avoids stumbling on subtle coercion bugs\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\f1 deepEqual( actual, expected, message )} - similar to {\f1 strictEqual}, comparing the contents (with {\f1 ===}) of the given objects, arrays and primitives.\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Creating new test cases with QUnit is relatively straight-forward and can be done using {\f1 test()}, which constructs a test where the first argument is the {\f1 name} of the test to be displayed in our results and the second is a {\f1 callback} function containing all of our assertions. This is called as soon as QUnit is running.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Basic test case using test( name, callback ):\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var myString = 'Hello Backbone.js';\line
\line
test( 'Our first QUnit test - asserting results', function()\{\line
\line
    // ok( boolean, message )\line
    ok( true, 'the test succeeds');\line
    ok( false, 'the test fails');\line
\line
    // equal( actualValue, expectedValue, message )\line
    equal( myString, 'Hello Backbone.js', 'The value expected is Hello Backbone.js!');\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 What we\u8217're doing in the above is defining a variable with a specific value and then testing to ensure the value was what we expected it to be. This was done using the comparison assertion, {\f1 equal()}, which expects its first argument to be a value being tested and the second argument to be the expected value. We also used {\f1 ok()}, which allows us to easily test against functions or variables that evaluate to booleans.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Note: Optionally in our test case, we could have passed an \u8216'expected\u8217' value to {\f1 test()} defining the number of assertions we expect to run. This takes the form: {\f1 test( name, [expected], test );} or by manually settings the expectation at the top of the test function, like so: {\f1 expect( 1 )}. I recommend you to make it a habit and always define how many assertions you expect. More on this later.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 As testing a simple static variable is fairly trivial, we can take this further to test actual functions. In the following example we test the output of a function that reverses a string to ensure that the output is correct using {\f1 equal()} and {\f1 notEqual()}:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Comparing the actual output of a function against the expected output:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 function reverseString( str )\{\line
    return str.split("").reverse().join("");\line
\}\line
\line
test( 'reverseString()', function() \{\line
    expect( 5 );\line
    equal( reverseString('hello'), 'olleh', 'The value expected was olleh' );\line
    equal( reverseString('foobar'), 'raboof', 'The value expected was raboof' );\line
    equal( reverseString('world'), 'dlrow', 'The value expected was dlrow' );\line
    notEqual( reverseString('world'), 'dlroo', 'The value was expected to not be dlroo' );\line
    equal( reverseString('bubble'), 'double', 'The value expected was elbbub' );\line
\})\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Running these tests in the QUnit test runner (which you would see when your HTML test page was loaded) we would find that four of the assertions pass whilst the last one does not. The reason the test against {\f1 'double'} fails is because it was purposefully written incorrectly. In your own projects if a test fails to pass and your assertions are correct, you\u8217've probably just found a bug!\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Adding structure to assertions\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Housing all of our assertions in one test case can quickly become difficult to maintain, but luckily QUnit supports structuring blocks of assertions more cleanly. This can be done using {\f1 module()} - a method that allows us to easily group tests together. A typical approach to grouping might be keeping multiple tests testing a specific method as part of the same group (module).\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Basic QUnit Modules:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 module( 'Module One' );\line
test( 'first test', function() \{\} );\line
test( 'another test', function() \{\} );\line
\line
module( 'Module Two' );\line
test( 'second test', function() \{\} );\line
test( 'another test', function() \{\} );\line
\line
module( 'Module Three' );\line
test( 'third test', function() \{\} );\line
test( 'another test', function() \{\} );\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We can take this further by introducing {\f1 setup()} and {\f1 teardown()} callbacks to our modules, where {\f1 setup()} is run before each test whilst {\f1 teardown()} is run after each test.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Using setup() and teardown() :\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 module( "Module One", \{\line
    setup: function() \{\line
        // run before\line
    \},\line
    teardown: function() \{\line
        // run after\line
    \}\line
\});\line
\line
test("first test", function() \{\line
    // run the first test\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 These callbacks can be used to define (or clear) any components we wish to instantiate for use in one or more of our tests. As we\u8217'll see shortly, this is ideal for defining new instances of views, collections, models or routers from a project that we can then reference across multiple tests.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Using setup() and teardown() for instantiation and clean-up:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 // Define a simple model and collection modeling a store and\line
// list of stores\line
\line
var Store = Backbone.Model.extend(\{\});\line
\line
var StoreList = Backbone.Collection.extend(\{\line
    model: store,\line
    comparator: function( store ) \{ return store.get('name') \}\line
\});\line
\line
// Define a group for our tests\line
module( "StoreList sanity check", \{\line
    setup: function() \{\line
        this.list = new StoreList;\line
        this.list.add(new Store(\{ name: "Costcutter" \}));\line
        this.list.add(new Store(\{ name: "Target" \}));\line
        this.list.add(new Store(\{ name: "Walmart" \}));\line
        this.list.add(new Store(\{ name: "Barnes & Noble" \});\line
    \},\line
    teardown: function() \{\line
        window.errors = null;\line
    \}\line
\});\line
\line
// Test the order of items added\line
test( "test ordering", function() \{\line
    expect( 1 );\line
    var expected = ["Barnes & Noble", "Costcutter", "Target", "Walmart"];\line
    var actual = this.list.pluck("name");\line
    deepEqual( actual, expected, "is maintained by comparator" );\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Here, a list of stores is created and stored on {\f1 setup()}. A {\f1 teardown()} callback is used to simply clear our a list of errors we might be storing within the window scope, but is otherwise not needed.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Assertion examples\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Before we continue any further, let\u8217's review some more examples of how QUnits various assertions can be correctly used when writing tests:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 equal - a comparison assertion. It passes if actual == expected\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 test( "equal", 2, function() \{\line
  var actual = 6 - 5;\line
  equal( actual, true,  "passes as 1 == true" );\line
  equal( actual, 1,     "passes as 1 == 1" );\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 notEqual - a comparison assertion. It passes if actual != expected\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 test( "notEqual", 2, function() \{\line
  var actual = 6 - 5;\line
  notEqual( actual, false, "passes as 1 != false" );\line
  notEqual( actual, 0,     "passes as 1 != 0" );\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 strictEqual - a comparison assertion. It passes if actual === expected.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 test( "strictEqual", 2, function() \{\line
  var actual = 6 - 5;\line
  strictEqual( actual, true,  "fails as 1 !== true" );\line
  strictEqual( actual, 1,     "passes as 1 === 1" );\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 notStrictEqual - a comparison assertion. It passes if actual !== expected.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 test("notStrictEqual", 2, function() \{\line
  var actual = 6 - 5;\line
  notStrictEqual( actual, true,  "passes as 1 !== true" );\line
  notStrictEqual( actual, 1,     "fails as 1 === 1" );\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 deepEqual - a recursive comparison assertion. Unlike strictEqual(), it works on objects, arrays and primitives.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 test("deepEqual", 4, function() \{\line
  var actual = \{q: 'foo', t: 'bar'\};\line
  var el =  $('div');\line
  var children = $('div').children();\line
\line
  equal( actual, \{q: 'foo', t: 'bar'\},   "fails - objects are not equal using equal()" );\line
  deepEqual( actual, \{q: 'foo', t: 'bar'\},   "passes - objects are equal" );\line
  equal( el, children, "fails - jQuery objects are not the same" );\line
  deepEqual(el, children, "fails - objects not equivalent" );\line
\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 notDeepEqual - a comparison assertion. This returns the opposite of deepEqual\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 test("notDeepEqual", 2, function() \{\line
  var actual = \{q: 'foo', t: 'bar'\};\line
  notEqual( actual, \{q: 'foo', t: 'bar'\},   "passes - objects are not equal" );\line
  notDeepEqual( actual, \{q: 'foo', t: 'bar'\},   "fails - objects are equivalent" );\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 raises - an assertion which tests if a callback throws any exceptions\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 test("raises", 1, function() \{\line
  raises(function() \{\line
    throw new Error( "Oh no! It's an error!" );\line
  \}, "passes - an error was thrown inside our callback");\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Fixtures\par}
{\pard \ql \f0 \sa180 \li0 \fi0 From time to time we may need to write tests that modify the DOM. Managing the clean-up of such operations between tests can be a genuine pain, but thankfully QUnit has a solution to this problem in the form of the {\f1 #qunit-fixture} element, seen below.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Fixture markup:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 <!DOCTYPE html>\line
<html>\line
<head>\line
    <title>QUnit Test</title>\line
    <link rel="stylesheet" href="qunit.css">\line
    <script src="qunit.js"></script>\line
    <script src="app.js"></script>\line
    <script src="tests.js"></script>\line
</head>\line
<body>\line
    <h1 id="qunit-header">QUnit Test</h1>\line
    <h2 id="qunit-banner"></h2>\line
    <div id="qunit-testrunner-toolbar"></div>\line
    <h2 id="qunit-userAgent"></h2>\line
    <ol id="qunit-tests"></ol>\line
    <div id="qunit-fixture"></div>\line
</body>\line
</html>\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We can either opt to place static markup in the fixture or just insert/append any DOM elements we may need to it. QUnit will automatically reset the {\f1 innerHTML} of the fixture after each test to its original value. In case you\u8217're using jQuery, it\u8217's useful to know that QUnit checks for its availability and will opt to use {\f1 $(el).html()} instead, which will cleanup any jQuery event handlers too.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Fixtures example:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Let us now go through a more complete example of using fixtures. One thing that most of us are used to doing in jQuery is working with lists - they\u8217're often used to define the markup for menus, grids and a number of other components. You may have used jQuery plugins before that manipulated a given list in a particular way and it can be useful to test that the final (manipulated) output of the plugin is what was expected.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For the purposes of our next example, we\u8217're going to use Ben Alman\u8217's {\f1 $.enumerate()} plugin, which can prepend each item in a list by its index, optionally allowing us to set what the first number in the list is. The code snippet for the plugin can be found below, followed by an example of the output is generates:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 $.fn.enumerate = function( start ) \{\line
      if ( typeof start !== "undefined" ) \{\line
        // Since `start` value was provided, enumerate and return\line
        // the initial jQuery object to allow chaining.\line
\line
        return this.each(function(i)\{\line
          $(this).prepend( "<b>" + ( i + start ) + "</b> " );\line
        \});\line
\line
      \} else \{\line
        // Since no `start` value was provided, function as a\line
        // getter, returing the appropriate value from the first\line
        // selected element.\line
\line
        var val = this.eq( 0 ).children( "b" ).eq( 0 ).text();\line
        return Number( val );\line
      \}\line
    \};\line
\line
/*\line
    <ul>\line
      <li>1. hello</li>\line
      <li>2. world</li>\line
      <li>3. i</li>\line
      <li>4. am</li>\line
      <li>5. foo</li>\line
    </ul>\line
*/\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Let\u8217's now write some specs for the plugin. First, we define the markup for a list containing some sample items inside our {\f1 qunit-fixture} element:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 &lt;div id=&quot;qunit-fixture&quot;&gt;\line
    &lt;ul&gt;\line
      &lt;li&gt;hello&lt;/li&gt;\line
      &lt;li&gt;world&lt;/li&gt;\line
      &lt;li&gt;i&lt;/li&gt;\line
      &lt;li&gt;am&lt;/li&gt;\line
      &lt;li&gt;foo&lt;/li&gt;\line
    &lt;/ul&gt;\line
  &lt;/div&gt;\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Next, we need to think about what should be tested. {\f1 $.enumerate()} supports a few different use cases, including:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b No arguments passed} - i.e {\f1 $(el).enumerate()}\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b 0 passed as an argument} - i.e {\f1 $(el).enumerate(0)}\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b 1 passed as an argument} - i.e {\f1 $(el).enumerate(1)}\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 As the text value for each list item is of the form \u8220"n. item-text\u8221" and we only require this to test against the expected output, we can simply access the content using {\f1 $(el).eq(index).text()} (for more information on .eq() see {\field{\*\fldinst{HYPERLINK "http://api.jquery.com/eq/"}}{\fldrslt{\ul
here
}}}
).\par}
{\pard \ql \f0 \sa180 \li0 \fi0 and finally, here are our test cases:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 module("jQuery#enumerate");\line
\line
test( "No arguments passed", 5, function() \{\line
  var items = $("#qunit-fixture li").enumerate();\line
  equal( items.eq(0).text(), "1. hello", "first item should have index 1" );\line
  equal( items.eq(1).text(), "2. world", "second item should have index 2" );\line
  equal( items.eq(2).text(), "3. i", "third item should have index 3" );\line
  equal( items.eq(3).text(), "4. am", "fourth item should have index 4" );\line
  equal( items.eq(4).text(), "5. foo", "fifth item should have index 5" );\line
\});\line
\line
test( "0 passed as an argument", 5, function() \{\line
  var items = $("#qunit-fixture li").enumerate( 0 );\line
  equal( items.eq(0).text(), "0. hello", "first item should have index 0" );\line
  equal( items.eq(1).text(), "1. world", "second item should have index 1" );\line
  equal( items.eq(2).text(), "2. i", "third item should have index 2" );\line
  equal( items.eq(3).text(), "3. am", "fourth item should have index 3" );\line
  equal( items.eq(4).text(), "4. foo", "fifth item should have index 4" );\line
\});\line
\line
test( "1 passed as an argument", 3, function() \{\line
  var items = $("#qunit-fixture li").enumerate( 1 );\line
  equal( items.eq(0).text(), "1. hello", "first item should have index 1" );\line
  equal( items.eq(1).text(), "2. world", "second item should have index 2" );\line
  equal( items.eq(2).text(), "3. i", "third item should have index 3" );\line
  equal( items.eq(3).text(), "4. am", "fourth item should have index 4" );\line
  equal( items.eq(4).text(), "5. foo", "fifth item should have index 5" );\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Asynchronous code\par}
{\pard \ql \f0 \sa180 \li0 \fi0 As with Jasmine, the effort required to run synchronous tests with QUnit is fairly straight-forward. That said, what about tests that require asynchronous callbacks (such as expensive processes, Ajax requests and so on)? When we\u8217're dealing with asynchronous code, rather than letting QUnit control when the next test runs, we can inform that we need it to stop running and wait until it\u8217's okay to continue once again.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Remember: running asynchronous code without any special considerations can cause incorrect assertions to appear in other tests, so we want to make sure we get it right.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Writing QUnit tests for asynchronous code is made possible using the {\f1 start()} and {\f1 stop()} methods, which programmatically set the start and stop points during such tests. Here\u8217's a simple example:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 test("An async test", function()\{\line
   stop();\line
   expect( 1 );\line
   $.ajax(\{\line
        url: "/test",\line
        dataType: 'json',\line
        success: function( data )\{\line
            deepEqual(data, \{\line
               topic: "hello",\line
               message: "hi there!"\line
            \});\line
            start();\line
        \}\line
    \});\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 A jQuery {\f1 $.ajax()} request is used to connect to a test resource and assert that the data returned is correct. {\f1 deepEqual()} is used here as it allows us to compare different data types (e.g objects, arrays) and ensures that what is returned is exactly what we\u8217're expecting. We know that our Ajax request is asynchronous and so we first call {\f1 stop()}, run the code making the request and finally at the very end of our callback, inform QUnit that it is okay to continue running other tests.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Note: rather than including {\f1 stop()}, we can simply exclude it and substitute {\f1 test()} with {\f1 asyncTest()} if we prefer. This improves readability when dealing with a mixture of asynchronous and synchronous tests in your suite. Whilst this setup should work fine for many use-cases, there is no guarantee that the callback in our {\f1 $.ajax()} request will actually get called. To factor this into our tests, we can use {\f1 expect()} once again to define how many assertions we expect to see within our test. This is a healthy safety blanket as it ensures that if a test completes with an insufficient number of assertions, we know something went wrong and fix it.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs36 SinonJS\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Similar to the section on testing Backbone.js apps using the Jasmine BDD framework, we\u8217're nearly ready to take what we\u8217've learned and write a number of QUnit tests for our Todo application.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Before we start though, you may have noticed that QUnit doesn\u8217't support test spies. Test spies are functions which record arguments, exceptions and return values for any of their calls. They\u8217're typically used to test callbacks and how functions may be used in the application being tested. In testing frameworks, spies can usually be either anonymous functions or wrap functions which already exist.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 What is SinonJS?\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In order for us to substitute support for spies in QUnit, we will be taking advantage of a mocking framework called {\field{\*\fldinst{HYPERLINK "http://sinonjs.org/"}}{\fldrslt{\ul
SinonJS
}}}
 by Christian Johansen. We will also be using the {\field{\*\fldinst{HYPERLINK "http://sinonjs.org/qunit/"}}{\fldrslt{\ul
SinonJS-QUnit adapter
}}}
 which provides seamless integration with QUnit (meaning setup is minimal). Sinon.JS is completely test-framework agnostic and should be easy to use with any testing framework, so it\u8217's ideal for our needs.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The framework supports three features we\u8217'll be taking advantage of for unit testing our application:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b Anonymous spies}\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b Spying on existing methods}\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b A rich inspection interface}\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Using {\f1 this.spy()} without any arguments creates an anonymous spy. This is comparable to {\f1 jasmine.createSpy()} and we can observe basic usage of a SinonJS spy in the following example:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Basic Spies:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 test("should call all subscribers for a message exactly once", function () \{\line
    var message = getUniqueString();\line
    var spy = this.spy();\line
\line
    PubSub.subscribe( message, spy );\line
    PubSub.publishSync( message, "Hello World" );\line
\line
    ok( spy1.calledOnce, "the subscriber was called once" );\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We can also use {\f1 this.spy()} to spy on existing functions (like jQuery\u8217's {\f1 $.ajax}) in the example below. When spying on a function which already exists, the function behaves normally but we get access to data about its calls which can be very useful for testing purposes.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Spying On Existing Functions:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 test( "should inspect jQuery.getJSON's usage of jQuery.ajax", function () \{\line
    this.spy( jQuery, "ajax" );\line
\line
    jQuery.getJSON( "/todos/completed" );\line
\line
    ok( jQuery.ajax.calledOnce );\line
    equals( jQuery.ajax.getCall(0).args[0].url, "/todos/completed" );\line
    equals( jQuery.ajax.getCall(0).args[0].dataType, "json" );\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 SinonJS comes with a rich spy interface which allows us to test whether a spy was called with a specific argument, if it was called a specific number of times and test against the values of arguments. A complete list of features supported in the interface can be found here (http://sinonjs.org/docs/), but let\u8217's take a look at some examples demonstrating some of the most commonly used ones:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Matching arguments: test a spy was called with a specific set of arguments:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 test( "Should call a subscriber with standard matching": function () \{\line
    var spy = sinon.spy();\line
\line
    PubSub.subscribe( "message", spy );\line
    PubSub.publishSync( "message", \{ id: 45 \} );\line
\line
    assertTrue( spy.calledWith( \{ id: 45 \} ) );\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Stricter argument matching: test a spy was called at least once with specific arguments and no others:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 test( "Should call a subscriber with strict matching": function () \{\line
    var spy = sinon.spy();\line
\line
    PubSub.subscribe( "message", spy );\line
    PubSub.publishSync( "message", "many", "arguments" );\line
    PubSub.publishSync( "message", 12, 34 );\line
\line
    // This passes\line
    assertTrue( spy.calledWith("many") );\line
\line
    // This however, fails\line
    assertTrue( spy.calledWithExactly( "many" ) );\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Testing call order: testing if a spy was called before or after another spy:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 test( "Should call a subscriber and maintain call order": function () \{\line
    var a = sinon.spy();\line
    var b = sinon.spy();\line
\line
    PubSub.subscribe( "message", a );\line
    PubSub.subscribe( "event", b );\line
\line
    PubSub.publishSync( "message", \{ id: 45 \} );\line
    PubSub.publishSync( "event", [1, 2, 3] );\line
\line
    assertTrue( a.calledBefore(b) );\line
    assertTrue( b.calledAfter(a) );\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Match execution counts: test a spy was called a specific number of times:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 test( "Should call a subscriber and check call counts", function () \{\line
    var message = getUniqueString();\line
    var spy = this.spy();\line
\line
    PubSub.subscribe( message, spy );\line
    PubSub.publishSync( message, "some payload" );\line
\line
\line
    // Passes if spy was called once and only once.\line
    ok( spy.calledOnce ); // calledTwice and calledThrice are also supported\line
\line
    // The number of recorded calls.\line
    equal( spy.callCount, 1 );\line
\line
    // Directly checking the arguments of the call\line
    equals( spy.getCall(0).args[0], message );\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Stubs and mocks\par}
{\pard \ql \f0 \sa180 \li0 \fi0 SinonJS also supports two other powerful features which are useful to be aware of: stubs and mocks. Both stubs and mocks implement all of the features of the spy API, but have some added functionality.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Stubs\par}
{\pard \ql \f0 \sa180 \li0 \fi0 A stub allows us to replace any existing behaviour for a specific method with something else. They can be very useful for simulating exceptions and are most often used to write test cases when certain dependencies of your code-base may not yet be written.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Let us briefly re-explore our Backbone Todo application, which contained a Todo model and a TodoList collection. For the purpose of this walkthrough, we want to isolate our TodoList collection and fake the Todo model to test how adding new models might behave.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We can pretend that the models have yet to be written just to demonstrate how stubbing might be carried out. A shell collection just containing a reference to the model to be used might look like this:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 var TodoList = Backbone.Collection.extend(\{\line
    model: Todo\line
\});\line
\line
// Let's assume our instance of this collection is\line
this.todoList;\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Assuming our collection is instantiating new models itself, it\u8217's necessary for us to stub the models constructor function for the the test. This can be done by creating a simple stub as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 this.todoStub = sinon.stub( window, "Todo" );\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The above creates a stub of the Todo method on the window object. When stubbing a persistent object, it\u8217's necessary to restore it to its original state. This can be done in a {\f1 teardown()} as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 this.todoStub.restore();\par}
{\pard \ql \f0 \sa180 \li0 \fi0 After this, we need to alter what the constructor returns, which can be efficiently done using a plain {\f1 Backbone.Model} constructor. Whilst this isn\u8217't a Todo model, it does still provide us an actual Backbone model.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 teardown: function() \{\line
    this.model = new Backbone.Model(\{\line
      id: 2,\line
      title: "Hello world"\line
    \});\line
    this.todoStub.returns( this.model );\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The expectation here might be that this snippet would ensure our TodoList collection always instantiates a stubbed Todo model, but because a reference to the model in the collection is already present, we need to reset the model property of our collection as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 this.todoList.model = Todo;\par}
{\pard \ql \f0 \sa180 \li0 \fi0 The result of this is that when our TodoList collection instantiates new Todo models, it will return our plain Backbone model instance as desired. This allows us to write a spec for testing the addition of new model literals as follows:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 module( "Should function when instantiated with model literals", \{\line
\line
  setup:function() \{\line
\line
    this.todoStub = sinon.stub(window, "Todo");\line
    this.model = new Backbone.Model(\{\line
      id: 2,\line
      title: "Hello world"\line
    \});\line
\line
    this.todoStub.returns(this.model);\line
    this.todos = new TodoList();\line
\line
    // Let's reset the relationship to use a stub\line
    this.todos.model = Todo;\line
    this.todos.add(\{\line
      id: 2,\line
      title: "Hello world"\line
    \});\line
  \},\line
\line
  teardown: function() \{\line
    this.todoStub.restore();\line
  \}\line
\line
\});\line
\line
test("should add a model", function() \{\line
    equal( this.todos.length, 1 );\line
\});\line
\line
test("should find a model by id", function() \{\line
    equal( this.todos.get(5).get("id"), 5 );\line
  \});\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Mocks\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Mocks are effectively the same as stubs, however they mock a complete API out and have some built-in expectations for how they should be used. The difference between a mock and a spy is that as the expectations for their use are pre-defined, it will fail if any of these are not met.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Here\u8217's a snippet with sample usage of a mock based on PubSubJS. Here, we have a {\f1 clearTodo()} method as a callback and use mocks to verify its behavior.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 test("should call all subscribers when exceptions", function () \{\line
    var myAPI = \{ clearTodo: function () \{\} \};\line
\line
    var spy = this.spy();\line
    var mock = this.mock( myAPI );\line
    mock.expects( "clearTodo" ).once().throws();\line
\line
    PubSub.subscribe( "message", myAPI.clearTodo );\line
    PubSub.subscribe( "message", spy );\line
    PubSub.publishSync( "message", undefined );\line
\line
    mock.verify();\line
    ok( spy.calledOnce );\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs36 Practical\par}
{\pard \ql \f0 \sa180 \li0 \fi0 We can now begin writing test specs for our Todo application, which are listed and separated by component (e.g Models, Collections etc.). It\u8217's useful to pay attention to the name of the test, the logic being tested and most importantly the assertions being made as this will give you some insight into how what we\u8217've learned can be applied to a complete application.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 To get the most out of this section, I recommend looking at the QUnit Koans included in the {\f1 practicals\\qunit-koans} folder - this is a port of the Backbone.js Jasmine Koans over to QUnit that I converted for this post.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 {\i In case you haven\u8217't had a chance to try out one of the Koans kits as yet, they are a set of unit tests using a specific testing framework that both demonstrate how a set of specs for an application may be written, but also leave some tests unfilled so that you can complete them as an exercise.}\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Models\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For our models we want to at minimum test that:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab New instances can be created with the expected default values\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Attributes can be set and retrieved correctly\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Changes to state correctly fire off custom events where needed\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Validation rules are correctly enforced\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 module( 'About Backbone.Model');\line
\line
test('Can be created with default values for its attributes.', function() \{\line
    expect( 1 );\line
\line
    var todo = new Todo();\line
\line
    equal( todo.get('text'), "" );\line
\});\line
\line
test('Will set attributes on the model instance when created.', function() \{\line
    expect( 3 );\line
\line
    var todo = new Todo( \{ text: 'Get oil change for car.' \} );\line
\line
    equal( todo.get('text'), "Get oil change for car." );\line
    equal( todo.get('done'), false );\line
    equal( todo.get('order'), 0 );\line
\});\line
\line
test('Will call a custom initialize function on the model instance when created.', function() \{\line
    expect( 1 );\line
\line
    var toot = new Todo(\{ text: 'Stop monkeys from throwing their own crap!' \});\line
    equal( toot.get('text'), 'Stop monkeys from throwing their own rainbows!' );\line
\});\line
\line
test('Fires a custom event when the state changes.', function() \{\line
    expect( 1 );\line
\line
    var spy = this.spy();\line
    var todo = new Todo();\line
\line
    todo.on( 'change', spy );\line
    // How would you update a property on the todo here?\line
    // Hint: http://documentcloud.github.com/backbone/#Model-set\line
    todo.set( \{ text: "new text" \} );\line
\line
    ok( spy.calledOnce, "A change event callback was correctly triggered" );\line
\});\line
\line
\line
test('Can contain custom validation rules, and will trigger an error event on failed validation.', function() \{\line
    expect( 3 );\line
\line
    var errorCallback = this.spy();\line
    var todo = new Todo();\line
\line
    todo.on('error', errorCallback);\line
    // What would you need to set on the todo properties to cause validation to fail?\line
    todo.set( \{ done: "not a boolean" \} );\line
\line
    ok( errorCallback.called, 'A failed validation correctly triggered an error' );\line
    notEqual( errorCallback.getCall(0), undefined );\line
    equal( errorCallback.getCall(0).args[1], 'Todo.done must be a boolean value.' );\line
\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Collections\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For our collection we\u8217'll want to test that:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab New model instances can be added as both objects and arrays\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Changes to models result in any necessary custom events being fired\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab A {\f1 url} property for defining the URL structure for models is correctly defined\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 module( 'About Backbone.Collection');\line
\line
test( 'Can add Model instances as objects and arrays.', function() \{\line
    expect( 3 );\line
\line
    var todos = new TodoList();\line
    equal( todos.length, 0 );\line
\line
    todos.add( \{ text: 'Clean the kitchen' \} );\line
    equal( todos.length, 1 );\line
\line
    todos.add([\line
        \{ text: 'Do the laundry', done: true \},\line
        \{ text: 'Go to the gym' \}\line
    ]);\line
\line
    equal( todos.length, 3 );\line
\});\line
\line
test( 'Can have a url property to define the basic url structure for all contained models.', function() \{\line
    expect( 1 );\line
    var todos = new TodoList();\line
    equal( todos.url, '/todos/' );\line
\});\line
\line
test('Fires custom named events when the models change.', function() \{\line
    expect(2);\line
\line
    var todos = new TodoList();\line
    var addModelCallback = this.spy();\line
    var removeModelCallback = this.spy();\line
\line
    todos.on( 'add', addModelCallback );\line
    todos.on( 'remove', removeModelCallback );\line
\line
    // How would you get the 'add' event to trigger?\line
    todos.add( \{text:"New todo"\} );\line
\line
    ok( addModelCallback.called );\line
\line
    // How would you get the 'remove' callback to trigger?\line
    todos.remove( todos.last() );\line
\line
    ok( removeModelCallback.called );\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Views\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For our views we want to ensure:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab They are being correctly tied to a DOM element when created\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab They can render, after which the DOM representation of the view should be visible\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab They support wiring up view methods to DOM elements\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 One could also take this further and test that user interactions with the view correctly result in any models that need to be changed being updated correctly.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 module( 'About Backbone.View', \{\line
    setup: function() \{\line
        $('body').append('<ul id="todoList"></ul>');\line
        this.todoView = new TodoView(\{ model: new Todo() \});\line
    \},\line
    teardown: function() \{\line
        this.todoView.remove();\line
        $('#todoList').remove();\line
    \}\line
\});\line
\line
test('Should be tied to a DOM element when created, based off the property provided.', function() \{\line
    expect( 1 );\line
    equal( this.todoView.el.tagName.toLowerCase(), 'li' );\line
\});\line
\line
test('Is backed by a model instance, which provides the data.', function() \{\line
    expect( 2 );\line
    notEqual( this.todoView.model, undefined );\line
    equal( this.todoView.model.get('done'), false );\line
\});\line
\line
test('Can render, after which the DOM representation of the view will be visible.', function() \{\line
   this.todoView.render();\line
\line
    // Hint: render() just builds the DOM representation of the view, but doesn't insert it into the DOM.\line
    //       How would you append it to the ul#todoList?\line
    //       How do you access the view's DOM representation?\line
    //\line
    // Hint: http://documentcloud.github.com/backbone/#View-el\line
\line
    $('ul#todoList').append(this.todoView.el);\line
    equal($('#todoList').find('li').length, 1);\line
\});\line
\line
asyncTest('Can wire up view methods to DOM elements.', function() \{\line
    expect( 2 );\line
    var viewElt;\line
\line
    $('#todoList').append( this.todoView.render().el );\line
\line
    setTimeout(function() \{\line
        viewElt = $('#todoList li input.check').filter(':first');\line
\line
        equal(viewElt.length > 0, true);\line
\line
        // Make sure that QUnit knows we can continue\line
        start();\line
    \}, 1000, 'Expected DOM Elt to exist');\line
\line
\line
    // Hint: How would you trigger the view, via a DOM Event, to toggle the 'done' status.\line
    //       (See todos.js line 70, where the events hash is defined.)\line
    //\line
    // Hint: http://api.jquery.com/click\line
\line
    $('#todoList li input.check').click();\line
    expect( this.todoView.model.get('done'), true );\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Events\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For events, we may want to test a few different use cases:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Extending plain objects to support custom events\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Binding and triggering custom events on objects\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Passing along arguments to callbacks when events are triggered\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Binding a passed context to an event callback\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Removing custom events\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 and a few others that will be detailed in our module below:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 module( 'About Backbone.Events', \{\line
    setup: function() \{\line
        this.obj = \{\};\line
        _.extend( this.obj, Backbone.Events );\line
        this.obj.off(); // remove all custom events before each spec is run.\line
    \}\line
\});\line
\line
test('Can extend JavaScript objects to support custom events.', function() \{\line
    expect(3);\line
\line
    var basicObject = \{\};\line
\line
    // How would you give basicObject these functions?\line
    // Hint: http://documentcloud.github.com/backbone/#Events\line
    _.extend( basicObject, Backbone.Events );\line
\line
    equal( typeof basicObject.on, 'function' );\line
    equal( typeof basicObject.off, 'function' );\line
    equal( typeof basicObject.trigger, 'function' );\line
\});\line
\line
test('Allows us to bind and trigger custom named events on an object.', function() \{\line
    expect( 1 );\line
\line
    var callback = this.spy();\line
\line
    this.obj.on( 'basic event', callback );\line
    this.obj.trigger( 'basic event' );\line
\line
    // How would you cause the callback for this custom event to be called?\line
    ok( callback.called );\line
\});\line
\line
test('Also passes along any arguments to the callback when an event is triggered.', function() \{\line
    expect( 1 );\line
\line
    var passedArgs = [];\line
\line
    this.obj.on('some event', function() \{\line
        for (var i = 0; i < arguments.length; i++) \{\line
            passedArgs.push( arguments[i] );\line
        \}\line
    \});\line
\line
    this.obj.trigger( 'some event', 'arg1', 'arg2' );\line
\line
    deepEqual( passedArgs, ['arg1', 'arg2'] );\line
\});\line
\line
\line
test('Can also bind the passed context to the event callback.', function() \{\line
    expect( 1 );\line
\line
    var foo = \{ color: 'blue' \};\line
    var changeColor = function() \{\line
        this.color = 'red';\line
    \};\line
\line
    // How would you get 'this.color' to refer to 'foo' in the changeColor function?\line
    this.obj.on( 'an event', changeColor, foo );\line
    this.obj.trigger( 'an event' );\line
\line
    equal( foo.color, 'red' );\line
\});\line
\line
test( "Uses 'all' as a special event name to capture all events bound to the object." , function() \{\line
    expect( 2 );\line
\line
    var callback = this.spy();\line
\line
    this.obj.on( 'all', callback );\line
    this.obj.trigger( "custom event 1" );\line
    this.obj.trigger( "custom event 2" );\line
\line
    equal( callback.callCount, 2 );\line
    equal( callback.getCall(0).args[0], 'custom event 1' );\line
\});\line
\line
test('Also can remove custom events from objects.', function() \{\line
    expect( 5 );\line
\line
    var spy1 = this.spy();\line
    var spy2 = this.spy();\line
    var spy3 = this.spy();\line
\line
    this.obj.on( 'foo', spy1 );\line
    this.obj.on( 'bar', spy1 );\line
    this.obj.on( 'foo', spy2 );\line
    this.obj.on( 'foo', spy3 );\line
\line
    // How do you unbind just a single callback for the event?\line
    this.obj.off( 'foo', spy1 );\line
    this.obj.trigger( 'foo' );\line
\line
    ok( spy2.called );\line
\line
    // How do you unbind all callbacks tied to the event with a single method\line
    this.obj.off( 'foo' );\line
    this.obj.trigger( 'foo' );\line
\line
    ok( spy2.callCount, 1 );\line
    ok( spy2.calledOnce, "Spy 2 called once" );\line
    ok( spy3.calledOnce, "Spy 3 called once" );\line
\line
    // How do you unbind all callbacks and events tied to the object with a single method?\line
    this.obj.off( 'bar' );\line
    this.obj.trigger( 'bar' );\line
\line
    equal( spy1.callCount, 0 );\line
\});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 App\par}
{\pard \ql \f0 \sa180 \li0 \fi0 It can also be useful to write specs for any application bootstrap you may have in place. For the following module, our setup initiates and appends a TodoApp view and we can test anything from local instances of views being correctly defined to application interactions correctly resulting in changes to instances of local collections.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \f1 module( 'About Backbone Applications' , \{\line
    setup: function() \{\line
        Backbone.localStorageDB = new Store('testTodos');\line
        $('#qunit-fixture').append('<div id="app"></div>');\line
        this.App = new TodoApp(\{ appendTo: $('#app') \});\line
    \},\line
\line
    teardown: function() \{\line
        this.App.todos.reset();\line
        $('#app').remove();\line
    \}\line
\});\line
\line
test('Should bootstrap the application by initializing the Collection.', function() \{\line
    expect( 2 );\line
\line
    notEqual( this.App.todos, undefined );\line
    equal( this.App.todos.length, 0 );\line
\});\line
\line
test( 'Should bind Collection events to View creation.' , function() \{\line
      $('#new-todo').val( 'Foo' );\line
      $('#new-todo').trigger(new $.Event( 'keypress', \{ keyCode: 13 \} ));\line
\line
      equal( this.App.todos.length, 1 );\line
 \});\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Further Reading & Resources\par}
{\pard \ql \f0 \sa180 \li0 \fi0 That\u8217's it for this section on testing applications with QUnit and SinonJS. I encourage you to try out the {\field{\*\fldinst{HYPERLINK "https://github.com/addyosmani/backbone-koans-qunit"}}{\fldrslt{\ul
QUnit Backbone.js Koans
}}}
 and see if you can extend some of the examples. For further reading consider looking at some of the additional resources below:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b {\field{\*\fldinst{HYPERLINK "http://tddjs.com/"}}{\fldrslt{\ul
Test-driven JavaScript Development (book)
}}}
}\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b {\field{\*\fldinst{HYPERLINK "http://sinonjs.org/qunit/"}}{\fldrslt{\ul
SinonJS/QUnit Adapter
}}}
}\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b {\field{\*\fldinst{HYPERLINK "http://cjohansen.no/en/javascript/using_sinon_js_with_qunit"}}{\fldrslt{\ul
SinonJS and QUnit
}}}
}\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b {\field{\*\fldinst{HYPERLINK "http://msdn.microsoft.com/en-us/scriptjunkie/gg749824"}}{\fldrslt{\ul
Automating JavaScript Testing With QUnit
}}}
}\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b {\field{\*\fldinst{HYPERLINK "http://benalman.com/talks/unit-testing-qunit.html"}}{\fldrslt{\ul
Ben Alman\u8217's Unit Testing With QUnit
}}}
}\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b {\field{\*\fldinst{HYPERLINK "https://github.com/jc00ke/qunit-backbone"}}{\fldrslt{\ul
Another QUnit/Backbone.js demo project
}}}
}\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\b {\field{\*\fldinst{HYPERLINK "http://devblog.supportbee.com/2012/02/10/helpers-for-testing-backbone-js-apps-using-jasmine-and-sinon-js/"}}{\fldrslt{\ul
SinonJS helpers for Backbone
}}}
}\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs36 Resources\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Whilst what we get with Backbone out of the box can be terribly useful, there are some equally beneficial add-ons that can help simplify our development process. These include:\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\field{\*\fldinst{HYPERLINK "https://github.com/derickbailey/backbone.marionette"}}{\fldrslt{\ul
Backbone Marionette
}}}
\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\field{\*\fldinst{HYPERLINK "https://github.com/tbranyen/backbone.layoutmanager"}}{\fldrslt{\ul
Backbone Layout Manager
}}}
\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\field{\*\fldinst{HYPERLINK "https://github.com/backbone-boilerplate/backbone-boilerplate"}}{\fldrslt{\ul
Backbone Boilerplate
}}}
\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\field{\*\fldinst{HYPERLINK "https://github.com/derickbailey/backbone.modelbinding"}}{\fldrslt{\ul
Backbone Model Binding
}}}
\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\field{\*\fldinst{HYPERLINK "https://github.com/PaulUithol/Backbone-relational"}}{\fldrslt{\ul
Backbone Relational - for model relationships
}}}
\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\field{\*\fldinst{HYPERLINK "https://github.com/janmonschke/backbone-couchdb"}}{\fldrslt{\ul
Backbone CouchDB
}}}
\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\field{\*\fldinst{HYPERLINK "https://github.com/n-time/backbone.validations"}}{\fldrslt{\ul
Backbone Validations - HTML5 inspired validations
}}}
\sa180\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In time, there will be tutorials in the book covering some of these resources but until then, please feel free to check them out.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs36 Conclusions\par}
{\pard \ql \f0 \sa180 \li0 \fi0 That\u8217's it for \u8216'Developing Backbone.js Applications\u8217'. I hope you found this book both useful, enlightening and a good start for your journey into exploring Backbone.js.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 If there are other topics or areas of this book you feel could be expanded further, please feel free to let me know, or better yet, send a pull request upstream. I\u8217'm always interested in making this title as comprehensive as possible.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Until next time, the very best of luck with the rest of your journey!\par}
{\pard \ql \f0 \sa180 \li0 \fi0 \b \fs32 Notes\par}
{\pard \ql \f0 \sa180 \li0 \fi0 I would like to thank the Backbone.js, Stack Overflow, DailyJS (Alex Young) and JavaScript communities for their help, references and contributions to this book. This project would not be possible without you so thank you! :)\par}
{\pard \qc \f0 \sa180 \li0 \fi0 \emdash\emdash\emdash\emdash\emdash\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Where relevant, copyright Addy Osmani, 2012.\par}
}