May 2011 - web-devel - Haskell.org

Yesod. Hamlet . Templates
by Anton Cheshkov 26 May '11

26 May '11

Hello Michael, my question is i have the follow code *tpl1 :: tp1 -> tp2 -> Hamlet MyApp* *tpl1 p1 p2 = $(hamletFile "hamlet-template")* * * *tpl2 :: (tp1,tp2) -> Hamlet MyApp* *tpl2 (p1,p2) = $(hamletFile "hamlet-template")* Now we can use in hamlet template like *^{tpl1 p1 p2}* but next one does not work ^{tpl (p1,p2)} brackets give some wrong. why ? and how to get around ? Thanks. -- Best regards, Cheshkov Anton

2 1

Re: [web-devel] [hamlet] implicit spaces with newlines?
by Michael Snoyman 25 May '11

25 May '11

I'm concerned with introducing a new special character. Currently, #, @ and ^ all have special meaning wherever they are used, and \ has special meaning either at the beginning of the line or immediately following one of #@^. And I'm particularly concerned with using a common punctuation character to have a special meaning at the end of a line. How would we allow people to actually use an exclamation point? Michael On Wed, May 25, 2011 at 2:59 AM, Francisco José CHAVES ALONSO <pachopepe(a)gmail.com> wrote: > I think the same as Michael, for me implicit spaces could be confusing, > complex and unclear. > > In the other hand, I think that could be nice to unify the character for the > explicit space at beginning and end of line. > Maybe the '!' could be an interesting option, because the \ at the end of > line for some people could means to ignore the end of line or add an extra > line, and the # could be confusing with the interpolation at begining of > line, but, if followed (or preceded) with space, the ! will represent an > imperative space. Anyway if it is necesary one ! at the begining (or end of > line) preceded (or followed) by space could be escaped with !!. > > By example > > This paragraph has an ID and a class. It also has ! > bold > ! and ! > italic > , and shows you how to control whitespace! > > The ! in the last line is not an explicit space. > > Francisco > > > > Le 24/05/11 12:53, Michael Snoyman a écrit : > > If people really want this, I'll consider it. But it looks to me like > a like of confusion and complexity for very little gain. > > Michael > > On Tue, May 24, 2011 at 5:05 PM, Greg Weber <greg(a)gregweber.info> wrote: > > Yes, that is the idea- all the inner content or descendant nodes will now > have implicit spacing- adding a '>' to get the "huge win" scenario from the > examples given. I do think it adds confusion for new users- it isn't > something we would want to use in a tutorial. It would be a feature for > users already comfortable with Hamlet. Perhaps '>' is actually too > subtle. Some alternatives: > spaced> > S> > #> > < > > There is also a possibility of adding an indicator inside the tag. > <p=> > <p=spaced> > <p=#> > > > On Mon, May 23, 2011 at 11:22 PM, Mark Bradley <barkmadley(a)gmail.com> wrote: > > On Tue, May 24, 2011 at 4:13 PM, Michael Snoyman <michael(a)snoyman.com> > wrote: > > On Tue, May 24, 2011 at 7:00 AM, Greg Weber <greg(a)gregweber.info> wrote: > > The Yesod homepage looks like this: > > If you are new to Yesod, you should start off with # > <a href=@{FiveMinutesR}>the five minute start instructions > . The # > <a href=@{ScreencastsR}>screencasts > \ give a nice introduction to some of the advanced > concepts, and > # > <a href=@{BookR}>the book > \ is the recommended approach to learning Yesod. Ask the # > <a href=@{CommunityR}>commnunity > \ for help. > Allowing one-line tags in positions other than the very beginning > allows for > the removal of the '#' character: > > If you are new to Yesod, you should start off with > \ <a href=@{FiveMinutesR}>the five minute start > instructions > . The <a href=@{ScreencastsR}>screencasts > \ give a nice introduction to some of the advanced > concepts, and > \ <a href=@{BookR}>the book > \ is the recommended approach to learning Yesod. Ask the > \ <a href=@{CommunityR}>commnunity > \ for help. > Having implicit spaces is actually a huge win here: > > If you are new to Yesod, you should start off with > <a href=@{FiveMinutesR}>the five minute start instructions > The > <a href=@{ScreencastsR}>screencasts > give a nice introduction to some of the advanced concepts, > and > <a href=@{BookR}>the book > is the recommended approach to learning Yesod. Ask the > <a href=@{CommunityR}>commnunity > for help. > But I am wondering if it is best to keep things the way they are but > just > indicate when there should be implicit spaces. My thought is to somehow > use > angle brackets. Changing to > would indicate implicit spaces. > > What's the advantage of adding a new syntax for "implicit" space > versus just explicitly adding the space? > > I think he means that the child nodes of > would be affected by > some implicit spacing rules. > > Personally I prefer one consistent behaviour (explicit spacing every > time). Trying to get too smart will get confusing and inaccurate > quickly. > > Michael > > Greg Weber > On Fri, May 20, 2011 at 8:22 AM, Patrick Brisbin <pbrisbin(a)gmail.com> > wrote: > > On 05/20/11 at 11:12am, Daniel Patterson wrote: > > I think what the original author was saying was that when you make a > new > line with html, whitespace is inserted, not whether hamlet should > automatically insert space after every tag. > > So yes, writing hellothere should not put > white > spacing. > > But when you write, in html: > hello > there > > It is equivalent to hello there (note the > space). > > Isn't that simply due to the fact that HTML compresses whitespace > across > the board? (turning that "\n\t" or "\n " into just " ") > > Leading spaces in hamlet are used to define nesting, so also > compressing > this whitespace (rather than stripping it) would produce odd effects: > > <div> > Hey > there > > Would turn into > > <div> Hey there</div> > > Which has an unneeded space after the parent <div> > > Right? > > > On May 19, 2011, at 11:57 PM, Michael Snoyman wrote: > > On Thu, May 19, 2011 at 11:49 PM, Patrick Palka > <patrick(a)parcs.ath.cx> > wrote: > > I find it a bit unintuitive that the hamlet code > > hello > there > > or > > > hello > there > > generates the html > > hellothere > > I expected there to be a space between "hello" and "there" > similar to > what > the html specifications dictate. Is this behavior intentional or > an > oversight? If it's the former, then what is the recommended way > to > simulate > my expected behavior? Appending a space to the end of a line is > mentally ugly and syntactically obscure. > > I'm not sure what you mean by "what the html specifications > dictate." > HTML is whitespace-sensitive, meaning that: > > foo bar > > and > > foobar > > Are different. Now, in all likelihood in the above example, you > will > want to have the whitespace surrounding tags. But consider the > following HTML: > > You are logged in as Michael Snoyman, <a > href="/logout">logout</a>.Another paragraph. > > In the case of the and <a> tags, we definitely do *not* want > to > add whitespace after the tag (though we do want it before the > tag). In > the case of , we don't care one way or another, but adding the > whitespace everywhere will take up (a trivial amount of) extra > bandwidth. tl;dr: Sometimes you don't want the whitespace. > > So when designing Hamlet, I thought up a few possibilities: > > 1) What we do now: all whitespace must be explicit. > 2) Implicitly add whitespace before/after every tag. > 3) Do something "smart", adding whitespace where it's desired. > > (2) isn't really an option because it makes having a tag as the > last > word in a sentence impossible. (3) gives me the creeps: I like > smart > libraries, but I will *never* trust a library to do this kind of > stuff > correctly all the time, even if I'm the one making up the rules > for it > to follow! And I have no doubt that it will quickly devolve into > 500 > lines of hairy code to try and cover millions of corner cases. Oh, > and > don't forget that there are other languages than English that > might > approach it differently. > > I suppose another possibility is (2) along with some special way > of > forcing the removal of extra whitespace, but this seemed much less > intuitive than the current approach. > > Anyway, that's the reasoning behind this stuff, if people have > better > ideas, I'd like to hear them. > > Michael > > _______________________________________________ > web-devel mailing list > web-devel(a)haskell.org > http://www.haskell.org/mailman/listinfo/web-devel > > _______________________________________________ > web-devel mailing list > web-devel(a)haskell.org > http://www.haskell.org/mailman/listinfo/web-devel > > -- > patrick brisbin > > _______________________________________________ > web-devel mailing list > web-devel(a)haskell.org > http://www.haskell.org/mailman/listinfo/web-devel > > _______________________________________________ > web-devel mailing list > web-devel(a)haskell.org > http://www.haskell.org/mailman/listinfo/web-devel > > > _______________________________________________ > web-devel mailing list > web-devel(a)haskell.org > http://www.haskell.org/mailman/listinfo/web-devel > > > > -- > -barkmadley > sent from an internet enabled device > > _______________________________________________ > web-devel mailing list > web-devel(a)haskell.org > http://www.haskell.org/mailman/listinfo/web-devel > > >

