October 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

Question for y'all: simplifying cassius
by Michael Snoyman 28 Oct '10

28 Oct '10

Hey all, Cassius (the CSS template language that goes along with Hamlet[1]) has some features which I've never advertised, and frankly never use: * mixins * nesting My question is: will anyone miss them if they're gone? Right now, neither one of these features is implemented in a good way: mixins requires a special datatype, a separate quasi-quoter, and don't always work as expected. Nesting doesn't do what you expect often, eg: p, div .some-class color: red Generates: p, div .some-class { color: red } As a result of having these two features, cassius is overall worse: * You *must* put a space between the colon and the attribute value. This has to do with determining if we're nesting and pseudo-classes. * The error messages are rotten. I have no doubt that all of these problems could be fixed, given some time. However, I personally don't actually find that I need these features, and if no one else is using them right now, I'd rather release a new version of Hamlet without this extra weight and perhaps come back to these features in the future. By the way, if anyone is interested in tackling this stuff, I imagine the proper way to get it working would involve using an intermediate datatype that keeps line/column information, and then rendering that intermediate datatype using blaze. It won't be quite as fast as the current approach, but I highly doubt Cassius is going to be a bottleneck in anyone's applications. Michael [1] http://hackage.haskell.org/package/hamlet

1 0

Yesod change: mutable session
by Michael Snoyman 26 Oct '10

26 Oct '10

Hey all, One of the things which has been a stumbling block of Yesod users has been the semantics of setSession. In particular, it seems strange that this does not work: myHandler = do setSession "foo" "bar" Just "bar" <- getSession "foo" Up until now, I have kept the "input" session that the user submitted in his/her request separate from the "output" session which will be sent in the response. I've just pushed a change to the repo which modifies things so the above code works. I don't *think* this will break anyone's code, unless you were relying on the old behavior in a strange way I can't think of. If this causes anyone problems, please let me know soon; Yesod 0.6 should be released either today or tomorrow. Michael

2 1

Yesod change for 0.6: CSRF protection
by Michael Snoyman 25 Oct '10

25 Oct '10

Hey all, This should probably go in a blog post (and it probably will yet), but I wanted to get some quick feedback on an upcoming change for 0.6. Greg Weber pointed out that Yesod currently has no Cross Site Request Forgery (CSRF) protection, so I've made a patch that addresses this. You can see the code on the ver0.6 branch on github[1], but here's a bird's-eye view of the solution: * Each session will be assigned a random, 10-character nonce. * runFormPost will check for a _nonce hidden field and ensure that it matches the nonce for the session. If not, it causes a FormFailure. * runFormPost now returns a 4-tuple, containing the result, the form xml, the encoding type and an Html value for the nonce hidden field. You may be wondering why I don't just stick the hidden field directly in the xml. The reason is that we don't know the type of the xml value: it may be a FieldInfo, a Widget, a Hamlet, Html, anything. Also, even if we knew the datatype, we don't know *where* to append the nonce. For example, if the xml value is a collection of <tr> tags, it would generate invalid markup to simply append an <input> tag there. I've also added a runFormPostNoNonce which has the same behavior as the old runFormPost. I've specifically renamed the unsafe version to something wordier so that current code will be prompted to reconsider whether or not to check the nonce. I know this may cause significant code breakage, so I'd appreciate user feedback on this one. Michael [1] http://github.com/snoyberg/yesod/tree/ver0.6

1 0

Yesod question: renaming widget functions
by Michael Snoyman 25 Oct '10

25 Oct '10

Hey all, I have a general rule of thumb: if I get confused about how I named things, I probably named them badly. For example, addStyle takes a Cassius value as an argument, while addStylesheet takes a route to a CSS file. On the other hand, addScript takes a route to a Javascript file, and addJavascript takes a Julius value. There's also addBody, which takes a Hamlet. And there's no addWidget, which is fine (it would just be id), except that it looks wrong and can lead to confusing type errors with the new polymorphic Hamlet. For example: defaultLayout $ do setTitle "Widget test" [$hamlet|This is a widget|] works fine, but: defaultLayout $ do [$hamlet|This is a widget|] setTitle "Widget test" confuses the compiler. I'm considering some renamings for Yesod 0.6 which will cause breakage, so I wanted your opinions if the changes are worth it, or if you have any better ideas. Here's what I'm thinking: addCassius :: Cassius -> Widget addJulius :: Julius -> Widget addHamlet :: Hamlet -> Widget addHtml :: Html -> Widget addHamletHead :: Hamlet -> Widget addHtmlHead :: Html -> Widget addWidget :: Widget -> Widget addStylesheet :: Route -> Widget addScript :: Route -> Widget And with the new polymorphic hamlet, I don't think wrapWidget and extractWidget are generally necessary. Nonetheless, I think I'd like to leave extractWidget, in case there is some use case I'm not thinking of. I think it's safe to remove wrapWidget, as it's easy to express it in terms of extractWidget. Thoughts? Michael

