Christopher Arndt schrieb:
> The recursion guard was put in for a reason, which was discussed on the
> mailing list a while ago and seemed sensible me to me back then but I
> can't remember exactly anymore what is was exactly ;) I think Christoph
> Zwerschke let the discussion back then, maybe he can comment?
Took me a while to remember what this was all about :/
Let me quote Matt's code first:
@validate(validators={'sh':MyValidator()})
def drawform(self, sh, tg_errors=None):
"draw the form"
return dict(myform=myform)
@validate(form=myform)
@error_handler(drawform)
def processform(self, **kwargs):
"save the data"
Matt, can you clarify:
* Are you talking about TG1 or TG2?
* I assume "sh" is part of the data processed in the form, probably a
unique identifier for the data record?
* You were first talking about the situation of chained error handlers,
but actually there's only one error handler involved here. So your
problem is only that "MyValidator()" is not called when drawform was
called as error handler of processform, right?
Now to answer the question:
There was a "recursion check" implemented which originally should
probably only prevent infinite recursions of error handlers. Due to a
bug in a utility function, that recursion check however prevented
chained validation completely. That bug has been fixed, but we
consciously kept that behavior of nonrecurring validation because
changing it to chained validation would break many applications.
The problem is when you enter erroneous data that does not validate and
the validator of the error handler would be called, which gives no
error, the original error would not be displayed any more since after
the second validation it looks like there was no error at all.
It may be possible to solve this by "merging" the errors of both
validations instead of considering only the last one.
However, I currently see no real use case for this. In your case, if
tg_errors is not empty, then you know drawform has been called as error
handler and you don't care about the 'sh' parameter at all, but just
redisplay the old form (all the needed values are still stored in the
request). If tg_errors is empty, then you know the controller has been
called directly and 'sh' has been validated, so you can fetch the
corresponding data record and display it. That's my usage pattern in
TG1; I never needed to manually validate parameters.
But if you can come up with a good use case, we may consider chained
validation and merging of errors in future TG versions (probably
configurable, as suggested in #1993).
-- Christoph
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---
