- web-devel - Haskell.org

Re: [web-devel] [Yesod] Creating a static link
by Michael Snoyman 13 Feb '11

13 Feb '11

On Sun, Feb 13, 2011 at 5:26 PM, Rafael Cunha de Almeida <rafael-lists(a)kontesti.me> wrote: > Michael Snoyman <michael(a)snoyman.com> disse: >> You could go either way on that one. The content of an interpolation >> is specifically *not* a fully-powered Haskell expression. > > Why is that? I have a little experience with RoR, there I could do > something like this: > > - @people.each do |person| > = person.name > > I think you don't want to have a fully-powered Haskell expression to > avoid people adding too much code to the view (thinking in MVC pattern). > However, it's not like people can't do it just because it's a little > harder. Meanwhile, there are a lot of useful things that could be done > if all (or most) haskell syntax was allowed to be interpolated. > > Instead of having special syntax like $forall, wouldn't it be better to > just provide monad tranformers to allow for those sort of loops? > Something like Control.Monad.LoopWhile module provides. That way hamlet > would need only to provide a ${} syntax that allow for adding haskell > code which will be evaluated but won't print anything to the site. That > way things could work a lot like in ruby, which I think makes things a > lot simpler. > > Allowing for a new sort of interpolation and any sort of haskell > expression to be interpolated, hamlet wouldn't need to create its own > flow control statements. The user could write their views freely using > only haskell syntax when code logic is required. There's a few reasons for this: 1) I do *not* think it is a good thing for a template language to expose the full power of the programming language. As it is, I think Hamlet already stretches the bounds of what a designer would feel comfortable with. 2) This needs to get coded at some point, and frankly I don't feel like completely reinventing a full-blown Haskell parser. I'm aware of packages like haskell-src-exts-qq, but they are very heavy-weight and introduce a huge body of possible bugs/unanticipated behavior to Hamlet. 3) I'm not quite certain how you would intend to completely replace all of the control structures with some variable splicing, I think that would require further elucidation. However, I *highly* doubt it will come out as concise as a forall statement currently is. My goal for Hamlet isn't to provide absolute power in templates: it's to provide a user-friendly, terse syntax to achieve 95% of what people want to do easily. And for that extra 5%, it's very easy to call out to a helper Haskell function. The list syntax itself does not really bother me, though it does just beg the question of where we draw the line. For instance, I have *no* intention of implementing do-notation inside an interpolation. To bring up Dmitry's suggestion: operators introduce all kinds of precedence issues, since we won't have access to the precedence levels Haskell is aware of. I think barking up *that* tree is a recipe for very unintuitive behavior. Michael

2 3

Re: [web-devel] [Yesod] Creating a static link
by Dmitry Kurochkin 13 Feb '11

13 Feb '11

On Sun, 13 Feb 2011 13:26:24 -0200, Rafael Cunha de Almeida <rafael-lists(a)kontesti.me> wrote: > Michael Snoyman <michael(a)snoyman.com> disse: > > You could go either way on that one. The content of an interpolation > > is specifically *not* a fully-powered Haskell expression. > > Why is that? I have a little experience with RoR, there I could do > something like this: > > - @people.each do |person| > = person.name > > I think you don't want to have a fully-powered Haskell expression to > avoid people adding too much code to the view (thinking in MVC pattern). > However, it's not like people can't do it just because it's a little > harder. Meanwhile, there are a lot of useful things that could be done > if all (or most) haskell syntax was allowed to be interpolated. > > Instead of having special syntax like $forall, wouldn't it be better to > just provide monad tranformers to allow for those sort of loops? > Something like Control.Monad.LoopWhile module provides. That way hamlet > would need only to provide a ${} syntax that allow for adding haskell > code which will be evaluated but won't print anything to the site. That > way things could work a lot like in ruby, which I think makes things a > lot simpler. > > Allowing for a new sort of interpolation and any sort of haskell > expression to be interpolated, hamlet wouldn't need to create its own > flow control statements. The user could write their views freely using > only haskell syntax when code logic is required. > I join the question! I have some style-related constants in Style module, e.g. sizes and colors. Then I want to do computations using these constants in Cassius, something similar to SCSS. E.g. width: #{Style.width1 + Style.width2} (not talking about appending "px" suffix for now). Currently, because of artificial limitations on Hamlet interpolations, I have to define (plus = (+)) (minus = (-)) and so on. Would be nice if it allowed full-featured Haskell. Regards, Dmitry > []'s > Rafael > > _______________________________________________ > web-devel mailing list > web-devel(a)haskell.org > http://www.haskell.org/mailman/listinfo/web-devel

