On 2/7/06, Simon Belak <[EMAIL PROTECTED]> wrote:
>
> Kevin Dangoor wrote:
> > The generalized error_hander mechanism is fine and flexible on the
> > whole. But, I'd still contend that validation errors are of a
> > different breed than actual programming exceptions and deserve mildly
> > special treatment as a result.
>
> OK, what should than happen in case of a error-unaware method with
> validators? If my understanding is correct, validators assure arguments
> passed to the method will conform to a certain protocol. Right now
> (continuing the legacy of _call_with_errors) we deliberately break this
> promise.
I'm inclined to say that if there's no @error_handler() declaration
and no tg_errors, the validation exception is raised (not counting the
legacy validation_error method, which will die soon enough). It's ugly
for such a thing to get through to users, but it's *so* easy to define
the error behavior that it seems better to just hand the exception
back up the chain.
> > I'd only support moving identity's redirect logic to an error handler
> > if you didn't have to explicitly put references to it all over the
> > place. (@identity.require is nice and easy, and the control flow for
> > the identity piece does not involve the controller, so it's still
> > clean...)
>
> The idea was to create a specialisation for IdentityException less
> specific than per-method rules so one can override it at any time. But
> this can (and should) wait. First I want to fully define error handling
> protocol.
Makes sense. And that seems perfectly reasonable that you have default
behavior that can be overridden by a rule.
> > What do you mean by "the URL should be rewritten behind the scenes"?
> > There are actually certain advantages to doing a real browser redirect
> > (users don't keep posting the same form over and over again, for
> > example).
>
> Yes, but why should this consideration influence how I program my
> controllers? We could for example check in expose() whether URL
> corresponds to the method being called. If not, a redirect could be
> preformed without messing about with hard-coded URL and the like.
You should be able to call another method directly, if that's all
you're looking to do. I've done it in the past...
@turbogears.expose(html="groovy.template")
def index(self):
return dict(value=5)
@turbogears.expose(html="other.template")
def foo(self):
return self.index()
Kevin
