But Paul's cautionary articles are very much to the point. Even as the Zope development community is pushing the envelope with version 3, most JPPs don't know what version 2 can do. His mission is to help them break the ice. More power to you, Paul. [Jon Udell]
Something I hope (and doubt) I'll have time to do in the near future is the ability to document my experiences writing a totally custom Zope 2 based application for a customer written with a Zope 3 "Component Architecture" mentality. We were contracted to do a Project Approver project that I initially thought would be a good match for the CMF, but speed issues and budget issues (deprogramming the CMF down to the minimal requirements allowed by the customer's latest budget would have taken too long) required going a different route. And we wanted to stay away from SQL storage requirements. But doing Zope 2 "products" is known to be a difficult process sometimes. What we came up with, however, is a simple system where the content classes, like many CMF and Zope 3 classes, were very simple and responsible for their jobs only - no ZMI weaves, no disk based Page Templates or DTML (for better or worse). The project was done on schedule, even though the customer threw a major requirements change in our face at our first milestone meeting. So what we have is a flexible and extensible object oriented architecture where data we would traditionally put into a relational database is in the object database, where we ultimately have more control over the data. And we have a base that should be able to move over to Zope 3 easily. And again, I hope to have time to write this up in the near future. It could help the so-called JPP, particularly those who come from more of an object background (Servlets, etc) than a scripting-language-in-html-plus-sql background (PHP, etc), see how to make flexible persistent business objects in Zope 2 in a way that should help them move to Zope 3.