[Zope] Zope Documentation

Trevor Toenjes zope@toenjes.com
Mon, 12 Aug 2002 16:36:26 -0400


DAMN BOY!!
You are on top of things.  I will crawl back in my hole.  ;)

You are doing some good things with the Zope Book.  Releasing 2.6 docs
before the final 2.6.1 is VERY impressive.  lol.  is there going to be one?
And you have a point, that the online Zope Book could be the place to
reference in many of the NZO requirement areas.  And if the ZBook has the
answer then we should  utilize it rather than recreating the wheel.

The proposed Software Product GUI goes a long way toward organizing
community released products and organizes product specific how-tos in that
area.
hmmm, now you have me thinking that how-tos should be categorized as Zope,
non-specific scripts, and Product specific.

-Trevor

> -----Original Message-----
> From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of Chris
> McDonough
> Sent: Monday, August 12, 2002 4:06 PM
> To: Trevor Toenjes; Breuer, Yvon; Dieter Maurer; Sidnei@X3ng. Com. Br
> Cc: zope@zope.org; douwe@oberon.nl; zope@toenjes.com; jprice22@wvu.edu
> Subject: Re: [Zope] Zope Documentation
>
>
> > The first steps to build your first Zope website often creates
> enough
> > momentum to hinder the newbie from learning alternative approaches
> until
> > much later.  How many newbies think that the DTML_Document is that
> all
> > powerful object because it is what is used in most examples with
> > standard_html_header?  And then proceed to create a website with
> 100%
> > DTML_Documents, only to discover they have now defeated many
> benefits of
> > acquisition and folders?  And then you go back and convert
> everything to
> > DTML_Methods with folders containing properties.
>
> Note that this practice is explicitly denounced in the new Zope Book
> edition.  As a matter of fact, I go so far as to say that people
> should probably *never* use a DTML Document.  This is in the
> introduction to DTML.
>
> > When a newbie has a problem, the only choice is to search mail
> list archives
> > and zope.org docs.  But these are heavily laden with DTML
> references and can
> > quickly send the newbie into the perception that DTML is
> everything in Zope,
> > which just isn't the case anymore.  I think it is a big mistake
> that the
> > Zope Book consider p-scripts advanced.  This should be considered
> a basic
> > requirement for newbies.
>
> Good point.
>
> > We almost
> > need a community endorsed comparison of DTML, p-scripts, and
> external
> > methods and python products and the suggested appropriate
> situations for
> > each.
>
> FWIW, I try to do this in the docs (see
> http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/BasicObj
> ect.stx).
>
> > How is that for trying to address both sides?
> > The hard work is sitting down to create this document.
>
> Weel, forgive me for having a one-track mind, but it's already in
> motion if you're willing to live within the constraints of the Zope
> Book.  I think this is its main purpose, as folks need a sanity
> check when they first come in to Zope.  The ZB can help to do this
> because it's highly organized, it has a controlled scope, and it has
> at least a little bit of momentum (FWIW, I have spent ~ 200 hours
> editing it for 2.6 and a few other people have contributed time and
> effort as well).
>
> NZO can help people *find* the Zope Book and other critical
> documents, help people make decisions about which third-party
> products are "good" and which are bad, and help folks better
> categorized HowTos, all of which are problems that need to be solved
> that are not even close to being solved by the current docset.
>
> - C
>
>
>
> _______________________________________________
> Zope maillist  -  Zope@zope.org
> http://lists.zope.org/mailman/listinfo/zope
> **   No cross posts or HTML encoding!  **
> (Related lists -
>  http://lists.zope.org/mailman/listinfo/zope-announce
>  http://lists.zope.org/mailman/listinfo/zope-dev )