2 1

[Yesod] Creating a static link
by Rafael Cunha de Almeida 13 Feb '11

13 Feb '11

Hello, >From what I could gather, the way to create a link to a static page, like a picture is: StaticR $ StaticRoute ["figure.png"] [] I wanted to add a static picture in my site's template so I added <img alt="" src=@{StaticR $ StaticRoute ["figure.png"] []}> to my template. Unfortunately, that didn't work. It seems like creating lists inside @{} or even #{} is impossible. For instance #{head ["test"]} doesn't work either. Is that a bug? Or is it how it's supposed to work?

3 5

Yesod. Routes. Resources. Authorization. ACL
by Антон Чешков 12 Feb '11

12 Feb '11

Hi Michael. I want to make authorization in Yesod application build on ACL principle. We have in Yesod "*Routes*". *"Route"* is resource. I have the list : *Resource | Access* ---------------------------------- RouteA | Allow RouteB | Deny I would like to : 1. save, read this list outward yesod 2. check, that the concrete route satisfy or not satisfy the list 3. have more flexible way to define *resource pattern* in list. For example i have *RouteX String Int. *I wish to define pattern * "RouteX * 666"* * * If i had this, i would to implement *Yesod.isAuthorized* method similar *isAuthorized _ = do* * acl <- getACL* * route <- getCurrentRoute* * case check acl route of* * True -> return Authorized* * **False -> return Unauthorized* * * * * I do not know, may be there is the way to make this now. How i can put it into practice ? Thanks. -- Best regards, Cheshkov Anton Phone: +7 909 005 18 82 Skype: cheshkov_anton

2 1

[Yesod][Auth][OpenId]
by いとうかつとし 12 Feb '11

12 Feb '11

Hi, I have a question. OpenId plugin in yesod-auth 0.2.0.3 don't support OP identifier? for example, i try japanese SNS mixi.jp, Claimed identifier: https://id.mixi.jp/<myid> => success and login my developed site. OP identifier: https://mixi.jp => fail!! I success to login to mixi, but mixi say the error message: `Given OpenID is not yours, your OpenID is http://id.mixi.jp/<myid>. confirm and try again.' the mixi's developer center say mixi 's OP identifier is https://mixi.jp. anyone success to login by using OP identifier? regards.

3 4

Re: [web-devel] Rich Internet Applications using Haskell
by Greg Weber 10 Feb '11

10 Feb '11

I am just going to chime in with links to a few tools that might be useful that you probably already know about :) Algebraic Data Types in JavaScript http://w3future.com/weblog/stories/2008/06/16/adtinjs.xml Javascript Pattern Matching http://www.bramstein.com/projects/junify/ Javascript Arrows http://blog.tupil.com/look-ma-no-callbacks/ haskell client-server state transferring http://blog.on-a-horse.org/

2 1

Rich Internet Applications using Haskell
by Bardur Arantsson 10 Feb '11

10 Feb '11

