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.
There's a trick there, of course. We now have 4 decorators: expose validate error_handler identity.require 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.
Simon
