Ian Bicking: the old part of his blog

Re: On form libraries

I don't really have much of a point with this, just some observations.

One is that a form generation library can have independently evolving components. Let's take the Zope 3 has a form generation library. I'm sure you don't like it. :) It has multiple components that work together:

These components can evolve by themselves. formlib for instance is reasonably new, replacing another system for putting a form together that didn't work as well. It's built on the existing schema system and widget systems, however, so those weren't rewritten. It would also be possible to revise the way the widget system work without an enormous impact on the other pieces, though formlib would likely need some adaptation.

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.

It appears that to you the tradeoffs weigh in favor of HTML driven forms. To me, it depends in what you're trying to accomplish.

Note by the way that ToscaWidgets is not necessarily a form generation system. It's a way to package and reuse bundles of python, HTML, CSS and javascript at its core. It has a form library built on top of it.

Finally, I have the suspicion that any set of abstractions that helps you deal with complex real world scenarios in any domain will be vulnerable to your criticism of form generation libraries, including your own proposal on how to handle this particular problem domain. :)

Comment on On form libraries
by Martijn Faassen

Comments:

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 ;)

# Ian Bicking

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