Come visit us!

Create a migration:

  def up
    add_column :users, :deleted_at, :timestamp
  end

When deleted_at gets a value, we’ll consider the record deleted. Otherwise, it is active. Now we need to change the log in behaviour to check if the user has been deleted or not. Devise provides the valid_for_authentication? method, which you can override as I did below:

  def valid_for_authentication?
    result = super
    self.deleted_at.present? ? false : result
  end

This method first checks whatever ‘super’ has to say about the user’s eligibility to log in, and then checks whether the deleted_at value has been set. If it has, the user is not allowed to log in (returning false). If it has not, then whatever the value for result is is used.

Finally, you’ll want a scope for active users:

scope :active, where(:deleted_at => nil, :confirmation_token => nil)

If you’re using devise_invitable you’ll also want to include :invitation_token => nil, or any other rules for what defines an active user.

So we’ve covered models, collections, controllers, and the basic case of tying a view to a model’s callbacks.

Now we’re going to cover tying a view to a collection. This gets a little hairy, so I’m going to keep it nice and simple to start.

Note: As with most things, there are large number of ways you could do this. If you feel that you have a better way, feel free to reply with it as a comment.

A Basic Collection View

Let’s say that we have an existing page that looks like this:

<header> OMG Donut Shop </header>

<section>
  <header>Donut Selection</header>
  <ul class=donuts></ul>
</section>

I’m going to define a DonutCollectionView that will, when given a collection of donuts, render an UpdatingDonutView for each donut.

This is a pattern I use fairly often. A View that is composed of other views. In this way you can easily reuse functionality between Views.

var DonutCollectionView = Backbone.View.extend({
  initialize : function() {
    var that = this;
    this._donutViews = [];

    this.collection.each(function(donut) {
      that._donutViews.push(new UpdatingDonutView({
        model : donut,
        tagName : 'li'
      }));
    });
  },

  render : function() {
    var that = this;
    // Clear out this element.
    $(this.el).empty();

    // Render each sub-view and append it to the parent view's element.
    _(this._donutViews).each(function(dv) {
      $(that.el).append(dv.render().el);
    });
  }
});

Initialize

I didn’t go into much detail about this before. Backbone’s View, Model, and Collection all have their own constructors (which you don’t override*) that take care of initializing a number of functionalities, and the “initialize” method is run inside of their constructors.

*You could, but you’d better have a good reason.

Creating and Rendering

So let’s say I create a Backbone.Collection of donuts.

var donuts = new Donuts([
  {"name" : "Boston Cream"},
  {"name" : "Lemon-Filled"},
  {"name" : "Rusty Iron Shavings"}
]);

I can then create a View with those Donuts.

var donutCollectionView = new DonutCollectionView({
  collection : donuts,
  el : $('ul.donuts')[0]
});

donutCollectionView.render();

This will render each of the donuts into the View and append them to the ul that I created earlier. Which will end up looking like this:

<header> OMG Donut Shop <header>

<section>
  <header> Donut Selection <header>
  <ul class="donuts">
	<li> Boston Cream </li>
	<li> Lemon-Filled </li>
	<li> Rusty Iron Shavings </li>
  </ul>
</section>

So by virtue of using our UpdatingDonutView, the individual donuts will register changes and rerender.

But adding or removing an item from the collection won’t be reflected. Let’s alter the above DonutCollectionView and hook it into the Collection’s events.

As a reminder, the collection will trigger “add” events each time a model is added to it, and a “remove” event each time a model is removed.

So what would binding the view above to the collection’s events look like?

