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
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