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. -steve
"Chris" == Chris Withers <chrisw@nipltd.com> 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