On Nov 29, 2005, at 10:57 PM, Brad Allen wrote:

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.

Like Chris said, a qualified "yes" -- i.e., during development. For a production alternative, he pointed to the generations tool. I haven't had a need to use it yet, but I've heard folks talking about it.

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.

I have several sites with base content that is pre-populated from python scripts and external files.

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?

Whenever I am told by client that they want me to build an application for them, and they want to be able to add data/content while I do it, I either gently educate them on the proven process that we use, or I walk away from the project. Maintaining content during development is almost always a nightmare. There are tools to use to enable this... approach... but in my mind (and many others') it's just not a good way to do development.

To come a little closer to answering your question, the only time that I have ever needed this kind of thing is on projects where we were delivering a product to multiple clients, pre-populated with default content. All of that content was added via python.

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.

As soon as you create an instance of a content object, you've written to the ZODB. Whenever you render a page that presents a content object, you've read from the ZODB. z3 "protects" the developer from the ZODB. You never have to do direct reads/writes. You're simply operating within a z3 "app"...

As for particulars, there are several emails in the archives for this list that detail z3 site setups. Even better, there are examples in the wild. IIRC, the cubic project had an example for this, and the "worldcookery" demo site might too. I'd certainly check out schooltool to see what they have done. Code-based site creation/setup/configuration will provide you with lots of ideas, hands-on examples, and a good sense of how to approach this.

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.

Yeah, I think you're looking for code-based content addition -- is that right? If so, you're going to want to spend some time looking at zope.app.zapi (a lot of which comes from zope.component). In particular, the createObject() function. Take a look at those projects I mentioned above... and other folks may have good suggestions for code examples on site creation and pre-population of content.

Hang in there ;-)


Zope3-users mailing list

Reply via email to