Hey Simon, For some reason your message bounced. ---------- Forwarded message ---------- From: Simon Michael To: web-devel@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 ?