So this style of Zope 3 development involves not using
ZODB so much for permanent storage, but instead as a
temporary scaffolding on which to hang the current version
of class instances and their content. When you refactor
your classes and interfaces, you just re-instantiate everything
into the ZODB to recreate the site.


For development, yes.


It sounds great, except not all data can be simply regenerated.
For stuff like port numbers and configuration, fine, it can be
in ZCML or embedded in Python scripts.  But the site content
generated by end users has to be stored somewhere, too,.
If you throw away your ZODB and regenerate it, what happens
to that data? Does your regeneration script transfer
all that data to the newly generated ZODB?

While you're developing, it's much easier because the *content* in your ZODB doesn't typically have any value during development. If it does have value during development, you have a development model that's not similar to mine.

But obviously, after you go into production, the content does have value, and preserving this value is the purpose of GenericSetup for Zope 2. It's a "dump and reload" solution which allows you to create a represention of your ZODB data and its associated hierarchy as files on a filesystem. You can basically push a button to dump the data in your ZODB ro files, and then create a new ZODB, instantiate the tool, and push a button to reload it. Zope 3's "filesystem synchronization" capability is similar in concept, although I don't know if that has been maintained recently.

I'd be interested in seeing the particulars of how
you guys do that stuff.

I do it all the time for customer jobs and there are examples in CMF for Zope 2 (e.g. the "SiteGenerator") but I don't have any code that uses Zope 3 that does site generation.

I've yet to run across a direct
mention of how to create an arbitrary ZODB and
start reading and writing objects. That seems to
be a big piece missing from my understanding
of how to work with Zope 3. Every ZODB example
I've seen in the books seems to involve creating a content
object that can be added via the ZMI.  However, I'm
not finished with either book, and I have very likely
missed something.

There are tons of examples about how to access ZODB data outside of the context of Zope around, do a little googling. The thing that might make it a little mindbending is that "accessing data in ZODB" is just.. Python. You open the database, get the root Zope object, and then traverse to an object in the database (usually via getattr or getitem or whatever the folder API is) and call methods on it or read attributes from it or whatever. There's really not much to it. It's largely the same as writing code in your content classes, but you can do it from a Python prompt. Zope 2 has "zopectl debug" which dumps you off at a Python prompt with the name "app" built in to the root Zope object.

Note that this is not particular to any version of Zope. Zope is just a consumer of ZODB, and the issues are the same no matter what consumer of ZODB you're using.

- C

_______________________________________________
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Reply via email to