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 / [EMAIL PROTECTED] / http://blog.ianbicking.org
