On 1/23/06, Simon Belak <[EMAIL PROTECTED]> wrote:
>
> Kevin Dangoor wrote:
> > I like the idea, except for one thing: the common idiom for dealing
> > with form validation errors with turbogears widgets is this:
> >
> > @expose(html="...")
> > def index(self):
> > ...
> >
> > @expose(html="...")
> > @validators(form=myform)
> > def save(self, val1, val2):
> > if cherrypy.request.form_errors:
> > return index()
> >
> > Note that index doesn't have an errors parameter. An earlier version
> > of the TurboGears code would introspect the function to see if it had
> > an errors parameter, and pass the errors in if it does. Maybe we
> > should do that?
>
> I am not sure I follow you, so forgive me for responding with two random
> guesses. ;)
>
> If error_handler() is not used, methods still get called through
> _call_with_errors().
>
> Or are you summarising that since 'errors' parameter is the sole
> requirement of dispatch_error protocol, every controller method
> declaring it should implicitly be declared it's own error handler?
> Sure we could do that, if you think continence outweighs induced magic?
> Personally I like it, as it can greatly reduce boiler-plate.
Hey, that's a good idea. Not what I was talking about, but a good idea
nonetheless.
What I was angling for was to have @errorhandler also be used for the
idiom I described above. Specifically, the above could change to:
@expose(html="...")
def index(self):
...
@expose(html="...")
@error_handler('index')
@validators(form=myform)
def save(self, val1, val2):
# assume everything is good and do saving stuff
Note that the index method doesn't have an errors option, so that
should be left out. The widgets code will automatically display errors
and input values as appropriate.
> > In order to introspect the function, we need direct access to it. I
> > think the TurboGears decorators should all set an attribute on the
> > function that has the original function object. That way, the
> > decorators are a bit more flexible in terms of how they are arranged
> > over the method in question.
> >
> > Opinions?
>
> Ideally *all* decorators would be true invariants. Unfortunately doing
> so would mean quite a serious rewrite (all except error_handler of
> course ;))). However I belive this is still the best solution in the
> long-run.
Hmm... You're right. It would be nice for the decorators to be
invariants or as close as possible to invariants. What would be nice
is if the decorators actually maintained the signature of the
functions they're decorating but added additional parameters as
needed. I wonder how easy that would be?
Kevin
