abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <dan.diepho...@mulesource.com>
Subject Re: RouteManager
Date Tue, 29 Jan 2008 18:04:19 GMT
Thanks for the docs. I'm going to try to flesh this out today (i.e. 
implement requirements/default values) and make it the default 
implementation for DefaultProvider. This should greatly simplify our 
lives :-)

- Dan

James M Snell wrote:
> The matching rules are loosely modeled after this:
>   http://routes.groovie.org/manual.html#minimum-urls
>
> 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
>>>>
>>
>>


-- 
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog


Mime
View raw message