[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
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
[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
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
[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
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:: labelWIDGET_LABEL/label div class=value labelinput id=WIDGET_NAME.0 name=WIDGET_NAME value=spam type=checkboxnbsp;spam/label br labelinput id=WIDGET_NAME.1 name=WIDGET_NAME value=ham type=checkboxnbsp;ham/label br labelinput id=WIDGET_NAME.2 name=WIDGET_NAME value=eggs type=checkboxnbsp;eggs/label /div While pointing the label to the div element that contains the input fields is not very useful, this seems to be valid HTML:: label for=WIDGET_NAMEWIDGET_LABEL/label div class=value id=WIDGET_NAME labelinput id=WIDGET_NAME.0 name=WIDGET_NAME value=spam type=checkboxnbsp;spam/label br labelinput id=WIDGET_NAME.1 name=WIDGET_NAME value=ham type=checkboxnbsp;ham/label br labelinput id=WIDGET_NAME.2 name=WIDGET_NAME value=eggs type=checkboxnbsp;eggs/label /div 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
[Zope3-dev] browser widgets: items widgets and label tags
Hi! I plan to do some bugfixing in zope.formlib and zope.app.form. This is what I'd like to fix first: The HTML label tag is not used correctly with items widgets. The result is invalid HTML. This is how a MultiCheckBoxWidget is basically rendered:: label for=WIDGET_NAMEWIDGET_LABEL/label div class=value input id=WIDGET_NAME.0 name=WIDGET_NAME value=spam type=checkboxnbsp;spam br input id=WIDGET_NAME.1 name=WIDGET_NAME value=ham type=checkboxnbsp;ham br input id=WIDGET_NAME.2 name=WIDGET_NAME value=eggs type=checkboxnbsp;eggs /div The 'for' attribute is invalid because its value is the *name* of the widget, not an ID of an input field. 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:: labelWIDGET_LABEL/label div class=value labelinput id=WIDGET_NAME.0 name=WIDGET_NAME value=spam type=checkboxnbsp;spam/label br labelinput id=WIDGET_NAME.1 name=WIDGET_NAME value=ham type=checkboxnbsp;ham/label br labelinput id=WIDGET_NAME.2 name=WIDGET_NAME value=eggs type=checkboxnbsp;eggs/label /div The widget's label tag is created by the form template, not by the widget. ISimpleInputWidget doesn't seem to have an attribute that is useful for creating a label tag. zope.formlib uses IWidget's name attribute, but as the example above shows it is not always useful. So I propose to add a 'controlID' attribute (or something similar):: controlID = TextLine( title=u'Control ID', description=u'ID used for binding the widget label.', required=False) In most cases this would have the same value as 'name', but for MultiCheckBoxWidget and other item widgets this could be set to None or the ID of a specific control element. Does that make sense? Am I missing something? This is a bugfix, but also a significant change. Is it fine to fix this on the Zope 3.2 and 3.3 branches? 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] Zope 3.2 maintenance
Hi! Recently I started to use formlib in Zope 2. The current stable release of Zope 3 is shipped with Zope 2.9, so I thought I would use actively maintained code. But I stumbled over some rough edges in zope.formlib and zope.app.form and started to wonder if I'm the first person who tries to use some specific features. So I decided to work on some fixes. But surprise! Many issues are already fixed on the 3.3 branch and trunk. Here is a small list of fixes that were never backported to the current stable branch: http://svn.zope.org/?rev=41043view=rev http://svn.zope.org/?rev=66579view=rev http://svn.zope.org/?rev=68157view=rev http://svn.zope.org/?rev=69760view=rev Are there good reasons why these changes were not backported? I volunteer to backport some fixes I'm missing in Zope 3.2, but that's no general solution for keeping the current stable branch maintained. 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: Zope 3.2 maintenance
Hi Stephan! Stephan Richter wrote: On Friday 08 September 2006 04:12, yuppie wrote: Are there good reasons why these changes were not backported? I volunteer to backport some fixes I'm missing in Zope 3.2, but that's no general solution for keeping the current stable branch maintained. The short answer is: We are a bit sloppy. I always develop against the trunk, so when I fix an issue, I do not event think about porting it back to another release, other when one is imminent, like Zope 3.3 now. I think most other Zope 3 developers are the same. I just re-read http://www.zope.org/DevHome/Subversion/ZopeDevelopmentProcess - the only relevant document I was able to find. Some of the fixes I'm missing on the 3.2 branch were checked in after creating the 3.3 branch. The policy described in ZopeDevelopmentProcess doesn't require backports to 3.2 after the new branch was created. Overall, I would really like to find a person for each release being responsible for backporting bug fixes. It would be a relatively easy way to contribute to Zope 3. IMHO maintaining the current stable branch should be the responsibility of all developers - if you fix a bug you should be familiar with the issue and best qualified for backporting the fix. But if this is resolved in a different way I'm fine with it - as long as the problem is resolved. Dot-zero releases always contain new bugs introduced by new features. It is important to have always one stable branch that is actively maintained. Anyway. Should I just go ahead with backporting fixes or should I wait until a procedure and responsible person are found? Regards, Yuppie ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] ZConfig change breaks Zope 2 and Zope 3
Hi! On Windows, this 15 months old change in ZConfig sets the default hostname for inet_address to 'localhost': http://svn.zope.org/ZConfig/?rev=376view=rev I have no idea why this was changed, the checkin message is not very helpful: fix the default hostname for address datatypes for Windows This ZConfig change is responsible for the Zope 2.8 release blocker http://www.zope.org/Collectors/Zope/1728 (the relevant info is in http://www.zope.org/Collectors/Zope/1507) and caused similar problems with Zope 3 http://www.zope.org/Collectors/Zope3-dev/383 http://mail.zope.org/pipermail/zope3-dev/2005-March/013770.html So if nobody can tell me why ZConfig was changed, I propose to 1.) revert the change and tag a new version of ZConfig 2.) update ZEO: the ZEO tests expect the old behavior, see http://mail.zope.org/pipermail/zope3-dev/2005-March/013794.html 3.) update Zope 2 trunk and Zope 3 trunk to the new versions of ZConfig and ZEO 4.) fix http://www.zope.org/Collectors/Zope/1507 and http://www.zope.org/Collectors/Zope3-dev/383 I'd volunteer to do the necessary changes in Zope 2. Any comments? Any volunteers for the other tasks? Cheers, Yuppie BTW: Why is ZConfig not a svn:external in Zope 2 and 3? ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
