Ian Bicking: the old part of his blog

On form libraries comment 000

There are two very different extremes of dealing with forms. One is schema-driven, the other HTML driven. Most systems fall in the middle somewhere (which probably creates some of the muddle); Zope 3's system leans fairly heavily towards schemas (which introduces its own limitations). I see benefits in both approaches: HTML driven is very good at being able to adapt to a wide variety of real-world forms. Schema-driven is good at producing lots of forms from small descriptions of data and encourages widget reuse.

I'm not really opposed to creating forms programmatically. I just think it should be a simpler task than what most form generation libraries have bitten off. It should look a lot more like templating, and a lot less like programming. It shouldn't include things like filling in defaults, filling in errors, collecting Javascript and CSS, and maybe not layout (or at least very simple layout). Once the definition is sufficiently limited you can get away with a very simple and transparent library for form generation. And certainly that is important, since lots of domains require form generation -- stuff like Django's CMS, or user-driven models generally.

As to formlib, I'm afraid I don't really know much. I've seen Zope Schemas, and I think they are fine, though as I remember they did validation without conversion, and I think two-way conversion is integral. Combining validation with widgets and worse data bindings is a really bad path, and you didn't go down that. I'm a little wary of data bindings in general, as it puts the logic in the framework and I hate that; it makes my head hurt. But if it's done really well it's possible -- as long as you aren't squeezing it into a normal web app framework design. I suppose htmlfill is a kind of data binding library; but it's very clearly a library. Anyway, no one will accuse Zope 3 of being a normal web app framework design, so no problem there ;)

Comment on Re: On form libraries
by Ian Bicking

Comments:

I'm sympathetic with your general idea that much that is now done inside widget libraries should be pulled out into independent systems. It will need some thought on my end.

Ian:

As to formlib, I'm afraid I don't really know much. I've seen Zope Schemas, and I think they are fine, though as I remember they did validation without conversion, and I think two-way conversion is integral.

Zope 3's design considers two-way conversion the responsibility of the widget, as it's part of viewing logic. Conversion might be quite different if the data is coming from another source than the web, or is going to another target than the web, after all (an int might already be an int).

Ian:

Combining validation with widgets and worse data bindings is a really bad path, and you didn't go down that. I'm a little wary of data bindings in general, as it puts the logic in the framework and I hate that; it makes my head hurt. But if it's done really well it's possible -- as long as you aren't squeezing it into a normal web app framework design. I suppose htmlfill is a kind of data binding library; but it's very clearly a library. Anyway, no one will accuse Zope 3 of being a normal web app framework design, so no problem there ;)

Zope 3's more normal than it looks like, it's just not presenting itself well. :)

As to data binding, what you mean by this is the code that gets the data to display in the form from somewhere and then gets it back from the web into the application, right? I believe in Zope 3 that's scattered a bit between formlib and the widget system. It'd be nice if it were a more coherent library. It's quite powerful in the sense that it handles nested and/or composite form values well (which can be expressed with Zope 3 schema).

# Martijn Faassen