Hi there,

it's quite confusing that sequence widgets and items widgets (such as SelectWidget, DropdownWidget, etc.) cannot be specified in the <widget /> subdirective of the addform and editform directives. I actually consider it a bug because documentation and implementation are saying something different. Rather than changing the documentation by limiting the use of <widget /> to the simple form fields, I have added changed the directive handler to support both sequence widgets and vocabulary widgets on the philikon-widget-subdirective branch.

The idea of the change is the following:

Normal widgets's __init__ take (field, request) like a regular browser view. Sequence widgets take (field, value_type, request) because they are multiviews for (field, value_type) and vocabulary widgets take (field, vocabulary, request) because they are multiviews for (field, vocabulary).

I have created a CustomVocabularyWidgetFactory like CustomSequenceWidgetFactory. All factories, including CustomWidgetFactory, comply with the IViewFactory interface, however (which means their __call__ takes (context, request)). That means that API backward compatability with CustomSequenceWidgetFactory is broken. However, since the latter was only introduced on the trunk recently, I would think it's ok to break it. I also think API conformity is to be valued highly here.

I have also created two new interfaces, ISequenceWidgetFactory and IVocabularyWidgetFactory. The sequence widget classes *provide* the former, the vocabulary widget classes *provide* the latter (not implement!). Now, when you use the <widget /> directive, it chooses either CustomSequenceWidgetFactory or CustomVocabularyWidgetFactory according to which interface the given widget class provides. That way, widget classes are always called with the right number of arguments when <widget /> is used.

I have implemented these changes on a branch because they break API backward compabatility on CustomSequenceWidgetFactory. Before I merge these changes, I would like to hear your comments, especially from people who are heavily involved into forms (Roger, Garret, ...?). Given no objections, I can merge anytime. The branch is ready.



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

Reply via email to