var DonutCollectionView = Backbone.View.extend({
  initialize : function() {
    // bind the functions 'add' and 'remove' to the view.
    _(this).bindAll('add', 'remove');

    // create an array of donut views to keep track of children
    this._donutViews = [];

    // add each donut to the view
    this.collection.each(this.add);

    // bind this view to the add and remove events of the collection!
    this.collection.bind('add', this.add);
    this.collection.bind('remove', this.remove);
  },

  add : function(donut) {
    // We create an updating donut view for each donut that is added.
    var dv = new UpdatingDonutView({
      tagName : 'li',
      model : donut
    });

    // And add it to the collection so that it's easy to reuse.
    this._donutViews.push(dv);

    // If the view has been rendered, then
    // we immediately append the rendered donut.
    if (this._rendered) {
      $(this.el).append(dv.render().el);
    }
  },

  remove : function(model) {
    var viewToRemove = _(this._donutViews).select(function(cv) { return cv.model === model; })[0];
    this._donutViews = _(this._donutViews).without(viewToRemove);

    if (this._rendered) $(viewToRemove.el).remove();
  },

  render : function() {
    // We keep track of the rendered state of the view
    this._rendered = true;

    $(this.el).empty();

    // Render each Donut View and append them.
    _(this._donutViews).each(function(dv) {
      this.$('ul.donuts').append(dv.render().el);
    });

    return this;
  }
});

The use of this DonutCollectionView is identical to the one above, but now it’s adding and removing properly.

Building a Generic UpdatingCollectionView

Alright, so that’s a lot of code to get an updating collection view for donuts. Maybe not the awesomest thing ever. But does it really need to be tightly coupled to Donuts or DonutViews? Let’s decouple this jerk and make a generic updating view that we can use like this.

var donutCollectionView = new UpdatingCollectionView({
  collection           : donuts,
  childViewConstructor : UpdatingDonutView,
  childViewTagName     : 'li',
  el                   : $('#donut_list')[0]
});

And here’s the implementation of that…

var UpdatingCollectionView = Backbone.View.extend({
  initialize : function(options) {
    _(this).bindAll('add', 'remove');

    if (!options.childViewConstructor) throw "no child view constructor provided";
    if (!options.childViewTagName) throw "no child view tag name provided";

    this._childViewConstructor = options.childViewConstructor;
    this._childViewTagName = options.childViewTagName;

    this._childViews = [];

    this.collection.each(this.add);

    this.collection.bind('add', this.add);
    this.collection.bind('remove', this.remove);
  },

  add : function(model) {
    var childView = new this._childViewConstructor({
      tagName : this._childViewTagName,
      model : model
    });

    this._childViews.push(childView);

    if (this._rendered) {
      $(this.el).append(childView.render().el);
    }
  },

  remove : function(model) {
    var viewToRemove = _(this._childViews).select(function(cv) { return cv.model === model; })[0];
    this._childViews = _(this._childViews).without(viewToRemove);

    if (this._rendered) $(viewToRemove.el).remove();
  },

  render : function() {
    var that = this;
    this._rendered = true;

    $(this.el).empty();

    _(this._childViews).each(function(childView) {
      $(that.el).append(childView.render().el);
    });

    return this;
  }
});

Using the UpdatingCollectionView

So, now that we’ve made a generic updating collection view, let’s go through a potential use case of it!
Let’s say that we’re building a view for a DonutShop.

I’m starting to get nice and opinionated now and I’m going to bring in jQuery template
Here’s a template for a DonutShop

<script id="tmpl-donut_shop" type="template/jquery">
  <header>{{name}}</header>

  <section>
    <header>Donuts offered:</header>
    <ul class=donuts></ul>
  </section>
</script>

And now I’ll declare a view that uses that template.

var DonutShopView = Backbone.View.extend({
  templateId : 'donut_shop',
  initialize : function() {

    // Don't worry about this syntax too much.
    // Basically all that this template bit does is grab a template from jQuery
    // I'll have taken care of compiling the template somewhere earlier.
    this.template =  $.template(this.templateId);
    this._donutCollectionView = new UpdatingCollectionView({
      collection           : this.model.donuts,
      childViewConstructor : UpdatingDonutView,
      childViewTagName     : 'li'
    });
  },

  render : function() {
    $(this.el).empty();

    // And here I use the template to render this object,
    // then take the rendered template
    // and append it to this view's element.
    $.tmpl(this.template, this.model.toJSON()).appendTo(this.el);

    this._donutCollectionView.el = this.$('.donuts');
    this._donutCollectionView.render();
  }
});

var donutShopView = new DonutShopView({ model : donutShop });

So now we’ve got a donut shop view, which contains an autoupdating collection view, which contains autoupdating model views.

Everything stays in sync.

And everyone is happy.

Next, I will be going over declaratively binding events to views, which is a pretty great thing.

