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

[yuppie]

Hi Fred!


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

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.

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

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.


Opinions?

Cheers,

	Yuppie