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
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to