August 2010 - web-devel

Interpolation character in Julius
by Michael Snoyman 20 Dec '10

20 Dec '10

Hamlet, Cassius and (currently) Julius all use a consistent set of characters for interpolation. The dollar sign ($) is for plain scalars, the at sign (@) is for URLs and the caret (^) is for embedding other templates (mixins in the case of Cassius). I like this consistency. Unfortunately, in the case of Julius, the dollar sign is a suboptimal character to use since jQuery uses is so extensively. Currently, to write some simple jQuery Javascript such as: $("h1").hide() you have to use a double dollar sign to achieve escaping, namely: $$("h1").hide() So the questions to the list are: * Is it worth trading consistency for a better choice of interpolation character? * If so, what would be a more optimal interpolation character? I think percent sign (%) might be acceptable. Interpolation is not as important in Julius as it is in Hamlet, so I'm beginning to lean towards replacing the character. Michael

2 4

Proposed changes to web-routes: query-string support
by Michael Snoyman 21 Sep '10

21 Sep '10

Hi Jeremy, I've CCed the web-devel list, as I think the discussion will be of interest to a number of readers there. When we were originally working on web-routes, you had mentioned the idea of including some form of support for query strings, and I said it was a bad idea. I'd like to backtrack on that statement: I *would* like to include support, and I'm including a patch that does just that. Let me explain the use case this is meant to serve, which will help explain my design decisions. Yesod includes a static file subsite. One trick a lot of sites are using these days is including a hash of the file contents in the query string of the URL and setting the expiration date of the file far in the future. This way, as long as the file contents stay the same, the browser should use the cached copy, and as soon as a new version is available, the HTML will reflect this by a change in the hash value. I wanted to provide this feature with Yesod, but realized there was no straight-forward way to do this. What I needed was to change the formatPathSegments function to have a type signature of: url -> ([String], [(String, String)]), where the second element in the tuple is the query-string parameters. This, however, presents a small problem: let's say that we want to add query string parameters *on top of* those provided by the formatPathSegments function; we could do manually addition textually, but we won't know whether to include is as "?foo=bar" or "&foo=bar"; the former should be used if formatPathSegments does not given any query string parameter, the latter if it does. I therefore modified the handleSite function to be: (url -> [(String, String)] -> String) -> url -> a. I also changed encodePathInfo to also encode the query string parameters, so its type is now: [String] -> [(String, String)] -> String. All the other changes were just to get the code to compile. I'm planning on this being a change throughout a few other libraries: web-routes-quasi will obviously change to reflect this, as will Yesod. One other perhaps unexpected change would be in Hamlet: the definition of Hamlet is now "type Hamlet = (url -> [(String, String)] -> String) -> Html ()". One nice side effect of this is query-string encoding code is now completely localized to web-routes, instead of copied throughout multiple packages. This at least implies to me that this is a good move. You'll notice that I have purposely *not* modified decodePathInfo and parsePathSegments; I still don't believe routing should be affected in any way by query string parameters. Look forward to hearing your thoughts on this, Michael

3 7

Comments in Hamlet
by Michael Snoyman 23 Aug '10

23 Aug '10

After everyone gave me such great naming advice for Cassius and Julius, I've decided to be greedy and ask for some more help. The subject: comments in Hamlet. I've been asked a few times to add a feature where you can comment your templates, so I wanted to discuss it with the list. I'm really trying to avoid making any more special characters, so the first thing that comes to mind is to reuse an old character. My thought was to allow "$#" at the beginning of a line turn the whole line into a comment. What are people's thoughts on that? Also, Hamlet and Cassius almost certainly should have the comments, but I'm not sure about Julius. Since it's basically just raw Javascript, I think people should use Javascript comments, and then hopefully in the future we'll include Javascript compression in Hamlet that removes all comments. Michael

2 4

Sending email
by Michael Snoyman 20 Aug '10

20 Aug '10

Hey all, I'm wondering what people do in general for sending email, especially from web apps. So far, I've written some basic modules in my apps that wrap around the sendmail executable on the system. Are there packages on Hackage that people would recommend? As long as I'm bringing this up, I think I nice email system would offer built in support for creating multipart messages. Bonus points would be to automatically create a text/plain version from an HTML version. If no one knows of prior art on this, I might try to implement it as a module in Yesod. Michael

3 3

Re: [web-devel] Re: Runtime Hamlet template parsing/rendering
by Michael Snoyman 10 Aug '10

10 Aug '10

Hey Simon, For some reason your message bounced. ---------- Forwarded message ---------- From: Simon Michael <simon(a)joyful.com> To: web-devel(a)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 ?

1 0

Runtime Hamlet template parsing/rendering
by Michael Snoyman 08 Aug '10

08 Aug '10

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

4 7

statically compiled css
by Mark Bradley 05 Aug '10

05 Aug '10

So I was thinking today about how far you can go with statically type checked web programs. Yesod uses Hamlet and web-routes, which allow you to statically type check your internal urls and html. What other parts of web applications can you type check? Well there are at least two other language domains that are commonly used in web applications, CSS and javascript. Javascript might be a bit hard for now, but CSS type checking might be possible within hamlet. Has this ever happened to you? you write an awesome css class that clears floats. called "AwesomeClearThing" Now it is time to use it in hamlet %p!class="AwesomClearThing" Recompile + Reload later...nothing has changed...Fail! what you need is: %p!@class|AwesomClearThing@ and now since it is type checked, the compiler will tell you something is up. This also has a prerequisite that yesod knows the css that is being used. Another interesting side note of this is that you could potentially figure out which classes and rules are unused and not put them in the compiled css file. There are other things, but I think type-checked class and id names would be a pretty awesome first step. What do you guys think?

1 0