[Web-SIG] Re: Just lost another one to Rails
faassen at infrae.com
Tue Apr 12 15:53:36 CEST 2005
Peter Hunt wrote:
> In writing a Zope 3 application, for example, one must design objects
> that fit the Zope interface requirements, write a couple of XML
> configuration files to document the object, and figure out the entire
> API all at once.
The requirements for a mimimal Zope 3 application are really not that
big as you make it sound, though the learning curve could be much
> I really want to be able to say that we should all come together to improve
> Zope, the "king" of Python web frameworks . . . but I can't say that. Zope 2
> was a mess, and Zope 3 is so overengineered that it's painful to write code.
I really do not think Zope 3 is "so overengineered that it is painful to
write code". Where did you get this idea from?
The minimal Zope 3 code is a page template and a few lines of ZCML in a
Python package with an empty __init__.py to hook up a new view to an
existing object (say, a folder). There's no Python code *at all*, unless
you count the expressions in the page template that you might write (or
the empty __init__.py).
If you want to add some python methods to the view, that's a simple
class, and a few more lines of ZCML to hook it up.
Writing a simple persistent content object means you need to inherit
from Persistent somewhere and add a few more lines of ZCML registration.
It's obvious from this that Zope 3 doesn't seem to be accessible to
Python programmers as it's supposed to be. I think that's only minimally
a technical issue, largely a documentation and presentation issue, and
in part I think a historical baggage issue.
One issue seems to be that Python programmers are automatically allergic
to domain specific glue languages like ZCML, especially when they look
like XML. I think this attitude is not really reasonable, but it's
extremely widespread. Jim Fulton looked into a Zope 3 based bobo a while
back; something I haven't studied, but might be a way to avoid ZCML for
In addition, I think that integrating into the Zope 3 UI, using macros
and so on, may be a bit too much of a barrier. Even though it's not that
hard, it involves a lot of ZCML here and there before you're fully done.
Often, for a web application, you don't care a whit about integrating
with the existing Zope UI. It should become clear and obvious how to
avoid this. Again, I think mostly a documentation issue, but I think
some technical progress might be made there too.
> The ideal framework should allow the programmer to be organized, while still
> allowing a monkey to write Hello, World.
is a documented hello world package in Zope 3 by the way. It creates a
persistent hello world object that can be added through the Zope 3 UI,
with a page template and the like. It's too verbose as a minimal case;
dumping the UI requirement and some stylistic issues could cut it down a
bit more. If you were to add 'hello world' as a template to an existing
object, it'd be a lot simpler still (cutting away all Python code and
just leaving a ZCML snippet to hook up the template, and the template
It's not monkey-level yet. I think the framework is clean enough to get
there. I think it's very important to reach monkey-level.
Why don't you hop on over and talk to the Zope 3 developers to try to
improve this? Are you sure you're truly dealing with something horribly
overengineered here, something that could not be improved at all? I.e,
were you actually serious when you said this?
> I really want to be able to say that we should all come together to
> improve Zope, the "king" of Python web frameworks
... for you seem to have discarded Zope 3 so easily. No questions on a
Zope 3 mailing list that I can find, for instance...
More information about the Web-SIG