- web-devel - Haskell.org

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

A URL by another name...
by Michael Snoyman 20 Sep '10

20 Sep '10

Here's an opinion question for the web-devel list. In Yesod, I try to ensure that we keep a single canonical URL for each resource, and redirect non-canonical URL there. For example: /foo/bar ---> /foo/bar/ /foo//bar/ ---> /foo/bar/ /static/myfile.png/ ---> /static/myfile.png There are essentially two components to this cleanup: collapsing multiple slashes and dealing with the trailing slash. If you pay careful attention to the example above, you'll notice that there's a subtlety to this trailing slash rule: * If the last piece of the URL contains a period, it is assumed to be a filename + extension, and therefore no trailing slash is used. * Otherwise, a trailing slash is used. My question is whether people would prefer a different default rule. (I say default because you can easily override this setting using the splitPath and joinPath functions.) The other two rules I could think of are always requiring or always banning the trailing slash. I think the former will make filenames look strange, but I don't really have a strong feeling on the latter. So the question is, what do y'all think? Cheers, Michael

2 1

Web development work
by Michael Snoyman 16 Sep '10

16 Sep '10

Hi all, Often times when trying to pitch Haskell to potential clients the concern is the lack of qualified developers willing to take on projects. As I'm sure many of you are familiar with, clients prefer not to be locked in to a single programmer: an errant bus can significantly reduce the value of their investment. So I'd like to get an idea of how many people out there would be interested in Haskell web development work. For the moment I'm just interested in doing this informally via email, though perhaps in the future it would be beneficial to the community to have this information centralized on a website. I think it would be useful to have some basic skills and experience information, including system administration abilities. I might also have one or two Yesod projects that I'll need to pass off in the future, though it's still unclear if this will happen. If you're interested in that, please let me know, I can give some more details privately. Michael

1 0

Upgrading from Yesod 4.0 to 5.0
by Rehno Lindeque 14 Sep '10

14 Sep '10

Hi all, I'm upgrading UrbanListing to Yesod 5.0 from 4.0 after a long hiatus. So I'm feeling a bit rusty :) I was wondering about the new signature for StaticRoute: > StaticRoute [String] [(String, String)] What is the purpose of the second argument [(String),(String)]? I couldn't pick it up from the documentation. Regards, Rehno

2 2

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

ANNOUNCE: wai-handler-scgi 0.2.0
by Michael Snoyman 28 Jul '10

28 Jul '10

Hi all, I'd like to announce a (slightly experimental) release: wai-handler-scgi. SCGI is an alternative to CGI and FastCGI; like FastCGI, it allows you to have persistent processes. However, unlike FastCGI, it's a very simple protocol to implement. This package requires no external C libraries. SCGI is supported by most web servers that support FastCGI (Apache, Lighttpd, Nginx, Cherokee, I'm sure others), so this can be an alternate hosting method. My tests showed no problems with the package, but as this is the first release, you may not want to host production sites on it. There also plenty of room for optimizations, though my testing showed it to be competitive with FastCGI. I've also released new versions of wai-extra and wai-handler-fastcgi to provide a new feature: CGI sendfile support. Some servers allow you to specify an HTTP header (X-Sendfile, X-LIGHTTPD-send-file, etc) and then they will send the specified static file via a sendfile system call. This can have big performance advantages. The new function is called runSendfile, and is available in all three packages. The code for wai-handler-scgi is very short; I encourage anyone who has experience optimizing socket IO to have a look and fix up the performance bottlenecks. Cheers, Michael

1 0