Steve Spicklemire wrote:
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.
Cool... how would I go about doing that?
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'.
Ah, yes, now I see, in my case, as with the ZODB, the unique id would be the path from the specialist/FwCS to the DataSkin in question, ending in the dataskin's ID, I think :-S The difference is that, because of the multiple parents thing, unique id -> dataskin isn't a one to one mapping. many unique id's map onto one dataskin. I suppose that means the _actual_ unique id for the dataskin needs to be a unique integer number or some such. But I guess the user would never need to be exposed to that? Does strike me that this is all redo-ing Zope's traversal stuff, which is why I'm trying to find a better way... wagh! My head hurts :-S
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...
I think id would be better, because it's closest to Zope's notion of id, the bit that goesi nto the Rack probably wants to be called 'unique idenitifier' or maybe even 'path' depending on what gets used :-S
Wow... multiple parents, multiple children.. it's almost incestuous!
inbred objects, now there's a concept ;-)
So long as you can write queries for 'find parents for child x' and 'find children for parent y' it shouldn't matter.
cool...
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. ;-)
But then what happens if I ask how to do it?
Seriously though... for this you'll probably need to store the objects persistently in the Rack(s),
Why?
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.
Well, that may not be a problem. The important thing is that if someone creates a record in a.n.other system, then one of these 'virtual' objects automatically appears in the Zope side of things... reckon that's not too hard?
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.
Why would the sister classes be needed? Anyway, how do I break this down into small beginner sized steps and start doing it? thanks for all your help, Chris