[Web-SIG] Re: Just lost another one to Rails

[Martijn Faassen]

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 
improved still.

[snip]

>  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 
some projects.

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.

This:

http://svn.zope.org/Zope3/trunk/src/zope/app/demo/hellopackage/

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 
itself).

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...

Regards,

Martijn