There is a bug (a feature?) in Specialist.getItem in zpatterns-0.4a4: def getItem(self, key): if hasattr(self.aq_base,'retrieveItem'): return self.retrieveItem(key=key) # XXX need DTML check? for rack in self.rackList: item = rack.__of__(self).getItem(key) return item This code should (IMHO) read: def getItem(self, key): if hasattr(self.aq_base,'retrieveItem'): return self.retrieveItem(key=key) # XXX need DTML check? for rack in self.rackList: item = rack.__of__(self).getItem(key) if item is not None: return item return None regards, jephte clain jclain@univ-reunion.fr
Jephte CLAIN wrote:
There is a bug (a feature?) in Specialist.getItem in zpatterns-0.4a4:
def getItem(self, key): if hasattr(self.aq_base,'retrieveItem'): return self.retrieveItem(key=key) # XXX need DTML check?
for rack in self.rackList: item = rack.__of__(self).getItem(key) return item
This code should (IMHO) read:
def getItem(self, key): if hasattr(self.aq_base,'retrieveItem'): return self.retrieveItem(key=key) # XXX need DTML check?
for rack in self.rackList: item = rack.__of__(self).getItem(key) if item is not None: return item return None
I also think so, Jephte. But I thought 'for rack ...' was just a shorter form of if len( rackList) > 0) : return rackList[0].__of__( self).getItem( key) else : return None Better you, Phillip, replace it with one of more clear forms - Jephte's or mine. By the way, I do not like this Rack list at all. Racks and Specialists are both DataManagers with compatible interfaces (getItem, newItem). IMHO, Specialists should have list of DataManagers. This make much sense in context of combining Specialists - ZSession and ClientManager, for example. It is not sufficient just to tune ZSession using ClientManager's rack and ZClass, because in this case we are losing the ClientManager's aspect in sessions. Of course, one always can create delegating rack (and even rack-to-specialist bridge), but what do this for if simple replacing rackList with dataManagerList will solve all such problems? (Oh Gott, help mine improvink mie English :-) Mike
mike wrote:
I also think so, Jephte. But I thought 'for rack ...' was just a shorter form of
if len( rackList) > 0) : return rackList[0].__of__( self).getItem( key) else : return None The intended behavior (at least in zpatterns-0.3) was to get an item from one of the racks. This is why I think this is a bug. It changes the behavior of zpatterns-0.3 because it returns the value from the first rack, and ignore the others. I wonder then of what use is the other racks... (or is this intended? I don't think so) If a rack returns None, then we assume the rack is not responsible for storage of that element, and go on with the next rack in the list
Better you, Phillip, replace it with one of more clear forms - Jephte's or mine.
By the way, I do not like this Rack list at all. Racks and Specialists are both DataManagers with compatible interfaces (getItem, newItem). IMHO, Specialists should have list of DataManagers. This make much sense in context of combining Specialists - ZSession and ClientManager, for example. It is not sufficient just to tune ZSession using ClientManager's rack and ZClass, because in this case we are losing the ClientManager's aspect in sessions. Of course, one always can create delegating rack (and even rack-to-specialist bridge), but what do this for if simple replacing rackList with dataManagerList will solve all such problems? I believe RackMountable/Racks/Specialist are not the same as DataSkin/DataManagers (in the spirit at least) They are used for different things. Or it is kept for compatibilty with old applications (at least, LoginManager use the Specialist/Rack paradigm)
(Oh Gott, help mine improvink mie English :-) itoo :-)
regards, jephte clain jclain@univ-reunion.fr
Jephte CLAIN wrote:
I believe RackMountable/Racks/Specialist are not the same as DataSkin/DataManagers (in the spirit at least) They are used for different things. Or it is kept for compatibilty with old applications (at least, LoginManager use the Specialist/Rack paradigm)
As I can remember, there were no DataSkins first time, they were breeded from ancient RIPP RackMountables (or so) much later and were things which provide 'RackMountability' outside of Racks. Look, the Specialist is just Aspect, which adds context functionality to items, regardless of their nature. Why should we distinct white- and black-box Specialists? Their white- and black-boxeness is depending on *our* point of view. If I understand something, things like LoginManager or ZSession can be deployed on any level of the system and can as *integrate* as *be integrated*. Does it mean framework developer should create two separate kinds of the same aspect to be used in master's and slave's contexts? I think, no. ZPatterns were created to avoid such dependencies. At least, they (Specialist and Rack) are both DataManagers and PlugIns. Mike
At 07:13 PM 6/26/00 +0800, mike wrote:
By the way, I do not like this Rack list at all. Racks and Specialists are both DataManagers with compatible interfaces (getItem, newItem). IMHO, Specialists should have list of DataManagers. This make much sense in context of combining Specialists - ZSession and ClientManager, for example. It is not sufficient just to tune ZSession using ClientManager's rack and ZClass, because in this case we are losing the ClientManager's aspect in sessions. Of course, one always can create delegating rack (and even rack-to-specialist bridge), but what do this for if simple replacing rackList with dataManagerList will solve all such problems?
Let me see if I understand what you're saying... you want a Specialist to be able to be used as a Rack in another Specialist? That seems reasonable enough. But why not just add the Specialist on the Methods tab, and then override retrieveItem and createItem to include the Specialist in the list of sub-objects queried? Or, simply create a SpecialistRack class that's a plain Specialist, except registered with the 'Rack' __plugin_kind__, so that it can go on the tab. I don't have Specialists registered as a 'Rack' plugin by default because PlugInContainers use the presence of a __plugin_kind__ attribute to suppress display of PlugIns on their main Contents tab, and that would mean that if you put a Specialist inside a PlugInContainer, it would disappear from the management interface unless the PlugInContainer had a tab which supported the Rack plugin kind. (Perhaps by 0.5.0 this display quirk could be fixed, however, by making the Contents tab a bit smarter). (Note, by the way, that the DataManager interface doesn't support getItem/newItem, so I can't just make Specialist use DataManagers. Customizers, for example have no idea what objects they're customizing, so they can't support getItem.)
Hi ZPatterns folks... ZPatterns-0.4.1snap1 Zope2.2.0-src I have a specialist with a defaultRack storing DataSkin subclassed ZClass instances with only persistent attribute providers. <dtml-var "defaultRack.getPersistentItemIDs()"> or <dtml-in "defaultRack.getPersistentItemIDs()"> ... </dtml-in> raise AuthorizationFailed <dtml-in "defaultRack.getPersistentItemIDs()" sort> ... </dtml-in> works fine. What did I do now? ;-) thanks for any ideas! -steve
Steve Spicklemire wrote:
Hi ZPatterns folks...
ZPatterns-0.4.1snap1 Zope2.2.0-src
I have a specialist with a defaultRack storing DataSkin subclassed ZClass instances with only persistent attribute providers.
<dtml-var "defaultRack.getPersistentItemIDs()">
When I call that, I get <BTreeItems object at 869a5d8>. To get that list of IDs, I use an external method: def get_persistent_ids(self): try: items = self.defaultRack.aq_base.getPersistentItemIDs() return map(lambda x: x, items) except: import sys, traceback, string etype, val, tb = sys.exc_info() sys.stderr.write(string.join(traceback.format_exception(etype, val, tb),'')) del etype, val, tb I've tried something like your code, with no sheetproviders in the rack. I can't reproduce your error. I'm using the method as a Manager.
or
<dtml-in "defaultRack.getPersistentItemIDs()"> ... </dtml-in>
raise AuthorizationFailed
<dtml-in "defaultRack.getPersistentItemIDs()" sort> ... </dtml-in>
works fine. What did I do now? ;-)
Line 318, Rack.py. The method getPersistentItemIDs has no docstring. Is that still significant under the new security model? Does the user you're running the method as have the permission "Access contents information" ? Looks like you may have uncovered a Zope security bug in <dtml-in ... sort> :-/ How could we test this further? -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
Hi Steve, Thanks for the reply. Of course as soon as I reported this, I went away for a couple days and I haven't been able to check the list. It appears that the problem is that the BTreeItems object returned by getPersistentObjectIDs isn't currently allowed as an argument of 'in' by itself since it's not in the 'containerAssertions' dictionary defined in SimpleObjectPolicies.py and it doesn't have the magic property: '__allow_access_to_unprotected_subobjects__'. If you *sort* the BTreeItems object however, the dtml-in tag makes a copy of the items in the BTreeItems object as a simple List, and sorts that rather than destructively attempting to sort the original. The simple list is in containerAssertions, and is therefore allowed. I was wrong about the <dtml-var "defaultRack.getPersistentItemIDs()"> it's only <dtml-in "defaultRack.getPersistentItemIDs()"> that seems to cause the problem. The odd thing is that the method 'getPersistentObjectIDs' is correctly included in the definition of __ac_permissions__ in Rack.py, but as you point out, it returns a BTreeItems object that doesn't want to play nice with <dtml-in... >. Once possible solution would be to add an '__allow_access_to_unprotected_subobjects__' property to the BTreeItems object. I'm not sure who should do that..... maybe Rack.py? For now.. I'll just sort the ids. ;-) thanks, -steve
"Steve" == Steve Alexander <steve@cat-box.net> writes:
Steve> Steve Spicklemire wrote: >> Hi ZPatterns folks... >> >> ZPatterns-0.4.1snap1 Zope2.2.0-src >> >> I have a specialist with a defaultRack storing DataSkin >> subclassed ZClass instances with only persistent attribute >> providers. >> >> <dtml-var "defaultRack.getPersistentItemIDs()"> Steve> When I call that, I get <BTreeItems object at 869a5d8>. To Steve> get that list of IDs, I use an external method: Steve> def get_persistent_ids(self): try: items = Steve> self.defaultRack.aq_base.getPersistentItemIDs() return Steve> map(lambda x: x, items) Steve> except: import sys, traceback, string etype, val, tb = Steve> sys.exc_info() Steve> sys.stderr.write(string.join(traceback.format_exception(etype, Steve> val, tb),'')) del etype, val, tb Steve> I've tried something like your code, with no sheetproviders Steve> in the rack. I can't reproduce your error. I'm using the Steve> method as a Manager. >> or >> >> <dtml-in "defaultRack.getPersistentItemIDs()"> ... </dtml-in> >> >> raise AuthorizationFailed >> >> <dtml-in "defaultRack.getPersistentItemIDs()" sort> ... >> </dtml-in> >> >> works fine. What did I do now? ;-) Steve> Line 318, Rack.py. The method getPersistentItemIDs has no Steve> docstring. Is that still significant under the new security Steve> model? Steve> Does the user you're running the method as have the Steve> permission "Access contents information" ? Steve> Looks like you may have uncovered a Zope security bug in Steve> <dtml-in ... sort> :-/ Steve> How could we test this further? Steve> -- Steve Alexander Software Engineer Cat-Box limited Steve> http://www.cat-box.net Steve> _______________________________________________ Zope-Dev Steve> maillist - Zope-Dev@zope.org Steve> http://lists.zope.org/mailman/listinfo/zope-dev ** No cross Steve> posts or HTML encoding! ** (Related lists - Steve> http://lists.zope.org/mailman/listinfo/zope-announce Steve> http://lists.zope.org/mailman/listinfo/zope )
At 01:08 PM 6/26/00 +0400, Jephte CLAIN wrote:
This code should (IMHO) read:
def getItem(self, key): if hasattr(self.aq_base,'retrieveItem'): return self.retrieveItem(key=key) # XXX need DTML check?
for rack in self.rackList: item = rack.__of__(self).getItem(key) if item is not None: return item return None
Corrected for next release.
participants (5)
-
Jephte CLAIN -
mike -
Phillip J. Eby -
Steve Alexander -
Steve Spicklemire