[Zope-dev] Objects with multiple parents and storage flexibility, ZPatterns?

[Steve Spicklemire]

Hi Chris,

>>>>> "Chris" == Chris Withers <chrisw@nipltd.com> writes:


    Chris> Steve Spicklemire wrote:
    >> I think that if you make your DataSkins folderish it will be
    >> hard to make the storage anything other than ZODB.

    Chris> Well, I don't mind the 'skins' being stored in the ZODB,
    Chris> but, as Steve A mentioned, I _would_ like stuff created in
    Chris> the RDBMS to 'magically appear' in the Zope side of
    Chris> things. I guess that means FwCS and folder-subclassing
    Chris> DataSkins are a no-no?

No... I don't think so! If you don't mind keeping stuff in ZODB
then you *could* have a traversal interface that made stuff 'appear'
wherever you want it to, though its persistent storage would 'really' 
be in a Rack or FwCS.

    >> Let's say your objects have an attribute that defines them in
    >> the context of their parent (e.g., dataskin2 in your example
    >> URL),

    Chris> their id in Zope parlance, right?

Hmm. not really...  the Zope 'id' is used by the Rack to keep track
of all the objects of a single type. If all your 'X's are kept in one
Rack, they all need a unique 'id'. The idea context_id is an id-like
attribute that 'plays the role of id' in the context of a particular
parent. It's probably a bad name... but all I could think of in 5
minutes... 

    >> let's call it 'context_id'. You may have six objects with the
    >> same context_id, but they would all have different parents.

    Chris> They may each have mutliple parents too ;-) The point for
    Chris> me is that the id (context_id in your example) is unique in
    Chris> terms of _only_ the following constraint: No parent may
    Chris> have more than one child with the same id.  This is
    Chris> actually how the ZODB works except that it objects in the
    Chris> ZODB may only have one parent (well, at least ZODBs managed
    Chris> with Zope ;-)

Wow... multiple parents, multiple children.. it's almost incestuous!
So long as you can write queries for 'find parents for child x' and
'find children for parent y' it shouldn't matter. If not you'll need
to keep references to parents/childred stored in the objects and that
can be bothersome, but possible.

    >> Now.. you could implement a search interface that finds an
    >> object in context.
    >> 
    >> GetObjectInContextOfParent( context_id, parent_id )

    Chris> might be better if it resolved a path into an object, like
    Chris> Zope does, hence my keenness to see if there isn't a simple
    Chris> way I can make Zope and Zpatterns do the bulk of the work,
    Chris> just with the tweaks I need...

I'm not sure how the path will help you at this point... but if you need
it you can always ask Zope for it once traversal is complete.

    >> Now for the traversal interface:
    >> 
    >> def __bobo_traverse__(self, REQUEST, name): ob = getattr(self,
    >> name, _marker) if ob is _marker: ob =
    >> self.GetObjectInContextOfParent( context_id = name, parent_id =
    >> self.id) if ob is not None: return ob raise 'NotFound' return
    >> ob

    Chris> looks good...

    >> Totally untested of course. ;-) Anyway the idea would be to
    >> *not* use folderish DataSkins, but to build a hierarchy out of
    >> them that could be traversed.

    Chris> Hurm... I'd love them to have a UI identical to normal Zope
    Chris> folders/objectmanagers, though, with properties, a security
    Chris> tab, and, in a dream world, the ability to drop normal DTML
    Chris> methods, python Scripts and the like into the foldersish
    Chris> objects.

    Chris> Is this asking for too much? ;-)

You can never *ask* for too much. ;-) 

Seriously though... for this you'll probably need to store the objects
persistently in the Rack(s), though you could farm some of their
attributes out to other data storage systems with SkinScript. Nothing
will prevent you from making your DataSkins inherit from ObjectManager
or Folder, but you won't be able to completely 'virtualize' them.  The
only way I *think* you could make this work with completely virtual
data-skins is to create 'sister' classes to everything you wanted to
add (e.g. 'SkinDTML Method' and 'SkinPython Script' which would be new
classes that inherit from DataSkin *and* the class you want to emulate
(and probably yet another class that hanldles the interconnection glue
parents/context and all that). Then you'd need to add whatever
attribute providers were necessary to keep all the attributes of the
original classes (e.g., DTML Method) in your external storage. But it
sounds like you just want to keep 'some' of the associated data
in the external source... so I don't think any of that will be
necessary.

good luck!
-steve

    Chris> Chris