On Nov 30, 2:00 pm, Christoph Zwerschke <[EMAIL PROTECTED]> wrote:
> 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:
>
> [EMAIL PROTECTED](validators={'sh':MyValidator()})
> def drawform(self, sh, tg_errors=None):
> "draw the form"
> return dict(myform=myform)
>
> [EMAIL PROTECTED](form=myform)
> [EMAIL PROTECTED](drawform)
> def processform(self, **kwargs):
> "save the data"
>
> Matt, can you clarify:
>
> * Are you talking about TG1 or TG2?
TG1
> * I assume "sh" is part of the data processed in the form, probably a
> unique identifier for the data record?
Yes. My validator converts a string to an ID and then retrieves an
object from the database.
> * 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?
Yes. This is exactly 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.
I think I need to study the approach you describe here and see if I
can use it.
> 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
Thanks for taking the time to write this out!
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
