repo-based-blog: Blogging module using blaze html for markup

[ bsd3, library, program, web ] [ Propose Tags ]

This package contains a module that can be used in web applications. It's use cases are only limited by the use of blaze for the markup of pages. If anynoe cares to abstract that away, I would not stand in the way.

This package also contains an executable that uses the dyre library to allow a configuration of a web application in the way xmonad or yi does. An examle can be fount in the RBB module.

The blog contents are managed via a version control system. The filestore library has been used as a backend for this and hence the supported repository types mainly depend on the filestore version used. Thes currently suppored repository types are git, mercurial and darcs. The entries are rendered using the pandoc library.

For more information see the haddock documentation of the exported modules or the included in this package.

[Skip to Readme]


Maintainer's Corner

Package maintainers

For package maintainers and hackage trustees


  • No Candidates
Versions [RSS] 0.0.1
Change log
Dependencies base (>=4.6 && <5), blaze-html (>=, containers, data-default, directory, dyre, filepath, filestore (>=, ixset, lens, mtl, old-locale, pandoc (>=, parsec (>=3), repo-based-blog, stm, text, time, transformers, transformers-base, transformers-compat [details]
License BSD-3-Clause
Copyright Copyright (C) 2014 Sebastian Witte
Author Sebastian Witte
Category Web
Home page
Bug tracker
Uploaded by saep at 2014-11-14T12:42:20Z
Reverse Dependencies 1 direct, 0 indirect [details]
Executables rbb
Downloads 1046 total (4 in the last 30 days)
Rating (no votes yet) [estimated by Bayesian average]
Your Rating
  • λ
  • λ
  • λ
Status Docs uploaded by user
Build status unknown [no reports yet]

Readme for repo-based-blog-0.0.1

[back to package description]



A blogging module that uses a repository as its content backend.


The Haddock documentation of the module Web.RBB should contain enough information to get started.


As long as there are no web application specific changes required, I would usually just review and accept every pull request.


  • Please write documentation!
  • Please try to write tests!
  • If an issue exists, reference it!
  • Similar to neovim's development, use [WIP], [RFC] and [RDY] as tags in pull requests. Especially the [WIP] annotation has the potential to avoid unnecessary duplicate work if the pull request is created immediately after starting to work at the issue.