[?music?]

[Backbone Collections]

[Jim Hoskins] So now we have our form in a state

where it will actually take all the information from the fields and save it into a New Note.

However, when we do this and we submit it:

Text Body

--even though it's saving, it's not quite having the behavior we want.

When we save it, it seems to submit and has that sort of slide forward form.

But you remember, the way we actually brought it up was a dialog,

so how we actually like it to complete

is to simply puff away much like that.

So what we need to do is go into our View,

and here we are inside of our new Views form.

So after we create the note, what we want to do is two things.

First we want to tell the browser that we don't want it to submit like a normal form,

and we can do that by using the event object that's passed

into our createNote handler and telling it to prevent default,

which will stop a normal form load.

The second is we want to stop the propagation of this submit event

and that's because jQuery Mobile also does some magic

whenever it sees forms in order to make our app run like a typical iPhone or IOS application.

That means it intercepts a form submission,

does some AJAX, and then moves into another page,

and we don't want jQuery Mobile doing that, either.

So what we're going to do is we're going to call e.preventDefault();

and this will stop our browser from submitting the form like normal.

The second thing we want to do on that event is call e.stopPropagation();

which will stop jQuery Mobile from intercepting that event

and doing its AJAX magic.

Now, in the event handlers, the equivalent of calling e.preventDefault();

and e.stopPropagation(); would be to simply return false from this handler function,

but I prefer to do it more explicitly like this.

So now we've prevented the browser from submitting the form

and we've prevented jQuery from handling the form and doing its normal animation.

Now, the last thing we want to do is to close the dialog in its normal way.

We also want to reset the form fields because we don't want

the input from the previous one to show up when we start adding a new note.

So the way that we can close the dialog--

let me just move this up the screen a little bit--

and to close the dialog, all we need to do is call this piece of code right here,

and what this does is it's a jQuery call

and it uses a selector here

and it uses the .ui-dialog to capture any dialog that's open;

in our case, our new form.

And then, we can call the dialog plugin and pass it the method "close")

and that's a way you can close whatever open dialog there is

from anywhere in your application.

Finally, we want to reset it, and I'm going to delegate this out to a new method,

so we'll call this.reset();

and let's go ahead and create our reset function.

