July 2010 - web-devel

Re: yesod stylesheet serving
by Michael Snoyman 06 Jul '10

06 Jul '10

On Mon, Jul 5, 2010 at 10:43 PM, Simon Michael <simon(a)joyful.com> wrote: > Great, thanks for the clarifications. sendFile made this easy. Has using > that affected my portability much, eg to windows ? As far as I know, not at all. I actually run some of this code on Windows system (via wai-handler-webkit[1]) in production environments, and it all works fine. I'm just building on top of the sendfile library[2] which does The Right Thing. Of course, like anything WAI, it depends on the implementation. If I'm not mistaken, Snap doesn't run on Windows (please correct me if I'm wrong on this, I'd like to know), so using the not-yet-released Snap WAI backend would clearly not work on Windows either. > > On Jul 5, 2010, at 12:04 PM, Michael Snoyman wrote: > >> the rendering details for you. If you point me to the code in question, >> I'll take a look. >> > > Latest code pushed to > http://joyful.com/darcsweb/darcsweb.cgi?r=hledger;a=headblob;f=/Hledger/Cli… > > Firstly, very nice code. I especially like how you're able to get an entire interface to fit into just 6 routes... impressive. I believe the problem is on line 120, where you call "renderHamlet id". If you look at the type of renderHamlet: renderHamlet :: (url -> String) -> Hamlet url -> L.ByteString You'll see that: renderHamlet id :: Hamlet String -> L.ByteString In general, you don't need to call renderHamlet directly when using Yesod. Instead, you have two better options: * hamletToRepHtml handles the rendering, calling toContent, and wrapping in a RepHtml. So your line 120 could be rewritten as: hamletToRepHtml $ template req msg as ps "hledger" s At which point you'd be able to use type-safe URLs in your Hamlet template (wrapping in the @ signs), and you can forget about URL splicing. * applyLayout just builds on top of hamletToRepHtml, by also applying your default layout to the returned content. In your case, I wouldn't say it's necessary, but it makes a lot of sense for large sites that want to have a standard look for all pages. Few other comments: * On line 228, you use a non-breaking space. I'm not sure if you *need* that, or are just trying to work around Yesod's whitespace rules. If the latter, there's a relatively new feature that allows you to put a backslash at the beginning of the content to bypass the whitespace rules.[3] * I'm impressed to see you found the getMessage/setMessage API. I keep meaning to blog about it, but haven't had a chance. * On line 212, I see you drop to plain XHTML syntax. If you just want to get XHTML closing-tag rules and keep the Hamlet syntax, use "$xhamlet" instead of "$hamlet" at the beginning of your quasi-quoter. Let me know if you have any other questions, I've been interested in hledger for a while now, so it's very gratifying to see it move over to Yesod. Michael [1] http://hackage.haskell.org/package/wai-handler-webkit [2] http://hackage.haskell.org/package/sendfile [3] http://docs.yesodweb.com/hamlet/lineparsing.html

2 5

bird: a simple haskell web framework
by Matt Parker 06 Jul '10

06 Jul '10

hi, i'm making a simple haskell web framework, "bird". check it out on github if you're interested. the project is still in its infancy - and i'm still learning haskell :-) http://github.com/moonmaster9000/bird

1 0

Re: yesod stylesheet serving
by Michael Snoyman 05 Jul '10

05 Jul '10

On Mon, Jul 5, 2010 at 10:01 PM, Michael Snoyman <michael(a)snoyman.com>wrote: > Hey Simon, > > Firstly, I'm not sure if your message went through to the rest of the list, > but at least they should see this reply. > > On Mon, Jul 5, 2010 at 8:02 PM, Simon Michael <simon(a)joyful.com> wrote: > >> Hi Michael.. thanks again for the great real-world-driven updates to Yesod >> et al. I'm looking forward to trying widgets. Meanwhile... >> >> I'm having trouble serving a stylesheet that Chrome will recognise, >> because this: >> >> getStyleCss :: Handler HledgerWebApp RepPlain >> getStyleCss = do >> app <- getYesod >> let dir = appWebdir app >> s <- liftIO $ readFile $ dir </> "style.css" >> header "Content-Type" "text/css" >> return $ RepPlain $ toContent s >> >> serves up this: >> >> $ curl -i http://localhost:5000/style.css >> HTTP/1.1 200 OK >> Content-Type: text/plain; charset=utf-8 >> Set-Cookie: _SESSION=...; path=/; expires=2010-07-05T18:41:35-00:00 >> Content-Type: text/css >> >> Note the two content-types. (Also, no content-length header; I don't know >> if that matters.) >> >> Let me explain. In general, you don't need to explicitly set content-type > headers in Yesod. Yesod determines the content type automatically based on > the return type of the handler function. In particular, a handler must > return an instance of HasReps, which allows a handler to specify multiple > representations of data if it so desires. > > By using a return type of RepPlain, you're telling Yesod to set a > content-type header of "text/plain". Instead, you probably want to use a > different return type. For example, you could use the [(ContentType, > Content)] return type. > > However, in your case, you have two much better options (in my opinion): > > * Use the Static helper. > * Use the sendFile function. When using sendFile, you short-circuit the > remainder of the handler code and immediately send a file. You get to > explicitly state the content type, and also get another bonus: some backends > optimize the sending of static files. For example, the SimpleServer backend > using a sendfile system call, so you avoid unnecessary data copying. > > Your examples seem to serve css using Yesod.Helpers.Static. I'm not using >> that because it seems to require a file path known at compile time, or am I >> wrong ? I get the path at run-time with cabal's getDataFilename. >> >> No, the path does not need to be known at compile time, but you'll need to > supply it when constructing the Static data type value. All of this would > happen when initializing your site argument; I can put together an example > of this if you like. > > And an unrelated question: what's the meaning of the type returned by a >> hamlet template ? I see one of your examples returning something like Hamlet >> AppRoutes, but my app will accept only Hamlet String for some reason. I >> wouldn't worry except hamletToRepHtml seems to require the former. >> >> type Hamlet url = (url -> String) -> Html () > > The Html is a datatype taken from Blaze, which is what let's Hamlet get all > of the performance advantages of that library. The url has to do with the > type-safe URL feature: every site has a URL datatype associated with it, > which defines all valid routes into an application. Of course, we can't just > display Haskell datatypes in our HTML code, so Hamlet takes a "url rendering > function" as its first argument. > > In general, you shouldn't need to be bothered with any of these details, as > Yesod automates all of the rendering details for you. If you point me to the > code in question, I'll take a look. > > Michael >

1 0

haskell web development with a restricted shell account
by Markus Läll 03 Jul '10

03 Jul '10

Hi! I have a noobish question -- what are my chances of doing web development on a host, where I have restricted shell access? Like, if I can copy programs to my own folders, then I could also copy a version of GHC and run that with my .hs files through a cgi folder, or maybe I could compile my programs and copy those executables to the cgi folder? Markus

4 3