Backbone patterns
ricostacruz.com
ricostacruz.com
ContactView = Backbone.View.extend({
template: function() {
var template = _.template($("#template-contact").html());
return template.apply(this, arguments);
},
render: function() {
// This is a dictionary object of the attributes of the models.
// => { name: "Jason", email: "j.smith@gmail.com" }
var dict = this.model.toJSON();
// Pass this object onto the template function.
// This returns an HTML string.
var html = this.template(dict);
// Append the result to the view's element.
$(this.el).append(html);
// ...
}
})
Otherwise, for every view you will be fetching the template from the DOM. The difference in implementation would be from this:
<div id="template-contact">Mail me at <%= email %></div>
<script>var templateContact = "Mail me at <%= email %>"</script>
If anyone want to see a rails-backbone application example Railscasts has published today "Backbone on rails part 1"[1].
[1] http://railscasts.com/episodes/323-backbone-on-rails-part-1
PS It's a paid screencast, but railscasts pro is worth the money.
I was about to make a pull request to fix a typo, when I found someone had already done so: https://github.com/rstacruz/backbone-patterns/pull/3
If a objective correction like this takes 6 weeks (and counting!) to be merged, does the open nature of this page really matter?
Not that this detracts from the message, but take the claim "This is a massive work-in-progress." with a grain of salt.
Sometimes They are used to listen to collections and create smaller things( like a factory ) sometimes they can represent a whole small popup, sometimes a single HTML entity. I am sure my code is not 100% yet, but patterns like this help a lot.
It takes a bit of forethought but you end up with much nicer, composable interfaces that allow you to respond quickly to changing requirements.
Also whats the purpose of putting your templates inline? I compile all my templates server side into a js file called template.js and when I need a template I simply call:
Template.documents.index
Performing "silent" changes to a model are a power-user feature of Backbone, where you can twiddle attributes on a model temporarily, or many times, without receiving change events. Then, when you're ready, you get a single change event with the diff in model state.
Prior to 0.9, you'd get the single diff, but not all of the individual "change:attribute" events for the diff. 0.9 and above have been improved to give you both. Yes, it's something to watch out for if you want to upgrade an existing app.
The way that silent works now should be it's own option, say "defer". Because you're deferring the changes until a later date. It could even be called delay or later. Whatever it is called, it is in no way silent anymore.
My proposal is to add a new option, mute, which bypasses the change events and causes the attribute to change but does not trigger change:attribute.
That said, what you do with your copy of backbone.js in your own project is your business. I'd highly encourage you to extend your version with your preferred behavior for "silent" -- in fact, the source is annotated to make this sort of thing easier for folks that find the need.
1. Initialize views without models, hidden.
2. Make your 'top-level' view bind to a collections 'reset' event that fires once the model is loaded. At that stage you can give instances of the loaded models to whatever views need them and they can redraw themselves, either by calling a method on them directly or because they're listening for some event that you trigger.
from dynamicresponse.emitters import JSONEmitter
@register.filter
def serialize_to_json(obj):
emitter = JSONEmitter(obj, {}, None)
return emitter.render()
var myObj = new MyObject({{python_object|serialize_to_json}});
var myObjView = new MyObjectView({ model: myObj });
If you feel weird about loading data as a js file, there is also a requirejs plugin for loading raw json files as a module: https://github.com/millermedeiros/requirejs-plugins
myApp.init = function() {
Books.fetch();
Authors.fetch();
Notes.fetch();
...
};
Im curious how one would setup a instant search using it? I have done it previously by attaching a jQuery keyup event listener but I know I should be using a view. I have had a poke on google for this but haven't turned up anything.
(function(){
var myPrivateView = Backbone.View.extend({...});
app.views.Foo = Backbone.View.extend({
/* use myPrivateView somewhere in here */
});
})();The Backbone link goes to a "who is using Backbone" page. Which is nice, and quite convincing that Backbone is a serious library used in some huge projects.
The Knockout link, however, goes to a "how do you use Knockout" page. Which is also nice, and a very useful documentation source that Backbone is sadly lacking.
But as a new developer, if anything, the Knockout link is a better reason to pick it. Good documentation goes a LOT further than knowing that Groupon has selected the library, in my book.
Backbone is, basically, just some "smart" models and collections that know how to consume and persist to a REST data source, and a router. If you want anything else - like templates, or any support for relational data, or two way binding of your data to your rendered HTML, then you need to turn to standalone libraries or plugins, or just write it yourself. (Note: There's some kickass template libraries around, but in my experience the only data binding options are Backbone.ModelBinding and Synapse, and neither of them is production ready. I also had a bad experience with Backbone relational. YMMV) Also, Backbone is, by design, very much NOT opinionated. You can structure your code however you want. That's good if you know what you're doing, but a pain in the ass if you're coming at it fresh from Django or something.
Knockout is, basically, just a fantastic data binding library with integrated support for a decent template library. If you need smart models, or to persist stuff to a REST data store, or routing, then you need to use standalone libraries or roll your own. (Note: Writing your own code to load and save models is actually easy. And as far as routing goes, there's a million solution. I like Sammy though.) Also, it's a little more opinionated, and I like the docs better - they give concrete examples of how to do things, rather than vague "some people like to implement this via X, but others prefer to Y" hints, like Backbone.
In short, neither is going to give you the full set of tools you want; you should pick the one that is more closely tailored to what you are planning, but always keeping in mind that you're going to need to fill in a lot of gaps yourself. (Hell, some people use both libraries at once; there's actually not a lot of overlap.) So it's not really a question of how complicated the webapp is, but more a question of what kind of webapp it is, and what features it needs.
If I was going to write a streaming music player (or something else that basically needs to be a simple GUI over some very complex JS code), I'd be inclined to turn to Backbone. I believe Pandora used Backbone for their recent interface rewrite, and PeepCode has an excellent series of tutorials showing someone building a music player in Backbone you can follow along with.
On the other hand, if I was building any form of CRUD app, especially one with a very complex or rich interface, and especially one that needs to edit deeply nested relational data, I'd be strongly pulled towards Knockout. You could do it in Backbone, but you'd do it by, basically, rewriting the core of Knockout in your own code, while getting only minimal benefit from Backbone.
TL;DR summary: Neither is really simpler. Neither is more appropriate for more complex apps. They solve different problems. (But personally, I had some pretty complex problems to solve, and after struggling with Backbone for weeks because all the cool kids were using it, I eventually rewrote my app in Knockout, and breathed a sigh of relief. More functionality in less time with fewer bugs and prettier code. But that's me, for my app. Different programmer or a different app? Different story. And keep in mind there's like, 15 different JS frameworks out there, some of which also look awesome. Serenade and Ember in particular...)