reset: function(){

Now, one way we could handle this reset is to use the built-in reset functionality

built into forms, but later on, we're going to run into a problem

where the toggle switch doesn't recognize that a select field

has changed state because of a reset request from the browser

so we're going to do it manually,

and I'm just going to paste in this code.

What this code is going to do is it's going to grab all of the inputs and text areas

from within this view and just set the value to the empty string,

which will essentially reset it.

So if we save this out and we refresh our page,

let's create a new one and we'll just call this Next Test

and Some Text Here

and we save it out--cool.

We got the dialog to pop away just like it popped up.

If we bring up the New Note, it's all cleared out and ready to go

for the next one, so it looks like we got our New Note dialog all set up.

Our next step is we want to make the page that this would link to functional,

which would display a list of all of the notes.

So what we're going to do is we're going to start in our HTML file

and create a new page under the name All.

So if we go back to our HTML page,

first, I'm going to collapse our new page here,

and if we look here, we see that we link to All,

so what we're going to do is create a new page

with the id of "#all" that will have a list of all of our notes.

So I'm also going to just spin that up.

We'll go ahead and start our next page

and we'll call this List of Notes.

All right. I'll paste this in, cut some stuff out.

Cool. So I'm just going to paste this in and let's just go over it.

It's a lot like the pages we've created before.

We start with the id of "all" and we give it a data-role of "page">.

Then here, we're defining our header, so it has a data-role of "header"

and its title is All Notes.

Here we've added a Back button,

and this is a button that jQuery Mobile adds by default

when we are navigating around our pages,

but the reason I add one in manually is because if somebody bookmarks this page

and loads it fresh and jQuery mobile doesn't know what the previous page would have been,

this offers us a default Back button which will take us home in all cases.

So we just did a normal button with the data-role of "button".

We have our data-icon of arrow left "arrow-l"

and then, we added this data-rel="back">

and this tells jQuery Mobile that when we can, just have it act like a Back button

and just take them back to wherever it was.

However, if it can't use the normal Back functionality,

it will take you to Home, which will work for if we load this page from a bookmark.

So that's our header, and then we have our div for our content.

Now, what I'm going to do here is just paste in an unordered list

with the data role of "listview"

which is what we saw on our homepage,

but you'll notice I am not having it with data inset true.

I want this to be an edge-to-edge list because this page is going to be nothing

but this single list of notes

and I've given it an id of "all notes">.

Now what we're going to do is we're going to fill in this list dynamically using Backbone.

Each list item in this list view

is actually going to be represented by its own instance of a View

that we're going to write, and that view is going to be called a NoteList item.

Besides each of those individual Views inside of it,

we're also going to create a View that represents this list,

and that will manage things like adding new items to the list

or just populating the list by itself.

So we're going to have two different Views:

one represents the entire list and will watch for a collection of notes

and add the list items in and each of those list items itself will be a View

and those will be concerned with changes to the Title or any other content

for that particular list item.

So now, before we start defining our Views, we need to introduce a new concept

which is very closely related to our model,

and that's the idea of a collection.

So while a model represents a single note,

a collection represents a list of multiple models or multiple notes.

In Backbone, collections are used for keeping lists of things

so they can be updated on the server.

It can be a little bit tricky to understand where to use collections,

but basically, we want a collection because we're going to be showing a list

and having that collection object will give our list View

something to look at and observe

and the collection can notify our View when a new note is added to the list

or the new note is removed or anything like that.

So the collection sits between our database or our localStorage

as an abstraction of that.

Our collections are going to be pretty simple--

they're just going to represent the entire contents of our database or localStorage.

So we don't interact directly with the localStorage; instead we use these collections

and they will watch our localStorage and notify us of any changes.

So I'm going to define a collection here, and we'll call it a NoteList.

var NoteList

and we're going to inherit from the Backbone collection class,

so we'll say Backbone.Collection.extend({.

What we're going to do here is add some properties and methods

to customize how our collection works for our notes class.

The first built-in property we want to specify

is the model property, and this will tell Backbone

what type of model we're dealing with.

In our case, we're dealing with the Note.

The next thing we want to do is tell it that it's going to utilize localStorage as its data source.

In order to do that, we just add the localStorage property

and tell it to use App.stores.notes, which we can remember

we defined up here, right at the beginning of our code.

This is exactly the same as our note model here,

which means that they're using the same database or localStorage database

when we save a model directly as well as when we try to retrieve a list of models

from our localStorage.

So this tells our collection that it's watching localStorage

and let's add an initializer here.

initialize: function (){

and we're actually going to have to make a change to our localStorage code.

See, the type of application we're creating isn't really the typical use for Backbone.

A collection is really used to sort of abstract away an endpoint on a web service,

and the way we're using it now

is we are going to have multiple collections:

one collection for sorting by name

and one location for sorting by geolocation or how close that note is to your current location

and the way we're saving notes themselves is not actually saving them through a collection

but just saving them directly, which will store them into localStorage.

So when we create a New Note and save it into localStorage,

the collections that we also have hooked up to that same data store

are not going to be notified of that change.

So the way we can handle this is we can modify the localStorage code

to send out an event every time that the data is updated.

Any collection that's set up to use that data store as its database

can be set up to watch for that update event and then handle itself accordingly.

So what we're actually going to do is we're going to open up the Backbone.localStorage.js.

Now, even though this isn't a library that we wrote,

unfortunately, I couldn't find an elegant way to get around having to modify

this library code, so it's worth taking a look.

It's not too difficult to understand; there's some things here about generating random numbers

to manage our id, but basically, we're just creating a store.

It will load the load the store from localStorage.

And then there's these functions here which are called behind the scene in Backbone

whenever we save an object.

So for instance, this save method is just going to call the localStorage.setItem

and then just sort of stringify its current internal memory,

and later on, when we restore from it, it'll read from localStorage and deserialize it.

Now, you can see that create also implicitly calls save,

update also calls save,

and destroy calls save,

so any time our data actually changes, the save function is invoked.

So if we're going to notify the outside world of any changes to our database,

we're definitely going to want to do it from inside of this save function.

Backbone has another class that's really useful to use

in any situation, and it's called Events. documentcloud.github.com/backbone/#events

What we can do is we can extend any object or any class

with Backbone.events, and what that will add is three methods:

object.bind, which will allow us to watch for a certain type of event

to be broadcast from this particular object;

similarly, an unbind method, which will remove any listener from it,

as well as the trigger.

Trigger and bind work together, so the object will trigger to create a new event.

For instance, we can trigger an update event

and then other parts of our code can bind to that update event

and every time that save method is called, we can hook our own code into there

to update, for instance, our collections.

In order to do that, we need to make sure that store class extends from Backbone.events

and if we go look at our code,

we can see that we're already extending Store.prototype with these methods.

So what we can do is the extend method can take in multiple objects

that will be all extended to Store.prototype.

So we'll just type in Backbone.Events, (comma)

so now our store will also extend from Events

as well as this custom code, and we can now use bind and trigger on this object.

So in our save function, when we update our localStorage database

with the new information, all I'm going to do is call this.trigger

since now this has a trigger method,

and let's call our event ("update")

which will just say that the data inside of our localStorage data store

has been updated.

So now, any time our localStorage updates, it's going to broadcast an event

called update, so inside of our initializer, what we're going to do

is we're going to grab this.localStorage, which is our data store right here,

and we're going to use the bind() method and look for the ("update") event.

So every time our localStorage is updated,

this function(){ that we're going to define here will be executed.

What we want to do when the localStorage or the underlying data store is updated

is to tell this collection to fetch, and what fetch does in a Backbone application

is it goes to its data source, whether it's localStorage or a remote web service

and gets that full collection from it.

So in our case, calling fetch will look at the localStorage and just retrieve

all of the items in that particular store.

So all we need to do is call this.fetch; however,

because we're using a callback function, what this refers to on this particular line

is no longer our collection, but instead whatever this particular function is bound to.

So in order to get around that, what we're going to do is set a variable called collection

var collection and set it = this;

So now, the current value of this at this scope

is now assigned to a variable called collection

and then in here, we can call collection.fetch();.

which would basically be like calling this.fetch.

Now, when fetch is called, besides just getting the data from the remote source,

it'll also set off a bunch of different events that other parts of our code will listen to

and that change will cascade all the way down to our views

saying that things have changed.

So we'll see how this comes into play when we write our next piece of code.