On Nov 23, 2007 7:34 AM, Paweł Stradomski [EMAIL PROTECTED] wrote:
W liście Mike Orr z dnia piątek 23 listopada 2007:
On Nov 23, 2007 6:19 AM, Paweł Stradomski [EMAIL PROTECTED] wrote:
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.
Hmm. Well, the match function is called in only one place by the
framework, so it would be easy to catch it close to the source. And
without an exception it would have to have two very different return
values: a match dict or a string destination.
But redirect_to might be called by the user.
So redirect_to can stay the same. I would actually prefer that
redirect_to would get replaced by raise Redirect, but it's too
established in Pylons apps to change it now.
However, there are a couple ways to make the matching side more to
your liking. There are two special cases: status with location
(redirect), and status without location (gone, forbidden, future
statuses). This could be handled by two special keys in the match
dict (_status and _location). If present, the framework should call a
special controller to handle them. This would allow the user to
customize the response if desired.
Or routes could choose the controller and action itself, either via
attributes (the way .sub_domains is handled now), or via ordinary
controller/action arguments. The latter would avoid changes to Routes
itself but would add boilerplate verbosity to the route definitions.
m.connect(None, foo/foo, location=http://example.com/bar/bar.html;,
controller=special, action=redirect,
status=303)
At least that would define a standard Pylons way to support
redirects/statuses without forcing each user to reinvent it on their
own. Perhaps this can be tucked into one of the existing standard
controllers somewhere. (The Template controller doesn't do much, for instance.)
--
Mike Orr [EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
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
-~--~~~~--~~--~--~---
