Re: FormEncode wishlist

On Thu, Apr 9, 2009 at 12:22 PM, Ian Bicking <[email protected]> wrote:
> These are all just ideas... I don't have the, I dunno... willpower(?) to
> make these happen.  But if a maintainer were to emerge, these are
> suggestions about things I think would be useful.

The important thing is to document what we want, and to have an
explicit consensus among the motivated FormEncode users (i.e., the
subscribers of this list).

> 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.

>> - 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?

-- 
Mike Orr <[email protected]>

------------------------------------------------------------------------------
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