[EMAIL PROTECTED] wrote:
I begin to start using the validator and got confused of what is the
design philosophy behind it.
1. There is an instance method validator_error that would be called if
exist otherwise it would raise another exception.
I believe this has to be mentioned in the documentation as otherwise,
this exception would not be caught by anyone and it would be the ugly
"server get in trouble" message, which is very scary but not the case.
Just some data content error.
To me it seems like it should be an error if there's no validation_error
method and any validators are given. This way the error is caught early
during development.
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
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
