Re: FormEncode wishlist

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.

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

> At PyCon Ian mentioned he's looking for a maintainer for FormEncode.
> I don't have time to do this right now but I may in a few months.  In
> the meantime I'd like to start a discussion on what direction
> FormEncode should go.
>
> - The manual is incomplete, both in terms of how to use FormEncode
> under a web framework, and many validators are undocumented.  Ian and
> I made a list of things to include:
>
> http://wiki.pylonshq.com/display/pylonscookbook/The+other+FormEncode+manual+(UNFINISHED)<http://wiki.pylonshq.com/display/pylonscookbook/The+other+FormEncode+manual+%28UNFINISHED%29>
>
> - Are there any features missing in the validators?
>

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

Also maybe some decorators to create validators from simpler functions.


> - Are there any features missing in htmlfill?
>
> - Are there unused dead ends we can delete?  Some of the anemic
> validators like Constant, MaxLength, MinLength, Empty, and NotEmpty
> aren't really useful alone because the user would typically want to do
> more than just these.  not_empty is now an attribute of
> FancyValidator, for instance.  MinLength, MaxLength, and Regex could
> likewise be attributes of FancyValidator (with None to skip those
> tests).


I don't think Regex can be eliminated.


> - OneOf, DictConverter, ListConverter, and Set are confusing because
> they use Python data types differently than expected.  For instance,
> OneOf is what you normally do with a list (make sure the entered value
> is in the list).  And Set you would think is for working with sets,
> but it isn't, it's a multiple-value control (akin to a MultiDict
> value).  I would somehow group the validators between the universal
> ones everybody should know vs the specialized ones.
>
> - 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.


> - What about wrapper functions, along the lines of Pylons' @validate.
> Are there any that would make FormEncode more useful in web
> applications?
>

Maybe a simpler way to handle the logic.  Maybe just as simple as:

values, errors = convert(schema, values)

Something so people can avoid @validate if they don't need it would be
helpful, as it's a lot easier to think in terms of simple logic and if
statements than the decorator.


>
> - FormEncode and htmlfill could be merged into WebHelpers since they
> are often used together.  That would also solve the problem of "Why is
> FormEncode called FormEncode when it does validation rather than
> encoding?"


It actually does translation, hence the bidirectional nature of all
validators.


> and "Why is htmlfill part of FormEncode when it doesn't do
> validation?"  I'm not sure if the ToscaWidgets developers would like
> this though since I think they use the validators alone.
>

htmlfill isn't particularly large, so simply the fact both pieces of source
are distributed together doesn't seem concerning.  It's pretty clear they
aren't bound to each other.


>
> - The validators are also useful outside forms, for instance to
> validate configuration files.  But the error messages are not quite
> ideal for that since they don't show the filename and line number of
> the error.  Maybe this could be added somehow.
>

After going about this a few ways, I think the best way for a configuration
file to work is to produce simple values but give a way to get the line
number.  E.g., parsed_config_file.position({'section': 'key'}) would return
('config.ini', 21).  So wrapping it together would involve a way of taking
the Invalid exception (which has the necessary information) and formatting
that using knowledge of the source config file.

INITools has a ConfigParser-compatible interface that also has methods to
get source location, so some glue between the two could make this possible.


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