Re: yesod stylesheet serving
On Mon, Jul 5, 2010 at 10:43 PM, Simon Michael
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
Thanks! On 7/5/10 12:59 PM, Michael Snoyman wrote:
* 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
Indeed - see line 121. When I comment 120 and uncomment 121 I get: Hledger/Cli/Commands/WebYesod.hs:122:22: Couldn't match expected type `Hledger.Cli.Commands.WebYesod.R:RoutesHledgerWebApp' against inferred type `[Char]' Expected type: Routes HledgerWebApp -> String Inferred type: [Char] -> String In the second argument of `($)', namely `template req msg as ps "hledger" s' In the expression: hamletToRepHtml $ template req msg as ps "hledger" s Perhaps there's something else forcing the type, I haven't seen it yet..
* 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]
Interesting. I'm just forcing the account fields to be a bit indented here.
* I'm impressed to see you found the getMessage/setMessage API. I keep meaning to blog about it, but haven't had a chance.
Yup, I have been digging through all docs. The above was just what I wanted.
* 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.
I was happy when I realised you can write plain HTML in a hamlet template, if you want to. I'm not getting exactly what you meant above, but I'm sure I will soon.
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.
Current status is hledger-darcs can be installed with -fweb (loli/hsp/hack/simpleserver) or -fwebyesod (yesod/hamlet/wai/simpleserver). I'm going to focus on the latter now, I just feel the need to keep the former around as yesod requires 6.12 and I'm always trying to reduce installation pain.
I'm looking forward to trying this.
Thanks!
On 7/5/10 12:59 PM, Michael Snoyman wrote:
* 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
Indeed - see line 121. When I comment 120 and uncomment 121 I get:
Hledger/Cli/Commands/WebYesod.hs:122:22: Couldn't match expected type `Hledger.Cli.Commands.WebYesod.R:RoutesHledgerWebApp' against inferred type `[Char]' Expected type: Routes HledgerWebApp -> String Inferred type: [Char] -> String In the second argument of `($)', namely `template req msg as ps "hledger" s' In the expression:
hamletToRepHtml $ template req msg as ps "hledger" s
Perhaps there's something else forcing the type, I haven't seen it yet..
There were a few places where you used the @-interpolation with strings, which resulted in the "Hamlet String" datatype. The first patch addresses
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]
Interesting. I'm just forcing the account fields to be a bit indented here.
* I'm impressed to see you found the getMessage/setMessage API. I keep
meaning to blog about it, but haven't had a chance.
Yup, I have been digging through all docs. The above was just what I wanted.
* 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.
I was happy when I realised you can write plain HTML in a hamlet template, if you want to. I'm not getting exactly what you meant above, but I'm sure I will soon.
All I meant is that Hamlet comes in multiple flavors: a plain HTML version by default, and an XHTML variant. It takes the exact same input, but
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.
Current status is hledger-darcs can be installed with -fweb (loli/hsp/hack/simpleserver) or -fwebyesod (yesod/hamlet/wai/simpleserver). I'm going to focus on the latter now, I just feel the need to keep the former around as yesod requires 6.12 and I'm always trying to reduce installation pain.
I agree with that decision, I was not happy upon realizing that Template Haskell for GHC 6.10 didn't support type families. I considered taking out
On Mon, Jul 5, 2010 at 11:56 PM, Simon Michael
[1] http://hackage.haskell.org/package/wai-handler-webkit
I'm looking forward to trying this.
Michael
On 7/5/10 8:46 PM, Michael Snoyman wrote:
There were a few places where you used the @-interpolation with strings, which resulted in the "Hamlet String" datatype. The first patch addresses that, and adds a bunch of type signatures.
Aha! This is very helpful. I think I get it. I was assuming @...@ takes a string, and just enforces proper encoding. And indeed you can give it a string, and this forces the type of the template to Hamlet String (and prevents easy use of hamletToRepHtml, at least in my experience.) But for stronger checking, you should give it a route (type ...Routes, eg one of the Route constructors defined with parseRoutes). And if you occasionally still want to specify a url with a string, you can use $...$. If the above is correct.. is it useful to have @...@ be polymorphic in this way ? Or should it just require a route ?
The second patch may not be exactly what you're looking for, but I'm pretty sure it's correct: in generals, you don't need to capture multiple values for GET parameters, so I just changed the data types of "as" and "ps" throughout the code to be "String" instead of "[String]". This allowed me to use the special URL-params interpolation sequence of Hamlet:
I guess you're right, one GET parameter can hold all the command-line args or options. Thanks very much for the patches! -Simon
Michael, given that the "here" added by your recent patch is representing a single distinct route.. would it make sense to change the spelling of HledgerWebAppRoutes to HledgerWebAppRoute ?
On Tue, Jul 6, 2010 at 7:54 PM, Simon Michael
Michael,
given that the "here" added by your recent patch is representing a single distinct route.. would it make sense to change the spelling of HledgerWebAppRoutes to HledgerWebAppRoute ?
Good question. Overall, the datatype contains *all* of the routes for an app, but each constructor is a single route. Let's think about other examples like this:
data Color = Red | Blue | Green data Expr = ... I think you're right about this. Unless anyone else has a different opinion they'd like to share, I think I'll include this Routes -> Route renaming for Yesod 0.4. Thanks! Michael
participants (2)
-
Michael Snoyman -
Simon Michael