[FE-discuss] Re: Form/widget libraries; roundup?

So, here's my summary of what's in FormEncode now...

> * The name and URL of the package and/or repositories

FormEncode trunk (may have gotten in 0.2.3 or something, but not 
intentionally): http://svn.colorstudy.com/FormEncode/trunk/formencode/

> * If it is embedded in another project, where in the project to look 
> (i.e., the module name(s))

In formencode.fields and formencode.formgen

> * Any URLs of examples or docs

Nope, none.

> Some additional commentary would also be helpful, like:
> 
> * What are your design goals?

Haven't figured that out entirely yet.  I want to support repeating 
fields, WHAT-WG Web Forms 2.0 style.  I want forms and fields to be 
unified, in the same way that FormEncode validators and schemas are 
unified.  At the same time, treating both cases the same for layout is 
insufficient.

I'm also very concerned (and try to address) that there be a smooth 
curve from highly automated forms (like CakeWalk would use) to highly 
customized forms (like you'd write without using any form generator). 
The same form can progress from one to the other over time (usually away 
from automation).

> * Does it have any novel features you'd like to point out?

Covered below, I suppose...

> * How does it deal with exceptional cases, and developer/designer 
> tweaking of forms?

The generated forms are mutable objects.  You can go in and tweak them, 
e.g.:

   form.fields['name']['style'] += '; width: 100%'

Or at least something like that.  Also, it should be possible to unpack 
the objects (like that form) and lay them out manually in a template. 
The generated fields *aren't* powerful, so you can use them in part or 
not at all, without changing around other parts of the code.

> * Does it have any fancy widgets (e.g., Javascript)?

Not at this point, except maybe a color selector.  The design does allow 
for this, though, by trying to generate both a form and a validation 
schema; the validation schema only applies to the specific form, not the 
underlying thing that is being created/updated (which may have its own 
schema).  The schema can be used to present the results of a set of HTML 
fields as a single value.  E.g., if you had dropdowns for day, month, 
and year, the schema could turn that into a date.  Not that you should 
have such dropdowns, because those suck.  But you could.

> * Presumably it uses FormEncode; to what degree?  Does it use htmlfill? 
>  Does it integrate specifically with the validation in any way?

It doesn't do form filling, so htmlfill is expected to be used.  It 
doesn't really integrate well with validation yet, especially error 
displaying (not being particularly compatible with htmlfill in this 
respect).  I'm not 100% sure about htmlfill and the form:error stuff. 
At the same time, I have a strong intuition that htmlfill (in concept if 
not necessarily implementation) is really important to keeping form 
generation workable.

> * Thoughts on the future?  Is this a prototype or a serious library? Are 
> you looking to merge it with something else?

Despite its presence in FormEncode, this should not be considered a 
stable library or interface, or the last word on form generation with 
FormEncode.  It's just where I put stuff.  This is very very alpha, 
i.e., not even usable.  There are some latent capabilities in FormEncode 
that I'm worried some other projects might not allow to be revealed, and 
I have some opinions on this stuff in general, but at the same time I 
recognize that I'm too overcommitted to actually move this stuff forward 
very efficiently.

> * Any special SQLObject integration?  Extensible integration?  General 
> CRUDiness?

It does have some SQLObject integration, using RuleDispatch (generic 
functions).  SQLObject is just one case, so it should be generally 
extensible, without modifying the library at all.

Also, specialized rules can be used to tweak the generated forms.  It 
includes a context object, which can be a holder for arbitrary 
attributes that can be used in specialization.  This offers a second 
escape for someone who wants to make small changes to the form without 
digging deep into the framework.  E.g., if you want to globally make a 
your Address.street column display as a textarea, you can make a rule 
that applies to just that one column.


-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org