Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Zope comments

 [1/1] 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
<<quoted lines omitted: 3>>
> 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 there. 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" http://www.librelogiciel.com/software/ 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. - Jason

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted