15 messages in com.googlegroups.pylons-discussRe: Routes user survey
FromSent OnAttachments
Mike Orr23 Nov 2007 01:36 
Marcin Kasperski23 Nov 2007 04:30 
Paweł Stradomski23 Nov 2007 05:46 
Mike Orr23 Nov 2007 05:50 
Mike Orr23 Nov 2007 06:06 
Paweł Stradomski23 Nov 2007 06:18 
Mike Orr23 Nov 2007 07:31 
Paweł Stradomski23 Nov 2007 07:34 
Mike Orr23 Nov 2007 08:37 
Jose Galvez23 Nov 2007 10:34 
Ben Bangert23 Nov 2007 15:34 
Ian Bicking23 Nov 2007 21:56 
Andrew Smart24 Nov 2007 11:04 
Ian Bicking24 Nov 2007 13:59 
Mike Orr26 Nov 2007 16:16 
Subject:Re: Routes user survey
From:Paweł Stradomski (pstr@public.gmane.org)
Date:11/23/2007 06:18:50 AM
List:com.googlegroups.pylons-discuss

W liście Mike Orr z dnia piątek 23 listopada 2007:

On Nov 23, 2007 5:46 AM, Paweł Stradomski
<pstr@public.gmane.org> wrote:

W liście Marcin Kasperski z dnia piątek 23 listopada 2007:

redirect routes need some detailed design.

If we had a separate redirect layer, where would it reside? As a separate function in routing.py that wraps make_map? How would you define the source routes, and wouldn't that be essentially making a second route map? If you add variables, it starts looking even more like a route map. And what if the user wants to group redirects next to their corresponding official route? If they're in separate functions, he can't.

In fact I'm using routes inside cherrypy project (albeit with my own dispatcher, not the default one). Because of that I needed to look a bit into routes internals and I've found that routes redirect_to just generates the url and calls the framework's function for performing a redirect (which needs to be passed by the framework).

So the call tree looks like: * user's code * routes redirect_to * url_for * framework's function for redirects

That could be changed to: * user's code * framework's redirect_to * routes url_for * framework's function for redirects

This would allow more flexibility on redirects - routes does not need to know how many redirect kinds are there.

I'm afraid this is a case where purity hinders practicality. My application has several tiny actions that do nothing but redirect legacy URLs. The Routes map is the natural place for this, especially since it's about ROUTE-ing or matching URLs to destinations. Routes fulfills a function similar to mod_rewrite, which also handles both internal and external redirects, so it provides a precedent.

I see your point - this would allow defining the redirect type in the route. So this might be feasible.

One problem may be how to do the redirect in a framework-neutral way.. Routes may have to simply raise a Redirect exception with the destination, and let something else catch it and generate the Response.

Well, I think the current solution (function being passed by the framework to routes) is better, as it gives more flexibility. Throwin an exception would force just a single way of informing the framework about redirects - and is a bad idea, as this propagating exception might cause strange behaviour, like rolling back database sessions.