Gary Poster wrote: > The use case we are trying to address with the iterable source > interface is that we want to be able to distinguish between sources > that should be searched, and those that should be displayed as explicit > choices. I'll call these 'searchable' and 'showable' sources and > widgets below. I'll discuss a few of the possible approaches to the > problem. > > One way is to register searchable widgets for all source fields. If > you want a showable widget for a given source, you need to confirm that > the source supports __iter__ and then register a showable widget for > the combinations of source plus each field type that uses the source > (i.e., Choice, Tuple, Set, etc.). That's a bit heavy when you have a > reasonable number of these sources in your application. You could also > do this kind of story with a custom widget for each form, but that > would be even more impractical and annoying with heavy source usage. > > Another way would be to have an interface that marks a source as > 'showable'. You could then register searchable widgets for standard, > non-showable source fields; and showable widgets for fields marked as > showable. This is convenient. If you make the decision actually in > the software, you are making the decision at the wrong level (it is > configuration), but if you declare the showable interface on the source > with zcml, it is closer to being in the right location. It still feels > problematic though: what if the source is used for display in multiple > formats--HTML vs. rich client, for instance? What if a source has > variable options during the lifetime of the application, and sometimes > is appropriate to be shown as a searchable, and sometimes as a showable?
Description: OpenPGP digital signature
_______________________________________________ Zope3-dev mailing list Zope3email@example.com Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com