Backbone.js adds Controllers and History
documentcloud.github.com
documentcloud.github.com
var Workspace = Backbone.Controller.extend({
routes:{
"search/:query/p:page": "search",
"folder/:name": "openFolder",
},
search: function(query, page) {
...
},
openFolder: function(name) {
...
}
});
Which will properly route URLs like "example.com/#search/lemons/p7"Pieces of the critique definitely apply to this release: I'm still of the opinion that routing is a relatively small portion of a client-side app. And you'll probably wind up with 10x more Views, Models, and Collections than you do Controllers.
The big difference between this approach and Sammy's is that here Controllers are just a library you can use -- with Sammy you structure your whole app around inappropriate faux-server-side-URLs-with-HTTP-methods. (Also, this works in Internet Explorer.) In the end, enough people requested we add routing to Backbone that it made sense to plug it in, one more battery included.
We talked about it a bit, and the consensus was that "/#!/" URLs were a temporary hack that is obsolete now that "pushState" and "replaceState" are part of HTML5 -- you can now mint real URLs that are crawled by Google and are accessible from single-page apps as well.
Didn't understand the downvotes.
example.com/#search/washington+news/p10
... to make it a bit more obvious that the number at the end is a page number. This is actually a real-world example -- it's the same route that DocumentCloud uses to run searches in the workspace. "image":"http://s3.dcloud.org/docs/101/pages/inauguration{page}-{size}.gif"
I'd be a bit concerned if we used them in Backbone, that we wouldn't be following the spec by parsing all variants of the expansions -- but on balance, it's probably a great thing to do.So, thanks!
A large part of jQuery's appeal is its modularity. The address-plugin already exists and seems to do the job very well.
In that spirit I'd prefer to see backbone stay as modular as possible, too, and have it integrate with existing, mature solutions, rather than grow its own knockou^Wknockoffs.
Now that there is a bit more client-side-only code, in the next release, we'll probably split the source into individual components, so that you can just load Models and Collections on the server-side.
With modularity I don't strictly mean LOC. Rather I think that most of these lines in the address plugin are probably in there for a good reason. Thus if backbone ships its own solution to the problem, but that solution covers only part of what I need, then I'd have to integrate both - and perhaps deal with conflicts. That would be undesirable.
On the other hand I recognize that introducing dependencies to specific other plugins is also undesirable. I'm a bit torn about which is the lesser evil here.
On the other hand, I'll leave it up to your judgement whether the lines in the address plugin are necessary. You can compare implementations here:
https://github.com/asual/jquery-address/blob/master/src/jque...
http://documentcloud.github.com/backbone/docs/backbone.html#...
If 90% of Backbone apps end up using Controllers, it's better to include a concise implementation than a heavy dependency, I think.