- web-devel - Haskell.org

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

Re: [web-devel] Including saltPass in the Auth2.Email API
by Michael Snoyman 19 Oct '10

19 Oct '10

Well, there's setCreds[1], is that what you're looking for? It's what the individual authentication backends (email, openid, rpxnow, facebook) each call. [1] http://hackage.haskell.org/packages/archive/yesod-auth/0.1.4/doc/html/Yesod… On Tue, Oct 19, 2010 at 10:44 AM, Max Cantor <mxcantor(a)gmail.com> wrote: > Furthermore, a programmatic way to login besides redirecting to the login route would be helpful.. > > Max > > On Oct 19, 2010, at 1:30 PM, Michael Snoyman wrote: > >> On Tue, Oct 19, 2010 at 7:18 AM, Max Cantor <mxcantor(a)gmail.com> wrote: >>> Michael, >>> >>> What do you think about exporting the saltPass function in the Auth2.Email plugin. The reason I would want this would be so that passwords could be set programmatically as opposed to solely via the current form. Currently, I just cut and pasted the code into my code, but it doesn't seem like this is a particularly sane/future-proof way to work. Any thoughts? >> >> Sounds great, I've justed pushed a commit to Git. By the way, starting >> with yesod 0.6/yesod-auth 0.2, the code lives under >> Yesod.Helpers.Auth.*, as it should. The Auth2 namespace was only to >> avoid conflicts with yesod 0.5. You mind waiting till 0.6 is released >> to have access to this function? >> >> By the way, porting to 0.6 should be a piece of cake. >> >> Michael > >

1 0

Fwd: [web-devel] Including saltPass in the Auth2.Email API
by Michael Snoyman 19 Oct '10

19 Oct '10

Sorry, forgot to Reply All: ---------- Forwarded message ---------- From: Michael Snoyman <michael(a)snoyman.com> Date: Tue, Oct 19, 2010 at 7:30 AM Subject: Re: [web-devel] Including saltPass in the Auth2.Email API To: Max Cantor <mxcantor(a)gmail.com> On Tue, Oct 19, 2010 at 7:18 AM, Max Cantor <mxcantor(a)gmail.com> wrote: > Michael, > > What do you think about exporting the saltPass function in the Auth2.Email plugin. The reason I would want this would be so that passwords could be set programmatically as opposed to solely via the current form. Currently, I just cut and pasted the code into my code, but it doesn't seem like this is a particularly sane/future-proof way to work. Any thoughts? Sounds great, I've justed pushed a commit to Git. By the way, starting with yesod 0.6/yesod-auth 0.2, the code lives under Yesod.Helpers.Auth.*, as it should. The Auth2 namespace was only to avoid conflicts with yesod 0.5. You mind waiting till 0.6 is released to have access to this function? By the way, porting to 0.6 should be a piece of cake. Michael

1 0

Including saltPass in the Auth2.Email API
by Max Cantor 19 Oct '10

19 Oct '10

Michael, What do you think about exporting the saltPass function in the Auth2.Email plugin. The reason I would want this would be so that passwords could be set programmatically as opposed to solely via the current form. Currently, I just cut and pasted the code into my code, but it doesn't seem like this is a particularly sane/future-proof way to work. Any thoughts? Max

1 0

Yesod-0.5.4 linking problem
by Max Cantor 17 Oct '10

17 Oct '10

Has anyone on the list had trouble building yesod-0.5.4? I'm getting the same linker error as interferon described here: http://hpaste.org/40633/ I tried all the usual suspects.. cabal install --reinstall <every relevant package> Seems to be a conflict between zlib and zlib-bindings. Thanks, Max

2 1