W liście Mike Orr z dnia piątek 23 listopada 2007:
> On Nov 23, 2007 5:46 AM, Paweł Stradomski <[EMAIL PROTECTED]> 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.
--
Paweł Stradomski
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" 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-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
