Jimbo, I concur 100%.

I am a Zope newbie (relatively speaking - since February) but I have been
developing Web Information Systems since '95.  My tool of choice was
perl/CGI.  I attended a DEVX conference in December of '99 and was
introduced to Java Servlets and the J2EE spec.  I knew this was the
transition that I had to make, professionally.  However, 100% of my work
evolves around information management and publishing.  J2EE doesn't
immediately solve this requirement without a great deal of tooling. I saw
the benefits of the enterprise but couldn't justify the effort (to my

In walks Zope and the lights/whistles/fireworks went off.  Zope immediately
provides me the vehicle to move from a 'Cottage Software' paradigm to a
(sort-of) 'Industrial Software' paradigm.

I am no python programmer, yet.  But, with the other available tools (DTML,
acquisition, ZClasses), I have been able to get the job done.  I have hit a
few land-mines since February.  In some cases I was able to work through the
problems from How-To's, others from the mail-listings.  But a couple of
problems have yet to be resolved. The new Zope Book is a step towards
consolidating all these other doc efforts but it falls short on utility. I
have many perl books on my book shelf.  The one that I always go back to is
my original 'Camel'  book.  Wall & Schwartz put the right mix of fact, fable
and 'case studies' to get the imagination brewing.  I don't need my hand
held but I would greatly appreciate some insight on what is possible and
what is not.  The biggest stumbling block for me to date (and potentially
the most powerful tool for me) has been connected with the nuances of
ZClasses.  The examples in the book gloss over the implementation details
that would be the most instructive and could have saved me days of searching
and swearing.  I ended up searching for some ZClass products and worked
through them to fill in the blanks.

I see enormous potential for Zope in the Peer-to-Peer revo/evo-lution.  I
want it to succeed.  I scream Zope at every opportunity.  But, I have
invested nearly 800 hours of my time to be able to talk-the-talk and now
walk-the-walk.  I feel quite comfortable in recommending this system as the
final solution as we move to P2P.  Not everyone can afford that kind of
commitment.  The people paying the bills certainly won't.

Certainly, the API documentation could be presented better, but expand on
some of that brain-storming that is going on behind those DC doors (well not
all of them ... you guys need your trade secrets too), those 'what if'
scenarios that would go a long way towards enlightening the masses.


>   Please don't banish this wonderful product to Eternal Geekdom by not
simplifing the documentation by putting together concrete examples on how to
implement concepts and products.
> In short enough geek speek.  Change the language into something the rest
of masses can understand.  How can I use zope/API to get PAID!  How can I
actually make the dcworkflow or the core session or the ZPT do something.
Plenty of example uses. I think they might call them case studies or
something to that effect.
> Thanks,
> -Jimbo

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to