Kevin Dangoor wrote:
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.
Ok, will do.
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.
I see. What can I say, will do. :)
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?
Is adding parameters enough?
The way I would approach this problem is to decouple our controller form
CherryPy altogether and have decorators dynamically build the actual
implementation.
This would also allow changing "HTTP layer" if anybody wishes to do so.
Simon
