Ian Bicking: the old part of his blog

Re: htmlfill

I think the nicest part of form generators is automatic generation of widgets (form controls), which IMHO often have much of business logic that shouldn't be putted into HTML (template), things like size, maxlength etc. Another problem are more advanced / combined widgets (date widget, for example), which require lot's of javascript - I don't want to code them over and over again in every template.

But I agree that the rendering of the form itself needs more freedom - order of the widgets, two widgets on the same line etc. Currently I use Quixote form package with HTMLTemplate (http://freespace.virgin.net/hamish.sanderson/htmltemplate.html), and have the best of both worlds, IMHO :)

Comment on htmlfill
by Ksenia


Data-driven Javascript is reasonably easy to use with these techniques; in that model, the Javascript reads and writes to a normal input element (maybe hidden), and is set up separately from the tag. For example, I've used htmlfill with jscalendar with no problem. That kind of Javascript is generally accessible to non-Javascript-supporting browsers too, so it's a good feature anyway.

# Ian Bicking

Yes, I see.... Also sorry for the last comment, I didn't notice that input attributes (size, maxlength etc.) can be passed with add_attributes. I think htmlfill is very usefull right now, but just out of curiosity: do you think it needs some extra functionality? Do you miss something in htmlfill already? :)

# Ksenia

Missing... well, there's the automatic error insertion, which I noted before. It would also be nice if there was a purely information parsing option. Like, you'd be able to put an attribute in like form:required="true" and then parse that out of the form and create a validation schema from that (using whatever validation system you chose). When actually rendering the form, all those attributes would be removed. I think that's mostly it.

# Ian Bicking