Thanks for sharing your struggles and helping out. I'm not sure that I like having to give up the ability to have a default route and instead have to create specific routes in order to bind to them.
Since this post, I've dug into the code a bit more and think that the can control route plugin could just be tweaked to look for the most-specific match of a route handler on the can.control, based on not just the pattern but the current route values. Currently, the logic just looks for a match of the matched route pattern (which comes back as :type/:view -- the default route in my code above) against registered handlers by string match. Would seem to me that you could include some substitution of known route values and search for all of the handlers that match.
e.g. you could have listeners like:
'foo/bar route'
'foo/:view route'
':type/:view route'
And those could all match and be fired by the plugin. Perhaps the plugin could expose a way to override the matching logic so you could define your own lookup convention as well.
BTW, is the project team out there? It's been radio silence on this issue ;-)
Since this post, I've dug into the code a bit more and think that the can control route plugin could just be tweaked to look for the most-specific match of a route handler on the can.control, based on not just the pattern but the current route values. Currently, the logic just looks for a match of the matched route pattern (which comes back as :type/:view -- the default route in my code above) against registered handlers by string match. Would seem to me that you could include some substitution of known route values and search for all of the handlers that match.
e.g. you could have listeners like:
'foo/bar route'
'foo/:view route'
':type/:view route'
And those could all match and be fired by the plugin. Perhaps the plugin could expose a way to override the matching logic so you could define your own lookup convention as well.
BTW, is the project team out there? It's been radio silence on this issue ;-)