On Thu, 2003-11-27 at 15:54, Iwan van der Kleyn wrote:

* Zope is often criticised for its perceived lack of documentation.

IMO, that's still a problem, despite some outstanding efforts.

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?

None that I'm aware of... in English, anyway. If you speak German or French, there may be other resources available to you.

* Zope seems to lack a dominant development methodology/paradigm.

There is no framework for Zope because Zope *is* a framework.

What shoudl I use in Zope? ZTP with Scripts? Or external Methods? ZCLasses? Products?

Skip ZClasses, first off. You'll probably do best to prototype with scripts/external methods and migrate to products. Whatever you use for logic, you'll be using templating (ZPT/DTML) throughout.

* 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.

With Zope, you can instantiate and configure objects entirely through the web. File system access is required to *extend* Zope with new products, but most development *is* rapid *and* form-based.

* 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?

Plone excels as a CMS. Plone might provide a *part* of a serious data-driven app, but you'll want to do most of the logic in plain Zope.

* And finally (which makes me come across somowhat like a Troll, sorry about that :-). What is the "life expectancy" of Zope?

Good question. What's the life expectancy of Python? Of web browsers?

Most of the hype regarding Zope seems to have died away somewhat.

Perhaps true. But I'll take *success* over *hype* any day. :-)

Recently its coming back in the slipstream of Plone.

Less cynically, you could say that Plone is the first well-deployed application to leverage Zope's power. It often takes years for platform technologies to spawn their killer apps.

But realistically, what are the chances of Zope being a *relevant* application platform in a couple of years time?

Zope has a solid corporate parent, strong ongoing development efforts, a vibrant user community, commercial support, hosting companies, service providers, and open source licensing. That which Zope lacks in two years could be created by any number of parties, including you. We don't have the raw numbers of PHP or Java. That means fewer books and sparser docs. But IMO the tool is good enough to justify the extra effort. Once you get the hang of a few idioms, the rest falls into place pretty easily and you stop missing the docs so much.

WIth "relevant" I mean: a platform which is well supported and keeps up with the compettition on *features*, not necessarilly market share.

Zope 3 may be of particular interest to you. It's a significant step toward maintaining long-term usefulness and relevance. It's not production-ready yet, but is far enough along you may wish to factor it into your long-term planning. Obviously, I'm a partisan, trying to be helpful anyway... :-) HTH, Dylan

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