1 0

[hamlet] implicit spaces with newlines?
by Patrick Palka 24 May '11

24 May '11

I find it a bit unintuitive that the hamlet code hello there or hello there generates the html hellothere I expected there to be a space between "hello" and "there" similar to what the html specifications dictate. Is this behavior intentional or an oversight? If it's the former, then what is the recommended way to simulate my expected behavior? Appending a space to the end of a line is mentally ugly and syntactically obscure.

7 14

Yesod. yesod-static
by Anton Cheshkov 20 May '11

20 May '11

Hello Michael, In new version of the *yesod-static-0.2.0* package the function "static" was changed. *static :: String -> FilePath -> IO Static* * * scaffold util (*yesod init*) does not support this new changes, and just scaffolded site does not work. Michael, please explain how to use new version of function. Thanks. -- Best regards, Cheshkov Anton

2 1

Embedding a persist key into a hamlet template
by Patrick Palka 19 May '11

19 May '11

What's the most idiomatic way of embedding a persist key into a hamlet template? (By persist key I mean a value of type Key a)

3 2

Database connection laziness (yesod)
by Jeremy Hughes 17 May '11

17 May '11

Another lazy question: > fun :: Int -> Int > > foo a = runReader ask (fun a) > > bar a = runReader (return 3) (fun a) foo causes (fun a) to be evaluated but bar doesn't. Is the same true for database connections? Are they created lazily? I ask because it would be neat to be able to write: > runDB $ getFromCache cache key where getFromCache queries the DB only on a cache miss, and have a connection created only in the case of a cache miss. I have tried test this myself, but I can't get ghci to cooperate and load yesod from source. Cheers, J

