Roman Joost wrote:
viewlet.py depends on simpleviewclass and ViewPageTemplatefile from
zope.app.pagetemplate. The dependency of simpleviewclass can easily be
factored out to zope.pagetemplate.
The problem is ViewPageTemplatefile which derives from TrustedAppPt. It
depends in turn on six or seven more classes. Moving these to
zope.pagetemplate could raise some other problems I didn't think of.
So, question is: what to do?
In  I came to the following conclusion:
There are several packages that do two things. One one hand they define
concepts (IContained, ISite, etc.) and a little bit of machinery
(contained(), getSite(), etc.) to deal with these concepts. On the other
hand they also provide full-fledged implementations. Those
implementations are the ones that end up introducing lots of
dependencies (because they involve security, events, persistency, etc. etc.)
Perhaps it makes sense to factor the *concepts* and the light-weight
helpers (contained(), getSite(), etc.) out to separate packages, e.g.:
Now back to zope.viewlet. It provides two things:
1. a generic definition of viewlet interfaces and a light-weight
implmentation for a viewlet manager and a light-weight base class for
viewlets. This is the part that has no dependencies other than on
zope.contentprovider, zope.interface and zope.component.
2. a bunch of ZCML directives that allow you to dynamically create
viewlet using a Page Template that runs with the
zope.app.pagetemplate.TrustedAppPT engine. This is the part that has the
If people needed #1 without #2 (e.g. in Zope 2 we might), then it makes
sense separating the two. However, for zope.viewlet I don't think it's
worth the effort, unless we actually grouped all of the ZCML stuff
together in one package. zope.app.publisher.browser has lots of ZCML
magic (browser:page, browser:view, browser:resource) and stuff like
"simpleviewclass" *shudder* are recurring elements in this code.
http://worldcookery.com -- Professional Zope documentation and training
Zope3-dev mailing list