[web-devel] Re: Runtime Hamlet template parsing/rendering

[Michael Snoyman]

Thanks for the input everyone. I've just pushed the new Hamlet runtime code
to github[1]. Instead of using data-object, I've created a new datatype:
HamletData[2]. Runtime templates support *almost* the entirety of valid
Hamlet documents; the only exception is complicated references, such as:

$(foo.bar).baz$

I don't think this should be a problem in real life; that syntax was only
added to support functions with multiple arguments, and since runtime
templates don't deal with functions, it should work just fine.

I'd appreciate feedback on this before releasing. I'm planning on making
this version 0.4.2. When I *do* make a release, I'll most likely accompany
it with a blog post explaining how to use it, and discuss when you should
use runtime versus quasi-quoted templates.

Michael

[1] http://github.com/snoyberg/hamlet
<http://github.com/snoyberg/hamlet>[2]
http://github.com/snoyberg/hamlet/blob/master/Text/Hamlet/RT.hs#L21

On Sat, Jul 31, 2010 at 10:34 PM, Michael Snoyman <michael at snoyman.com>wrote:

> Hey all,
>
> An often-mentioned "cool feature" for Hamlet would be to support runtime
> parsing/rendering of templates. Currently, the only supported method is
> quasi-quoting a template and thereby have it parsed into Haskell code at
> compile time. In my opinion, this is definitely the preferred way of using
> Hamlet, as it gives you very solid compile-time guarantees of correct syntax
> and type safety. Nonetheless, there are some use cases (static site
> generation via Hakyll, a hamlet-to-html tool, etc) that would really benefit
> from runtime parsing.
>
> It turns out this is pretty simple to add, except for one thing: I can't
> figure out a good API for passing in variables for a template. Hamlet
> templates have essentially four different datatypes they recognize:
>
> * Html
> * Some URL data type
> * That same URL datatype along with a [(String, String)] to represent
> query-string parameters
> * A Hamlet template
>
> In addition, $forall and $maybe need lists and Maybe values, respectively.
> Variable lookup is handled by a tree, which allows you to express arbitrary
> function application. $if requires Bools.
>
> So the question is, what should an API look like? The parse function is
> fairly straight-forward:
>
> parseHamletRT :: HamletSettings -> String -> Either HamletException
> HamletRT
>
> However, the render function is more complicated. I've toyed with a few
> possible ideas:
>
> * Use the data-object package with some complicated HamletData datatype.
> * Just do the complicated HamletData datatype.
> * Type lookup functions as parameters.
> * Disallow most of the more complicated features in Hamlet, like URL and
> subtemplates, and just allow dollar-sign interpolation with $forall and $if.
> That tree datatype for variable names could be collapsed into a [String].
>
> Thoughts on the matter are welcome, as well as sample use cases you have
> for such a function.
>
> Michael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/web-devel/attachments/20100805/8683624d/attachment.html