Marco Mariani wrote: > 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.
Agreed. This is not an adequate solution for most cases. > > 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 You also get to worry about exceeding the maximum get length in (webserver | browser | middleware). The internal redirects used by validation are a much better solution. > > 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 I actually like this solution. It encapsulates all of the data conditioning in one place. This way save() is only called when you know everything is good. That said you are working through your environment twice (once to check for valid conditions, once to alter the data) which I would consider a significant waste of resources on larger server loads. That and any complex analysis would be ... interesting to implement in validators. Considering validation kind of straddles the boundary between view and controller it may not be appropriate design to do this depending on where you feel it falls. > > 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? > AFAIK, they wouldn't, as you usually won't be putting validators on the method that initially displays the form. If, for some reason you are doing that, I believe validation makes a copy of the keywords involved instead of modifying those that came in. Not sure on that one, I followed the code until it lead to some generic functions, which I know nothing about. (IOW: the code was smarter than me) I can't really think of a problem with this method. Maybe that says more about me than the solution, but there you are. :) -Adam --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
