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
long I am"
shouldn't an exeption be raised? Otherwise 'for i in
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
other side effects too, such as if I do list(mysource), Python calls
mysource.__len__ (if it exists) to preallocate the list size. Wierd
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
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.
Zope3-dev mailing list