Hi Chris,

   It looks like it's a non-bug, more just an annoyance. Here's my current
feeling. In most 'real' situations you'll end up with a ZCatalog, or possibly
a totally virtual ZClass with some sort of dynamic (SQL? LDAP? etc.. ) 
data source where the ids you're after will be queried for.  My own practice
at this point is to define methods at the rack level like:

getAllItemIds, getRejectedItemIds, getCurrentItemIds 

and so on. These can then be implemented in a way that matches the
actual data storage. *If* the data is stored persistently, and *if*
you are implementing 'getAllItemsIds' and *if* you don't have a handy
ZCatalog around to query, then you can use the hack I sent Roche. ;-)
Otherwise there are better ways to do it anyway. The reason it's a
probem is that getPersistentItemIDs() returns a BTree object, that
isn't allowed to be exposed directly by the security
machinery. However, 'sort' short-curcuits the machinery so that you
can 'handle' them (in this hack, you store them in a simple python
list....). Anyway..  it's not clear it's a bug worth fixing... if it's
a bug at all.


>>>>> "Chris" == Chris Withers <[EMAIL PROTECTED]> writes:

    Chris> Steve Spicklemire wrote:
    >>  This is a known problem. Use:
    >> <dtml-let itemIDs="[]"> <dtml-in
    >> "addressRack.getPersistentItemIDs()" sort> <dmtl-call
    >> "itemIDs.append(_['sequence-item'])"> </dtml-in>

    Chris> Hmmm... that's not very nice, has the bug in
    Chris> getPersistentItemIDs() been fixed?

    Chris> cheers,

    Chris> Chris

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to