• A history of JavaScript and jQuery
  • Where JavaScript started.
  • Why we hated it (popups! popunders! marquees! dropdown navigation that didn’t work!)
  • Why developers looked down their noses at JS for years.
  • The introduction of Ajax and how it changed the web world, being the technological start of Web 2.0, as well as making the Internet a whole lot faster.
  • JavaScript frameworks, and why jQuery rose to the top to back over 41% of the top 10,000 web sites.
• A demo of jQuery — I had created a simple blog-like page and then used jQuery to manipulate DOM elements and add events various elements, including a form.
• A discussion of why I believe JavaScript is the future of the web — This is the subject of a future blog post, but a few of my bullet points are:
  • JavaScript is amazingly fast and it’s only getting faster.
  • JS is available on almost every modern Internet-connected device, and usually with a pretty respectable interpreter.
  • With recent improvements in browsers, the age of the fat client distributed over the Internet is finally here.
  • Fat client JS in the browser allows for a really light-weight server, meaning we have a new paradigm of scalability available to us.

The audience for my talk ended up being about 80% techies and 20% noobs, so I could have probably stepped up the technical complexity a bit to hit the majority a little better. Still the talk was well received and I had the opportunity to meet a number of Halifax-based developers I hadn’t met before. The conference photographer managed to snap a photo of me while I gave the talk.

Update: Glen Canning from videojournalist.ca wrote a really nice review of my talk.

That completed the first session. A quick iPad draw, didn’t win, and on to the next session. This one was titled JavaScript & jQuery – What it is, How to use it, and Why it’s the future of the web and it was presented by Paul Doerwald. Paul is is Chancellor of Liquid Media, a boutique web software development shop located in downtown Halifax, Nova Scotia. He and his team develop cutting-edge web applications, built primarily using Ruby and Ruby on Rails framework. I don’t even know what that means. Anyway, I took this session because I want to add more jQuery features to videojournalist.ca. Everyone there seemed to have some web development skills. For me that means Flash, html, php, perl, and a little javascript. For other it meant a great deal more but Paul spoke in a way that allowed his information to be on level with most of us. Thankfully! So JavaScript is getting huge geek love. All the cool apps are java apps – like Twitter and jQuery is the Standard Library for the web (@wycats). Paul spoke about Java history, problems, and solutions and explained why jQuery the winner? He even gave samples and coded for us. Loved this presentation and got out of it what I had hoped which was more information on the uses of jQuery.

We’re good with Backbone.Model. We’re good with Backbone.Collection. We’re good with Backbone.Events. So:

Backbone.Controller:

If you’re coming from Rails land, you’ll be pretty familiar with this guy, although it’s got a pretty neat twist. You get to write your routes right in the controller. This is very, very nice to work with.

var MyController = Backbone.Controller.extend({
  routes : {
    "say/:something" : "say"
  },

  say : function(something) {
    alert(something);
  }
});

var yC = new MyController;

Backbone.history.start();

This is pretty straightforward. I defined a prototype and constructor for MyController, complete with one route and the property name, as a string, of the function in this Controller that you want it it to call (analogous to an action in Rails).

Backbone.history is where Backbone stores all of the places you’ve been. This is necessary in order to not break the back button in your browser.

When I called the constructor, MyController gave all of its’ routes to Backbone.history, along with their relevant callbacks.

Next, when I called Backbone.history.start(), Backbone subscribed to the browser’s hashchange event*. Whenever the hash changes, Backbone.history takes care of running your Controller’s function.

*If the browser supports it. Otherwise, it starts monitoring the window.location for hashchanges periodically.

Now if I navigate to “http://myapp.root/#say/hello_world” … I get a butt ugly alert with “hello_world” in it.

Backbone.Views:

Views are designed to encapsulate a DOM element’s functionality. It exists between a Model/Collection and the DOM.

The View has the following responsibilities:

• rendering the DOM element
• initializing DOM events for user interactions within the element
• subscribing to events that are relevant to the DOM element and updating it appropriately, such as:
  • When a Model changes.
  • When a Collection changes.
  • When a specific event occurs elsewhere on the page (navigation, etc, etc).

