Duncan McGreggor <[EMAIL PROTECTED]>
It sounds like a pain, and to be honest, at first it is a bit
arduous. Not only does it get faster and become second nature, but
chunks of it can be generalized and reused. It really doesn't take
that long to get accustomed to it. And once you start doing it
regularly, you gain a tremendous amount. Not just in the mere
knowledge acquired, either... there's a subtle shift in your
programming where you give extra attention to the
data-generating/-populating code, which in turn makes you architect
your information better ahd brings higher overall levels of
organization to your project.
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.
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?
I'd be interested in seeing the particulars of how
you guys do that stuff. 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
Zope3-users mailing list