New Python.org website ?

Sun Jan 22 11:06:28 EST 2006

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've also done some experimentation this weekend, and my solution would
be based on MoinMoin and KID.

Fredrik Lundh wrote:
> [...] and a more
> extensive (but still rough) translation is available here:
> 
>     http://effbot.org/pydotorg/
> 
> the sample site contains ~600 pages.  each page has been automatically
> translated from python.org sources to moinmoin markup, and then stored
> in a moinmoin 1.5 instance.  a separate component has then extracted the
> pages from moinmoin, and converted them XHTML fragments for rendering.

Great.

This sounds a lot like the ugly hacked script I produced that would dump
all MoinMoin contents to XHTML in one directory, and the raw MoinMoin
sources to another directory:

http://ghaering.de/pydotorg/dumpwiki.py

> (the sample pages on that page are basically the XHTML fragments as is;
> the final site generator should of course use a suitable templating system
> and nice CSS for the final product). [...]

The other part of my experiment was a stupid build system that
recursively looks for KID files in a directory tree and renders them to
HTML.

My idea is that for each KID file there would be a corresponding
content.xml file that would come from the MoinMoin dump-to-XHTML (*).

As for the navigation, my solution would look like this:

  - each KID file uses a master KID template
  - the "normal" KID files do look about like this:

        <html py:extends="'templates/layout.kid'"
        xmlns:py="http://purl.org/kid/ns#">

        <head>
        <title>The page title</title>
        </head>

        <body>

        <div py:replace="document('src/content.xml')" />

        </body>
        </html>

    i. e. all they do is define the page title, and include the content
XML file created from MoinMoin.

  - the "make-like" generator script will give each template its name as
a parameter, so that the template (and in particular the master
template) know what the current path is. Using this information, it can
render the left-side navigation bar appropriately.

  - If there really is a need to, additional processing instructions can
be put as comments in MoinMoin at the top of a wiki page, like:

    ## RENDER hideNav("/dev"); expandNav("/about")

  As we also have access to the dumped raw MoinMoin sources, we could
parse these comments and handle them while rendering the KID templates.

IMO this system would be flexible enough to do all that the current one
can do, and integrate nicely with MoinMoin.

It would be not *ALL* dynamic via MoinMoin, but at least the contents
can be editied through a Wiki. Site structure would still be editied via
 the filesystem.

What do you think of an approach like this?

- -- Gerhard

(*) MoinMoin dumps do not always produce valid XHTML, so eventually I
still need a cleanup step.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD062EdIO4ozGCH14RAhoRAJ9pumD9LpKRohngbacHXSaub+zYtQCgmyHd
m9cCT2pXdRRIX0Qg+qdgMDM=
=hljf
-----END PGP SIGNATURE-----