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

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jim Fulton wrote:
> 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?

+1.  I would also like to be able to break the current
zope.app.publication dependencies within Zope2:

 - ZPublisher.BaseRequest uses zope.app.publication for the
   EndRequestEvent class

 - Products.Five.compuonent likewise uses it for 'IBeginReqeustEvent',
   'IEndRequestEvent', and 'BeforeTraverseEvent'

Can we move those events and their interfaces out into a non-zope.app
package?  E.g., the as-yet-notional zope.publication package you mention
for phase 3?  Or zope.traversing?


There are dependendencies on zope.app.publisher as well:

 - Products.Five.browser.adding uses 'getMenu'.

 - Products.Five.browser's configure.zcm uses IMenuItemType,
   MenuAccessView, and IMenuAccessView.

 - Products.Five.form.metaconfigure uses menuItemDirective.

 - Produts.Five.viewlet.metaconfigure uses viewmeta.

 - Products.Five.fivedirectives uses IBasicResourceInformation.

The first two may be the only real uses of the menu framework you
discuss above.  I would actually like to move Products.Five.viewlet out
into a separate pacakge (five.viewlet), as I don't think there is a core
requirement to support the viewlet machinery.  The last one is trickier:
  that interface likely belongs somewhere like zope.browser.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKPm6s+gerLs4ltQ4RAhNMAJ9g2hxeFOQPrzKlqA97PWLWbALwoQCfeOVy
CqGt2HPjW3AlJMlmu1n0dhM=
=iqvU
-----END PGP SIGNATURE-----