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

[Michael Snoyman]

Hey Simon,

For some reason your message bounced.

---------- Forwarded message ----------

From: Simon Michael <simon at joyful.com>

To: web-devel at haskell.org

Date: Sun, 8 Aug 2010 07:33:10 -0700

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

On Aug 7, 2010, at 10:28 PM, Michael Snoyman wrote:

I had a sudden inspiration yesterday of how to improve runtime Hamlet
templates. This should give you a lot of the benefits of compile-time
templates without requiring a recompile for every change. I've written this
up in a blog


Very cool, thank you! And timely.


http://gist.github.com/514069 is what I have been doing, and I was looking
at hamletFile next. I thought of having a readHamletFileOrBuiltin that would
read the external files at runtime (with --debug), or use compiled-in
defaults when they are not found (eg when someone has downloaded the
single-file executable instead of using cabal). And using identical hamlet
code in both cases (unlike the Html-based integration above where ^^ becomes
$$).


FWIW, here are some more thoughts that came up while using hamlet:


* allow (RT or non-RT) templates in $ $ as well ? Drop ^ ^ ?

I believe the only way to implement that internally would be via
MultiParamTypeClasses, which isn't a step I'd like to take at the moment. If
you see another implementation approach, let me know, but I kind of like
having the distinction apparent.

* HDString constructor for HamletData ?

I really think the straight runtime implementation of Hamlet is the corner
case, and in general people should be using hamletFileDebug. Adding HDString
would make it slightly easier to code against the RT while making the inner
code a little more complex. A compromise might be a function:

hdString = HDHtml . string

or even

hdHtml :: ToHtml h => h -> HamletData
hdHtml = HDHtml . toHtml

Any thoughts?

* auto-derive HamletData from native types ?

Once again, this would imply that RT would be the preferred way of doing
things as opposed to hamletFileDebug. I'd be willing to accept a patch on
this, but I'm not sure which types would get instances.

* data type for non-RT Hamlet as well, or better, the same type for both

You mean a HamletData for compile-time Hamlet? What advantage would it give
you? I find the huge advantage of compile-time Hamlet that you use Haskell
variables directly.

* thread data (HamletData and/or custom app data) through templates (eg,
nested) with a Reader monad ?

This approach was taken with earlier versions of Hamlet, but proved to be
much clunkier I believe.

* allow literal arguments in references, eg ^postingfield.1^

Yes, good call.

* easier verbatim content quoting, eg lines starting with \\ ? Having to
escape $$ is not so convenient for jquery

I hear your pain about jQuery, but I'm not certain adding another special
case is wise. Does anyone else have an opinion on this?

* docs and compiler errors could say something clearer than "Hamlet url".
Hamlet routetype, urltype, routet, urlt ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/web-devel/attachments/20100810/ce687ff5/attachment.html