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
