[Zope3-Users] Direct ZODB access in a Zope3 instance

[Duncan McGreggor]

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

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 
enabling/disabling features.

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 
questions like:
* 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 
>> content
>
> 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 
z3 project.

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

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 
is:
   http://mail.zope.org/pipermail/zope3-users/2005-September/001078.html

Here's a thread for making a folder a site:
   http://mail.zope.org/pipermail/zope3-users/2005-May/000548.html

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

d