New methods on the iterator would do the trick. I had suggested
currval and nextval or similar - two or three simple methods would
increase the versatility of the Iterator class for a variety of things.
Is there interest in adding new methods to ZTUtils to expose these
values? It seems to fit the purpose of ZTUtils and would save making
another tool at site or portal level. The fact is it doesn't have to
be a portal / portlets type of situation to benefit from this. It is
not CMF specific in the least and would be useful in any multi column
layout using ZPT where you need values for tabindex attributes without
hand coding (particularly when your content is dynamic).
If there is no interest, I'll leave this alone and carry on with a
portal tool for my CMF work instead. ZTUtils is really core Zope issue
so if there is interest, I can create a few methods but need some
direction on what to do with them afterwards.
Regards,
David
On Monday, July 25, 2005, at 06:03 AM, Tino Wildenhain wrote:
It looks like this part of the Iterator is just misdesigned:
def next(self):
if not (hasattr(self, '_next') or self._prep_next(self)):
return 0
self.index = i = self.nextIndex
self.nextIndex = i+1
self._advance(self)
return 1
IIRC, ZTUtils were written long before the python iterators became
standard. So the method name next was used and now clashes with
the standard iterator protocol.
It could be fixed but only if there is no product in the world using
it or all must be fixed before.
I propose: has_next() or something in place of it.
_______________________________________________
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
