[Grok-dev] ZTK and zopeapp
faassen at startifact.com
Wed Dec 30 10:51:42 EST 2009
Paul Wilson wrote:
> 2009/12/30 Souheil CHELFOUH <trollfot at gmail.com>:
>> I would love to be able to ditch zope.app out of grok. This can be
>> used by extensions libraries, but, Grok itself has no reason to use
>> it, according to me.
>> We need, of course, to provide alternatives, especially for advanced
>> features, like authentication, etc.
>> In Dolmen, I try to avoid the use of zope.app also. I'm not sure what
>> needs to be done for Grok 1.1 though.
>> What decision is needed ? What do we need to do ?
> Can someone explain what's wrong with zope.app.*. I know people are
> going to great lengths to remove it... but why? What's the history?
I'll try to give a sketch of what's going on:
When Zope 3 developed, we had a general rule that was something like this:
* zope.* will contain packages that are more generally reusable in other
* zope.app.* will contain things specific to Zope 3 "the application
server", which was to be the equivalent of the Zope 2 app server. I.e.
it can be started, has a specific configuration, includes a user
interface (the Zope 3 ZMI).
It was hard to strictly follow this rule as it wasn't always easy to
figure out what went were. Over time we also relaxed the rule and zope.*
started to contain code that did depend on more publisher-specific stuff
in zope.app, like zope.formlib.
Until 2007, all these packages were developed and tested together. This
meant that all packages within Zope 3 could easily depend on each other
in all kinds of different ways.
In 2007, we exploded Zope 3 into separately distributed libraries. The
advantage of that is that these libraries can more easily be
independently reused, and that we can more easily provide updates to
specific libraries without having to update all of them at the same time.
Another advantage of the "explosion" is that it made the dependency
structures between our packages clearer. It turned out that most
packages, also those intended to be reusable, would pull in almost all
other packages if you depended on them, through a complex dependency
relationship. That makes such packages less than reusable, and hard to
understand ("why does it need 50 packages just to do forms?"). It's also
a potential security risk to ship a lot of code that you don't really
need but that is still there and activated. And a performance drain on
startup loading all that ZCML.
The community also had more or less given up on the Zope 3 ZMI at the
time; nobody as really using it. Still we were including lots of code
that supplies the ZMI, and some content objects that never really took
off, such as, say, ZPTPage.
The role of the Zope libraries had also changed since it started: Zope 3
is not used only as an application framework, but also as part of other
systems, such as Zope 2 and Grok. Both Zope 2 and Grok have no real use
for the ZMI at all.
So now Zope 2 and Grok were shipping with a ton of code that wasn't
really used by these systems.
Early 2009, some things happened to reflect this changed role:
* we decided to refocus our efforts from the big Zope 3 to the libraries
we all share, the Zope Toolkit. Zope 3 is just one user of the Zope Toolkit.
* we made a huge amount of progress cleaning up dependencies between the
One strategy to clean up dependencies has been to mine zope.app.* for
code that is more reusable, leaving old stuff like the ZMI behind in
zope.app.* (zope.container versus zope.app.container is one such
example. zope.app.container only contains ZMI stuff now).
So now "zope.app.*" is seen as a whole lot of old stuff that we don't
really need for Grok. If we can make Grok not use all the zope.app.*
stuff anymore, Grok will have a *lot* fewer dependencies. The
dependencies that we do have will have a clearer role. We can stop
worrying about all that code that we mostly weren't using in the first
place, and worry better about the code that we *do* use.
I'm not saying that nothing useful is left in zope.app.*: zope.app.form
is an example that we use if we use zope.formlib. There is probably
other stuff. We'll find out as we try to make Grok use less of
zope.app.*. We'll need to decide on a case-by-case basis whether we want
to salvage code from zope.app.* or whether we can cut the dependency
Does that help?
More information about the Grok-dev