Form/widget libraries; roundup?

There's been a whole bunch of activity lately in form generation
libraries, especially around FormEncode and SQLObject. There's a bunch
of options out there, and I haven't had a chance to look at them all
(actually any of them yet ;), and I'm not even sure what all there is.

It would be really helpful to make a roundup of these, to get an idea of
where we are. I'm interested both in ones that are embedded in other
libraries or apps (if they could be extracted), and stand-alone
libraries. So I'd really appreciate it if people could put together a
little summary (or copy one they've already written). Please include:

* The name and URL of the package and/or repositories
* If it is embedded in another project, where in the project to look
(i.e., the module name(s))
* Any URLs of examples or docs

Some additional commentary would also be helpful, like:

* What are your design goals?
* Does it have any novel features you'd like to point out?
* How does it deal with exceptional cases, and developer/designer
tweaking of forms?
* Does it have any fancy widgets (e.g., Javascript)?
* Presumably it uses FormEncode; to what degree? Does it use htmlfill?
Does it integrate specifically with the validation in any way?
* Thoughts on the future? Is this a prototype or a serious library?
Are you looking to merge it with something else?
* Any special SQLObject integration? Extensible integration? General
CRUDiness?

Not everyone is necessary subscribed to all these lists, but if you are
involved in these things I would encourage you to be at least subscribed
to formencode-discuss
(http://lists.sourceforge.net/lists/listinfo/formencode-discuss). You
can also subscribe to google groups and disable email delivery. Sadly
GG breaks mailing list conventions with its stupid reply-tos, so
reply-to-all on this message may not pick up all these lists.

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

Hi Ian,

There are a small handful of links on this page:
http://trac.turbogears.org/turbogears/wiki/SimpleAdminIdeas

Kevin
--
Kevin Dangoor
Author of the Zesty News RSS newsreader

email: k...@blazingthings.com
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com

So, here's my summary of what's in FormEncode now...
FormEncode trunk (may have gotten in 0.2.3 or something, but not
intentionally): http://svn.colorstudy.com/FormEncode/trunk/formencode/
In formencode.fields and formencode.formgen
Nope, none.
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).
Covered below, I suppose...
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.
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.
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.
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.
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.

Here's my summary of formulaic.

Name: formulaic
URL: for now, http://developer.berlios.de/projects/formulaic
Brief description: a form generation toolkit designed to be very
compatible with formencode.

Its standalone, not embedded with any other project, though the
principal framework its intended to be used with is CherryPy.

Docs not up yet, but it includes a README with a basic tutorial.

Design goals: I have three main priorities: a shallow learning curve,
extensive customizability of the output markup, and preserving access
to 100% of formencode's functionality. I'm not trying to make it
generate stupendously sophisticated forms (ajax and javascript
validation could be done with it, but they're not high on my priority
list). Its intended to make typical forms be as easy to write as
possible.

Novel features: preserves all of formencode's functionality; forms
emulate python dicts for simpler syntax.

Fancy widgets: none yet, though I want to integrate a javascript
calendar widget soon.

Level of seriousness: definitely a prototype right now. If there's
interest, I'm happy to develop it into something more serious. I'm
specifically not looking to merge it with anything else (in the sense
of making it dependent on anything other than formencode), but have no
problem with it being included in others' work (its GPLed, after all).

Types of integration: it has no CRUD functionality, simply because I'm
intending for it to be a solution to the form problem, not the CRUD
problem (though CRUD functionality could be built on top). No
SQLObject integration either, for similar reasons. Its extensible in
the sense that users can develop custom fields and forms relatively
simply.