Atem-Project on GitHub @AtemProject on Twitter Subscribe to the News Feed Metapolator on Google+ Atem-Projekt on Patreon

Atem Project Website Generator

The Atem website is generated by the code in this directory. Ideally the website generator will be available as a shared project for all other Atem subprojects as well. This is pretty similar to Jekyll, but with much more specific site genrating capabilities.


Since the list above mixes two different concerns AND a third concern, which is application-deployment is missing we need to put names on all of this:

Where Documentation and Project website may appear in the same context. Well, all should be accessible via the Website somehow, so it must be possible to link and also the Navigation should at least on a high level reflect that.

API-Documentation will come later. Distribution will also come later, and not in Atem-Project at all.

There must be a directory structure to cope with the different parts of the page:

js ?
assets ?
    # built applications ready to use
    # This is specifically authored web content
    # docs will be authored similar to web, but may include stuff like a semver
    # directory layer
    # that also means, that to create older docs, we'd have to check out an
    # older tag ...
    # also, the last tag is almost always an old one and most of the time
    # `current` (rather HEAD) has no tag at all.
    # Checking out old versions may be problematic in a running build as
    # well. We could always build to `current` and then push a copy of
    # `current` to a tag folder if the tag === HEAD. That way, we would
    # also "freeze" that old documentation.

I think dist won't be handled by this in the beginning, but actually having a central build tool for distribution, documentation and website (communication) would be great

A blog with rss feed would be neat! Website entries marked as news

The plan: * The overall structure could be a per output directory/target configuration. * Inputs are also directories, per input source a router could be defined that knows how to interpret different file-suffixes, i.e. .md will be put into the appropriate template and interpreted as markdown , result: outputdir/path/to/ -> I want also a metadata enhanced file format -> like this: -> even a .md file may have this frontmatter, configurable? -> ducktyping: if it is separated like frontmatter and if it parses as yaml ...

remember setup steps for travis ...

# Atem-Project/website/generator$ virtualenv venv
# need py >=3 anyway, so pyvenv seems better than virtualenv
# Atem-Project$ pyvenv-3.5 website/generator/venv
Atem-Project$ . website/generator/venv/bin/activate
Atem-Project$ pip install wheel
Atem-Project$ pip install Flask
Atem-Project$ pip install pyyaml
Atem-Project$ pip install misaka # markdown
Atem-Project$ pip install # html escaping in mardow synax highlighter
Atem-Project$ pip install Pygments # syntax highlighting
Atem-Project$ pip install Frozen-Flask

custom template variables

if ```yaml is the first thing in the file and a ``` is present in a subsequent line everything in between is attempted to be parsed as yaml and if successful used as template variables and removed before rendering the document. Otherwise, the block remains unchanged in the document. This is cool, because github will syntax highlight the configuration properly:

this: will
be: configuration

custom templates

I want the repository to be able to define it's own templates. So, in the repositories config file, a template directory can be specified and that will be used to look up templates prior to the default directory of the generator. This will also make it possible to inherit from generator templates, if they are not overridden by the app. Datatypes in the configuration can specify their own templates, and maybe the document custom template variables could even override that.


We have a list of all links available from the url generator for Frozen Flask That is a great way to create one unified menu class, that basically can render the whole sitemap as a nested menu, marking the currently displayed page as the active one. There will be a way, like selectors, to define which menus should be output, so we can show different menus on different pages. The menu class will not actually render the links, instead it will just provide structure and contents. The Rendering will be done in jinja2 templates.