Re: [Zope-dev] zpatterns-0.4a4
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. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zpatterns-0.4a4
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zpatterns-0.4a4
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 [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zpatterns-0.4a4
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] zpatterns-0.4a4
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 [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
