You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@abdera.apache.org by James M Snell <ja...@gmail.com> on 2008/01/29 17:56:55 UTC
RouteManager
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
Re: RouteManager
Posted by Dan Diephouse <da...@mulesource.com>.
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
Re: RouteManager
Posted by David Primmer <da...@gmail.com>.
fyi, I just found out from Ben Bangert today when I mentioned your issues
that Routes is being rewritten to address these issues.
"Minimum routes are actually being ditched because they're inpredictable
during generation, and result in multiple URL's being for the same
place, which spreads out your hits and negatively affects social bookmarking
and such. Rails still has them, but they don't care as much about
predictability really, its a magic world for them"
see here:
http://wiki.pylonshq.com/display/routes/Routes+2+Spec
I'm glad to see you're embracing this. I think it's a slick system.
davep
On Jan 29, 2008 9:28 AM, James M Snell <ja...@gmail.com> 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
> >>>
> >
> >
>
Re: RouteManager
Posted by James M Snell <ja...@gmail.com>.
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
>>>
>
>
Re: RouteManager
Posted by Dan Diephouse <da...@mulesource.com>.
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
Re: RouteManager
Posted by James M Snell <ja...@gmail.com>.
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
>
Re: RouteManager
Posted by Dan Diephouse <da...@mulesource.com>.
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