Re: FormEncode wishlist

On Thu, Apr 9, 2009 at 2:43 PM, Mike Orr <[email protected]> wrote:

> > I'd like if the state object was better documented and exposed, and
> didn't
> > default to None quite like it does now.  There's some more complicated
> > validations that would be easier if people had a useful state object and
> > knew how to use it (e.g., you can validate off another field).
>
> What should the state object be?  I thought that was completely up to
> the application.
>
> The problem with @validate is it doesn't have access to
> request-specific information such as a database record.  That's what
> you normally want in a state object.  However, it's a chicken and egg
> thing because you have to validate the ID and convert it to an integer
> in order to do the lookup, in order to complete the validation.  Some
> Pylons users cheat by using 'c' variables from the request path in
> their validators.  Although the counterargument is that @validate is
> just wrong-headed in itself, because you want to do validation in the
> middle of the action rather than before.
>
> What kind of default state object would be useful?
>
> Hmm, I suppose @validate could pass 'c' as state.
>

Anything but None would be more useful.  object() would be okay.  Things
like Schema set attributes on the state object if they are able to.

A slightly fancier state might be appropriate.  Maybe one that carries a _
method (for i18n) or some other simple stuff.  But it can be very simple.

 >> - Are there any API changes that would make it more useful or
> convenient?
> >
> > Another general change I've thought about is if the to_python method were
> > __call__, and from_python was an optional method.  Then functions could
> act
> > as validators.  Also a simpler way to raise exceptions (not as easy to
> apply
> > i18n to or otherwise customize, but mostly for custom validators).  E.g.,
> > just allow ValueError.  Adding a to_python function would help make this
> > possible.  Or a decorator.
>
> Most of my usage is one-way, I think.
>
> Are there other existing validation packages/APIs we should consider?
>

The __call__ idea comes from, I think, ConfigObj, which uses something like
that for validation.  I haven't read other systems very closely, so I don't
know if there's good ideas to be taken from them.

-- 
Ian Bicking  |  http://blog.ianbicking.org

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com

_______________________________________________
FormEncode-discuss mailing list
FormEncode-discuss-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/formencode-discuss