Adam Jones wrote: >> 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. I'm unsure. Do people usually validate a form by taking all of the context into account? Or is a validator, after all, only interested the relationship between the form data?
>> 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. Uh, right. I don't either. If, sometimes, I could like to jump into the form by passing _some_ of the data as GET, I would handle the case accordingly. > I can't really think of a problem with this method. I haven't seen it in the examples/tutorials. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
