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. 


>     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),


> 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,


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

Reply via email to