[Zope3-dev] Re: browser widgets: items widgets and label tags

[Fred Drake]

On 11/11/06, yuppie <y.2006_ at wcm-solutions.de> 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
> zope.app.form.

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
any better.

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.

Philipp:
> * we now explicitly state a contract that has been assumed implicitly
> before

yuppie:
> 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
agreed upon.

> 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

-- 
Fred L. Drake, Jr.    <fdrake at gmail.com>
"Every sin is the result of a collaboration." --Lucius Annaeus Seneca