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
Re: [Zope3-dev] Re: adapter registration question
Morning, Rocky Burt wrote: > On Fri, 2006-10-11 at 08:00 +, Chris Withers wrote: >> This is a toy example, but I need to do something similar and can't seem >> to get the registration right... >> >> How can I register the str builtin as an adapter from python int objects >> to python str objects? > > I've personally found when I run into a situation where it seems like I > need to adapt on the builtin str class, I should probably be using named > adapters or named utilities instead. > > I use this technique for example to lookup mime type stuff in one of my > apps. > > for="*" > name="text/html" > factory=".somemodule.SomeClass" > provides=".interfaces.ISomeMimeTypeHandlerThingie" > /> > > from zope import component > component.getAdapter(randomobj, ISomeMimeTypeHandlerThingie, > name='text/html') Humm. Doesn't that totally work around the fact that the CA knows how to lookup what you need? What does you code do if you adapt from something else? The problem you have is to provide a specification for the 'str' interface. Let's create a marker interface that promises everything that 'str' does: class IString(zope.interface.Interface): """A marker for the 'str' interface.""" Now, you can setup your adapter like this: Cheers, Christian -- gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: OpenPGP digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: adapter registration question
On Fri, 2006-10-11 at 08:00 +, Chris Withers wrote: > This is a toy example, but I need to do something similar and can't seem > to get the registration right... > > How can I register the str builtin as an adapter from python int objects > to python str objects? I've personally found when I run into a situation where it seems like I need to adapt on the builtin str class, I should probably be using named adapters or named utilities instead. I use this technique for example to lookup mime type stuff in one of my apps. from zope import component component.getAdapter(randomobj, ISomeMimeTypeHandlerThingie, name='text/html') - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ 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
[Zope3-dev] adapter registration question
This is a toy example, but I need to do something similar and can't seem to get the registration right... How can I register the str builtin as an adapter from python int objects to python str objects? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com