While this is the general idea of the View, you are perfectly free to do whatever else you’d like with it. Backbone also doesn’t provide any implementation of these details, other than the triggering/binding of Events, so you’re free to implement what you’d like with the framework(s) of your choosing.

Creating a View Prototype

Let’s cut to the chase and make one!

DonutView = Backbone.View.extend({
  tagName : "div",
  className : "donut",

  render : function() {
    this.el.innerHTML = this.model.get('name');

    return this;
  }
});

I’ve overriden three values in my new prototype. The first two are fairly self-explanatory. When you create the donut view, it will create a div element with the class “donut”.

The last — “render” — is the core function of the Backbone.View. The View itself will create an element, but “render” is where you tell your view how to render itself. Backbone has no opinion on how you do this, so feel free to experiment with one of the dozens of JavaScript template formats that have crept up. (Here’s a cool performance comparison). In this case I set the innerHTML of the element to the content I desire. Pretty straightforward.

var bcDonut = new Donut({
  name : "Boston Cream"
});

var bcDonutView = new DonutView({
  model : bcDonut
});

var renderedDonutElement = bcDonutView.render().el;

Binding a View to a Model’s Changes

This is a little bit of overhead for just rendering a model’s name. but this extra layer of abstractions gets us a lot. For instance, what if you want to automatically update the view whenever the model changes?

var UpdatingDonutView = DonutView.extend({
  initialize : function(options) {
    this.render = _.bind(this.render, this); 

    this.model.bind('change:name', this.render);
  }
});

Whoa. Did I blow your mind? First thing we inherited the prototype of DonutView, and overrode its’ “initialize” property with our own function.

Inside initialize we bind this.render to our instance of UpdatingDonutView. The Underscore method ‘bind’ makes sure that when we call “this” in  ”render” it will always reference this UpdatingDonutView instance.

Then we bind to the model’s “change:name” event with “render” as the callback function. It’ll now re-render this view when the name changes. Cool!

var uDonutView = new UpdatingDonutView({
  model : bcDonut
});

var renderedDonutElement = uDonutView.render().el;

Now, if we change the name:

uDonutView.model.set({name : "Lemon-Filled"});

The element reflects the name change!

renderedDonutElement.innerHTML;
-> "Lemon-Filled"

That took a little longer than I’d expected to go over, so we’re going to save collection binding for the next post!

JavaScript interpreters are FAST, and they’re in every browser out there. You can run a rich application in the browser using only open technologies and built in browser-functionality, today.

Backbone.js can help build it. It’s a light-weight MVC for the browser – only ~1000 lines of code, and it’s clean.

There’s no magic. It’s mostly just a structure for the code you write – not a bulky collection of widgets and doodads. It’s fast to learn, and lets you work with whatever technologies you’re already comfortable with.

Trying Out Backbone

If you’re looking to try it out, you’re going to need to load Underscore.js first. It’s Backbone’s only major dependency.

Oh yeah, and Backbone does not have anything to do with the DOM, although it does have some loose dependencies on the $ and ajax calls of jQuery/Zepto. If you aren’t using jQuery or Zepto then you’ll need to do a little more work (like 10 lines of code). I’ll go over the particulars in the next post. For now, play nice and just use jQuery or Zepto if you feel like following along.

What’s going on in there?

There are five main prototypes in Backbone.

• Backbone.Collection – A little more than what you’re thinking.
• Backbone.Model – ActiveRecord implementation, but it’s got a url!
• Backbone.Controller – More or less exactly what you’re thinking.
• Backbone.View – If you’re from Rails, then it’s not what you’re thinking.
• Backbone.Events – Inherit from this guy to give your objects PubSub!

In this blog post we’re going to look at Models, Collections, and Events.

Backbone.Model:

An implementation of the ActiveRecord pattern, but using JSON and a RESTful API instead of directly interfacing with a database.

So let’s say that we’re working on a donut app, and we want to be able to describe our donuts!

  // We extend the Backbone.Model prototype to build our own
  var Donut = Backbone.Model.extend({

    // We can pass it default values.
    defaults : {
      name : null,
      sparkles : false,
      cream_filled : false
    },

    url : function() {
      // Important! It's got to know where to send its REST calls.
      // In this case, POST to '/donuts' and PUT to '/donuts/:id'
      return this.id ? '/donuts/' + this.id : '/donuts';
    } 

  });

