[Zope-dev] RFC: ZTK custom publications, zope.app.publication, and zope.traversing

[Jim Fulton]

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