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:
>
>http://server:8080/specialist/dataskin1/dataskin2/manage
>
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]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
