Hello Mike,
On Jan 16, 2008 12:57 AM, Mike Orr <[EMAIL PROTECTED]> wrote:
>
> > 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.
You can use two different names instead of a single connect() to avoid this.
> 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).
Hmm, sounds promising. ;)
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.
>
I agree that it's better to have the methods stand on their own, even if the
implementation is shared. They differ enough conceptually to deserve their
own "place" in user's mind. Though if the impl really *is* shared it may be
worth exposing as well, as "advanced feature". ;)
> 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.
>
I'd all for having Routes handling redirects/failures by itself, at least as
an option.
I'd say if you need log some of this requests in an app you can always
define a normal route and do abort/redirect yourself.
--
Max
http://maxischenko.in.ua // http://www.linkedin.com/in/maksim
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
