Updating builds to latest

Author: addyosmani

backbone-fundamentals.epub

@@ -1535,7 +1535,9 @@ The `set()` method available for Collections can also be used for "smart" updati
 
 // Define a model of type 'Beatle' with a 'job' attribute
 var Beatle = Backbone.Model.extend({
-  job: 'musician'
+  defaults: {
+    job: 'musician'
+  }
 });
 
 // Create models for each member of the Beatles
@@ -3790,7 +3792,7 @@ The outline for this section looks like this:
 
 Download and install node.js from nodejs.org. The node package manager (npm) will be installed as well.
 
-Download and install MongoDB from mongodb.org. There are detailed installation guides [on the website](http://docs.mongodb.org/manual/installation/).
+Download, install, and run MongoDB from mongodb.org (you need Mongo to be running to store data in a Mongo database). There are detailed installation guides [on the website](http://docs.mongodb.org/manual/installation/).
 
 ###Install node modules
 
@@ -4567,7 +4569,7 @@ var ZombieView = Backbone.View.extend({
 
   initialize: function() {
     // bind the model change to re-render this view
-    this.model.on('change', this.render, this);
+    this.listenTo(this.model, 'change', this.render);
   },
 
   close: function() {
@@ -5841,7 +5843,7 @@ In most cases, the view removal should not affect any associated models. For exa
 
 (Thanks to [dira](http://stackoverflow.com/users/906136/dira) for this tip)
 
-Note: You may also be interested in reading the about Marionette Composite Views in the Extensions part of the book.
+Note: You may also be interested in reading about the Marionette Composite Views in the Extensions part of the book.
 
 #### Rendering View Hierarchies
 
@@ -6478,7 +6480,7 @@ The difference, then, is why these two patterns are both using events. The event
 
 Both the event aggregator and mediator, by design, use a third-party object to facilitate things. The event aggregator itself is a third-party to the event publisher and the event subscriber. It acts as a central hub for events to pass through. The mediator is also a third party to other objects, though. So where is the difference? Why don’t we call an event aggregator a mediator? The answer largely comes down to where the application logic and workflow is coded.
 
-In the case of an event aggregator, the third party object is there only to facilitate the pass-through of events from an unknown number of sources to an unknown number of handlers. All workflow and business logic that needs to be kicked off is put directly into the the object that triggers the events and the objects that handle the events.
+In the case of an event aggregator, the third party object is there only to facilitate the pass-through of events from an unknown number of sources to an unknown number of handlers. All workflow and business logic that needs to be kicked off is put directly into the object that triggers the events and the objects that handle the events.
 
 In the case of the mediator, though, the business logic and workflow is aggregated into the mediator itself. The mediator decides when an object should have it’s methods called and attributes updated based on factors that the mediator knows about. It encapsulates the workflow and process, coordinating multiple objects to produce the desired system behaviour. The individual objects involved in this workflow each know how to perform their own task. But it’s the mediator that tells the objects when to perform the tasks by making decisions at a higher level than the individual objects.
 
@@ -6691,7 +6693,7 @@ Addy's post on [Writing Modular JS](http://addyosmani.com/writing-modular-js/) c
 Before using RequireJS and Backbone we will first set up a very basic RequireJS project to demonstrate how it works. The first thing to do is to [Download RequireJS](http://requirejs.org/docs/download.html#requirejs). When you load in the RequireJS script in your HTML file, you need to also tell it where your main JavaScript file is located. Typically this will be called something like "app.js", and is the main entry point for your application. You do this by adding in a `data-main` attribute to the `script` tag:
 
 ```html
-<script data-main="app.js" src="lib/require.js"></script>
+<script data-main="app" src="lib/require.js"></script>
 ```
 
 Now, RequireJS will automatically load `app.js` for you.
@@ -6902,7 +6904,7 @@ I've called this collection `Cart`, as it's a group of items. As the `Item` mode
 Finally, let's have a look at the view for this collection. (This file is much bigger in the application, but I've taken some bits out so it's easier to examine).
 
 ```javascript
-define(["lib/backbone", "models/item", "views/itemview"], function(Backbone, Item, ItemView) {
+define(["lib/backbone", "views/itemview"], function(Backbone, ItemView) {
   var ItemCollectionView = Backbone.View.extend({
     el: '#yourcart',
     initialize: function(collection) {

backbone-fundamentals.md

@@ -1223,7 +1223,9 @@ Todos.reset([]);\par}
 {\pard \ql \f0 \sa180 \li0 \fi0 \f1 \line
 // Define a model of type 'Beatle' with a 'job' attribute\line
 var Beatle = Backbone.Model.extend(\{\line
-  job: 'musician'\line
+  defaults: \{\line
+    job: 'musician'\line
+  \}\line
 \});\line
 \line
 // Create models for each member of the Beatles\line
@@ -2448,7 +2450,7 @@ TodoMVC.com
 {\pard \ql \f0 \sa180 \li360 \fi-360 \bullet \tx360\tab {\f1 toggleAllComplete()}: Allows a user to mark all of the items in the todo list as completed by clicking the toggle-all checkbox.\par}
 {\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\f1 initialize()}: We\u8217've bound callbacks to several additional events:\par}
 {\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab We\u8217've bound a {\f1 filterOne()} callback on the Todos collection for a {\f1 change:completed} event. This listens for changes to the completed flag for any model in the collection. The affected todo is passed to the callback which triggers a custom {\f1 visible} event on the model.\par}
-{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab We\u8217've bound a {\f1 filterAll()} callback for a {\f1 filter} event, which works a little similar to addOne() and addAll(). It\u8217's responsibility is to toggle which todo items are visible based on the filter currently selected in the UI (all, completed or remaining) via calls to filterOne().\par}
+{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab We\u8217've bound a {\f1 filterAll()} callback for a {\f1 filter} event, which works a little similar to addOne() and addAll(). Its responsibility is to toggle which todo items are visible based on the filter currently selected in the UI (all, completed or remaining) via calls to filterOne().\par}
 {\pard \ql \f0 \sa180 \li360 \fi-360 \bullet \tx360\tab We\u8217've used the special {\f1 all} event to bind any event triggered on the Todos collection to the view\u8217's render method (discussed below).\sa180\par}
 {\pard \ql \f0 \sa180 \li0 \fi0 The {\f1 initialize()} method completes by fetching the previously saved todos from localStorage.\par}
 {\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab {\f1 render()}: Several things are happening in our {\f1 render()} method:\par}
@@ -3011,7 +3013,7 @@ addBook: function( e ) \{\line
 {\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Create the REST API\sa180\par}
 {\pard \ql \f0 \sa180 \li0 \fi0 \b \fs28 Install node.js, npm, and MongoDB\par}
 {\pard \ql \f0 \sa180 \li0 \fi0 Download and install node.js from nodejs.org. The node package manager (npm) will be installed as well.\par}
-{\pard \ql \f0 \sa180 \li0 \fi0 Download and install MongoDB from mongodb.org. There are detailed installation guides {\field{\*\fldinst{HYPERLINK "http://docs.mongodb.org/manual/installation/"}}{\fldrslt{\ul
+{\pard \ql \f0 \sa180 \li0 \fi0 Download, install, and run MongoDB from mongodb.org (you need Mongo to be running to store data in a Mongo database). There are detailed installation guides {\field{\*\fldinst{HYPERLINK "http://docs.mongodb.org/manual/installation/"}}{\fldrslt{\ul
 on the website
 }}}
 .\par}
@@ -3571,7 +3573,7 @@ Derick.set('email', '[email protected]');\par}
 \line
   initialize: function() \{\line
     // bind the model change to re-render this view\line
-    this.model.on('change', this.render, this);\line
+    this.listenTo(this.model, 'change', this.render);\line
   \},\line
 \line
   close: function() \{\line
@@ -4582,7 +4584,7 @@ NewChildView = Backbone.View.extend(\{\line
 dira
 }}}
  for this tip)\par}
-{\pard \ql \f0 \sa180 \li0 \fi0 Note: You may also be interested in reading the about Marionette Composite Views in the Extensions part of the book.\par}
+{\pard \ql \f0 \sa180 \li0 \fi0 Note: You may also be interested in reading about the Marionette Composite Views in the Extensions part of the book.\par}
 {\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 Rendering View Hierarchies\par}
 {\pard \ql \f0 \sa180 \li0 \fi0 {\b Problem}\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 HTML that reflects the hierarchical nature of the data structure.\par}
@@ -5079,7 +5081,7 @@ var View2 = Backbone.View.extend(\{\line
 {\pard \ql \f0 \sa180 \li0 \fi0 The difference, then, is why these two patterns are both using events. The event aggregator, as a pattern, is designed to deal with events. The mediator, though, only uses them because it\u8217's convenient.\par}
 {\pard \ql \f0 \sa180 \li0 \fi0 \b \fs16 Third-Party Objects\par}
 {\pard \ql \f0 \sa180 \li0 \fi0 Both the event aggregator and mediator, by design, use a third-party object to facilitate things. The event aggregator itself is a third-party to the event publisher and the event subscriber. It acts as a central hub for events to pass through. The mediator is also a third party to other objects, though. So where is the difference? Why don\u8217't we call an event aggregator a mediator? The answer largely comes down to where the application logic and workflow is coded.\par}
-{\pard \ql \f0 \sa180 \li0 \fi0 In the case of an event aggregator, the third party object is there only to facilitate the pass-through of events from an unknown number of sources to an unknown number of handlers. All workflow and business logic that needs to be kicked off is put directly into the the object that triggers the events and the objects that handle the events.\par}
+{\pard \ql \f0 \sa180 \li0 \fi0 In the case of an event aggregator, the third party object is there only to facilitate the pass-through of events from an unknown number of sources to an unknown number of handlers. All workflow and business logic that needs to be kicked off is put directly into the object that triggers the events and the objects that handle the events.\par}
 {\pard \ql \f0 \sa180 \li0 \fi0 In the case of the mediator, though, the business logic and workflow is aggregated into the mediator itself. The mediator decides when an object should have it\u8217's methods called and attributes updated based on factors that the mediator knows about. It encapsulates the workflow and process, coordinating multiple objects to produce the desired system behaviour. The individual objects involved in this workflow each know how to perform their own task. But it\u8217's the mediator that tells the objects when to perform the tasks by making decisions at a higher level than the individual objects.\par}
 {\pard \ql \f0 \sa180 \li0 \fi0 An event aggregator facilitates a \u8220"fire and forget\u8221" model of communication. The object triggering the event doesn\u8217't care if there are any subscribers. It just fires the event and moves on. A mediator, though, might use events to make decisions, but it is definitely not \u8220"fire and forget\u8221". A mediator pays attention to a known set of input or activities so that it can facilitate and coordinate additional behavior with a known set of actors (objects).\par}
 {\pard \ql \f0 \sa180 \li0 \fi0 \b \fs20 Relationships: When To Use Which\par}
@@ -5244,7 +5246,7 @@ Writing Modular JS
 Download RequireJS
 }}}
 . When you load in the RequireJS script in your HTML file, you need to also tell it where your main JavaScript file is located. Typically this will be called something like \u8220"app.js\u8221", and is the main entry point for your application. You do this by adding in a {\f1 data-main} attribute to the {\f1 script} tag:\par}
-{\pard \ql \f0 \sa180 \li0 \fi0 \f1 <script data-main="app.js" src="lib/require.js"></script>\par}
+{\pard \ql \f0 \sa180 \li0 \fi0 \f1 <script data-main="app" src="lib/require.js"></script>\par}
 {\pard \ql \f0 \sa180 \li0 \fi0 Now, RequireJS will automatically load {\f1 app.js} for you.\par}
 {\pard \ql \f0 \sa180 \li0 \fi0 \b \fs24 RequireJS Configuration\par}
 {\pard \ql \f0 \sa180 \li0 \fi0 In the main JavaScript file that you load with the {\f1 data-main} attribute you can configure how RequireJS loads the rest of your application. This is done by calling {\f1 require.config}, and passing in an object:\par}
@@ -5392,7 +5394,7 @@ Backbone application with RequireJS that you can find on Github
 \});\par}
 {\pard \ql \f0 \sa180 \li0 \fi0 I\u8217've called this collection {\f1 Cart}, as it\u8217's a group of items. As the {\f1 Item} model is the second dependency, I can bind the variable {\f1 Item} to it by declaring it as the second argument to the callback function. I can then refer to this within my collection implementation.\par}
 {\pard \ql \f0 \sa180 \li0 \fi0 Finally, let\u8217's have a look at the view for this collection. (This file is much bigger in the application, but I\u8217've taken some bits out so it\u8217's easier to examine).\par}
-{\pard \ql \f0 \sa180 \li0 \fi0 \f1 define(["lib/backbone", "models/item", "views/itemview"], function(Backbone, Item, ItemView) \{\line
+{\pard \ql \f0 \sa180 \li0 \fi0 \f1 define(["lib/backbone", "views/itemview"], function(Backbone, ItemView) \{\line
   var ItemCollectionView = Backbone.View.extend(\{\line
     el: '#yourcart',\line
     initialize: function(collection) \{\line