[Zope-dev] Specialists in Specialists (was Re: zpatterns-0.4a4)

[Phillip J. Eby]

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.)