Question

I have a view which doesn’t seem to want to render as the model’s change event is not firing.

here’s my model:

var LanguagePanelModel = Backbone.Model.extend({
    name:       "langpanel",
    url:        "/setlocale",
    initialize: function(){
        console.log("langselect initing")
    }
})

here’s my view:

var LanguagePanelView = Backbone.View.extend({
    tagName:        "div",
    className:      "langselect",
    render:         function(){
        this.el.innerHTML = this.model.get("content");
        console.log("render",this.model.get(0))
        return this;
    },
    initialize : function(options) {
        console.log("initializing",this.model)
        _.bindAll(this, "render");
        this.model.bind('change', this.render);
        this.model.fetch(this.model.url);
  }
});

here’s how I instantiate them:

if(some stuff here)
{
   lsm = new LanguagePanelModel();
   lsv = new LanguagePanelView({model:lsm});
}

I get logs for the init but not for the render of the view?
Any ideas?

Answer 1

I guess it’s about setting the attributes of the model – name is not a standard attribute and the way you’ve defined it, it seems to be accessible directly by using model.name and backbone doesn’t allow that AFAIK. Here are the changes that work 🙂 You can see the associated fiddle with it too 🙂

$(document).ready(function(){
var LanguagePanelModel = Backbone.Model.extend({
    //adding custom attributes to defaults (with default values)
    defaults: {
        name:       "langpanel",
        content: "Some test content"  //just 'cause there wasn't anything to fetch from the server
    },

    url:        "/setlocale",

    initialize: function(){
        console.log("langselect initing"); //does get logged
    }
});

var LanguagePanelView = Backbone.View.extend({
    el: $('#somediv'), //added here directly so that content can be seen in the actual div

    initialize : function(options) {
        console.log("initializing",this.model);
        _.bindAll(this, "render");
        this.render(); //calling directly since 'change' won't be triggered
        this.model.bind('change', this.render);
        //this.model.fetch(this.model.url);
    },

    render: function(){
        var c = this.model.get("content");
        alert(c);
        $(this.el).html(c); //for UI visibility
        console.log("render",this.model.get(0)); //does get logged :)
        return this;
    }
});

var lpm = new LanguagePanelModel();
var lpv = new LanguagePanelView({model:lpm});

}); //end ready

UPDATE:

You don’t need to manually trigger the change event – think of it as bad practice. Here’s what the backbone documentation says (note: fetch also triggers change!)

Fetch

model.fetch([options])
Resets the model’s state from the server.
Useful if the model has never been populated with data, or if you’d
like to ensure that you have the latest server state. A “change” event
will be triggered if the server’s state differs from the current
attributes. Accepts success and error callbacks in the options hash,
which are passed (model, response) as arguments.

So, if the value fetched from the server is different from the defaults the change event will be fired so you needn’t do it yourself. If you really wish to have such an event then you can use the trigger approach but custom name it since it’s specific to your application. You are basically trying to overload the event so to speak. Totally fine, but just a thought.

Change

model.change()
Manually trigger the “change” event. If you’ve been
passing {silent: true} to the set function in order to aggregate rapid
changes to a model, you’ll want to call model.change() when you’re all
finished.

The change event is to be manually triggered only if you’ve been suppressing the event by passing silent:true as an argument to the set method of the model.

You may also want to look at ‘has changed‘ and other events from the backbone doc.

EDIT Forgot to add the updated fiddle for the above example – you can see that the alert box pops up twice when the model is changed by explicitly calling set – the same would happen on fetching too. And hence the comment on the fact that you “may not” need to trigger ‘change’ manually as you are doing 🙂