[web-devel] Runtime Hamlet template parsing/rendering

[Kyle Murphy]

Well, runtime loading is definitely something I want (and the single biggest
reason I haven't switched to using Hamlet yet), as I'm currently building my
app and then uploading it to my server which is a rather slow process. Being
able to upload a new template (or edit it in place) most of the time rather
and a completely new binary would be a major time saver. As to your
question, I'm not entirely sure, as there needs to be some sort of
information about the expected template available at compile time. It ruins
the symmetry somewhat, but maybe create a compile time version of the
template that essentially specifies what sort of variables are expected, and
so long as the variables remain the same at runtime (and there are no syntax
errors) the templates should continue to function properly. I'm still pretty
new to Haskell, so the kind of reflective black magic necessary to do
something like that is a bit beyond me currently, but perhaps some sort of
new TH to specify name -> type bindings in the template?

Something like:

[$runtimehamlet|
  exampleVar -> SomeType
  anotherVar -> SomeOtherType
|]

I'm not sure if it would be better to provide some mechanism to specify
which template that's expected to be the args for, or if you should have to
define an "argument set" for each template you plan to use.

-R. Kyle Murphy
--
Curiosity was framed, Ignorance killed the cat.


On Sat, Jul 31, 2010 at 15:34, 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
>
> _______________________________________________
> web-devel mailing list
> web-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/web-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/web-devel/attachments/20100802/e7b16afa/attachment.html