2 2

Exception Handling on GHandler monad level
by Anton Cheshkov 17 May '11

17 May '11

Hi Michael, i need to handle exception on GHandler monad level. We have: *type GHandler sub master = GGHandler<http://hackage.haskell.org/packages/archive/yesod-core/0.8.1/doc/html/Yesod…> sub master (Iteratee<http://hackage.haskell.org/packages/archive/enumerator/0.4.10/doc/html/Data…> ByteString<http://hackage.haskell.org/packages/archive/bytestring/0.9.1.10/doc/html/Da…> IO<http://hackage.haskell.org/packages/archive/base/4.3.1.0/doc/html/System-IO…> **)* * *data GGHandler sub master m a ... MonadControlIO<http://hackage.haskell.org/packages/archive/monad-control/0.2.0.1/doc/html/…> m => MonadControlIO<http://hackage.haskell.org/packages/archive/monad-control/0.2.0.1/doc/html/…> (GGHandler<http://hackage.haskell.org/packages/archive/yesod-core/0.8.1/doc/html/Yesod…> sub master m) *(Iteratee<http://hackage.haskell.org/packages/archive/enumerator/0.4.10/doc/html/Data…> ByteString<http://hackage.haskell.org/packages/archive/bytestring/0.9.1.10/doc/html/Da…> IO<http://hackage.haskell.org/packages/archive/base/4.3.1.0/doc/html/System-IO…> **) have no instance of * MonadControlIO<http://hackage.haskell.org/packages/archive/monad-control/0.2.0.1/doc/html/…> thus we got error: No instance for (MonadControlIO (Data.Enumerator.Iteratee Data.ByteString.Internal.ByteString IO)) arising from a use of `E.catch' Possible fix: add an instance declaration for (MonadControlIO (Data.Enumerator.Iteratee Data.ByteString.Internal.ByteString IO)) i need something like: * * *function :: Handler (Maybe Int)* *function = do * * res <- E.catch (runDB $ do * * action1* * action2* * ... * * return 1* * )* * (\(e :: E.SomeException) -> return 0)* How i can get this ? Thanks. -- Best regards, Cheshkov Anton Phone: +7 909 005 18 82 Skype: cheshkov_anton

