newbie: Zope

[Cary O'Brien]

In article <39b51ca2 at news.xtml.co.uk>,
Nick Trout <nick at nil_spam_videosystem.co.uk> wrote:
>
>"Andrew Kuchling" <akuchlin at mems-exchange.org> wrote in message
>news:3d3djk6jz2.fsf at kronos.cnri.reston.va.us...
>> Geoff Talvola <gtalvola at nameconnector.com> writes:
>> > I too tried out Zope and found myself overwhelmed by all of the new
>concepts I'd
>> > have to learn.  I don't want to have to learn and use DTML.  I don't
>want to
>> > store everything in an object database -- I want to use a regular source
>control
>> > system.  I don't want to have to figure out ZClasses, Products,
>Versions, etc.
>> > I don't need through-the-web administration.  I just want a nice way to
>write a
>> > web application as a Python application.  Zope is a _very_ ambitious
>system, and
>>
>> Yes, this is pretty much what we've found; we wrote Quixote for our
>> own purposes instead of using WebWare, but the principle is much the
>> same.  Zope works really well if you have a bunch of simple things --
>> objects that are mostly bags of attributes, rows of data from a SQL
>> database, pieces of text -- and can glue them together with DTML.  For
>> example, Squishdot is well suited to Zope, because an article or a
>> follow-up isn't that complicated an object, so you can implement it, a
>> bit painfully but not too bad, and then use DTML to combine objects
>> flexibly.
>
>To be honest I'm tempted to go away and try WebWare and even Medusa and come
>back to Zope if and when it becomes more usable.
>
>I need a quick easy solution for an intranet. I can see the benefits of Zope
>and I like where its going, but for me it not there yet! The intranet is a
>simple side project of mine and I cant afford the time really.
>

If you are in a hurry you may get frustrated with Zope.  It has a wierd sigmoidal
learning curve.  Easy to just add html and simple dtml to do things like common
headers/footers.  Then you try and do something a bit more complex and you find
you have to deal with dtml quirks, acquisition, and not-particularly-well documented
internal interfaces.  You spend a lot of time digging around the .py files in Zope.
You get angry.  Then you amass a critical amount of understanding and things fall
into place.  And things get easier, and more elegant.  (I'm just starting to be
able to see this level of understanding in the distance).

My suggestion?  If you need to get an intranet thingo going in a hurry, use the tool you
know the best,  cgi, mod-perl, whatever.  But set up a zope server (really very easy)
and try to spend a little time each day learning one new zope thing.  And one day,
someone is going to ask you to add feature x to your mod-perl scripts, and you just
might say "the heck with it, it would be easier just do do this in Zope".  Or mabye
not.

Don't underestimate the power of the permissions system in Zope.  If you have
any sort of collabaritive(sp) site, you're going to need user classes and
permissions, and Zope's got it built in.

NB  We are using Zope internally, and are pretty happy with it, but not yet for 
external prouction systems.  Mabye someday.

-- cary