I'm trying to make the Zope Toolkit (ZTK) publisher/publication
framework a little easier to deal with. I think zope.app.publication
mostly provides a generally useful publication implementation. It has
- Its getApplication method digs a particular object out of a ZODB
database. Some people would like
the flexibility of not using ZODB.
- It aggressively proxies objects using
zope.security.checker.ProxyFactory. Some people don't want
to use proxies and those that do might want to use a different
proxy or checker implementation.
It was already possible for a subclass to override getApplication
fairly cleanly. (This also entailed overridding __init__ in a pretty
I made it possible to override proxying by overriding the proxy
method. At this point, I think zope.app.publication provides a pretty
reasonable base class for custom publication implementations, although
the module arrangement could be made a bit simpler.
In working on this, I've found the implementation and tests of
zope.app.publication to be split between zope.app.publication and
zope.traversing. I want to sort this out, but I'm not certain what
the intent if zope.traversing is. I think the intent has become
muddled over time, if it was ever clear in the first place. :)
Early on, we mixed up ZPT path traversal and URL traversal. These are
similar, but different. There are features you want in ZPT traversal,
like the resource namespace that you don't want in URL traversal.
Similarly, you want features like virtual host support and default
pages in URL traversal but not in ZPT traversal.
Early on, we used path traversal in many places, not just ZPT, which
is probably why most of the code in zope.traversing isn't in zope ZPT-
Early on, we decided that the menu framework should be able to filter
menu items based on whether the user could traverse to an item. On
some level, this was reasonable because it made menu specifications
simpler, but it adds great expense and complexity. I'm not sure
anyone in the know uses the menu framework anymore. If they are and
aren't specifying permissions on their menu items, they are being
helped to do the wrong thing.
Originally, zope.app.publication defined a base class,
PublicationTraverse, that provided traverseName. Even though I may
have done this, I don't know why this was broken out into a separate
base class. I don't think anyone else is subclassing this, but I
I propose the following:
In phase 1 reduce the scope of zope.traversing:
- Move path traversal code to zope.tales
- Move the URL traversal code used by zope.app.publisher.menu to
zope.app.publisher.menu. Refactor it to use the request.publication.
Deprecate definition of menu items without permissions.
- Move the virtual host and skin tests from zope.traversing to
The only things left, I think will be the namespace framework and the
absolute-url support. (Both of these could use more thought, but I've
used up my thinking budget for this morning. :)
In phase 2, simplify the class tree in zope.app.publication
Merge zopepublication, http, browser, and xmlrpc. traverse using
request.method when request,method isn't one of GET, HEAD, or POST.
Maybe in phase 3:
- Create zope.publication from zope.app.publcatiobn
- use webtest rather than zope.app.testing.
- Maybe provide a paste deployment mechanism for easily assembling
publisher-based appls based on prototype work I'm doing in
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -