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