On Wed, Jun 1, 2011 at 11:39 PM, Chris McDonough <chr...@plope.com> wrote:
>> #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.
>
> The folks I've talked to on the "don't turn HTTPExceptions into
> responses by default" side of the debate argue that both use cases above
> are poor coding practices because only "view code" (code that is
> contacted only because a view was matched, as opposed to random things
> that that view may call into) has enough information to be able to
> return a sensible response. They further argue that since it's so easy
> to "turn on" the feature, allowing folks that don't share their opinion
> to do it, Pyramid shouldn't do it by default. Just FYI, that's the
> other side of the argument.
OK, but there's such a thing as view support methods, code that's
common to several views so it doesn't have to be repeated in all of
them. That's the only place where I'd use this. For instance:
class MyHandler(object):
def my_view(self):
params = self.request.params
self._process_id(params.get("id"))
# Private methods
def _process_id(self, id_str):
if id_str is None or not id_str.isdigit():
abort(400, "query param 'id' missing")
id = str(id)
self.record = model.Something.get(id)
if self.record is None:
abort(404, "that Something does not exist")
--
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.
