Iwan van der Kleyn wrote: Man do these big overview questions take a lot of time!
* Zope is often criticised for its perceived lack of documentation. Although the current Zope book seems to have improved greatly, I still miss a good reference guide/book on advanded topics (the Development Guide seems to have stuck at version 2.4 and is rather limited). Which book(s) can fullfill this role?
Perhaps. I'm not really sure what fits in the "advanced" category. Most of the stuff you see in Java books is plumbing anyway, and you don't often have to worry about that with Zope.
* Zope seems to lack a dominant development methodology/paradigm. DOT.NET has got form-based ASP.NET/ADO.NET, Java has MVC with Struts/J2EE, PHP has either form-based or MVC with Pear/Smarty.
This point is two different questions. This one is "what application framework should I use?" The other web-dev platforms you mention are very low-level at heart, and these extra layers help avoid the spaghetti that's endemic to that model. Zope is a web app framework, based around object publishing. Objects are model, they usually provide their own views, and object methods and/or glue with Python scripts takes care of the controller part (plus the actual function of the app.) Or you could consider Plone/CMF as a framework (at an evern higher level). It's a great way to go even if you only use the skins tool and the form controller (another way to get the C part of MVC.) Plus you get Archetypes, which is fantastic.
What shoudl I use in Zope? ZTP with Scripts? Or external Methods? ZCLasses? Products?
This one is "where do I do my Zope development?" Use Products to define content and logic, page templates (either from the Product, a skins tool, or the ZODB) to render them, and use page templates and Python scripts (and maybe a form controller) to glue everything together. Forget ZClasses, and look seriously at Archetypes: schema-driven content object creation is a real time-saver.
* Releated to the former question: ASP.NET and PHP (through Pear) excell in easy (fast!) form-based development. What functionality can Zope offer? I've seen some references to a " Formulator" product.
Not really sure what "form-based development" is. Seems to be a term out of the ASP world. If I guess right, Formulator or Archetypes (esp. with "schemata") will do this for you nicely. As to speed, I also do J2EE, and it takes for-blasted-ever compared to Zope.
* Plone seems to be all the rage. But is Plone usable as an application framework? Can I use Plone for form-based, data-driven applications?
That's nice to hear. Plone (or CMF with some Plonish additions) is a first-rate framework, even outside the realm of content-based applications (although if you go too far out you tend to lose some applicability.)
* Thanks to Python's Global Interpreter Lock, Python programs don't scale well on SMP systems. Which is a "must have" in our situation. I' ve found some references to using ZEO to circumvent this, effectively running multiple instances of Zope on one server. Is there any documentation to be found on this subject? And how proven is this solution?
Run a ZEO client for each processor. Probably you have to set a processor affinity. That's all you need to know (besides how to set up ZEO, which is documented in the ZEO docs and a HOWTO or two, and made REALLY easy by Zope 2.7.) As for proven-ness, lots and lots of people do this, both for multi-processor and multi-machine, and both.
* And finally (which makes me come across somowhat like a Troll, sorry about that :-). What is the "life expectancy" of Zope? Most of the hype regarding Zope seems to have died away somewhat. Recently its coming back in the slipstream of Plone. But realistically, what are the chances of Zope being a *relevant* application platform in a couple of years time? WIth "relevant" I mean: a platform which is well supported and keeps up with the compettition on *features*, not necessarilly market share.
Wish my time machine were still working. But I think you can expect Zope and its orbit to make a fine showing in the future. I base that partly on the fact that it's hard to keep up with all the exciting things going on. --jcc