[ZWeb] RE: Creation and Last Modified dates?

[Don Hopkins]

>Didn't get that...

It was another bad vain/vein pun. You're supposed to take the lord's
name in vain, but some religious junkies take it in intravenously
instead (in vein). Thus religious tracts -vs- junkie's track marks. 

>I thought all content showed a modified date? Can you give me some
examples that don't?

http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/AppendixC.st
x
http://zope.org/Documentation/Books/ZDG/current/ComponentsAndInterfaces.
stx
http://zope.org/Products/CMF/docs/design/system_architecture/view
http://zope.org/Products/CMF/docs/design/system_architecture/interfaces/
tools/IF_portal_membership

The Zope HowTos seem to have last modified dates, but not creations
dates. 

Hopefully this is something that can be easily fixed in a template. 

>Does anyone want to volunteer to do this?

I will be glad to help out with fixing up the documentation if you'll
trust me with the appropriate permissions. I'm sorry that I can't put a
lot of time into it, but I frequently read the Zope documentation and
will fix anything I catch. 

>> What I would cherish would be a good concentrated API reference,
sorted
>> by category, with an index at the top instead of a barrage of user
>> comments. 

>This comes under my comment of "The Zope Book is there, it just needs 
>editing" ;-)

The API reference looks pretty frightening to casual readers just
looking into Zope to find out if it's worth using. I strongly agree with
the first user comment at the top of the page: "This section needs a
Table of Contents too."

>> Especially a quick-reference to the core Zope classes, and one
>> for the commonly used core products, without all the goofy stuff
nobody
>> uses on a day-to-day basis. 

>*shrugs* a reference, by defenition, is complete...

Unfortunately the API reference that the front page links to is quite
off-putting and probably scares a lot of potential recruits away from
Zope. 

>> Source code should be primarily written for other people to read, and
>> only incidentally for the computer to interpret. (To paraphrase a
quote
>> from the preface of Abelson & Sussman's Structure and Interpretation
of
>> Computer Programs.)

>Not sure how this relates to the documentation structure...

Well the "semantic web" freaks would tell you the converse:
Documentation should be primarily written for computers to interpret,
and only incidentally for people to read. 

	-Don