pcplantdb

["John Schinnerer" <john@eco-living.net>]

Aloha,

> Wow, there is a lot to Zope and I get the feeling I've just scratched
> the surface.  Fortunately the documentation seems pretty good.

There is a lot, and a lot can be done with a little of it (for me so far
anyhow).
Glad you find the docs good, I find them great up to a point and then
there's no more info beyond a certain newbie level; I find a distinct lack
of "rich" examples.  However there are some very helpful and knowledgeable
people on the Zope list - info from there is how I managed to get my first
reasonably complex product working.

> I've spent most of time looking at zope 3 (X3 beta 1).  I was trying
> to get a feel for where the product is headed by looking at the
> cutting edge.  I'm not sure it's ready for our use but I like the
> direction it's headed using some post-OO ideas like components and
> adapters (I especially like the adpater ideas).  Anyway some the
> reasons Z3 is headed the way it is is because of issues with Z2.

Z3 is still pretty raw as far as I can tell.  Conceptually great but not
ready for production, and I think the Z3 folks are pretty clear about
that, though I haven't read the latest on Z3 for a while.

Z2 is quite stable and mature however - current stable is 2.7.2
I am still developing/hosting on 2.5.1 and it's fine.
There are indeed "issues" in Z2 that Z3 aims to address; and, Z2 is miles
ahead of anything else out there.  Meanwhile I'd say dig into current
release Z2 and see what you think.  Z3 is a ways off for production unless
I'm way behind on Z3 news.

>   You can't learn Zope development in bite sized chunks; you must
>   learn the entire framework at once.

For developing products, that seems to be true - even a simple product can
make your head hurt at first.  Now I've done a couple, though, it seems
less overwhelming.
I would guess this would be easier for you because you're a python pro.
Much of my head-hurting was learning enough about python to just plain
make a simple product's code do what I wanted.

> It's hard to use familiar tools
>   and techniques.  It's hard to reuse code.

Not sure what your usual tools and techniques are.
As for code reuse - how do you see it as hard?
We may be at totally different levels here about code reuse - for me it's
wonderful that I can put one python script or page template or whatever in
my root folder and call it on any relevant object in any subfolder.
And I can use one product across multiple parts of a site and even
multiple sites.
It has all the OO code re-use benefits...a class (or several) can be the
base class(es) for another class, no need to rewrite it all...??

>The Zope development model
>   (ie Products) often seem too heavy-weight.

You mean the initial overhead to get the basic elements of a product in
place?  Or...?
There is for example mxmEasyProduct, which offers a "prefab" starter class
for products (both simple and "folderish").
And, it does seem like a lot of overhead for a "hello world" product.  For
a real complex product though, it seems pretty simple relatively speaking.

> Zope products don't offer
>   a good separation between logic and content.

How so?  Are you looking at examples that use DTML?
Forget DTML, it's the old/early zope data-munging markup.
Still lots of legacy code and DTML die-hards, but TAL (template
application language) and METAL (Macro Expansion TAL) is the newer stuff
(page templates are the objects that support these, part of core zope
since 2.4.1).  I use no DTML at all, just TAL and METAL.  Provides
XML-compliant "markup" that accomplishes clean separation of logic and
content.  Also enables WYSIWYG editors to handle page templates correctly
because there's no HTML-munging as with DTML (or PHP and so on).  That is,
someone doing presentation work can use their fave WYSIWYG editor to edit
page template code without snafus due to the non-HTML-compliant tags used
in DTML, PHP, etc. and without damaging the logic.

Any logic that starts getting too complex or messy using TAL and METAL is
separated out (as it should be) and done with python scripts and/or python
products.

So IMO, FWIW, Zope has far better presentation/logic/content separation
than anything else I've seen.

> The api is big and complex, something good to know going in.  The
> learning curve may be a bit more than I expected.  On the other side
> zope will probably do more than I expected.

This has been my experience.  The hardest part for me has been figuring
out/finding out how simple it can be to do some real gee-whiz stuff.  This
is why I say I find the docs lacking after a certain point...

><http://toulouse.amber.org/archives/2003/04/14/comparing_zwiki_code_bases.html>.
> Skip the first three paragraphs, but techies should be sure to check
> out the code comparison pages.  Zwiki for zope 2 is pretty horrible
> with multiple inheritance of 10 superclasses, etc.  Hmmm... object
> abuse.

It can happen to the best of us...there's an article on code
cleanup/optimization of ZCatalog that you might enjoy, somewhere on the
zope.org site...it always *worked* OK, but even I can grok from the
article that the enhancements were huge and mostly a matter of
simplifying...

> Anyway, if you get a chance to talk to your geeks John ask them what
> they think about Zope 3.  Like I said I'm not even at the point of
> knowing whether to consider it as a possible platform but it's pretty
> exciting stuff.

See above - my impression is that Z3 is exciting *and* a ways from prime
time, and I think Zope 2 is still the best out there.  Production Z3 will
incorporate Z2 compatibility (currently not implemented), so porting can
be done gradually if it comes to that.
One thing is that the "overhead" of getting off the ground in Z3 sounds
still pretty onerous, with all the definition code for components and
adapters and so on - it's conceptually wonderful, and it sounds like a lot
of typing.  Hopefully there will be some tools to ease that.

John H., have you been following Z3 any more closely than me?

Whatsisname, the guy who "invented: hypertext back at Apple decades ago,
has a rave about zope somewhere on the net...I think another old
technology dog has also praised it as above and beyond.  Maybe that's why
it's a brain-stretcher.

And hey, it's written in python...what more could you want?  ;-)


John Schinnerer - MA, Whole Systems Design
------------------------------------------
- Eco-Living -
Whole Systems Design Services
People - Place - Learning - Integration
john@eco-living.net
http://eco-living.net