Ron Bickers wrote:
Using Zope we knew that we would reach situations which may be unresolvable in the short term, and could not make significant business decisions with so many unknown factors and lack of any way to circumvent problems.
What in the world does that mean?!? Maybe it should read "We don't know how to use Zope or code in Python."
I can give you a personal example. When I was trying to get LoginManager to display it's stored users in the local roles security form, I couldn't fix it using what I knew, which was DTML and ZClasses. I had asked for help on the lists, and got some pointers in the general direction, but that was all. After a week of crawling around in Zope's source (and a lot of whining), I found the parts I needed to duplicate for PersistentUserSource.py, and I added them. It should not have taken me a week, except that I don't really consider myself a coder. The only thing that made it possible at all was my extensive experience *using* zope, and my familiarity with Tracebacks and a basic understanding of most of Zope's underlying mechanisms. If I had been a real Zope/Python coder, I probably would have figured it out in a day. However, for a programmer who had to come into the Zope environment 'cold', the problem would likely have seemed intractable. They wouldn't have even known where to look, and the fact that LoginManager is not an 'official' core Zope product could have been a show-stopper. (Why did I have to use LoginManager, you ask? Membership requires it, and I needed to store user data in the ZODB about NT authenticated users on a Solaris box. Gah). So the problem, as I see it, is multiple dependencies that may not be obvious. While over the long term, factoring common functionality into separate products that other products depend on makes more sense, and creates a *much* more powerful framework, in the interim (waiting for things to jell) it can frustrating as all get-out, and pretty easy to get stuck. Conversely, that things about Zope that are relatively mature are a dream to use and leverage, so this is an acceptable trade-off for me. Cheers, Michael Bernstein.