Hmm... I think I will have to check out FormEmcode and it's schemas more
closely. I was going to create a boiler-plate validation_error method
that just re-calls the original method but with an errors keyword
argument, thus achieving the errors=None idea in 0.5.1 without having to
modify TG.
But I am going to explore your idea too and see which I like better.
Thanks!
Krys
[EMAIL PROTECTED] wrote:
>Agree. In its(TurboGears) current form, I have changed all my functions
>to this form(thus ignore the validator feature) :
>
>func(self,**kwargs):
>
>Then I can define a formencode schema to validate against kwargs which
>is a dict. Basically achieve what you mentioned. The only issue is, a
>few line of code is needed to grab the keywords that is needed for
>processing, back from kwargs, rather than func(self,
>something=None,someother=None). But kwargs is needed anyway(as the
>kitchen sink) or any strange hidden fields in a form would bomb.
>
>Krys Wilken wrote:
>
>
>>Interesting idea. :-)
>>
>>I am unsure what benefit it provides over just say just having an extra
>>errors=None argument on the original method. I'd love to hear your
>>thoughts on it though. :-)
>>
>>It seems to me that that there are two simple ways of handling
>>validation errors:
>>
>>1) Adding an errors=None argument to the method and letting it handle
>>things (so the validators would just populate the errors dict and pass
>>them on to the method), or
>>2) Ian's idea of an on_error='method_name' added to expose.
>>
>>Actually, now that I am thinking of it, I'd say combine the two ideas.
>>
>>If no on_error is provided assume the on_error method is the method
>>being decorated, otherwise call the specified method.
>>
>>Whatever method is called would have and errors keyword argument which
>>is a dictionary in the form of: {'form_field_name': [list of Invalid
>>objects],...}
>>
>>That way you can have, as Ian believes, separate methods for
>>presentation of a form and processing of it, or you can have one method
>>responsible for both, as others prefer.
>>
>>In either case, the method that knows best about it's subject matter is
>>responsible for handling the errors, instead of some generic
>>validation_error method that knows nothing of the specifics of the
>>original method that was called.
>>
>>Anyway, just my $.02. Shoot me down if out in left field. :-)
>>
>>Krys
>>
>>Jeff Watkins wrote:
>>
>>
>>
>>>What about a nested validation_error function. For example:
>>>
>>>
>>> @turbogears.expose( validators= mySchema() )
>>> def index( self, arg1, arg2 )
>>> def validation_failed( errors ):
>>> # do something clever here and ultimately
>>> # either retry index or bail
>>> pass
>>>
>>> # real code for index
>>> pass
>>>
>>>
>>>Is it legal to have a self parameter for the nested function? If so,
>>>I guess we'll have to pass it along explicitly when calling the
>>>nested validation_failed function.
>>>
>>>Of course, if no validation_failed function is defined, the class-
>>>based one should be tried next.
>>>
>>>
>>>
>>>--
>>>Jeff Watkins
>>>http://metrocat.org/
>>>
>>>"Advertising directed at children is inherently deceptive and
>>>exploits children under eight years of age."
>>>-- American Academy of Pediatrics
>>>
>>>
>>>
>>>
>
>
>
>
