[Zope3-dev] Re: browser widgets: items widgets and label tags
Hi Fred! You vetoed my first proposal, so please let me know if I was able to convince you that it is the best short term solution. Or if you are at least fine with my alternative proposal. yuppie wrote: 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. Not fixing this at all is definitely the worst solution. So if nobody speaks up, I assume it is fine if I fix it as proposed. Cheers, Yuppie ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: browser widgets: items widgets and label tags
Gary Poster wrote: On Nov 12, 2006, at 7:30 AM, yuppie wrote: This is already broken for choice checkbox and radio widgets. In these cases we have no 1:1 relationship between widget labels and controls. (Though sometimes additional 1:1 labels within the widgets do work.) an aside: If they are set up correctly (i.e., using the spec) then labels for checkbox or radio buttons certainly should work. If they don't, that's a bug. Oops! Yes. I screwed up my sentence. This is what I meant to say: Sometimes the widgets have additional labels, one for each control. If these additional labels exist, they always work. Cheers, Yuppie ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: browser widgets: items widgets and label tags
On Nov 12, 2006, at 7:30 AM, yuppie wrote: Hi Benji! Benji York wrote: yuppie wrote: Adding additional complexity for getting the label issue perfectly right doesn't fit much to the rest of the code. And I doubt any browser will have trouble with 'for' attributes pointing to a non-control element. The "for" attributes in labels are used heavily in zope.testbrowser functional tests. If the human readable labels no longer correctly identify the controls, control IDs or names would have to be used instead, which is not conducive to good tests. This is already broken for choice checkbox and radio widgets. In these cases we have no 1:1 relationship between widget labels and controls. (Though sometimes additional 1:1 labels within the widgets do work.) an aside: If they are set up correctly (i.e., using the spec) then labels for checkbox or radio buttons certainly should work. If they don't, that's a bug. Then also, fwiw, if they are part of a collection of fields, you can use `.control` to get the "virtual" umbrella control for the collection of radio buttons or checkboxes. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: browser widgets: items widgets and label tags
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 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: browser widgets: items widgets and label tags
Hi Benji! Benji York wrote: yuppie wrote: Adding additional complexity for getting the label issue perfectly right doesn't fit much to the rest of the code. And I doubt any browser will have trouble with 'for' attributes pointing to a non-control element. The "for" attributes in labels are used heavily in zope.testbrowser functional tests. If the human readable labels no longer correctly identify the controls, control IDs or names would have to be used instead, which is not conducive to good tests. This is already broken for choice checkbox and radio widgets. In these cases we have no 1:1 relationship between widget labels and controls. (Though sometimes additional 1:1 labels within the widgets do work.) AFAICS this is a limitation of the HTML specs and no change in zope can really fix this. If the 'for' attribute is omitted for checkbox and radio widgets (as Fred proposes) there is no relationship at all. If the 'for' attribute points to a div surrounding the controls (as I propose), you can find the ListControl if you are willing to rely on that non-standard behavior. Cheers, Yuppie ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: browser widgets: items widgets and label tags
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 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. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: browser widgets: items widgets and label tags
yuppie wrote: Adding additional complexity for getting the label issue perfectly right doesn't fit much to the rest of the code. And I doubt any browser will have trouble with 'for' attributes pointing to a non-control element. The "for" attributes in labels are used heavily in zope.testbrowser functional tests. If the human readable labels no longer correctly identify the controls, control IDs or names would have to be used instead, which is not conducive to good tests. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: browser widgets: items widgets and label tags
Hi Philipp! Philipp von Weitershausen wrote: yuppie wrote: Looking at the output generated by formlib, I got the impression nobody cares much about valid output. formlib's standard template is horrible. zope.app.form's rendering is much better. I have no idea why formlib uses its own horrid template any way, it could simply have used widget_macros from zope.app.form (which is what I always do in my formlib forms). 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. AFAICS the biggest problem are the poorly maintained widgets in zope.app.form. I object; this is still a change to the contract. Well. It depends on the point of view. This seems to be the implicit contract. The templates in zope.formlib and in zope.app.form use the widget name in the 'for' attribute, so they depend already on that behavior. Making this contract explicit by fixing the description in the interface doesn't mean to change the contract. Or does it? The description of interface methods and attributes are part of the contract. We should therefore be reluctant to change them, unless * we just add documentation * we now explicitly state a contract that has been assumed implicitly before I think this would be the case if we choose the more pragmatic solution. This looks like overkill to me. No use case comes to my mind where focusControlId would be different to labelControlId. But if Zope 3 policies require a new interface for changes like that and if we really want to stick that close to the HTML specification I'm fine with adding IWidgetControlInformation. I'm not an expert on the exact HTML mechanics here, but it always sounds good to me to stick close to existing specs. The HTML spec is what people can refer to and what people know... 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. Cheers, Yuppie ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: browser widgets: items widgets and label tags
yuppie wrote: Looking at the output generated by formlib, I got the impression nobody cares much about valid output. formlib's standard template is horrible. zope.app.form's rendering is much better. I have no idea why formlib uses its own horrid template any way, it could simply have used widget_macros from zope.app.form (which is what I always do in my formlib forms). I object; this is still a change to the contract. Well. It depends on the point of view. This seems to be the implicit contract. The templates in zope.formlib and in zope.app.form use the widget name in the 'for' attribute, so they depend already on that behavior. Making this contract explicit by fixing the description in the interface doesn't mean to change the contract. Or does it? The description of interface methods and attributes are part of the contract. We should therefore be reluctant to change them, unless * we just add documentation * we now explicitly state a contract that has been assumed implicitly before You were on the right track with your first proposal. There's a need for widgets to provide more information to support integration in a form. Unfortunately, adding an attribute to the IWidget or other existing interfaces doesn't work well, since it makes it harder to write code that supports multiple versions of Zope. So there is no way to fix interfaces? Are all interfaces completely frozen? (I still have to make myself familiar with the Zope 3 policies.) Yes, public interfaces should not change. Otherwise people implementing the interface in question woudl all of a sudden not fulfill the contract anymore when upgrading to a newer Zope version. This looks like overkill to me. No use case comes to my mind where focusControlId would be different to labelControlId. But if Zope 3 policies require a new interface for changes like that and if we really want to stick that close to the HTML specification I'm fine with adding IWidgetControlInformation. I'm not an expert on the exact HTML mechanics here, but it always sounds good to me to stick close to existing specs. The HTML spec is what people can refer to and what people know... -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: browser widgets: items widgets and label tags
Hi Fred!
Fred Drake wrote:
On 11/10/06, yuppie <[EMAIL PROTECTED]> wrote:
While pointing the label to the div element that contains the input
fields is not very useful, this seems to be valid HTML::
Sorry for not replying earlier, but I wanted to have time to think
before responding. ;)
No problem. Thanks for your feedback!
There's valid according to the DTD (the XML definition of validity),
and there's valid according to the specification. DTDs aren't able to
specify the constraint documented in the specification document; in
this case, that means the DTD can be used to help detect invalid HTML
documents, but not determine whether an HTML document is valid. More
expressive schema languages could be used to produce a more useful
schema definition.
Given that the specification clearly states that the "for" attribute's
value be an ID for a control, I must conclude that referring to the ID
of a or other non-control element causes the HTML to be invalid.
I agree with your analysis, but I'm not sure I agree with your conclusions:
Looking at the output generated by formlib, I got the impression nobody
cares much about valid output. I would be happy if formlib would return
HTML that validates in a validator. Adding additional complexity for
getting the label issue perfectly right doesn't fit much to the rest of
the code. And I doubt any browser will have trouble with 'for'
attributes pointing to a non-control element.
Making sure that radio and checkbox widgets have a div tag with the
required ID is a simple bugfix. No API changes are required and
zope.formlib still can use the widget name in the 'for' attribute.
Regardless of the HTML specification, this is a semantic change in the
contract of the IWidget API. So it's a change, just not in the set of
attributes and methods and their signatures.
So IBrowserWidget's __call__ method *has to* return a snipped that
contains a tag with the widget's name as ID. All widgets that don't
follow that rule have to be fixed.
If there are no objections, I'll make the required changes on 3.2
branch, 3.3 branch and trunk.
I object; this is still a change to the contract.
Well. It depends on the point of view. This seems to be the implicit
contract. The templates in zope.formlib and in zope.app.form use the
widget name in the 'for' attribute, so they depend already on that
behavior. Making this contract explicit by fixing the description in the
interface doesn't mean to change the contract. Or does it?
You were on the right track with your first proposal. There's a need
for widgets to provide more information to support integration in a
form. Unfortunately, adding an attribute to the IWidget or other
existing interfaces doesn't work well, since it makes it harder to
write code that supports multiple versions of Zope.
So there is no way to fix interfaces? Are all interfaces completely
frozen? (I still have to make myself familiar with the Zope 3 policies.)
Another way to expose the required information is to create a new
interface and provide adapters for the existing widgets (possibly by
simply implementing the new interface on the existing widgets). A
form that's aware of the new interface can use the additional
information.
The new interface could look something like this:
class IWidgetControlInformation(zope.interface.Interface):
labelControlId = zope.schema.TextLine(
title=_("Label control id"),
description=_("Id of the control element that should be"
" associated with any element rendered"
" for the widget."),
required=False,
)
focusControlId = zope.schema.TextLine(
title=_("Focus control id"),
description=_("Id of the control element that should be"
" focused when the form is initially rendered."
" Since each widget may suggest an element for"
" the initial focus, this should only be regarded"
" as a hint."),
required=False,
)
This looks like overkill to me. No use case comes to my mind where
focusControlId would be different to labelControlId.
But if Zope 3 policies require a new interface for changes like that and
if we really want to stick that close to the HTML specification I'm fine
with adding IWidgetControlInformation.
Cheers,
Yuppie
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: browser widgets: items widgets and label tags
On 11/10/06, yuppie <[EMAIL PROTECTED]> wrote:
While pointing the label to the div element that contains the input
fields is not very useful, this seems to be valid HTML::
Sorry for not replying earlier, but I wanted to have time to think
before responding. ;)
There's valid according to the DTD (the XML definition of validity),
and there's valid according to the specification. DTDs aren't able to
specify the constraint documented in the specification document; in
this case, that means the DTD can be used to help detect invalid HTML
documents, but not determine whether an HTML document is valid. More
expressive schema languages could be used to produce a more useful
schema definition.
Given that the specification clearly states that the "for" attribute's
value be an ID for a control, I must conclude that referring to the ID
of a or other non-control element causes the HTML to be invalid.
Making sure that radio and checkbox widgets have a div tag with the
required ID is a simple bugfix. No API changes are required and
zope.formlib still can use the widget name in the 'for' attribute.
Regardless of the HTML specification, this is a semantic change in the
contract of the IWidget API. So it's a change, just not in the set of
attributes and methods and their signatures.
So IBrowserWidget's __call__ method *has to* return a snipped that
contains a tag with the widget's name as ID. All widgets that don't
follow that rule have to be fixed.
If there are no objections, I'll make the required changes on 3.2
branch, 3.3 branch and trunk.
I object; this is still a change to the contract.
You were on the right track with your first proposal. There's a need
for widgets to provide more information to support integration in a
form. Unfortunately, adding an attribute to the IWidget or other
existing interfaces doesn't work well, since it makes it harder to
write code that supports multiple versions of Zope.
Another way to expose the required information is to create a new
interface and provide adapters for the existing widgets (possibly by
simply implementing the new interface on the existing widgets). A
form that's aware of the new interface can use the additional
information.
The new interface could look something like this:
class IWidgetControlInformation(zope.interface.Interface):
labelControlId = zope.schema.TextLine(
title=_("Label control id"),
description=_("Id of the control element that should be"
" associated with any element rendered"
" for the widget."),
required=False,
)
focusControlId = zope.schema.TextLine(
title=_("Focus control id"),
description=_("Id of the control element that should be"
" focused when the form is initially rendered."
" Since each widget may suggest an element for"
" the initial focus, this should only be regarded"
" as a hint."),
required=False,
)
-Fred
--
Fred L. Drake, Jr.
"Every sin is the result of a collaboration." --Lucius Annaeus Seneca
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: browser widgets: items widgets and label tags
Hi! I found a simpler solution: yuppie wrote: Pointing the label to a specific input field would not be very useful. AFAICS the widget's label tag should have no 'for' attribute at all. Instead, each value text should be a label. Something like this:: WIDGET_LABEL spam ham eggs While pointing the label to the div element that contains the input fields is not very useful, this seems to be valid HTML:: WIDGET_LABEL spam ham eggs Making sure that radio and checkbox widgets have a div tag with the required ID is a simple bugfix. No API changes are required and zope.formlib still can use the widget name in the 'for' attribute. So IBrowserWidget's __call__ method *has to* return a snipped that contains a tag with the widget's name as ID. All widgets that don't follow that rule have to be fixed. If there are no objections, I'll make the required changes on 3.2 branch, 3.3 branch and trunk. Cheers, Yuppie ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