3 2

Generating, serving, and deleting temporary files with Wai/Yesod
by Matt Brown 24 Oct '10

24 Oct '10

Hello all, I've been experimenting with generating graphs from log files using timeplot and serving them with yesod. Each generated graph is only served once, so I need a way to clean them up. A cron job would be ok, but it's one more thing I'd have to remember to do, and I'm lazy. Instead, I'd like to pass a "clean up action" to the enumerator sending the file, to be performed after EOF is reached. For most files, this would just close the handle. For temp files, it would also delete the file. Here's the gist of it: http://gist.github.com/640902 The first revision defines a monolithic fromTempFile :: FilePath -> Enumerator. The second imports a factored version from Network.Wai.Handler (see my wai commit: http://github.com/softmechanics/wai/commit/2cb5ea47ca458f4b91a73e01a1dd0a29…) Not sure wai is the place for it. Perhaps wai-extra would be a better? Does this seem like a good approach? Regards, -matt

3 5

Persistent restriction on nullable fields in unique keys - is it necessary?
by Max Cantor 24 Oct '10

24 Oct '10

Is it strictly necessary to have the restriction on nullable fields in the Persistent library? Since Eq a => Eq (Maybe a) it shouldn't be strictly necessary right? I haven't looked at the underlying code yet, just curious.. Max

2 1

yesod CGI+apache2 deployment on shared hosting.
by Nubis 20 Oct '10

20 Oct '10

Hello World (I'm new here) I'm developing a simple web application using yesod, deploying it to apache2+cgi (that is, old school cgi) I first got my project working on my dev box using fastcgi but couldn't get it to work on my shared host, and it's harder to debug than cgi, so I thought I may just stick to cgi until I find a better host. The problem now is that I just can't get cgi to work on my local machine. I read on yesod's docs that the simple-server is smart enough to know when to run stand-alone or CGI, so I compiled that: $ ghc --make simple-server.hs But when I visit the url it just hangs there, and re-visiting throws a 500 error, and my apache log shows this: [Wed Oct 20 18:37:56 2010] [error] [client 127.0.0.1] malformed header from script. Bad header=Loaded: server.cgi [Wed Oct 20 18:37:56 2010] [error] [client 127.0.0.1] server.cgi: [Wed Oct 20 18:37:56 2010] [error] [client 127.0.0.1] bind: resource busy (Address already in use) I'm guessing, simple-server is launching a stand alone server the first time instead of handling the request as a CGI one. Am I using the right handler? Is there anything I should set in the environment to let simple-server know how to handle those requests? Then I have some other questions, after compiling, I need to move the binary file and the cassius, hamlet, julius and public directories to my web dir, then I need to set the permissions on public/tmp so yesod can write to them. I made a shellscript that does all that for me, but seems like the kind of thing that everyone must be solving their own way by now so I wanted to see if anyone had done anything better about compiling/packaging and didn't mind sharing :) That's all for now, thanks in advance for your help. cheers ----nubis :)

1 0

Potential gotcha in setSession/setCreds functions in Yesod
by Max Cantor 20 Oct '10

20 Oct '10

Maybe this is obvious to others, but it wasn't to me. Any code that sets a cookie or session variable wont "take effect" until the next request. Upon reflection, this should have been obvious to me because the session vars are read out of a Reader monad, but it wasnt.. My point is that, you can't do something like: setCreds False creds m <- requireAuthId in a single request. The simple solution is to stick a redirect in there. Not suggesting any code changes, but a simple note in the haddocks :) Again, sry to bother if this should have been obvious too me. Max

2 1

Haskell web dev job at CREATE-NET
by Christopher Done 19 Oct '10

19 Oct '10

Hi chaps, Thought I'd post here as it's the perfect audience. We're hiring at CREATE-NET for a Haskeller web-dev position: http://www.mail-archive.com/haskell-cafe@haskell.org/msg81526.html Feel free to drop me a message on chris.done(a)create-net.org you have questions for me specifically. Get it while it's hot. :-) We may hire an untyped Lisper instead! Ciao!

1 0