On 11/11/06, yuppie <[EMAIL PROTECTED]> wrote:
Well. I can't see why Zope 3 has to ship with two completely different
implementations of widget rows and I don't like the formlib template
either. But this is not the code that causes validation errors.
I can't say that I like any of the form-generating templates, but I'm
not convinced there's a solid generic solution. The formlib template
was good enough for some projects, but we use another for the project
I'm working on now, and that one's pretty unsatisfactory as well.
Good forms are hard to generalize, IMO.
AFAICS the biggest problem are the poorly maintained widgets in
Poorly maintained? I don't think that's it. While many were
developed quickly and are questionable, a lot of the problem is the
interfaces. They just aren't conducive to building robust forms. We
need a better interface, and I suspect we need to think about the ways
we build forms, and how we want to build them, before we can really do
Many of us have put thought into better ways to deal with widgets and
forms, but finding the time to work something out is hard to do; we're
all busy. Often we have to live with partial solutions.
* we now explicitly state a contract that has been assumed implicitly
I think this would be the case if we choose the more pragmatic solution.
Maybe. There are certainly some assumptions in the way the current
forms are being generated (both with zope.formlib and zope.app.form),
but it's not clear that the label id assumption is all that widely
This looks like overkill to me. No use case comes to my mind where
focusControlId would be different to labelControlId.
That depends on what it means to suggest that a particular control to
be focused. I'd expect that you don't want to suggest one normally,
and let the form determine whether it should focus the first control
identified with the labelControlId or not. If something like the
focusControlId were defined (as part of the contract) to be set when
the identified control is involved in fixing an input error, it makes
a lot more sense to have both. If there's an error, focusing the
first widget involved in correcting the error makes a lot more sense
than focusing the first widget.
Whatever such things are intended to be used for, it should be
described explicitly in the interface contract.
I'd say people don't care about the specs as long as validators and
browsers don't complain. But maybe this is too pragmatic.
Some people care and some don't. The framework should not stand in
the way of those who do. Those who don't also won't care that the
framework doesn't force them to ignore the specifications; they can do
that on their own.
Fred L. Drake, Jr. <fdrake at gmail.com>
"Every sin is the result of a collaboration." --Lucius Annaeus Seneca
Zope3-dev mailing list