[Zope3-dev] Re: [Zope3-checkins] SVN: Zope3/trunk/src/zope/schema/interfaces.py - add IIterableChoice and note the desire to depricate vocabularies

[Gary Poster]

On Sep 5, 2005, at 12:39 AM, Stuart Bishop wrote:

> Benji York wrote:
>
>> Stuart Bishop wrote:
>>
>>> If this is a way of saying "I'm iterable, but I don't want to  
>>> tell you
>>> how
>>> long I am"
>>
>> Right.
>>
>>> shouldn't an exeption be raised? Otherwise 'for i in
>>> range(0,len(source)):
>>> foo = source[i]' could start blowing up if the source changes.
>>
>> Of course, that particular spelling would be a strange way to iterate
>> over the values, and a source from a non-ZODB back-end really should
>> provide the C in ACID, but point taken. :)
>>
>> That is the way vocabularies do it, something else might work better.
>> Now would be the time to talk about it.
>
> Urgh... I hadn't noticed that in vocabularies before. I believe  
> this has
> other side effects too, such as if I do list(mysource), Python calls
> mysource.__len__ (if it exists) to preallocate the list size. Wierd  
> things
> can happen if your class lies about itself and breaks contracts.
>
> Do you happen to know *why* the vocabularies needed this method,  
> and if the
> callsites could be fixed to catch a NotImplementedError or similar?

It does sound like this story could be improved.  Tim and Fred have  
talked about the specific problem.  Here's a discussion of goals.

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?

The last way I'll discuss is the way we chose, but did not follow  
through on completely.  In this one, you mark the source as iterable  
in the software, and make iterable sources also specify a len.  In  
this case, you *can* (but we don't yet) register an intermediary  
adapter for these iterable sources.  If the len is beneath whatever  
limit you desire (for the given kind of request), you can return a  
showable widget, and otherwise return a searchable widget.  Note that  
if a source is iterable but is too big to quickly calculate its  
length, that almost certainly is going to suggest a searchable  
widget, rather than a showable widget.

So there's the situation.  I'll ponder possible next steps later, but  
meanwhile interested folks can maybe suggest ideas themselves.

Gary