Updated wiki/AutoReload to reflect changes in trunk.

[Jason Huggins]

I read the comment from Remi about how wiki isn't great for
documentation here:
http://groups-beta.google.com/group/cherrypy-devel/msg/1e08a9f54ffe40ee?hl=en

Keeping that in mind, I went ahead anyway and added an updated example
for http://www.cherrypy.org/wiki/AutoReload to reflect the changes in
changeset #382 (Renaming cpg to cherrypy).

I left the prior examples as-is because my updated example only applies
to the subversion trunk (and unreleased CherryPy 2.1).

Thus, I'm proving the point that wiki is awkward for tracking changes
as code changes.

Should I not have made that wiki change since svn trunk is in such flux
right now? Any tips on what should still be edited in wiki going
forward, in light of the new documentation effort?

I'd love to help with the docs and the code, just looking for a few
signposts to point me in the right direction. Thanks!

-Jason

[Sylvain Hellegouarch]

Selon Jason Huggins <jrhu...@gmail.com>:

>
> I read the comment from Remi about how wiki isn't great for
> documentation here:
> http://groups-beta.google.com/group/cherrypy-devel/msg/1e08a9f54ffe40ee?hl=en
>
> Keeping that in mind, I went ahead anyway and added an updated example
> for http://www.cherrypy.org/wiki/AutoReload to reflect the changes in
> changeset #382 (Renaming cpg to cherrypy).
>
> I left the prior examples as-is because my updated example only applies
> to the subversion trunk (and unreleased CherryPy 2.1).
>
> Thus, I'm proving the point that wiki is awkward for tracking changes
> as code changes.
>
> Should I not have made that wiki change since svn trunk is in such flux
> right now? Any tips on what should still be edited in wiki going
> forward, in light of the new documentation effort?

Well you did well by updating the wiki. In such an event where you want to keep
both version 2.0 and 2.1 code, you can simply create two sections on the page
(eg: http://www.cherrypy.org/wiki/WriteFilters).

But yes it's a proof that the wiki is limited for keeping several different
versions at one time.

Now the documentation project is there for solving that issue bye providing a
book for each version. It's still under work and won't be released before end
of July I guess at best.

>
> I'd love to help with the docs and the code, just looking for a few
> signposts to point me in the right direction. Thanks!

If you want to contribute to the doc project, simply grab a copy of the SVN
repository, pick up one section of the book (under trunk/docs/book/xml) and
fill the gap :)

- Sylvain

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

[Jason Huggins]

Sylvain Hellegouarch wrote:
> Well you did well by updating the wiki. In such an event where you want to keep
> both version 2.0 and 2.1 code, you can simply create two sections on the page
> (eg: http://www.cherrypy.org/wiki/WriteFilters).
>

Cool, I was wondering if there was an example wiki page like that.

However, I can see a lot of places that need two versions because of
the cpg to cherrypy rename... A potential problem that I see is when
2.1 comes out, a lot of sample code in the wiki will be invalid because
it is implicity 2.0-only code. Some effort will need to go into making
sure that your average new user of 2.1 doesn't try to apply a 2.0
example from the wiki and get really frustrated when it fails. At a
minimum, there should be a warning in the wiki when 2.1 comes out with
a pointer to the 2.1 DocBook and mentioning that many wiki examples are
2.0 only.

This same kind of problem happened when the Plone project went from
1.0.5 to 2.0. There were a lot confused users and incorrect
documentation on the plone website when Plone 2 was released.

-Jason