bitovi/canjs — pull request #549 by simpleTechs (2013-11-14 23:32:52+00:00)
Title: Allow for implicit route-definition in can.Control

This change will allow for way easier organization of multiple controls. Instead of binding every control to `/:view/:action`, you can now bind specific routes that still are matched through the default `/:view/:action/:id` route.
This allows very easy control-segmentation (one control only occupies the routes that are specifically defined for it) while also allowing to "extract" the parameters via `route.attr('view')` and alike.

Quick example:
```javascript
can.Control.extend("Router1", {
"/r1 route" : function () {
console.log('route updated to /r1')
},

"/r1/:id route" : function () {
console.log('route updated to /r1/:id');
},

"/r1/:action/:id route" : function () {
console.log('route updated to /r1/:action/:id')
}
});
can.Control.extend("Router2", {
"/r2 route" : function () {
console.log('route updated to /r2')
},

"/r2/:id route" : function () {
console.log('route updated to /r2/:id');
},

"/r2/action1/:id route" : function () {
console.log('route updated to /r2/action1/:id')
},

"/r2/action2/:id route" : function () {
console.log('route updated to /r2/action2/:id')
},

"/r2/action3/:id route" : function () {
console.log('route updated to /r2/action3/:id')
}
});
can.route('/:view');
can.route('/:view/:id');
can.route('/:view/:action/:id');
```

What do you think, would it make sense to allow for this kind of rules? The patches should not break any existing tests (they don't locally), but I do know this is probably not the most performant way to implement it.

Would you be open to a feature like this anyway?
I was not able to achieve similar behavior using only can.route+can.Map.delegate, it would have been way more complex, so brute-force-trying every possible match seems not too bad to me.