That’s analogous to defining a model class in Rails. Now let’s put it through it’s paces a little.

// Instantiating
  var bostonCream = new Donut({ // attributes passed to the Donut constructor will override the defaults
    name : "Bostan Cream",
    cream_filled : true
  });

  // Updating and retrieving attributes
  // Actually, let's put sprinkles on that...
  bostonCream.set({ sprinkles : true }); 

  // Saving
  bostonCream.save(); // this will now POST to the RESTful interface.

Backbone.Model#save is an asynchronous method. So you’ll need to provide a callback. The following code assumes success.

  // Now that it's saved it'll have an id..
  bostonCream.id;
  -> 3, or whatever number your JSON api passed up.

  // Wait, what's the name?
  bostonCream.get("name");
  -> "Bostan Cream"

  // Ugh, sprinkles are gross. And there's a typo in the name.
  bostonCream.set({
    sprinkles : false,
    name : "Boston Cream"
  });

  // Updating
  bostonCream.save(); // and now it's a PUT.
  // it will put directly to "donuts/3", since that's the URI
  // of the model now.

Backbone.Collection:

A collection of models, duh. It’s a little smarter than that. It proxies to Underscore to give you a bunch of sweet list functions for working your data out, and lets you keep an eye on what your models are up to through a bunch of handy events. Plus, if you have a RESTful API you can tie them directly to a collection on your backend. Cool, right?

So let’s work out this donut example a little. If you want to manage a collection of donuts, we can use the same API we were working with earlier…

  var Donuts = Backbone.Collection.extend({
    model : Donut,
    url : "/donuts"
  });

  var donuts = new Donuts;

  donuts.fetch(); // this makes a call to the server and populates the collection based on the response.

The call to collection#fetch is asynchronous, so let’s assume this code is being run after the call is complete.

  donuts.at(0); -> gets donuts by index.
  donuts.get(0); -> gets donuts by id.

And a few examples of the Underscore iterator methods…

  donuts.each(function(donut) {
    console.log(donut.get("name"));
  });

  // Select donuts with names longer than 2
  donuts.select(function(donut) {
    return donut.get("name").length > 2;
  });

  // Map...
  donuts.map(function(donut) {
    return donut.get("name");
  });

Nested Collections

One of the most common uses for collections is to make them nested. In this case, let’s introduce another model, the “Donut Shop” and let’s say that it has a list of Donuts that it serves.

  var DonutShop = Backbone.Model.extend({
    defaults : {
      name : "Untitled"
    },

    initialize : function() {
      // When you extend a Backbone.Model and give it an initialize function,
      // the function is called when you instantiate an instance of your Model.

      // The initialize function is used repeatedly in Backbone's prototypes. We'll be seeing this again
      this.donuts = new Donuts;
      this.donuts.url = 'donut_shops/' + this.id + "/donuts";
    }
  });

So now if you have an existing donut shop that has been saved to the server, you can go:

  donutShop.donuts.fetch();

Backbone.Events:

All of the Backbone core objects give you events to plug in to. For instance, the Collection prototype allows you to bind to “add” and “remove” events.

  donutShop.donuts.bind("add", function(donut) {
    alert("added " + donut.get("name"));
  });

  // now adding a donut will trigger the alert
  var lemonFilled = donutShop.donuts.add({ name : "Lemon Filled" });

Backbone provides you with the Backbone.Events object as well. So, since Underscore is a prereq of Backbone anyway, you can do fancy nonsense like this…

var application = {};
_(application).extend(Backbone.Events);

// Now your application object has it's own events! For example.

application.bind("fun:had", function() { alert("wee!"); });
application.trigger("fun:had"); // it'll alert "wee!"

There’s part 1. Next time I’ll take you through some fun parts:

• Navigating using Backbone.Controllers
• HashChange routing!
• Creating a view
• Tying a view to model events
• Tying a view to a collection’s events.

If you’re looking to try out Backbone, which I’m guessing you are, here are the relevant links.

• Underscore.js.
• Backbone.js.