abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James M Snell <jasn...@gmail.com>
Subject Re: RouteManager
Date Tue, 29 Jan 2008 17:28:47 GMT
The matching rules are loosely modeled after this:

from the example given by that link

m.connect(':controller/:action/:id', action='view', id=4)

# Will match all of the following
# /content/view/4
# /content/view
# /content

This works, of course, because of the default values given for action 
and id, which we currently do not have any notion of.

The main thing about Routes is that I'm not yet certain exactly how they 
should work in this context yet.  The basic implementation provides is 
exactly that, just a quick basic implementation intended to lay the 
basic groundwork for a more fully fleshed out implementation.

- James

Dan Diephouse wrote:
> But "/customers" shouldn't match "/:collection/:entry" at all should it? 
> Its missing that second path segment.
> - Dan
> James M Snell wrote:
>> Yes, the Route matching is very loose.  We need to be able to match 
>> against multiple route patterns, but the patterns need to be sorted in 
>> terms of the most-specific/least-specific/closest-match.
>> - James
>> Dan Diephouse wrote:
>>> James M Snell wrote:
>>>> FYI.. within the i18n and server modules, you will find two new 
>>>> classes: Route and RouteManager.  A "Route" is loosely based on the 
>>>> Ruby on Rails route concept for URI templating, e.g. 
>>>> ":collection/:entry". RouteManager is a Target Resolver and Target 
>>>> Builder implementation that uses simple routes.
>>>> For instance,
>>>>   RouteManager rm = new RouteManager()
>>>>     .addRoute("feed", ":collection", TargetType.TYPE_COLLECTION)
>>>>     .addRoute("entry", ":collection/:entry:", TargetType.TYPE_SERVICE);
>>>> A Provider can then use RouteManager as the Target Resolver and 
>>>> Target Builder.
>>>> Then mechanism is highly experimental and definitely needs more 
>>>> fleshing out but the foundation is there.
>>>> Comments/Feedback/Suggestions are requested.
>>>> - James
>>> I'm actually diving into this right now. Awesome stuff. I like this 
>>> approach way better than our current approach. It allows easy 
>>> modification of route rules, allows us to get rid of 
>>> StructuredResolver, and also allows us to to build a workspaceManager 
>>> that works for most cases by default! All big issues I'm having at 
>>> the moment :-) I like the RoR idea of "requirements" as well*. I 
>>> think that'd make a great addition.
>>> I think I found a bug though. Given these patterns:
>>>    routeManager = new RouteManager()
>>>      .addRoute("feed", "/:collection", TargetType.TYPE_COLLECTION)
>>>      .addRoute("entry", "/:collection/:entry", TargetType.TYPE_ENTRY);
>>> When do a resolution of the URL "/mycollection" I get back a match on 
>>> the "entry" route inside RouteManager.resolve(). It seems to me that 
>>> the "entry" route should not match at all. I'm just digging into the 
>>> whole regexp thing, but as I'm not a huge regexp expert, the code is 
>>> a bit hard for me to read (would be great if you could add a few 
>>> comments to Route.compile()). Any thoughts?
>>> - Dan
>>> *http://manuals.rubyonrails.com/read/chapter/65

View raw message