pcplantdb

[Chad Knepp <pyg@galatea.org>]

John Schinnerer writes:
 > 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.

There is a lot of working code out there which can actually be pretty
helpful as examples if it is similar to what you are doing.  Looking
at Zwiki and squishdot will probably answer most of my questions not
included in docs.

 > >   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.

So most of your concerns above should actually be directed toward the
developers of Z3.  I was quoting them from
<http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/VisionStatement/>:
 
and I snipped out:

    You can't learn Zope development in bite sized chunks; you must
    learn the entire framework at once. It's hard to use familiar
    tools and techniques.  It's hard to reuse code. The Zope
    development model (ie Products) often seem too heavy-weight. Zope
    products don't offer a good separation between logic and content.

I thought it was interesting to see why Jim Fulton and co's thought
they needed to rewrite zope from ground up.  Anyway, I just wanted to
clarify that in case you thought those where my own opinions.  I
actually don't know nearly enough about zope to have such an in depth
criticism.

-- 
Chad Knepp
python -c 'import base64;print base64.decodestring("cHlnQGdhbGF0ZWEub3Jn")'