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 _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
