848 lines
28 KiB
Plaintext
848 lines
28 KiB
Plaintext
% -*- Mode: poly-noweb+coffee -*-
|
|
\documentclass{article}
|
|
\usepackage{noweb}
|
|
\usepackage[T1]{fontenc}
|
|
\usepackage{hyperref}
|
|
\usepackage{fontspec, xunicode, xltxtra}
|
|
\setromanfont{Georgia}
|
|
\begin{document}
|
|
|
|
% Generate code and documentation with:
|
|
%
|
|
% noweave -filter l2h -delay -x -html backbonestore.nw | htmltoc > backbonestore.html
|
|
% notangle -Rstore.js backbonestore.nw > store.js
|
|
% notangle -Rindex.html backbonestore.nw > index.html
|
|
|
|
\section{Introduction}
|
|
|
|
This is version 3.0 of \textbf{The Backbone Store}, a brief tutorial on
|
|
using [[backbone.js]]. The version you are currently reading has been
|
|
tested with the latest versions of the supporting software as of April,
|
|
2016.
|
|
|
|
\nwanchorto{http://documentcloud.github.com/backbone/}{Backbone.js} is a
|
|
popular Model-View-Controller (MVC) library that provides a framework
|
|
for creating data-rich, single-page web applications. It provides (1) a
|
|
two-layer scheme for separating data from presentation, (2) a means of
|
|
automatically synchronizing data with a server in a RESTful manner, and
|
|
(3) a mechanism for making some views bookmarkable and navigable.
|
|
|
|
Backbone is dependent upon \nwanchorto{http://jquery.com}{jQuery} and
|
|
\nwanchorto{http://underscorejs.org}{Underscore}. Both of those
|
|
dependencies are encoded into the build process automatically.
|
|
|
|
The version of this tutorial you are currently reading uses
|
|
Coffeescript, Stylus, and Ruby's HAML. The purpose of this tutorial is
|
|
to show how to use Backbone in a modern, constrained programming
|
|
environment.
|
|
|
|
\nwanchorto{http://jashkenas.github.com/coffee-script/}{CoffeeScript} is
|
|
a lovely little languange that compiles into Javascript. It provides a
|
|
class-based architecture (that is compatible with Backbone), has an
|
|
elegant structure for defining functions and methods, and strips out as
|
|
much extraneous punctuation as possible. Some people find the
|
|
whitespace-as-semantics a'la Python offputting, but most disciplined
|
|
developers already indent appropriately anyway.
|
|
|
|
\nwanchorto{http://haml-lang.com/}{HAML} is a languange that compiles
|
|
into HTML. Like CoffeeScript, it uses whitespace for semantics:
|
|
indentation levels correspond to HTML containerizations. It allows you
|
|
to use rich scripting while preventing heirarchy misplacement mistakes.
|
|
Its shorthand also makes writing HTML much faster.
|
|
|
|
\nwanchorto{https://github.com/LearnBoost/stylus/}{Stylus} is languange
|
|
that compiles into CSS. Like CoffeeScript and HAML, it uses whitespace
|
|
for semantics. It also provides mixins and functions that allow you to
|
|
define visual styles such as borders and gradients, and mix them into
|
|
specific selectors in the CSS rather than having to write them into the
|
|
HTML.
|
|
|
|
There are a number of other good tutorials for Backbone (See:
|
|
\nwanchorto{http://www.plexical.com/blog/2010/11/18/backbone-js-tutorial/}{Meta
|
|
Cloud},
|
|
\nwanchorto{http://andyet.net/blog/2010/oct/29/building-a-single-page-app-with-backbonejs-undersc/?utm_source=twitterfeed&utm_medium=twitter}{\&Yet's
|
|
Tutorial},
|
|
\nwanchorto{http://bennolan.com/2010/11/24/backbone-jquery-demo.html}{Backbone
|
|
Mobile} (which is written in
|
|
\nwanchorto{http://jashkenas.github.com/coffee-script/}{Coffee}), and
|
|
\nwanchorto{http://joshbohde.com/2010/11/25/backbonejs-and-django/}{Backbone
|
|
and Django}. However, a couple of years ago I was attempting to
|
|
learn Sammy.js, a library very similar to Backbone, and they had a
|
|
nifty tutorial called
|
|
\nwanchorto{http://code.quirkey.com/sammy/tutorials/json_store_part1.html}{The
|
|
JsonStore}.
|
|
|
|
In the spirit of The JSON Store, I present The Backbone Store.
|
|
|
|
\subsection{Literate Program}
|
|
|
|
A note: this article was written with the
|
|
\nwanchorto{http://en.wikipedia.org/wiki/Literate_programming}{Literate
|
|
Programming} toolkit
|
|
\nwanchorto{http://www.cs.tufts.edu/~nr/noweb/}{Noweb}. Where you see
|
|
something that looks like \\<\\<this\\>\\>, it's a placeholder for code
|
|
described elsewhere in the document. Placeholders with an equal sign
|
|
at the end of them indicate the place where that code is defined. The
|
|
link (U->) indicates that the code you're seeing is used later in the
|
|
document, and (<-U) indicates it was used earlier but is being defined
|
|
here.
|
|
|
|
\subsection{Revision}
|
|
|
|
This is version 3.0 of \textit{The Backbone Store}. It includes several
|
|
significant updates, including the use of both NPM and Bower to build
|
|
the final application.
|
|
|
|
\subsection{The Store: What We're Going to Build}
|
|
|
|
To demonstrate the basics of Backbone, I'm going to create a simple
|
|
one-page application, a store for record albums, with two unique views:
|
|
a list of all products and a product detail view. I will also put a
|
|
shopping cart widget on the page that shows the user how many products
|
|
he or she has dropped into the cart. I'll use some simple animations to
|
|
transition between the catalog and the product detail pages.
|
|
|
|
\subsection{Models, Collections, and Controllers}
|
|
|
|
Backbone's data layer provides two classes, [[Collection]] and
|
|
[[Model]].
|
|
|
|
Every web application has data, often tabular data. Full-stack web
|
|
developers are (or ought to be) familiar with the \textit{triples} of
|
|
addressing objects on the web: Table URL → Row → Field, or Page URL →
|
|
HTML Node → Content. The [[Collection]] object represents just that: a
|
|
collection of similar items. The [[Model]] represents exactly one of
|
|
those items.
|
|
|
|
To use the Model, you inherit from it using Backbone's own [[.extend()]]
|
|
class method, adding or replacing methods in the child object as
|
|
needed. For our purposes, we have two models: [[Product]] represents
|
|
something we wish to sell, and [[Item]] represents something currently
|
|
in the customer's shopping cart.
|
|
|
|
Shopping carts are a little odd; the convention is that [[Item]] is not a
|
|
single instance of the product, but instead has a reference to the
|
|
product, and a count of how many the buyer wants. To that end, I am
|
|
adding two methods that extend Item: [[.update()]], which changes the
|
|
current quantity, and [[.price()]], which calculates the product's price
|
|
times the quantity:
|
|
|
|
<<models>>=
|
|
class Product extends Backbone.Model
|
|
|
|
class Item extends Backbone.Model
|
|
update: (amount) ->
|
|
return if amount == @get 'quantity'
|
|
@set {quantity: amount}, {silent: true}
|
|
@collection.trigger 'update', @
|
|
|
|
price: () ->
|
|
@get('product').get('price') * @get('quantity')
|
|
@
|
|
|
|
The methods [[.get(item)]] and [[.set(item, value)]] are at the heart of
|
|
Backbone.Model. They're how you set individual attributes on the
|
|
object being manipulated. Notice how I can 'get' the product, which is
|
|
a Backbone.Model, and then 'get' its price.
|
|
|
|
Backbone supplies its own event management toolkit. Changing a model
|
|
triggers various events, none of which matter here in this context so I
|
|
silence the event, but then I tell the Item's Backbone.Collection that
|
|
the Model has changed. Events are the primary way in which Backbone
|
|
objects interact, so understanding them is key to using Backbone
|
|
correctly.
|
|
|
|
Collections, like Models, are just objects you can (and often must)
|
|
extend to support your application's needs. Just as a Model has
|
|
\texttt{.get()} and \texttt{.set()}, a Collection has [[.add(item)]] and
|
|
[[.remove(id)]] as methods. Collections have a lot more than that.
|
|
|
|
Both Models and Collections also have [[.fetch()]] and [[.save()]]. If
|
|
either has a URL, these methods allow the collection to represent data
|
|
on the server, and to save that data back to the server. The default
|
|
method is a simple JSON object representing either a Model's attributes,
|
|
or a JSON list of the Collection's models' attributes.
|
|
|
|
The [[Product.Collection]] will be loading it's list of albums via these
|
|
methods to (in our case) static JSON back-end.
|
|
|
|
<<product collection>>=
|
|
class ProductCollection extends Backbone.Collection
|
|
model: Product
|
|
|
|
initialize: (models, options) ->
|
|
@url = options.url
|
|
|
|
comparator: (item) ->
|
|
item.get 'title'
|
|
@
|
|
|
|
The [[.model]] attribute tells the [[ProductCollection]] that if
|
|
[[.add()]] or [[.fetch()]] are called and the contents are plain JSON,
|
|
a new [[Product]] Model should be initialized with the JSON data and
|
|
that will be used as a new object for the Collection.
|
|
|
|
The [[.comparator()]] method specifies the per-model value by which the
|
|
Collection should be sorted. Sorting happens automatically whenever the
|
|
Collection receives an event indicating its contents have been altered.
|
|
|
|
The [[ItemCollection]] doesn't have a URL, but we do have several helper
|
|
methods to add. We don't want to add Items; instead, we want to add
|
|
products as needed, then update the count as requested. If the product
|
|
is already in our system, we don't want to create duplicates.
|
|
|
|
<<cart collection>>=
|
|
class ItemCollection extends Backbone.Collection
|
|
model: Item
|
|
|
|
@
|
|
|
|
First, we ensure that if we don't receive an amount, we at least provide
|
|
a valid \textit{numerical} value to our code. The [[.detect()]] method
|
|
lets us find an object in our Collection using a function to compare
|
|
them; it returns the first object that matches.
|
|
|
|
If we find the object, we update it and return. If we don't, we create
|
|
a new one, exploiting the fact that, since we specified the Collection's
|
|
Model above, it will automatically be created as a Model in the
|
|
Collection at the end of this call. In either case, we return the new
|
|
Item to be handled further by the calling code.
|
|
|
|
<<cart collection>>=
|
|
updateItemForProduct: (product, amount) ->
|
|
amount = if amount? then amount else 0
|
|
pid = product.get 'id'
|
|
i = this.detect (obj) -> (obj.get('product').get('id') == pid)
|
|
if i
|
|
i.update(amount)
|
|
return i
|
|
|
|
@add {product: product, quantity: amount}
|
|
|
|
@
|
|
|
|
And finally, two methods to add up how many objects are in your cart,
|
|
and the total price. The first line creates a function to get the
|
|
number for a single object and add it to a memo. The second line uses
|
|
the [[.reduce()]] method, which goes through each object in the
|
|
collection and runs the function, passing the results of each run to the
|
|
next as the memo.
|
|
|
|
<<cart cart collection>>=
|
|
@
|
|
getTotalCount: () ->
|
|
addup = (memo, obj) -> memo + obj.get 'quantity'
|
|
@reduce addup, 0
|
|
|
|
getTotalCost: () ->
|
|
addup = (memo, obj) -> memo + obj.price()
|
|
@reduce addup, 0
|
|
|
|
@
|
|
|
|
\subsection {Views}
|
|
|
|
Backbone Views are simple policy objects. They have a root DOM
|
|
element, the contents of which they manipulate and to which they
|
|
listen for events, and a model or collection they represent within
|
|
that element. Views are not rigid; it's just Javascript and the DOM,
|
|
and you can hook external events as needed.
|
|
|
|
More importantly, a View is sensitive to events \textit{within its model
|
|
or collection}, and can respond to changes automatically. This way,
|
|
if you have a rich data ecosystem, when changes to one data item results
|
|
in a cascade of changes throughout your datasets, the views will receive
|
|
``change'' events and can update themselves accordingly.
|
|
|
|
I will show how this works with the shopping cart widget.
|
|
|
|
To achieve the [[fadeIn/fadeOut]] animations and enforce consistency,
|
|
I'm going to do some basic object-oriented programming. I'm going to
|
|
create a base class that contains knowledge about the main area into
|
|
which all views are rendered, and that manages these transitions.
|
|
|
|
With this technique, you can do lots of navigation-related tricks: you
|
|
can highlight where the user is in breadcrumb-style navigation; you
|
|
can change the class and highlight an entry on a nav bar; you can add
|
|
and remove tabs from the top of the viewport as needed.
|
|
|
|
<<base view>>=
|
|
class _BaseView extends Backbone.View
|
|
parent: $('#main')
|
|
className: 'viewport'
|
|
|
|
@
|
|
|
|
The above says that I am creating a class called \texttt{BaseView} and
|
|
defining two fields. The first, 'parent', will be used by all child
|
|
views to identify into which DOM object the View root element will be
|
|
rendered. The second defines a common class we will use for the purpose
|
|
of identifying these views to jQuery. Backbone automatically creates a
|
|
new [[DIV]] object with the class 'viewport' when a view constructor is
|
|
called. It will be our job to attach that [[DIV]] to the DOM. In the
|
|
HTML, you will see the [[DIV\#main]] object where most of the work will
|
|
be rendered.
|
|
|
|
As an alternative, the viewport object may already exist, in which case
|
|
you just find it with a selector, and the view attaches itself to that
|
|
DOM object from then on.
|
|
|
|
<<base view>>=
|
|
initialize: () ->
|
|
@el = $(@el)
|
|
@el.hide()
|
|
@parent.append(@el)
|
|
@
|
|
|
|
@
|
|
%$
|
|
|
|
The method above ensures that the element is rendered, but not
|
|
visible, and contained within the [[DIV\#main]]. Note also that
|
|
the element is not a sacrosanct object; the Backbone.View is more a
|
|
collection of standards than a mechanism of enforcement, and so
|
|
defining it from a raw DOM object to a jQuery object will not break
|
|
anything.
|
|
|
|
Next, we will define the hide and show functions.
|
|
|
|
Note that in Coffeescript, the [[=>]] operator completely replaces the
|
|
[[.bind()]] function provided by modern Javascript.
|
|
|
|
<<base view>>=
|
|
hide: () ->
|
|
if not @el.is(':visible')
|
|
return null
|
|
promise = $.Deferred (dfd) => @el.fadeOut('fast', dfd.resolve)
|
|
promise.promise()
|
|
|
|
show: () ->
|
|
if @el.is(':visible')
|
|
return
|
|
|
|
promise = $.Deferred (dfd) => @el.fadeIn('fast', dfd.resolve)
|
|
promise.promise()
|
|
|
|
@
|
|
|
|
\textbf{Deferred} is a feature of jQuery called ``promises''. It is a
|
|
different mechanism for invoking callbacks by attaching attributes and
|
|
behavior to the callback function. By using this, we can say thing like
|
|
``\textit{When} everything is hidden (when every deferred returned from
|
|
\textbf{hide} has been resolved), \textit{then} show the appropriate
|
|
viewport.'' Deferreds are incredibly powerful, and this is a small
|
|
taste of what can be done with them.
|
|
|
|
Before we move on, let's take a look at the HAML we're going to use for
|
|
our one-page application. The code below compiles beautifully into the
|
|
same HTML seen in the original Backbone Store.
|
|
|
|
<<index.haml>>=
|
|
!!! 5
|
|
%html{:xmlns => "http://www.w3.org/1999/xhtml"}
|
|
%head
|
|
%title The Backbone Store
|
|
%link{:charset => "utf-8", :href => "jsonstore.css", :rel => "stylesheet", :type => "text/css"}/
|
|
<<product list template>>
|
|
<<product detail template>>
|
|
<<cart template>>
|
|
</head>
|
|
%body
|
|
#container
|
|
#header
|
|
%h1
|
|
The Backbone Store
|
|
.cart-info
|
|
#main
|
|
%script{:src => "lib/jquery.js", :type => "text/javascript"}
|
|
%script{:src => "lib/underscore.js", :type => "text/javascript"}
|
|
%script{:src => "lib/backbone.js", :type => "text/javascript"}
|
|
%script{:src => "store.js", :type => "text/javascript"}
|
|
@
|
|
|
|
It's not much to look at, but already you can see where that
|
|
[[DIV\#main]] goes, as well as where we are putting our templates.
|
|
The [[DIV\#main]] will host a number of viewports, only one of
|
|
which will be visible at any given time.
|
|
|
|
Our first view is going to be the product list view, named, well,
|
|
guess. Or just look down a few lines.
|
|
|
|
This gives us a chance to discuss one of the big confusions new
|
|
Backbone users frequently have: \textit{What is \texttt{render()}
|
|
for?}. Render is not there to show or hide the view.
|
|
\texttt{Render()} is there to \textit{change the view when the
|
|
underlying data changes}. It renders the data into a view. In our
|
|
functionality, we use the parent class's \texttt{show()} and
|
|
\texttt{hide()} methods to actually show the view.
|
|
|
|
That call to [[.prototype]] is a Javascript idiom for calling a method
|
|
on the parent object. It is, as far as anyone knows, the only way to
|
|
invoke a superclass method if it has been redefined in a subclass. It
|
|
is rather ugly, but useful.
|
|
|
|
<<product list view>>=
|
|
class ProductListView extends _BaseView
|
|
id: 'productlistview'
|
|
template: $("#store_index_template").html()
|
|
|
|
initialize: (options) ->
|
|
_BaseView.prototype.initialize.apply @, [options]
|
|
@collection.bind 'reset', _.bind(@render, @)
|
|
|
|
render: () ->
|
|
@el.html(_.template(@template, {'products': @collection.toJSON()}))
|
|
@
|
|
|
|
@
|
|
%$
|
|
|
|
That \texttt{\_.template()} method is provided by undescore.js, and is
|
|
a full-featured, javascript-based templating method. It's not the
|
|
fastest or the most feature-complete, but it is more than adequate for
|
|
our purposes and it means we don't have to import another library. It
|
|
vaguely resembles ERB from Rails, so if you are familiar with that,
|
|
you should understand this fairly easily.
|
|
|
|
And here is the HAML:
|
|
|
|
<<product list template>>=
|
|
%script#store_index_template(type="text/x-underscore-tmplate")
|
|
%h1 Product Catalog
|
|
%ul
|
|
<% for(i=0,l=products.length;i<l;++i) { p = products[i]; %>
|
|
%li.item
|
|
.item-image
|
|
%a{:href => "#item/<%= p.id %>"}
|
|
%img{:src => "<%= p.image %>", :alt => "<%= p.title %>"}/
|
|
.item-artist <%= p.artist %>
|
|
.item-title <%= p.title %>
|
|
.item-price $<%= p.price %>
|
|
<% } %>
|
|
|
|
@
|
|
%$
|
|
|
|
|
|
One of the most complicated objects in our ecosystem is the product
|
|
view. It actually does something! The prefix ought to be familiar,
|
|
but note that we are again using [[\#main]] as our target; we will be
|
|
showing and hiding the various [[DIV]] objects in [[\#main]] again and
|
|
again.
|
|
|
|
The only trickiness here is twofold: the means by which one calls the
|
|
method of a parent class from a child class via Backbone's class
|
|
heirarchy, and keeping track of the itemcollection object, so we can add
|
|
and change items as needed.
|
|
|
|
<<product detail view>>=
|
|
class ProductView extends _BaseView
|
|
id: 'productitemview'
|
|
template: $("#store_item_template").html()
|
|
initialize: (options) ->
|
|
_BaseView.prototype.initialize.apply @, [options]
|
|
@itemcollection = options.itemcollection
|
|
@item = @itemcollection.getOrCreateItemForProduct @model
|
|
|
|
@
|
|
%$
|
|
|
|
There are certain events in which we're interested: keypresses and
|
|
clicks on the update button and the quantity form. (Okay, ``UQ''
|
|
isn't the best for ``update quantity''. I admit that.) Note the
|
|
peculiar syntax of ``EVENT SELECTOR'': ``methodByName'' for each
|
|
event.
|
|
|
|
Backbone tells us that the only events it can track by itself are
|
|
those that jQuery's ``delegate'' understands. As of 1.5, that seems
|
|
to be just about all of them.
|
|
|
|
<<product detail view>>=
|
|
events:
|
|
"keypress .uqf" : "updateOnEnter"
|
|
"click .uq" : "update"
|
|
|
|
@
|
|
|
|
And now we will deal with the update. This code ought to be fairly
|
|
readable: the only specialness is that it's receiving an event, and
|
|
we're ``silencing'' the call to [[cart.add()]], which means that the
|
|
cart collection will not publish any events. There are only events
|
|
when the item has more than zero, and that gets called on
|
|
[[cart_item.update()]].
|
|
|
|
In the original tutorial, this code had a lot of responsibility for
|
|
managing the shopping cart, looking into it and seeing if it had an
|
|
item for this product, and there was lots of accessing the model to
|
|
get its id and so forth. All of that has been put into the shopping
|
|
cart model, which is where it belongs: \textit{knowledge about items
|
|
and each item's relationship to its collection belongs in the
|
|
collection}.
|
|
|
|
Look closely at the [[update()]] method. The reference [[@\$]] is
|
|
a special Backbone object that limits selectors to objects inside the
|
|
element of the view. Without it, jQuery would have found the first
|
|
input field of class 'uqf' in the DOM, not the one for this specific
|
|
view. [[@\$('.uqf')]] is shorthand for [[$('uqf', @el)]], and
|
|
helps clarify what it is you're looking for.
|
|
|
|
%'
|
|
|
|
<<product detail view>>=
|
|
update: (e) ->
|
|
e.preventDefault()
|
|
@item.update parseInt(@$('.uqf').val())
|
|
|
|
updateOnEnter: (e) ->
|
|
if (e.keyCode == 13)
|
|
@update e
|
|
|
|
@
|
|
%$
|
|
|
|
The render is straightforward:
|
|
|
|
<<product detail view>>=
|
|
render: () ->
|
|
@el.html(_.template(@template, @model.toJSON()));
|
|
@
|
|
|
|
@
|
|
|
|
The product detail template is fairly straightforward. There is no
|
|
[[underscore]] magic because there are no loops.
|
|
|
|
<<product detail template>>=
|
|
%script#store_item_template(type= "text/x-underscore-template")
|
|
.item-detail
|
|
.item-image
|
|
%img(src="<%= large_image %>" alt="<%= title %>")/
|
|
.item-info
|
|
.item-artist <%= artist %>
|
|
.item-title <%= title %>
|
|
.item-price $<%= price %>
|
|
.item-form
|
|
%form(action="#/cart" method="post")
|
|
%p
|
|
%label Quantity:
|
|
%input(type="text" size="2" name="quantity" value="1" class="uqf")/
|
|
%p
|
|
%input(type="submit" value="Add to Cart" class="uq")/
|
|
|
|
.item-link
|
|
%a(href="<%= url %>") Buy this item on Amazon
|
|
.back-link
|
|
%a(href="#") « Back to Items
|
|
@
|
|
|
|
So, let's talk about that shopping cart thing. We've been making the
|
|
point that when it changes, when you call [[item.update]] within the
|
|
product detail view, any corresponding subscribing views sholud
|
|
automatically update.
|
|
|
|
<<cart widget>>=
|
|
class CartWidget extends Backbone.View
|
|
el: $('.cart-info')
|
|
template: $('#store_cart_template').html()
|
|
|
|
initialize: () ->
|
|
@collection.bind('change', _.bind(@render, @));
|
|
|
|
@
|
|
%$
|
|
|
|
And there is the major magic. CartWidget will be initialized with the
|
|
ItemCollection; when there is any change in the collection, the widget
|
|
will receive the 'change' event, which will automatically trigger the
|
|
call to the widget's [[render()]] method.
|
|
|
|
The render method will refill that widget's HTML with a re-rendered
|
|
template with the new count and cost, and then wiggle it a little to
|
|
show that it did changed:
|
|
|
|
<<cart widget>>=
|
|
render: () ->
|
|
tel = @el.html _.template @template,
|
|
'count': @collection.getTotalCount()
|
|
'cost': @collection.getTotalCost()
|
|
tel.animate({paddingTop: '30px'}).animate({paddingTop: '10px'})
|
|
@
|
|
|
|
@
|
|
|
|
And the HTML for the template is dead simple:
|
|
|
|
<<cart template>>=
|
|
%script#store_cart_template(type="text/x-underscore-template")
|
|
%p Items: <%= count %> ($<%= cost %>)
|
|
|
|
@
|
|
%$
|
|
|
|
Lastly, there is the [[Router]]. In Backbone, the Router is a
|
|
specialized View for invoking other views. It listens for one
|
|
specific event: when the [[window.location.hash]] object, the part of
|
|
the URL after the hash symbol, changes. When the hash changes, the
|
|
Router invokes an event handler. The Router, since its purpose is to
|
|
control the major components of the one-page display, is also a good
|
|
place to keep all the major components of the sytem. We'll keep track
|
|
of the [[Views]], the [[ProductCollection]], and the
|
|
[[ItemCollection]].
|
|
|
|
<<router>>=
|
|
class BackboneStore extends Backbone.Router
|
|
views: {}
|
|
products: null
|
|
cart: null
|
|
|
|
@
|
|
|
|
There are two events we care about: view the list, and view a detail.
|
|
They are routed like this:
|
|
|
|
<<router>>=
|
|
routes:
|
|
"": "index"
|
|
"item/:id": "product"
|
|
|
|
@
|
|
|
|
Like most Backbone objects, the Router has an initialization feature.
|
|
I create a new, empty shopping cart and corresponding cart widget,
|
|
which doesn't render because it's empty. I then create a new
|
|
[[ProductCollection]] and and corresponding [[ProductListView]].
|
|
These are all processes that happen immediately.
|
|
|
|
What does not happen immediately is the [[fetch()]] of data from the
|
|
back-end server. For that, I use the jQuery deferred again, because
|
|
[[fetch()]] ultimately returns the results of [[sync()]], which
|
|
returns the result of an [[ajax()]] call, which is a deferred.
|
|
|
|
<<router>>=
|
|
initialize: (data) ->
|
|
@cart = new ItemCollection()
|
|
new CartWidget
|
|
collection: @cart
|
|
|
|
@products = new ProductCollection [],
|
|
url: 'data/items.json'
|
|
@views =
|
|
'_index': new ProductListView
|
|
collection: @products
|
|
$.when(@products.fetch({reset: true}))
|
|
.then(() -> window.location.hash = '')
|
|
@
|
|
|
|
@
|
|
%$
|
|
|
|
There are two things to route \textit{to}, but we must also route
|
|
\textit{from}. Remember that our two major views, the product list
|
|
and the product detail, inherited from [[\_BaseView]], which has the
|
|
[[hide()]] and [[show()]] methods. We want to hide all the views,
|
|
then show the one invoked. First, let's hide every view we know
|
|
about. [[hide()]] returns either a deferred (if the object is being
|
|
hidden) or null. The [[_.select()]] call at the end means that this
|
|
method returns only an array of deferreds.
|
|
|
|
<<router>>=
|
|
hideAllViews: () ->
|
|
_.select(_.map(@views, (v) -> return v.hide()),
|
|
(t) -> t != null)
|
|
|
|
|
|
@
|
|
|
|
Showing the product list view is basically hiding everything, then
|
|
showing the index:
|
|
|
|
<<router>>=
|
|
index: () ->
|
|
view = @views['_index']
|
|
$.when(@hideAllViews()).then(() -> view.show())
|
|
|
|
@
|
|
%$
|
|
|
|
On the other hand, showing the product detail page is a bit trickier.
|
|
In order to avoid re-rendering all the time, I am going to create a
|
|
view for every product in which the user shows interest, and keep it
|
|
around, showing it a second time if the user wants to see it a second
|
|
time.
|
|
|
|
Not that we pass it the [[ItemCollection]] instance. It uses this to
|
|
create a new item, which (if you recall from our discussion of
|
|
[[getOrCreateItemForProduct()]]) is automagically put into the
|
|
collection as needed. Which means all we need to do is update this
|
|
item and the item collection \textit{changes}, which in turn causes
|
|
the [[CartWidget]] to update automagically as well.
|
|
|
|
<<router>>=
|
|
product: (id) ->
|
|
product = @products.detect (p) -> p.get('id') == (id)
|
|
view = (@views['item.' + id] ||= new ProductView(
|
|
model: product,
|
|
itemcollection: @cart
|
|
).render())
|
|
$.when(@hideAllViews()).then(
|
|
() -> view.show())
|
|
|
|
@
|
|
%$
|
|
|
|
Finally, we need to start the program
|
|
|
|
<<initialization>>=
|
|
$(document).ready () ->
|
|
new BackboneStore();
|
|
Backbone.history.start();
|
|
@
|
|
%$
|
|
|
|
\section{The Program}
|
|
|
|
Here's the entirety of the program. Coffeescript provides its own
|
|
namespace wrapper:
|
|
|
|
<<store.coffee>>=
|
|
<<models>>
|
|
|
|
<<product collection>>
|
|
|
|
<<cart collection>>
|
|
|
|
<<base view>>
|
|
|
|
<<product list view>>
|
|
|
|
<<product detail view>>
|
|
|
|
<<cart widget>>
|
|
|
|
<<router>>
|
|
|
|
<<initialization>>
|
|
@
|
|
|
|
\section{A Little Stylus}
|
|
|
|
Stylus is a beautiful little language that compiles down to CSS. The
|
|
original version of The Backbone Store used the same CSS provided from
|
|
the original Sammy tutorial, but I wanted to show you this one extra
|
|
tool because it's an essential part of my kit.
|
|
|
|
If you want rounded borders, you know that writing all that code, for
|
|
older browsers as well as modern ones, and providing it to all the
|
|
different objects you want styled that way, can be time consuming.
|
|
Stylus allows you to define a function that can be called from within
|
|
any style, thus allowing you to define the style here, and attach a
|
|
set style to a semantic value in your HTML:
|
|
|
|
<<jsonstore.styl>>=
|
|
rounded(radius)
|
|
-moz-border-radius-topleft: radius
|
|
-moz-border-radius-topright: radius
|
|
-moz-border-radius-bottomleft: radius
|
|
-moz-border-radius-bottomright: radius
|
|
-webkit-border-bottom-right-radius: radius
|
|
-webkit-border-top-left-radius: radius
|
|
-webkit-border-top-right-radius: radius
|
|
-webkit-border-bottom-left-radius: radius
|
|
border-bottom-right-radius: radius
|
|
border-top-left-radius: radius
|
|
border-top-right-radius: radius
|
|
border-bottom-left-radius: radius
|
|
|
|
background_gradient(base)
|
|
background: base
|
|
background: -webkit-gradient(linear, left top, left bottom, from(lighten(base, 20%)), to(darken(base, 20%)))
|
|
background: -moz-linear-gradient(top, lighten(base, 20%), darken(base, 20%))
|
|
|
|
@
|
|
|
|
And if you look down below you'll see the [[rounded()]] function
|
|
called for the list items, which have borders.
|
|
|
|
One of the real beauties of Stylus is that you can contains some style
|
|
definitions within others. You can see below that the header
|
|
contains an H1, and the H1 definitions will be compiled to only apply
|
|
within the context of the header. Stylus allows you to write CSS the
|
|
way you write HTML!
|
|
|
|
<<jsonstore.styl>>=
|
|
body
|
|
font-family: "Lucida Grande", Lucida, Helvetica, Arial, sans-serif
|
|
background: #FFF
|
|
color: #333
|
|
margin: 0px
|
|
padding: 0px
|
|
|
|
|
|
#header
|
|
background_gradient(#999)
|
|
margin: 0px
|
|
padding: 20px
|
|
border-bottom: 1px solid #ccc
|
|
|
|
h1
|
|
font-family: Inconsolata, Monaco, Courier, mono
|
|
color: #FFF
|
|
margin: 0px
|
|
|
|
.cart-info
|
|
position: absolute
|
|
top: 0px
|
|
right: 0px
|
|
text-align: right
|
|
padding: 10px
|
|
background_gradient(#555)
|
|
color: #FFF
|
|
font-size: 12px
|
|
font-weight: bold
|
|
|
|
img
|
|
border: 0
|
|
|
|
#productlistview
|
|
ul
|
|
list-style: none
|
|
|
|
.item
|
|
float:left
|
|
width: 250px
|
|
margin-right: 10px
|
|
margin-bottom: 10px
|
|
padding: 5px
|
|
rounded(5px)
|
|
border: 1px solid #ccc
|
|
text-align:center
|
|
font-size: 12px
|
|
|
|
.item-title
|
|
font-weight: bold
|
|
|
|
.item-artist
|
|
font-weight: bold
|
|
font-size: 14px
|
|
|
|
.item-detail
|
|
margin: 10px 0 0 10px
|
|
|
|
.item-image
|
|
float:left
|
|
margin-right: 10px
|
|
|
|
.item-info
|
|
padding: 100px 10px 0px 10px
|
|
|
|
@
|
|
|
|
And that's it. Put it all together, and you've got yourself a working
|
|
Backbone Store.
|
|
|
|
This code is available at my github at
|
|
\nwanchorto{https://github.com/elfsternberg/The-Backbone-Store}{The
|
|
Backbone Store}.
|
|
|
|
\end{document}
|