[REBOL] Zope comments
From: jason::cunliffe::verizon::net at: 13-Jan-2004 13:50
From: "Petr Krenzelok" <[petr--krenzelok--trz--cz]>
> It is just two weeks one of my friends visited me to help me to install
> Fedora server. He brought two books with him - Cocoon and Zope. Zope
> seems to be interesting, he showed me how he used some module for
> digital photo catalogue. Nice, but really nothing what could not be done
> in IOS in a MUCH clearer way, at least to me. He admitted, that Zope is
> nice even for beginners, but once you decide to modify some unsupported
> functionality, you have to go deep python.
Zope is very easy to use for fast turn-key installation. Amazing what's in
Be warned, all the books on Zope are already out of date, though do give
some helpful overview.
Zope development moves pretty fast. When we were developing with it four
years ago we found the simplest was simply to bypass the complex Zope
framework and develop external python scripts for Zope. Basically just
single nice readable Python script with a few critical calls into the Zope
architecture. Worked beautifully, thanks to the fact that Zope invites many
ways of working. There are many Zope products - plugin extensions, but they
are almost all individual experiments which people have generously shared.
Most of the time people just them as-is or adapt in small ways. The result
can be quite a spaghetti of versions and documentation to sort through. The
most popular ones are far better documented with plenty examples and people
who can help.
One of the best kept secrets about Zope is Jerome Alet's "ZShell"
ZShell : Manipulate the Zope Object DataBase with Unix shell like commands
Fascinating , with ZShell, instead of the struggling manually with boring
gui interface, or the deep syntax of Zope OO namespace, how it suddenly can
become so simple to program Zope. Jerome developed this very familiar
concise little tool to sit on top of this enormous framework with nasty
syntax. In the process effectively changed the paradigm by combingin old and
new in an obvious way, but which had not been obvious to others :-) Also
interesting to note that one of Zope's most enticing and clever paradigm --
'acquisition' -- has proved to be difficult to work with.
Ironic because it's the innovative Zope features everyone falls in love
with. But it can be brain-twister in practice. 'Acquisition' provides a
url-like path syntax where objects inherit methods and properties by
searching up the tree of their parents till they find the first match. Then
apply that. Its a brilliant idea. But after years of work, I believe the new
Zope3 now being written is to fresh code and component-based architecture. I
am not surprised they changed, but always believed Acquisition was such a
different paradigm that it really needed a different kind of interface to
manage it. And that never happened. An interactive map for example. But core
Zope developers seem to be non-visual creatures.
> Reblets seem to be really
> better aproach to me. But of course - once you want your "output device"
> to be web (html), not a View/IOS client, you are in trouble a bit.
Yes the interoperability issue again.