[Pythoncard-users] Re: ZODB Persistence

Let me clarify my need. It may not conflict at all with what Patrick 
is saying about using MetaKit (which I found wanting because it is 
not a pure OODBMS which, in my experience, means we're going to slam 
into some serious brick walls as object complexity grows).

I'm not sure I really care of ZODB is the native PythonCard data 
model. What I need is the ability to interact with a ZODB. More 
specifically, I need to craft PythonCard apps that retrieve data from 
and write data back to Zope. I've long since standardized on Zope as 
my app and content management framework and I have zero interest in 
changing that at this point. I have created a number of sites for 
friends and clients in Zope and we now want to create app-style 
interfaces to get at the data stored there. For me, then, PythonCard 
in that set of apps becomes a UI toolkit with smarts that lets me do 
things the browser won't.

Kevin says this is more like screen scraping than object storage. OK. 
Whatever I call it, it's what I want.

So if my app needs to create _new_ objects that aren't part of the 
data my clients need for their apps, I don't care if we store it as 
lightwaves in a cube as long as it persists and as long as the 
persistence mechanism is transparent to me as a PythonCard user (by 
which I mean scripter).

I have not yet had time to investigate the matter fully but it seems 
to me likely that getting PythonCard to interact with Zope data ought 
to be a walk in the park since Zope is Python native. And since I 
don't need a standlone ZODB for my purposes, the issues associated 
with that are also irrelevant.

In the end, I think what I'm saying is that my app needs call for me 
to create perhaps some PythonCard components and pre-built apps that 
are Zope-aware and be done with it. Can't be that hard, right? Right. 
SMS (Simple Matter of Software).
-- 
Dan Shafer, Personal Creativity Trainer and Consultant
Trained Hartman Value Profile Analyst
http://www.danshafer.com/valueprofile.html