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
missed something.
Zope3-users mailing list

Reply via email to