New Python.org website ?

Sun Jan 22 13:49:32 EST 2006

Gerhard Häring wrote:

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

It sounds very similar to what we have already built!! What we have also
parses yaml files, rest files, inline rest content, has special
renderers for navigation and breadcrumbs and handles cacheing of built
data to speed generation. It also keeps the format of all original
documents intact and can handle the differences in encodings that exist
in the current content. It will also include static html files (such as
some of the summaries and a lot of the pycon content), data structures
(the sigs and some other sections of the site), custom functionality
needed to remove emails from certain documents and the render some
custom data elements (peps) and the ability to add custom sidebar
elements. It also retains the ability to render complex page layouts on
the occasion they are needed. There is also a module being added that
will parse the current docs and rerender them within the site framework
adding a hierarchical navigation system.

With regards to integrating wiki content, it also has a beta directive
to include content from a wiki so there could be a good overlap here
between keeping the data stored in text files in subversion (a
requirement) and using moinmoin to help manage the content.

The goal will be to add a wiki-like rest editor that could also handle
the non-wiki/non-rest like content (such as sigs, peps, mirrors,
donations, jobs, members, psf meeting minutes, etc).

Tim