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 2 problems: - 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 simple way.) 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- related package. 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 don't know. 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 zope.app.publication. 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 zc.publication. Thoughts? Jim -- Jim Fulton Zope Corporation