[Zope-dev] zpatterns-0.4a4

[Jephte CLAIN]

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