Home Original page

Zope question: collaborative environments?

Jason Cunliffe jasonic at nomadicsltd.com
Sat Oct 28 12:33:20 EDT 2000 
Samuel A. Falvo II <kc5tja at garnet.armored.net> wrote in message

> I think this is an unnecessarily harsh assessment of Zope.  While I fully
> agree that Zope's feature set isn't as extensive as some alternatives,
> understand that half the problem with Zope is that the real functionality
of
> Zope comes from its *products*, not from Zope itself.  Zope provides the
> basic engine by which products are able to offer their services, though it
> hinders its ability to be easily learned.

Yes I agree.. see my revised 2nd opinion on the 'suitability' of Zope for
Tom Bryan' project. [Sent: Friday, October 27, 2000 3:19 PM]

> The problem, therefore, is that the assorted set of products available for
> Zope are all in varying stages of development, and none of the *products*
> are ready for prime-time.  Zope, the core itself, has always been ready
for
> prime-time -- at least since the 2.1 series was first unveiled.

An interesting point. Zope is a framework which is why it attracts so much
attention and experimentation. No the framework is not responsible for
components built on it.. but Yes the framework and its designers can do
things to help the end user integration.. I believe Zope year ahead will be
a very good one. Lots of maturing products and now with the shift of Python
core team from BeOpen to DC there is every reason to expect some terrific
results. Exciting times indeed.

> >framework with acquisition], have a great spec under in your left hand
and
> >the O'Reilly Zope book in the other, then maybe 3 months to show off
first
> >really solid site demo...
>
> Well, no -- not quite this severe.  You're exaggerating here.  However,
Zope
> is not designed for the web content newbie either.  It takes time -- it
took
> me about two months to learn Zope and its philosophies, and how to exploit
> them in varying circumstances.  I still have some difficulties even after
a
> year and a half of using it extensively in some cases.
>
> Like martial arts, painting, or fixing a car, there's only so much you can
> learn from reading a book or watching other people.  At some point, you
need
> to just dive in and try it yourself.  The single best way to learn how to
> use Zope is to just download it, install it, follow their simple tutorial,
> modify the set of pages supplied, and learn as you go.  Forget the web
spec
> for now.  Forget the books (though they're nice to have around if you need
> them).  Forget the fancy terms (the technique that Zope calls
"Acquisition"
> has actually been used in a variety of places previously in the history of
> computer industry).

Yes I agree about learning by doing.
..But books are very important for many reasons. In Zope's case the book
catalyses a much-demanded single source synthesis of a huge amount of online
discussion. It is *very* time consuming to go through all the back postings,
and also very confusing, because it is so difficult to determine which
version of which discussion is relevant to which version of which product
with which version of Zope. Greatly aggravated by poor search and catalog
features of www.zope.org website.

The book is a milestone and symbol of Zope maturity and stability, even in
the midst of such growth. Especially for those new to it, thus is very
important. You only have to go through the zope at zope.org mailing list
postings to see how strong the demand for better documentation is. The book
is simply a byproduct of all those formidable hands-on questions and
answers. All of which came from people downloading and trying get it
working. Broadly I would say they fall into three categories:

a. People whoh have just installed zope and can't get it work in basic
needed newbie ways

b. People who have been gainging experience and confidence, trying out
products etc but are banging their heads against lack of documentation and
{counter-intuitive} syntax headaches. often these problems are because they
are using DTML for things it was not intended for and does not do 'nicely'.

c. People who are developing products ro have ambitious plans for advancing
zope in exciting but complex new directions.

With a good book, you can conveniently hand a copy to people needing to be
involved in projects using Zope, but coming from other backgrounds. I have
had a hard time pitching Zope over the past 18 months. Would definitely be
easier with an OReilly paperback in hand. Likewise young engineers who are
able and willing, but completely new to it. There are so many links and
tidbits of wisdom. The book makes an excellent point of departure..


Call it what you want, I think Zope 'Acquisition' is very important and
interesting idea to grasp. When I try to explain Zope to people, I mention
that Zope goes in two directions:

1. hierarchical top or root down URL style path pointing to any
folder/object/method

2. acquired bottom up behavior in opposite sense.

Zope then combines these two in  yinyang symbiotic fashion, wherein comes
derives much of its power, simplicity and complexity.

I am still looking for a really good back of napkin schematic to illustrate
the key working of zope. Any one who has any suggestions about this, please
let me know. I am very ready to create a dynamic presentation model using
Flash of this for general online use, but so far have had zero response from
zope at zope.org.

- Jason
________________________________________________________________
Jason CUNLIFFE = NOMADICS['Interactive Art and Technology'].DesignDirector
More information about the Python-list mailing list