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

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to