- web-devel - Haskell.org

Getting the http request header in Yesod?
by Rehno Lindeque 25 Sep '10

25 Sep '10

I'm looking to detect ajax requests sent to my yesod application using the technique detailed in http://davidwalsh.name/detect-ajax Is it possible to gain access to the request header directly or would yesod require modification to get at it? If someone could just point me in the right direction, I would be grateful. I imagine it would be a function returning GHandler? Thanks, Rehno

2 1

On the state of Haskell web frameworks
by Christopher Done 22 Sep '10

22 Sep '10

For what it's worth, I thought I'd throw a simple web app into the mix, hpaste.org: * Address http://hpaste.org/ * Source http://github.com/chrisdone/amelie The notable thing about this application is it's easy to see all the requirements ("small libraries"): 1. CGI/FastCGI: I needed a way to talk to the web, I chose CGI/FastCGI. The CGI library is quite general and small. 2. highlighting-kate: I needed to do syntax highlighting. Notice how it's just a few lines in an isolated module: http://github.com/chrisdone/amelie/blob/master/src/Amelie/Highlight.hs 3. Takusen: I needed to talk to a PostgreSQL database to save/read pastes, just a few lines (for setup) in an isolated module: http://github.com/chrisdone/amelie/blob/master/src/Amelie/DB.hs 4. ConfigFile: I needed a way to store the service's settings in a configuration file. Again, just a few lines in an isolated module: http://github.com/chrisdone/amelie/blob/master/src/Amelie/Config.hs 5. blaze-html/xhtml: I needed a way to build HTML inside my program. 6. formlets: I needed a way to generate and validate forms (e.g. the paste form). 5 and 6 are used in the HTML module: http://github.com/chrisdone/amelie/blob/master/src/Amelie/HTML.hs All of these libraries are perfect, they do one thing and do it well. I just imported them and they did the work for me. You can see also how they are modules in themselves, not interdependent as part of some grand framework. It seems that with good libraries, the architecture of your web app just designs itself. Personally I've always thought the "MVC" approach isn't particularly novel and follows naturally from good design. I'm not saying mine is good design, but without putting much conscious thought towards it, I've ended up with a DB module (model), a Pages module (controller) and a HTML module (view). To make this into the MVC approach, I'd just rename them to Model.hs, Controller.hs and View.hs. The things that I had to implement myself are as follows: 7. URI routing: http://github.com/chrisdone/amelie/blob/master/src/Amelie/Routes.hs How to receive requests and map that into a page + parameters to that page (e.g. paste/pid/30196 -> pastePage [("pid","30196")]), how to *generate* a URL with parameters. And how to generate a *pretty* URL: http://github.com/chrisdone/amelie/blob/master/src/Amelie/Links.hs A URL that maps back to a normal URL (e.g. http://hpaste.org/30196/half_a_proof is actually rewritten by nginx to http://hpaste.org/paste/id/30196) I think there probably are quite a few URI routing libraries out there but I only gave it a cursory glance. 8. Simple template writing. http://github.com/chrisdone/amelie/blob/master/src/Amelie/Templates.hs In fact I found that tibbe already wrote something to do this: http://hackage.haskell.org/package/template but I didn't end up using it for some reason. Maybe because everything has to be Text and I couldn't be bothered littering my code with string conversions all over the place. Turned out I had to do that anyway. Converting between String and ByteString and lazy ByteString and now Text is a real pain but you have to do it because all these different libraries decided to use a particular type. (At least some let you implement a Stringable class.) I will probably eventually just replace the templating code with tibbe's or go the full hog and use HStringTemplate. It's all the same idea, just more or less engineered. I'm interested in your thoughts and ideas. If you have any hpaste-size web applications that you have available online to read that you can maybe summarise and evaluate in the same way I have above, maybe that can spark some interesting discussion. Cheers!

7 12

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