-----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 tsea...@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----- _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )