Adam Jones wrote:
> The only change you need to make to your 'edit' controller is that it
> has to accept a tg_errors parameter. If anything fails validation
> tg_errors will be a dictionary of validators.Invalid objects with the
> field names as keys. More info here:
>
I am not the OP. I'm picking up TG but didn't deliver anything yet.
Your explanation sounds fine for me; I use forms and like it.
However, I'd like to know what I am supposed to do when, during the
save, I found other errors (missing data in DB, integrity..) that I
could not -- or didn't want to -- check in the validator.
I see 4 ways to do it:
1 - have the save() function use the same template as the edit(), and
instantiate the widgets the same way. Code duplication, there be lions.
2 - raise a redirect to edit, and pass the parameters again after
re-converting them from python to form values. Ugly; and GET suddenly
shows huge URLs
3 - always write a form validator; have it "mess" with the DB and check
everything is in place, maybe doing half the work of the save()
method... not its job, I guess
4 - return self.edit(**data) from the save() function, after flashing
about the problem. It works. save() has an empty @expose(), the template
is defined in edit().
edit() receives the already validated (and converted..) data and
redisplays the form. Works for me.... in my simple cases... but some
validators could complain or make a mess when they receive already
converted values, right?
How do you handle this use case?
I could potentially have misunderstood everything :-)
Thanks.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
