On Tue, May 31, 2011 at 11:21 PM, Alexandre Conrad
<alexandre.con...@gmail.com> wrote:
> Hi,
>
> This post totally went over my head and there's a lot to read which I
> don't feel like doing right now, so I'll just give my 2 cent straight
> away (and if it was already addressed, reply "already addressed", and
> I will dig into the thread's archives):
>
> 2011/5/15 Chris McDonough <chr...@plope.com>:
>> def aview(request):
>> abort(401)
>>
>> def aview(request):
>> redirect('http://example.com')
>
> What I *really* didn't like with Pylons abort() and redirect() was the
> fact that that these functions were stopping the code flow without a
> return statement.
We could just make abort() and redirect() helper functions that return
an exception, which the user would then raise. The priority for me is:
1. Make HTTPExceptions raisable by default.
2. Add a helper to construct a redirect:
redirect(location, **kw) => HTTPFound(location=location, **kw)
3. Add a helper to construct an abort:
abort(N, message=None, **kw) =>
httpexception_by_number(status=N, message=message, **kw)
4. Make abort() and redirect() raise their result rather than returning it.
#1 is important so that you can cut through multiple function calls if
you discover an error condition.
Use case 1: a support method/function for several handlers
discovers a required query parameter is missing. The application's
forms and links would never produce such a request, so we presume the
request is illegitimate and abort 400.
Use case 2: a support method/function discovers that a required
support file is missing, an authentication server is unreachable, etc.
This is a webmaster/sysadmin error so we abort 500.
#2 is important because HTTPFound is not very self-documenting, and we
shouldn't have to specify the location by keyword argument since it's
the entire purpose of the call.
#3 is useful but perhaps not necessary. It's convenient but not
necessary self-documenting because you have to memorize all the
numbers. It's also helpful to have a message as a positional argument.
This would be added to the error message. This has been proven useful
in Pylons. A further enhancement would be to have both a secure and an
insecure message. The secure message would appear in the default error
screen, while the insecure message would be included in the sysadmin's
error report.
#4 is minimally useful. They do have the significant downside of
looking like returning function calls when they actually change the
program flow. It would be fine if they simply return the error and the
user raise it explicitly.
raise redirect(location)
raise abort(N, message=None)
Or they could be capitalized to appear more like class constructors:
raise Redirect(location)
raise Abort(N, message=None)
--
Mike Orr <sluggos...@gmail.com>
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
