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:

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


Zope3-users mailing list

Reply via email to