Jeremy Hylton : weblog : 2003-06-21

Zope3 Tutorial

Saturday, June 21, 2003

I took the Zope3 tutorial by myself today. It is coming along nicely, but still not ready for the home schooler. There are a bunch of bugs in the code in CVS and in the slides that make it difficult to make progress without an expert at hand.

I've taken the tutorial before, but probably not in about a year. It was a helpful refresher.

Programmer Tutorial

The code in CVS doesn't match the code in the slides. One example so far: The contact configure.zcml in CVS specifies a permission, but the slides don't. As a result, I burned an hour trying to figure out what was going wrong. (In part, my own fault for doing the tutorial on my own instead of having Jim teach it.)

I ended up having the same problem with the manage content permission, which lead to a separate problem -- component lookup error. The type showed up in the add menu, but I got the error after I chose a name for it. It wasn't obvious why a component lookup error would occur adding something.

There seem to be some capitalization problems. The README.txt, slides, and code differ about what to capitalize. It shouldn't matter, but since it does, it ought to be convenient.

The slides tend to move a bit quickly. I'm sure Jim explains more and demonstrates what happens when he gives the tutorial.

Step2 says it is about security assertions, but it seems to be more about views that an about security. Or maybe it isn't about views. It shows the, but doesn't seem to wire it up. What is it for?

In Step3, we create a new, so I'm not sure what the point was. I don't know what went wrong here, but I can't get the contact to show up in the add menu. It doesn't require a permission; I checked by adding a print in the global menu service thingy. I can add it manually by passing the type_name to @@contents.html. Good enough for 11pm.

Note: It looks like the browser menu action attribute is a name in the namespace of factory ids. In most menus, the action is a relative URL. The adding code knows to interpret it as a factory name if it isn't a view name.

While Step3 didn't work, Step4 did. Go figure.


The configuration code is simpler than the last time I looked at it. I wanted to verify that my contact config was getting loaded. The Contact object wasn't showing up in the add menu, but I wasn't sure why.

The XMLConfig class provides the basic machinery. Unfortunately, it doesn't have any comments or docstrings. The _include() method is called for each file, so a print there confirms that the config is getting loaded. (Ought to have a debug log call there.)

The actual files are parsed using SAX. The ConfigurationHandler class handles the data as it is processed. It accumulates configuration directives into __actions, which is a container passed in by the caller. The caller gets the results by virtue of side-effects on the container. (Not the clearest way to right that code; definitely deserves a comment.)

The handler looks up directives in a registry to find the method/function that should be called. The caller has the loop that actually defines the call.

It's still hard to find the code that handles the individual directives. XXX

User interface

>From the @@contents.html page, click on a content type to add. A new page is loaded with a text box to enter the name of the type, but there is no indication of what type. If you clicked the wrong thing, you'd never know. One solution would be to show the same menu with the selection highlighted.

The security grants page doesn't provide a way to get back to the rest of the management UI.


All lot of my early trouble had to do with security problems. When they occur, they don't seem to leave any trace. There's no logging or error message to indicate that something went wrong because of a permissions problem. In a production site, that might be the right thing. (By default, don't reveal too much information by announcing missing permissions.) But it makes it very difficult to developer or debug.

It might be interesting to have a special debug mode where you get to see all the permissions that were used to allow something to happen.


Slide 14: "Specify the interface of the container adding component." What does that mean?

When you're making something internationalize-able, you add an attribute i18n:translate=""? Are the quotes just for syntactic completeness? That is, is the mere presence of the attribute sufficient to mark it.