No description, website, or topics provided.
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.


This library provides data objects for handling Markdown files, rendering to Html, and doing application-level data management. Reference documentation is available through Haddock, though it is sparse at the time of this README.


Functions to parse a Markdown file into a WikiPage object. The constructor is hidden on purpose, giving only a basic set of accessors for getting into the object. All operations are pure, so you can provide any ByteString you like.

A couple of rules on parsing:

There are an optional three header lines for providing file metadata:

% title
% authors (semicolon-separated)
% date (YYYY-MM-DD)

The headers are position sensitive, meaning that the date header must be the third header row. If no title or author is desired, then simply put the '%' in that position and move on to the next row:

% 2014-01-01

Multi-line authors is not supported.

I have speculated on the possibility of switching to RFC822 headers in the future. If so, I may make that a separate parser, but an additional API will be needed for handling the arbitrary extra metadata that could be supported in that case.


A message translation system. This was inspired by my work in Yesod, but Happstack doesn't have such a system built in. I am likely to migrate the typeclass to a different library in the future since I planto use it in other places, but this outlines the idea behind translating an internal data type into a language-specific string. I've included English and some possibly very clumsy German and Esperanto.


Consider this to be a headless application. You could, in theory, run the application by loading this module into a REPL and then manually entering commands. It should then be easy to write a user interface on top of this.

This application reads only one directory, the one provided to initWeblog. On demand (calls to getWikiPage), it will load and parse a page, then save the result into a cache. On all additional accesses to that page, the system will first check the modified time for the file on the filesystem and reload the page if it has been changed. Since the data cache is a TVar, this should be multi-process (forkIO) safe.

getArticles already understands the concept that an article is a page that has a date on it. It will return all articles sorted in order from newest to oldest. It is up to the caller to decide which articles to display. getArticles is potentially very expensive in the first call because it will load the entire wiki page into memory, but subsequent calls have proven to be very quick.

To use App.Weblog, set it up like so:

app <- initWeblog "/path/to/wiki"
page <- runWeblog app $ getWikiPage (Name "a-page-name")
case page of
    Left err -> ...
    Right page' -> ...

All functions in App.Weblog are meant to be run inside the context of runWeblog. runWeblog returns either an application error (which could itself encapsulate a parser error) or the desired result.