Hi all, I just though I'd let y'all know that I've started work on "Dingo", a small framework for creating Rich Internet Applications (RIA) in Haskell. The basic idea is that you write Haskell code and the framework generates all the browser-related bits you need (HTML, JS, state serialization, etc.) at runtime. Writing an application is centered around Widgets and Events which are just what you'd expect if you were writing a Gtk+/Swing/SWT/Qt application. The way the application starts is that you provide a "start the application" callback to a "runServer" function. When a client connects to the server the first time, the "main" callback gets run and can set up the main application widget however it wants. There's a basic example in Main (see attachment). It doesn't really do much interesting, but it does demonstrate that state transfer and updates (client->server and server->client) work and that events work at a basic level. I've attached a tarball of my not-even-close-to-pre-alpha code -- I won't bother putting this on Hackage since it's not actually useful for any real work yet. To get something working in a browser ASAP I've taken some... uhm, liberties with code quality, so I will not be held responsible for self-induced eye-gouging as a result of looking at the code. The current status is basically: * Uses Happstack-server for serving HTTP. Given Dingo's extremely simple serving needs it may be a bit of a "heavy" dependency, but it works for now and it's not really a high priority to change this. It's also definitely NOT eye-gouging-inducing, so that's a plus :). * Only very simple widgets are included: A "panel" container widget (corresponds to an unstyled <div/> currently) and "input", "select" and "button" elements (corresponding to their HTML counterparts). The idea is that Panel will be expanded to a more general container which can lay out subwidgets horizontally or vertically. * ALL mutable widget state is transferred to/from the browser for every callback. This isn't an issue with the simple example in Main.hs, but it might become an issue for larger widget hierarchies. * Only ONE client supported at a time. You read that right. Weird things will happen if you try to connect multiple clients. Immediate plans: * Find a better way to handle state transfer to lessen the burden of having to write JSON <-> JS and JSON <-> server-state translations by hand. I'm thinking that some of the ideas from the "Invertible Syntax" paper ( http://www.informatik.uni-marburg.de/~rendel/unparse/rendel10invertible.pdf ) may apply for this. Text.JSON.Generic may also be workable, but I had some trouble getting it to work with Text values and it doesn't help with generating the widget-specific JavaScript. * On a related note, I need a better way of generating JavaScript than string concatenation. Unfortunately, HJScript seems to be *too* strict about typing. * Expand the selection of widgets with more complex widgets so that I can get a feel for how the current Widget type class may need to be generalized/tweaked. Something requiring CSS would be good too, so I can hopefully get a basic theming mechanism down. * Get rid of the "one client only" limitation so that Dingo may actually become somewhat useful in practice. * A way of tracking client-side and server-side updates so that only things that have actually changed are transferred between client and server. For the server side this should be easy enough and for the client I'm thinking of something like attaching a "change()" event handler to all relevant DOM elements. Comments and suggestions appreciated. Cheers,

2 2

Re: [web-devel] [Haskell-cafe] http-enumerator: redirects, streaming and keep-alive
by Felipe Almeida Lessa 07 Feb '11

07 Feb '11

On Wed, Feb 2, 2011 at 6:30 PM, Antoine Latter <aslatter(a)gmail.com> wrote: > Or you could remove the socket from the map while it's in use. And what about connection limits? We shouldn't create a thousand connections to the same host =). -- Felipe.

2 1

big executables in Yesod 0.7
by Dmitry Olshansky 07 Feb '11

07 Feb '11

Hi, I tried Yesod 0.7 (congratulations with new release!) and found that executables are too big. The reason is yesod -> wai-handler-devel -> hint dependency. In production it is not needed probably. Could it be refactored later in some way? Best regards, Dima

2 1

http-enumerator decisions
by Michael Snoyman 07 Feb '11

07 Feb '11

Hi everyone, I'm starting to make plans for http-enumerator 0.4, which will include keep-alive support, proper streaming request bodies and *hopefully* user controlled certificate checking. I say hopefully because that really depends on being able to stop using the OpenSSL backend. I know that I'm personally using it in my production systems because one of its dependencies, the AES package, does not compile on 32-bit systems. My question is, does anyone have other reasons for using the OpenSSL backend which should stop me from making such a transition? Thanks, Michael

1 0