Ian Bicking wrote:
> [EMAIL PROTECTED] wrote: [snip] >> If validator_error is defined, if will be called with the first >> parameter being the original function(the one that turbogears.expose >> supposed to be decorating). >> >> While the documentation said I can do whatever I want, I think it would >> be more natural to let the original function deal with it as this >> validator_error is a "centralized" function(sort of catch all) that is >> impossible to make meaningful error message/response. > > > It seems to me that another function should be called, but one that is > a sister function, not a single validation_error function. A > particularly common one would be the function that originally > generated the form, so it could regenerate the form with the errors in > it. > So it might be: > > > @expose(validators=..., on_error='register'): > def do_registration(self, ...): > # actually perform action > > @expose(html='form.html'): > def register(self): > # creates form with action="do_registration" > # maybe expose pipes the output through htmlfill if this > # is in response to an error, or... something > This works much better than a generic validation_error method, IMHO. Whether the same method is used to display the form and process the form data or not should be up to the programmer, but coding is much simpler if I can just say "ok, were there any errors", rather than "from which method did I get these errors and how to I tell it that there were errors". Krys

