Hi Fred!

Fred Drake wrote:
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
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.

Sorry, no insult intended. I don't want to complain, I want to offer my help. I don't have the time to work on a big refactoring, but AFAICS many small issues can be fixed without big changes.

Most issues I found are in the non-default widgets like the radio and checkbox widgets and in display widgets. They might not be used as often as the other widgets and therefor less maintained.

* 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
agreed upon.

Well. I guess nobody did agree upon this explicitly. But apparently the people who wrote the form templates took it for granted that the widget name is always used as an element ID.

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.

We already have the 'error' attribute. Wouldn't that be sufficient for your use case?

Whatever such things are intended to be used for, it should be
described explicitly in the interface contract.

I don't feel comfortable with making a policy decision like that part of the contract.

And I hope we can agree on a bugfix solution for Zope 3.2 and 3.3 without discussing new features like focusControlId.

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.

In this case it makes the framework more complex, so it has a negative impact on people who don't care. But nevertheless your position might be the right one.

This is what I propose:

- I'll fix the issue in Zope 3.2, 3.3 and trunk by making the current contract explicit and by changing the widgets that don't fulfill that contract.

- Everybody is welcome to propose a more sophisticated solution for Zope 3.4. That might include new features like focusControlId.

If you still object to this, I'd alternatively volunteer to fix the bug in Zope 3.2, 3.3 and trunk this way:

- Adding a new interface IWidgetControlInformation with one new attribute called labelControlId.

- Making sure the widgets in zope.app.form implement it and zope.formlib uses it.




Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to