.creole

Ideas for a Software the World Needs Desperately: Another Static Site Generator

• Use Genshi for templating
  • Elegant
  • Powerful
  • Speed not important for static sites
• But actually map template file extensions to 'renderer' objects
• SCSS for styles
• reST for textual content
  • Extensible directives, roles
  • Use field lists for metadata
    • Tags/Categories
    • Template to render page in
    • …or better yet, have a concept of programmable 'page types' that control:
      • Template
      • URL (e.g. include date?)
      • If content should be Atom published, index and archive -listed, listed in navigation…
• But be modular about filetypes so e.g. creole can be supported, using macros for extensions
  • Map file extensions to 'source readers'
• Metadata providers e.g. git, FS
  • List providers to use in order of "priority"
• Wrap content from reST etc as genshi.HTML rather than Markup
  • Serialization
  • Transformations
  • Match templates
• WSGI development server (better than watch-and-build?)
• YAML, INI or plain Python for configuration?
• Design like a framework more than like a tool, at least at the core
  • Don't make assumptions about page types, template contexts
  • Don't just build a page per source document etc - treat the documents more like a database

apis.py

# renderer
class Genshi(Renderer):
    def __init__(self, serializer='html', doctype='html5'):
        pass

site.renderers['.html'] = Genshi()
site.renderers['.xml'] = Genshi('xml', doctype=None)


# source documents
class Rst(Document):
    # parse an .rst file and set some attributes based on field lists etc
    pass

site.document_sources['.rst'] = Rst


# metadata informants
class Git(Informant):
    # get created/modified dates and revisions etc from git
    # maybe some configuration to link to github et al for diffs etc
    pass

class FileSystem(Informant):
    # get created/modified dates from filesystem
    pass

site.informants = [Git, FileSystem]

site.py

from . import Site

site = Site(__name__)

for source in site.documents:
    istype = lambda x: source.type == x

    # :type: page, publish as is
    if istype('page'):
        source.build('page.html', [source.name])

    # :type: blog, publish as /year/month/day/name
    elif istype('blog'):
        source.build('post.html', [
            source.created.year,
            source.created.month,
            source.created.day,
            source.name
        ])

        # also publish listings per date
        site.build('post-list.html', [
            source.created.year,
            source.created.month,
            source.created.day
        ], posts=[
            post for post in site.sources
            if (post.created.year, post.created.month, post.created.day)
            == (source.created.year, source.created.month, source.created.day)
        ])

        # …and month
        site.build('post-list.html', [
            source.created.year,
            source.created.month
        ], posts=[
            post for post in site.sources
            if (post.created.year, post.created.month)
            == (source.created.year, source.created.month)
        ])

        # …and year (better way to do all this?)
        site.build('post-list.html', [source.created.year], posts=[
            post for post in site.sources
            if post.created.year == source.created.year
        ])

# atom feed with five last modified posts
site.build('atom.xml', ['feed.xml'], posts=sorted([
    source for source in site.sources
    if source.type == 'blog'
], key=lambda x: x.modified)[:5])

+1 for YAML configuration - I'm not a fan of turing-complete languages for config files in most cases.... INI works more out of the box with Python, but I really like YAML syntax. How would the dynamic test server work? Would it be faster than just building and loading, since it would have to do it anyway? Just saw this gist in passing (I'm following you on github) and thought I'd comment, take what I say lightly. It seems like a neat idea though :)

The test server could generate only the requested page, plus can handle "index.html" for you and solves issues with file:// in Chrome. As for configuration, I'm not even sure yet if it'll make sense to have it at all when we can simply have parameters to the Site class. Of course, then you could also read configuration however you want and splat as kwargs to Site.

A test server could also avoid actually writing to the disk and cache in memory.

Very true. I'm liking where this is going :D