December 2010 - web-devel

Hamlet variables: (foo bar) baz or foo (bar baz)
by Michael Snoyman 03 Jan '11

03 Jan '11

I thought I would start this in a separate thread. Right now in Hamlet, $foo.bar.baz$ (or equivalently $foo bar baz$ gets converted to the Haskell code "foo (bar baz)". This makes a fair bit of sense for the period-delimited syntax, but feels very wrong for the space-delimited syntax. So the question is: should we change things around? That would mean we would need to modify our current templates to include extra parentheses, eg: $foo.bar.baz$ -> $foo (bar baz)$ $a.b.c.d$ -> $a (b (c d))$ I suppose that, in theory, if we actually change the variable interpolation character to a percent sign, we could take back the dollar sign to work like Haskell, eg: $a.b.c.d$ -> %a $ b $ c d% And just since I brought *that* up: we could consider using a different symbol for variable interpolation than the percent sign, such as a hash or ampersand. However, both of those already have special meaning (hash == id, ampersand == HTML escape character), so I don't know how well that would work. There was talk once upon a time of merging the syntax for dollar-sign and caret interpolation, which now that we've added some more polymorphism it might be possible. Caveat: I haven't actually written any code for this, so I don't know how feasible it is. I'm basically throwing out ideas as they come to me. Michael

5 6

rendering hamlet (esp julius) manually
by Max Cantor 01 Jan '11

01 Jan '11

I was wondering how to render a hamlet template (I'm specifically interested in julius - more on that later) outside of the context of a Handler handling a web request. The reason I want to do this is I have come client side javascript (for android and ios + phonegap) and it would be nice to use julius to automatically generate some javascript code for the xcode project. To be specific, i have a .js file like this: var URL_HOME = "http://localhost"; // var URL_HOME = "http://myhost"; var URL_PROFILE = URL_HOME + "/boo"; If its possible to render julius without a request, then I could do this: var URL_HOME = @HomeR@; var URL_PROFILE = @ProfileR@; and add a small executable to generate the JS file. So, how would one do this? Sorry if this is obvious, i spent some time trying and digging around the haddocks, didn't find an answer. happy new years, max

2 1

yesod-devel
by Christopher Done 31 Dec '10

31 Dec '10

This list only ever contains yesod posts and little else. Seeing as neither interest me I'm unsubscribing. FWIW.

1 0

Request body parsing in Yesod
by Michael Snoyman 31 Dec '10

31 Dec '10

One of the major changes coming in WAI 0.3 is how the request body is dealt with. I figure this is also a good time to address request body parsing in Yesod. I've put up a Wiki page[1] to describe my ideas. Input again is appreciated. Michael [1] http://wiki.yesodweb.com/Proper%20request%20body%20parsing

1 0

Hamlet variable interpolation syntax [previously: A few questions about Yesod]
by Alexander Dunlap 31 Dec '10

31 Dec '10

2010/12/30 Michael Snoyman <michael(a)snoyman.com>: > On Thu, Dec 30, 2010 at 3:31 PM, Iustin Pop <iustin(a)google.com> wrote: >> On Thu, Dec 30, 2010 at 03:09:16PM +0200, Michael Snoyman wrote: >>> Very good questions, answers below. >>> >>> On Thu, Dec 30, 2010 at 1:01 PM, Iustin Pop <iustin(a)google.com> wrote: >>> > Hi all, >>> > >>> > I just started looking at Yesod and its associated libs (hamlet, etc.) >>> > and it is very interesting, thanks. >>> > >>> > However, I'm confused by a few things and the docs are not helping, so >>> > please bear my beginner questions. >>> > >>> > First: hamlet uses '.' as function application, instead of the usual >>> > space. How can I then use a qualified name (e.g. Data.List.nub)? If I >>> > use it normally, it errors out on me. Must be something very trivial but >>> > I cannot find a way. >>> >>> Hamlet uses both '.' and space as function application, and therefore >>> qualified names are not supported. I work around this usually by >>> creating an alias for the function I want locally. I know this can be >>> inelegant; if you have any ideas, I'm all ears. >> >> Yep, that's what I'm using too now, but it becomes cumbersome quickly, >> especially when using records… >> >> I'm not sure what was the original impetus to use . (too) as function >> application if space is accepted too. I'm thinking reverting that >> decision would make the code look more like regular Haskell. >> >> A simpler alternative (not sure if easily doable) would be to allow >> escaping of the dot, e.g. $Data\.List\.nub.mylist$; it's ugly, but… > > It actually went the other way: period first, and space added by > request. Originally, Hamlet variables were not directly mapped to > Haskell function calls. Instead, it was meant to parallel variable > lookup in common template languages from the object-oriented world. > Another impetus is because of statements like forall and maybe: > > $forall allPeople.myFamily person > %li $person name$ > > This can also be written as > > $forall (allPeople myFamily) person > > You could argue that the latter is more legible; my problem with the > space is for cases with more than two functions in the chain. $foo bar > baz$ gets converted to the Haskell code "foo (bar baz)". > > I'll admit that this whole situation bothers me as well. Hamlet 0.7 is > currently in the works, and I don't mind introducing some major > changes. I think this issue deserves some attention: what does > everyone else think? Maybe we should start a separate thread to > discuss this issue in particular. > Would there be a problem with removing the dot syntax entirely and just having regular Haskell syntax for variable interpretation? That might be more flexible and easier to learn. Alexander

6 11

A few questions about Yesod
by Iustin Pop 30 Dec '10

30 Dec '10

Hi all, I just started looking at Yesod and its associated libs (hamlet, etc.) and it is very interesting, thanks. However, I'm confused by a few things and the docs are not helping, so please bear my beginner questions. First: hamlet uses '.' as function application, instead of the usual space. How can I then use a qualified name (e.g. Data.List.nub)? If I use it normally, it errors out on me. Must be something very trivial but I cannot find a way. Second: Yesod.Json says “Due to the limited nature of the JSON format, you can create any valid JSON document you wish using only jsonScalar, jsonList and jsonMap”. This seems false to me, as jsonScalar only deals with JSON strins, and not JSON numbers or the constants (true, false, null). In the meantime I'm using a hack for numbers using jsonRaw, but I think some more functionality needs to be added to it for non-trivial usage. And last: I don't understand how runDB and the persistent framework is supposed to do error handling. Case in point: let's say one tries to insert a duplicate unique key in a table, which fails as expected "user error (SQLite3 returned ErrorConstraint while attempting to perform step.)". The problem is any other use of that particular REST resource, even with different parameters, results in "user error (SQLite3 returned ErrorMisuse while attempting to perform bind text.)", and I don't know if this is due to my usage of the framework or due to something else. The interesting part is that other resources are working fine. Thanks again, iustin

2 3

Beta version of Yesod 0.7
by Greg Weber 29 Dec '10

29 Dec '10

Have you tried using cabal-dev for this? This seems like a good usage for it- getting things back to normal would mean just blowing away the project local cabal directory. Or does cabal-dev not work with wai-devel-handler? > Hi all, > > I've been working on the 0.7 release of Yesod. Unfortunately, getting > all of the dependencies from Github can be a bit of a pain, so I don't > think anyone besides the core team is testing it at all. Hopefully, we > can change this: I've just created a Yackage[1] server for Yesod[2]. > If you want to start playing with Yesod 0.7, all you need to do is: > > 1) Modify your ~/.cabal/config file to include: remote-repo: > yesodyackage:http://yackage.yesodweb.com/ > 2) cabal update > 3) cabal install yesod-0.7.0 > > That should do it! A few caveats: > > * There are likely still bugs, as this is not finished software > * With yesod 0.7, we are splitting things into many more packages. Not > all of these packages are automatically installed yet (eg, > yesod-static), even though previous versions of Yesod included this > functionality. > * If you install in this manner, cabal will *not* know to replace > these packages with the final packages released to Hackage ultimately. > At that point in time, you can: > > 1) manually unregister all packages installed from Yackage > 2) manually "cabal install --reinstall" all packages installed from Yackage > 3) wipe our your ~/.ghc folder and start from scratch > > Depending on how things go, I might start using odd-second-numbers to > denote beta versions of the software, and therefore avoid a lot of > these issues. If that becomes the case, then odd-second-numbers would > never appear on Hackage, only on Yackage. > > Let me know if you have any issues! > > Michael > > [1] http://hackage.haskell.org/package/yackage > [2] http://yackage.yesodweb.com/ > > > > ------------------------------ > > _______________________________________________ > web-devel mailing list > web-devel(a)haskell.org > http://www.haskell.org/mailman/listinfo/web-devel > > > End of web-devel Digest, Vol 16, Issue 22 > ***************************************** >

1 0

Beta version of Yesod 0.7
by Michael Snoyman 28 Dec '10

28 Dec '10

Hi all, I've been working on the 0.7 release of Yesod. Unfortunately, getting all of the dependencies from Github can be a bit of a pain, so I don't think anyone besides the core team is testing it at all. Hopefully, we can change this: I've just created a Yackage[1] server for Yesod[2]. If you want to start playing with Yesod 0.7, all you need to do is: 1) Modify your ~/.cabal/config file to include: remote-repo: yesodyackage:http://yackage.yesodweb.com/ 2) cabal update 3) cabal install yesod-0.7.0 That should do it! A few caveats: * There are likely still bugs, as this is not finished software * With yesod 0.7, we are splitting things into many more packages. Not all of these packages are automatically installed yet (eg, yesod-static), even though previous versions of Yesod included this functionality. * If you install in this manner, cabal will *not* know to replace these packages with the final packages released to Hackage ultimately. At that point in time, you can: 1) manually unregister all packages installed from Yackage 2) manually "cabal install --reinstall" all packages installed from Yackage 3) wipe our your ~/.ghc folder and start from scratch Depending on how things go, I might start using odd-second-numbers to denote beta versions of the software, and therefore avoid a lot of these issues. If that becomes the case, then odd-second-numbers would never appear on Hackage, only on Yackage. Let me know if you have any issues! Michael [1] http://hackage.haskell.org/package/yackage [2] http://yackage.yesodweb.com/

1 0

Re: [web-devel] [Yesod] How to write a field as binary data column.
by Felipe Almeida Lessa 27 Dec '10

27 Dec '10

[Please reply to the list as well :-)] 2010/12/27 いとうかつとし <cutsea110(a)gmail.com>: > Umm, This(B.concate . L.toChunks) don't work. > an inserted data is incomplete, which is dropped from invisible characters. > In my case , the image file with binary data as > "GIF89a^\NUL\NUL\213\&3\NUL...", > only "GIF89a^"(7bytes) can be stored. > I think I have to escape a binary data. > If ByteString field type means binary, I expect the yesod framework to > escape automatically. > How about? That's strange and sounds like a bug. I'm using the same (B.concat . L.toChunks) trick and it works very well for me. Are you using up-to-date versions of all libraries? Cheers! -- Felipe.

2 1

Re: [web-devel] [Yesod] How to write a field as binary data column.
by Felipe Almeida Lessa 27 Dec '10

27 Dec '10

2010/12/27 いとうかつとし <cutsea110(a)gmail.com>: > I tryed ByteString import from Data.ByteString. > Rather, This field's type is Data.ByteString.Internal.ByteString, > on the other hand, fileContent of posted file's content is > Data.ByteString.Lazy.Internal.ByteString. > then, i translateed by B.concat . L.toChunks > imported from Data.ByteString as B and Data.ByteString.Lazy as L. > 1. this is right solution? > 2. could the yesod framework automatically transform lazy <=> strict? > because i think posted file's content is always lazy, but we serialize > the content as strict. 1. Yes, I think it is the right solution to convert lazy to strict bytestrings. 2. No, because sometimes you want one, and sometimes you want the other. And converting is a potentially costly operation. I haven't tried and I don't know if there are any bad/good consequences, but you may try using a lazy bytestring in your model. In other words, use lazy bytestrings everywhere. Cheers, -- Felipe.

1 0