tseaver at palladion
Jun 21, 2009, 10:32 AM
Post #2 of 20
(1564 views)
Permalink
|
|
Re: RFC: ZTK custom publications, zope.app.publication, and zope.traversing
[In reply to]
|
|
-----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
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 [at] zope
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 )
|
