Roman Joost wrote: depends on simpleviewclass and ViewPageTemplatefile from 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 [1] 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.:

  * zope.container
  * zope.componentsite
  * ...

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 engine. This is the part that has the heavy dependencies.

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. has lots of ZCML magic (browser:page, browser:view, browser:resource) and stuff like "simpleviewclass" *shudder* are recurring elements in this code.


-- -- Professional Zope documentation and training
Zope3-dev mailing list

Reply via email to