At 05:15 PM 1/3/01 +0000, Chris Withers wrote:
What I'd like: 'Zope' objects of type 'X', which can have multiple parents and can contain other objects of type 'X', where storage isn't necessarily tied to the ZODB but where the objects have a normal properties page (in terms of use, again, it'd be nice if it could be stored anywhere) and participate in all the normal Zope security and management interface processes, and they need to be catalogable.
This sounds like ZPatterns to me, am I right?
If so, it appears there are two choices: 1. Folder w/Customiser Support (FwCS ;-) and DataSkins 2. Specialist with one or more Racks and DataSkins
Which one of these would be most appropriate? FwCS containg DataSkins that also mix in the Folder class sound like they'd give a closer approximation to 'real Zope objects', but Racks sound like the only way that objects of the same metatype can come from different sources (eg, some objects of type 'X' from ZODB, some from SQL, some from LDAP ,etc) and seem to be more flexible in general, but can I have DataSkins that nest stored in a specialists' rack, eg:
http://server:8080/specialist/dataskin1/dataskin2
How about doing something like:
You can't really "nest" DataSkins inside each other in a rack, and you really don't want to, anyway. But there's nothing that says you can't create a DataSkin subclass whose __bobo_traverse__ looks up related objects. You just can't "really" store the DataSkins inside each other. Note that if your __bobo_traverse__ uses a specialist "getXforY()" call, you can "store" objects from different databases (racks) "inside" each other. :)