Zope is great, but there are some things that
are seriously annoying. Much of it comes from things showing their age.
There is lots of code that does things in particular and complicated ways
because of the need to behave the way things have always behaved, even if
that no longer makes much sense. Also, CMF has a couple of basic design
flaws, the biggest of them being portal_skins. So in this way, Zope3 will be
very welcome, as it rewrites things from the start, and does thing The Right
But there is one thing that is not going to automatically be solved with
Zope 3: Peoples tendency in the Zope community to first of all do things
their own way, and secondly, not move these "own ways" into the common code
base, even if they could be of use to others.
I was hit by one of the more typical examples of this today: I need to have
permissions that i check dynamically. Usually in Zope, you protect methods
or objects with permissions, using the
"security.declareProtected(permission_name, method_name)" call. But
sometimes, which permission you want to check is dynamic. This is quite
possible to do, but first you then need the permission to exist, so you can
set up a role to permission mapping, and then check for the permission based
on what roles the user has.
And, it turns out, Zope has no method for creating permissions that are not
connected to a method or object or a class. I tried various ways and looked
through the code, and found nothing. I turned to Florent, and he pointed out
that there is a method to do this. In CMF....
CMF is, just like Zope, created and maintained by Zope Corp. And still,
this method, that belongs somewhere in the AccessControl module, is located
in CMFCore, where is has no business at all.
The examples of are numerous. The fact that most people use DCWorkflow as
the workflow with CMF wasn't reflected until recently, when CMF 1.5 came
out, and finally included DCWorkflow. And after much nagging (mostly from us
here at Nuxeo) Zope corp decided to include Stefan H Holeks excellent
ZopeTestCase product in Zope 2.8, so that is no longer is a pain in the ass
to write unit tests for Zope. Another good example are the almost infinite
number of user folders that exist. Only last year did Zope corp update come
up with a new user folder, instead of the default (and pretty much useless)
user folder. The new user folder is PAS, a pluggable, extensible user
And, if you expect it to be included in 2.8....ha! No, it's a separate
product. Of course. Meaning that every time somebody needs to use it, they
need to send an email to the Zope list and ask which of the different
extensible user folders they are supposed to use, since they found at least
4 of the when googling...
This all means that when you use Zope, you have to look all over the place
for the little thing that does what you want. There is no coherence, just a
sprawling spaghetti, and this in turn has the effect that the learning curve
for Zope never ends.
I don't know how to make sure this doesn't happen for Zope3, I guess we all
have to just make an extra effort to identify the things that are useful to
all, and make sure they end up in a place where everybody can find and use
them. codespeak.net has a z3-base
which is one effort to have a place for the things that are useful for many,
but shouldn't be in Zope3 itself. Having a place like that from the start
will at least help a bit. But the rest is up to us.
(Post originally written by Lennart Regebro on the old Nuxeo blogs.)