Hi,

What's the best source for idioms like this other than the mailing list?

Thanks,
nyenyec

On 2/9/06, Kevin Dangoor <[EMAIL PROTECTED]> wrote:
>
> On 2/8/06, Randall <[EMAIL PROTECTED]> wrote:
> > which is related to this discussion thread.  The method called looks
> > like this:
> >
> > def create(self, **data):
> >
> > Maybe I'll see things differently as I understand more, but right now
> > creating forms with validation is too difficult.  It should be simple
> > to create a form with some simple validation and the controller should
> > redisplay the form with error text when validation fails.  This should
> > be easily done without stacking decorators on a method.  Once a form
> > widget is defined including valdation the controller shouldn't need to
> > have any validation logic.
>
> Yes and no. I think there's a balance to be struck between ease of use
> and the flexibility to do real world things. In this particular case,
> it's actually not even very hard. If you're using the "two method"
> version of form handling (one method for display, one method for
> handling the update), you can do something like this:
>
> from turbogears import *
>
> @expose(template="blah")
> def index(self):
>     return dict(myform=myform)
>
> @expose()
> @validate(form=myform)
> @error_handler(index)
> def create(self, **data):
>     ...do your thing...
>
> The nice thing about this is that if control gets to create(), you
> know you've got good data and can just handle the pleasant case. If
> there is a validation error, control goes back to index() and the form
> is redisplayed with the error messages. Here's an alternative
> approach, if you need to pass parameters to the display method:
>
> @expose()
> @validate(form=myform)
> def create(self, tg_errors, **data):
>     if tg_errors:
>         return self.index("foo")
>
> Kevin
>

Reply via email to