[Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances

[Pjotr Prins]

Hi Jim & Martijn,

For xParrot we have a case in point where the ZMI both helped and
confused us. Because of the way the documentation is 'framed' (where
available) it lead us to believe, initially, that ZOPE was the ZMI.
The first incarnation of xParrot (an XML/XSLT provider) was
intermingled with the ZMI. The next version two was mostly about
driving the ZMI out of the equation. The OFS (if I understand
correctly we are referring to the file/object representation of ZOPE)
is still very valuable for reaching resources. In fact xParrot2 does
not use the ZMI at all now but would not be what it was without the
OFS.

On the other hand for another project I use the ZMI and the Rotterdam
skin to develop faster - providing a useful tree interface. The tree
is key here. It is obvious reflection/inspection etc. are quite useful
too, during development.

I would suggest to accentuate the library side of ZOPE and provide the
ZMI as a (lesser) example. For ZOPE3 to replace ZOPE2 a new
application engine may be an idea. A powerful engine that is better
than Rails - with some code generation - should be an enticing goal
for some. Because, take it or leave it, programming with ZOPE is
still (too) hard.

I learnt Ruby on Rails in a few days. With ZOPE3 I often still am in
the dire straights (after a year). We use ZOPE3 because of the
superior component model and because it looked better for xParrot, at
the time. And in fact, we have no regrets there as Andrew designed
xParrot so it can be used without any understanding of Python/ZOPE
now. So, there you have one great application without the ZMI.

Let me wrap up saying that despite my criticisms I think you all did a
great job. The stability and robustness of ZOPE3 is legendary.
Deployment is a bit odd, but one gets used to that (I agree about the
duplication - but then that is configuration too, it is not that bad).

A strong 2007 wished for.

Pj.