[Zope3-Users] Direct ZODB access in a Zope3 instance
duncan.mcgreggor at gmail.com
Wed Nov 30 19:01:35 EST 2005
On Nov 30, 2005, at 3:07 PM, Brad Allen wrote:
> Ok, so using the app/server framework to read and write from ZODB is
> the way to go. I'm trying to understand exactly how that works. The
> books show how to register components using ZCML, but that doesn't
> create instances, right? As far as I can remember seeing, a human has
> to click something in the ZMI Add menu to create an instance in the
About ZCML: it's kinda hard to get used to. I hated it at first. But it
makes more sense that most other ways of doing things... the problem is
that we've gotten used to mixing configuration and code. ZCML is the
quiet hero in this regard: it gives us the long-needed tool to separate
configuration from application. And if you think about it, this really
makes the most sense. If you've got a hundred clients that want to use
your product, each of those clients should only have to change
configurations, not the actual code itself.
Additionally, I really like the clean approach that z3 has as a result
of ZCML: if you haven't configured it, you aren't going to see it/use
it (as an end-user, I mean). This appeals to the security engineer in
me ;-) It also makes things wonderfully simple as far as
Back to your question: ZCML doesn't actually do anything -- z3 looks at
it to "know" what to do. So, in order for z3 to know about content
objects, custom views, resources like images, etc., you have to put it
in ZCML (well, for some things you can put it in python, too).
As far as the ZMI is concerned, there are entries you need to make in
your configuration files that tell z3 to (for instance) have a custom
content object appear in the "Add" menu. If you have made that entry in
your ZCML file(s), users will be able to click something in the ZMI,
and a content instance will be created.
ZCML is confusing at first because of the many features and the
conceptually different aspects of application configuration for which
it is responsible. To keep all of these straight, I ask myself
* is this part of my code just purely content object?
* is this part application internals?
* is this part management UI related?
* is this part content presentation?
* is this part just look at feel (page structure and CSS)?
I tend to put each of those in their own areas or sub areas (read
"directories"). They each have different ZCML files; a top-level ZCML
file includes the ones from the next level down, etc. The best way to
come to term with this stuff (in my mind) is to jump in and start using
it, even if it doesn't make sense at first. Much will be revealed
simply trough the doing of it.
BTW, As a result of practices such as these, the z3 projects I have
worked on have been the conceptually best organized projects I've ever
been a part of.
> Meanwhile, the chapter in Philikon's book on persistence just shows
> how to create persistent classes and talks about how they work, but it
> doesn't say anything about how to insert an instance into ZODB.
It's done for you "automatically" -- when you click "add my page" on
the ZMI menu (given that you have a content object called "my page"),
it is inserted into the ZODB.
>> 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
> How do I actually get a handle to an object in the ZODB, so I can
> manipulate attributes?
z3 utilizes a component-based approach - both in the way that it was
built and in the way that applications are built using it. To "get a
hold" of certain components, you use various useful functions that are
provided in the zapi (many of which come from the components package).
One of the most common ways of getting a hold of an object or object
type is by interface lookup.
So, if you want to create something, you'll need a context for that
object's creation. Quite frequently, that context will be a site. There
are many ways to do this, and it depends on how you have designed your
I'm not being deliberately obtuse ;-) This is the point where you need
to look at sample code, or pour over book chapters. I would like to
post some of the code that I've done that's related to the topic, but
most of it is very special-case... and it assumes fairly detailed z3
What we really need for discussions like this is some nice demo code...
does anyone have something like that? I know Gary Poster emailed the
list with some best practices for getting a site and adding a catalog
to it. But, IIRC it was not code (maybe some pseudo code?). Ah, here it
Here's a thread for making a folder a site:
It might be worth the effort to start up a peer-review thread here that
demos a simple site build, pre-populating with some simple content.
That would be a fantastic resource for folks. Hmmm. In fact, it might
be a good idea to do another z3project_starter script that included
code like that...
You're going to want to read up on interfaces, component-based design,
z3 utilities, and subscribers. And there's lots of super smart dudes on
the mail list that know this stuff inside and out who can assist as
your getting your head around this stuff.
It's totally worth the effort. I've used tons of web frameworks, and as
far as I am concerned, this one (z3) takes the cake. IMO,
component-based development is the only way to fly ;-)
More information about the Zope3-users