Works for me. Would you be interested in writing up a patch and
submitting it to jira? If not, I could work up the change but it may
take a few days longer as I'm trying disparately to get caught up on
some day job stuff.
- James
ed_ruder wrote:
James,
I'm not very familiar with Abdera, but I have browsed the source a bit after
hitting the same limitation that Jim reported, while working on Shindig. I
*think* that a simple change in RouteManager could alleviate some (and for
me, I think, all) of the limitation.
When resolving a route, Rails walks through its routes in the order that
they are defined. RouteManager walks through the targets.entrySet, which is
unordered. If RouteManager kept a targets List<> instead of a targets Map<>,
it could walk through the routes in order. (There would need to be a new
class defined, to hold both the Route and TargetType, but it would be very
simple.)
To work around the limitation Jim describes, a client would define a
/base/:collection/:entry route before the /base/:collection route.
WDYT?
Ed
James M Snell wrote:
Ruby matching can span segments if a default value for the missing
variables is provided. We, however, don't have default values for our
variables. It would make sense for us to tighten up the matching rules.
- James
Jim Ancona wrote:
I have run into some problems with my Routes matching unexpectedly.
Before filing a bug, I thought I'd ask for feedback on whether the
current behavior is correct.
The current algorithm attempts to match the non-variable parts of the
pattern, setting the variable to whatever is in between.
So the pattern "/base/:collection/" matches both "/base/test/" and
"/base/test/123/". In the second case, the value of the collection
variable is "test/123". In my opinion, not allowing matches to span URI
segments would be less prone to unintuitive results.
FWIW, a quick glance at some docs on Ruby Routes seems to indicate that
they do not span URI path segments.
Thoughts?
Jim