2 1

Yesod: facebook plugin
by Mathew de Detrich 17 May '11

17 May '11

I am currently transferring my website from using the client side flow version of facebook to using the server side flow (with the facebookauth helper) using Yesod and I am having issues getting the facebook plugin working. One of the interesting things I noticed is that the redirect_uri that Yesod outputs for my website is https://graph.facebook.com/oauth/authorize?client_id= <REMOVED>&redirect_uri=http%3a%2f%2flocalhost%2fauth%2fpage%2ffacebook&scope=userEmail%2cuserName%2cuserPasswordHash%2cuserCountryCode%2cuserActivated" Now the way I read this, the field in your facebook app should be localhost/auth/page/faceboook/ however putting this gives the error that redirect_uri is not the same as specified in the application, so I changed this to the same as the destination route which is defined in YesodAuth as loginDest _ = RootR (so in this case its just localhost), however when doing this I get an error (from facebook) stating "Invalid Arguments" (I retrieve a HTML page with the following in the body) <body><h1>Invalid Arguments</h1><ul><li>No input found</li></ul></body> Is there a trivial example lying around implementing simple facebook login using Yesod

1 0

http-enumerator : Any way to get the headers first?
by Erik de Castro Lopo 16 May '11

16 May '11

Hi all, I'm continuing work on the HTTP proxy I'm writing. The absolute bare basics are working with Warp, Wai and http-enumerator as long as the upstream web server doesn't send gzipped or chunked data. For these later two cases, httpe-enumerator helpfully gunzips/unchunks the data. That however causes a problem. If my proxy simply passes the HTTP headers and data it gets from http-enumerator and passes then on to the client, the client barfs because the headers claim the data is gzipped or chunked and the data actually isn't chunked/gzipped. There are a number of possible solutions to this: a) Strip the content/transfer-encoding header and add a content-length header instead. I think this is probably possible with the API as it is, but I haven't figured out how yet. b) Rechunk or re-gzip the data. This seems rather wasteful of CPU resources. c) Modify the Network.Http.Enumerator.http function so that de-chunking/gunzipping is optional. d) Expose the iterHeaders function that is internal to the http-enumerator package so that client code can grab the headers before deciding how to handle the body. Are there any other options I haven't thought of yet? >From the options I have, I actually think d) makes the most sense, Would a patch exposing iterHeaders be accepted? Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

3 4

Yesod: Lambda Abstraction inside interpolation
by Mathew de Detrich 16 May '11

16 May '11

I came across a situation where I tried using lambda abstraction inside variable/template interpolation (when adding html with hamlet) and found out that the quasi quoter inside hamlet had issues parsing lambda abstractions (I am assuming due to the use of the '\' character). Is there some way to do lamdba abstraction inside hamlet quasiquoter, and if not will there be support added for this? Thanks

2 3