On Jan 15, 2008 7:38 AM, Max Ischenko <[EMAIL PROTECTED]> wrote:
>
>
>
> On Jan 14, 2008 9:52 AM, Mike Orr <[EMAIL PROTECTED]> wrote:
> >
> > I've finished my Routes 2 spec.
> >
> > http://wiki.pylonshq.com/display/routes/Routes+2+Spec
> >
> > It defines a minimum functional spec, and optional features that can
> > be added. This is to guide the
> > implementation to make sure the core is robust. It also allows us to
> > decide which features to support.
> >
>
> 1. Mapper.connect('foobar') looks both simpler and more explicit than
> RouteMap.foobar. Why this "magic"?
> 2. url_for -object certainly ain't simpler or more explicit either. Again, I
> don't see how url_for().foobar is better then url_for("foobar").
That was Ben's idea to make the name and path more distinct.
Currently .connect has the "moving argument syndrome" where the path
is in first or second position depending on whether there's a name
present. That makes it difficult to look down the list of routes and
immediately recognize all the paths and names, especially if the path
doesn't have a slash. I argued against making the name an attribute
(preferring it as the first argument), both because it's untypical and
to avoid name conflicts with built-in methods. But Ben liked it so
much i figured I'd try it, and then I grew to like it. But there are
tradeoffs. If enough people complain, we might nix the idea.
> 3. "Unnamed routes will no longer be allowed". I remember Ben saying this
> will never happen.
He changed his mind. :) He originally said that because he had a
large number of existing routes he didn't want to change. But after
getting frustrated at writing unit tests for Routes and realizing it
was even more ambiguous and non-deterministic than he thought, he
decided we needed something more explicit and straightforward.
Currently .connect and url_for try handle so many cases they trip over
themselves: named routes, unnamed routes (i.e., variable matching),
literal path generation, and current URL generation. Much of this was
ported directly from Rails I guess.
Anyway, I had been advocating named routes all along. I was about to
dive into an implementation, but Ben came up with an alternate spec
that split .connect into five distinct methods (.dynamic, .named,
.static, .redirect, and (legacy) .connect). Then he grew to like
named routes more, and then decided the Routes 1 codebase was
unsalvagble and should be scrapped. Then dynamic and legacy routes
were scrapped, named routes became an attribute, and generation-only
("static") routes became a flag. I asked him last night if dropping
nameless routes (url_for(controller="foo", action="bar")) would be too
radical, and he said no, let's do it.
Pylons only uses Routes indirectly. It gets the match dict from the
WSGI environment. The user configures the routes and calls url_for.
So as long as the version of routes in routing.py, url_for, and
RoutesMiddleware is the same, Pylons shouldn't care. So James'
mini-Routes could be an optional implmentation. I've suggested
re-releasing Routes 1 as Routes1 so people can upgrade their Pylons
apps and keep their existing routes, by just changing the imports.
(No, Max, Routes 2 will not be compatible with Routes 1. There's no
way to do that and meet our goals, again because .connect and url_for
try to juggle too many cases at once.)
> 4. Redirect routes is a welcome addition. I'd like to help on this, if this
> can help you to make it into "permanent" feature. ;)
> 5. Failure routes can be seen as a special case of redirect routes. E.g.:
> m.redirect("employees/that_loser", None, 410). Or may be both redirect
> routes and failure routes can be generalized to some mod-rewrite-like
> feature.
Actually, both are cases of status-changing routes. Redirect routes
came first in our thinking; that's why they're a separate method.
Failure routes are just my proposal; Ben hasn't explicitly committed
to them yet. But the whole point is to be able to handle legacy URLs
without having to write a bunch of tiny controllers just to handle
redirects. Inasmuch as Routes feels similar to mod_rewrite (at least
to me), adding failure routes is just borrowing one of mod_rewrite's
nice features.
As for consolidating the methods, I'd say let's not. 3xx codes have a
destination URL, while 4xx and 5xx don't. "Redirect" is such an
important and distinct concept that it deserves a separate method to
make them stand out in the route list. I don't know if failure routes
will be used that much actually; it's just an experiment. I mainly
see it for "This section is under maintenance" or "Your syntax is
wrong, dodohead!" Anyway, making small syntax changes in .redirect and
.fail seems like a bikeshed issue.
One issue we're deciding is whether the Routes middleware should
handle redirects/failures itself or pass them on to the application.
Ben sees no reason why the middleware can't do it. I'm concerned
about application logging. (Some of my apps log in the base
controller because they log app-specific info which a logging
middleware wouldn't know about.) So we may make it switchable.
--
Mike Orr <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
