From bouanto at vivaldi.net Wed Jan 14 00:14:18 2015 From: bouanto at vivaldi.net (Antoni Boucher) Date: Tue, 13 Jan 2015 19:14:18 -0500 Subject: [web-devel] How to create Cassius Mixin? Message-ID: <20150114001417.GB3023@bouanto-laptop.ri.cgocable.ca> Hello. How can I create a CSS mixin with Cassius (from Yesod Haskell Web Framework) ? For instance, this code: transition val = [cassiusMixin| -webkit-transition: #{val} -moz-transition: #{val} -ms-transition: #{val} -o-transition: #{val} transition: #{val} |] does not work because cassiusMixin does not exist. Is there a way to create a mixin with cassius? If not, is cassius a limited version of lucius? Thanks. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From michael at snoyman.com Wed Jan 14 06:44:36 2015 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 14 Jan 2015 06:44:36 +0000 Subject: [web-devel] How to create Cassius Mixin? References: <20150114001417.GB3023@bouanto-laptop.ri.cgocable.ca> Message-ID: One answer is that Cassius is just a thin wrapper on top of Lucius. You can use a Lucius mixin with Cassius just fine. It's essentially an API oversight that there's no equivalent cassiusMixin function. I'll probably add one in the next few days, thanks for pointing it out. On Wed Jan 14 2015 at 2:14:26 AM Antoni Boucher wrote: > Hello. > > How can I create a CSS mixin with Cassius (from Yesod Haskell Web > Framework) ? > > For instance, this code: > > transition val = [cassiusMixin| > -webkit-transition: #{val} > -moz-transition: #{val} > -ms-transition: #{val} > -o-transition: #{val} > transition: #{val} > |] > > does not work because cassiusMixin does not exist. > > Is there a way to create a mixin with cassius? > > If not, is cassius a limited version of lucius? > > Thanks. > _______________________________________________ > web-devel mailing list > web-devel at haskell.org > http://www.haskell.org/mailman/listinfo/web-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Wed Jan 14 06:51:20 2015 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 14 Jan 2015 06:51:20 +0000 Subject: [web-devel] How to create Cassius Mixin? References: <20150114001417.GB3023@bouanto-laptop.ri.cgocable.ca> Message-ID: Actually, that turned out to be pretty easy. Now up on Hackage as shakespeare-2.0.3. Let me know if there are problems. On Wed Jan 14 2015 at 8:44:34 AM Michael Snoyman wrote: > One answer is that Cassius is just a thin wrapper on top of Lucius. You > can use a Lucius mixin with Cassius just fine. It's essentially an API > oversight that there's no equivalent cassiusMixin function. I'll probably > add one in the next few days, thanks for pointing it out. > > On Wed Jan 14 2015 at 2:14:26 AM Antoni Boucher > wrote: > >> Hello. >> >> How can I create a CSS mixin with Cassius (from Yesod Haskell Web >> Framework) ? >> >> For instance, this code: >> >> transition val = [cassiusMixin| >> -webkit-transition: #{val} >> -moz-transition: #{val} >> -ms-transition: #{val} >> -o-transition: #{val} >> transition: #{val} >> |] >> >> does not work because cassiusMixin does not exist. >> >> Is there a way to create a mixin with cassius? >> >> If not, is cassius a limited version of lucius? >> >> Thanks. >> _______________________________________________ >> web-devel mailing list >> web-devel at haskell.org >> http://www.haskell.org/mailman/listinfo/web-devel >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwanikibusiness at gmail.com Mon Feb 16 18:58:08 2015 From: mwanikibusiness at gmail.com (Njagi Mwaniki) Date: Mon, 16 Feb 2015 21:58:08 +0300 Subject: [web-devel] Payroll app Message-ID: <54E23DC0.9090104@gmail.com> I am wondering how to go about having users create user accounts and then use those accounts to create payrolls. A payroll is a set of payslips associated with a certain user. What I currently have is an auth system that uses openID. I am thinking of associating a payroll and subsequently the payslips in the payroll with the email address of the currently logged in user but I am not sure how to go about that. Second, I don't want to limit users to the kind of allowances and deductions they can enter. So in the web form they are going to have a button they can use to add fields of a key value pair for example one can add an allowance field and add [House_allowance] [3000]. This will be part of a payslip. However, these extra fields can't be added to the Payslip type because the additional fields are added through JS. So I shall have a separate type `Extra` to store this map where `data Extra = Extra { Allowance:: [(Text, Int)], Deduction :: [Text, Int]}` I can convert this map to a PersistentValue in GHCI but I have no idea how to represent it in the config/models file. How can I show in my config/models that I want to store this map in the DB and associate it with the relevant payslip? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From jos at vandenoever.info Fri Mar 6 08:58:49 2015 From: jos at vandenoever.info (Jos van den Oever) Date: Fri, 06 Mar 2015 09:58:49 +0100 Subject: [web-devel] proxy with wai Message-ID: <2532726.txKQVhyJZM@joga> Hello all, I'm studying the Yesod book by Michael Snoyman and I'm slowly coming to grips with Haskell for the web. My current goal is to write an http(s) proxy that does filtering and caching. I've found a nice example by Snoyman on github: https://gist.github.com/snoyberg/8779671 This code does not compile with wai >= 3 because that does not have responseSourceBracket any more. What is the best way to replace it? --- Wai.responseSourceBracket (HCl.responseOpen req2 man) (HCl.responseClose) $ \res -> do let body = mapOutput (Chunk . fromByteString) $ HCC.bodyReaderSource $ HCl.responseBody res headers = filter safeResHeader $ HCl.responseHeaders res return (HCl.responseStatus res, headers, body) ---- Best regards, Jos van den Oever From michael at snoyman.com Sun Mar 8 07:28:30 2015 From: michael at snoyman.com (Michael Snoyman) Date: Sun, 08 Mar 2015 07:28:30 +0000 Subject: [web-devel] proxy with wai In-Reply-To: <2532726.txKQVhyJZM@joga> References: <2532726.txKQVhyJZM@joga> Message-ID: I've updated that Gist to be compatible with WAI 3.0. The basic changes I made were: 1. Change the way Warp settings are applied (no longer use record syntax, but explicit set* functions). 2. conduit is no longer the standard streaming interface for WAI, so imported Network.Wai.Conduit and used helper functions from there. 3. The specific question you asked about: the semantics for how to do resource allocation in an application have changed. There were some holes in the previous approach that allowed async exceptions to leak in at the wrong time. Instead, WAI 3.0 uses a similar interface to most resource allocation functions in Haskell (like bracket or withFile). Specifically, this looks like: HCl.withResponse req2 man $ \res -> do let body = mapOutput (Chunk . fromByteString) $ HCC.bodyReaderSource $ HCl.responseBody res headers = filter safeResHeader $ HCl.responseHeaders res respond $ responseSource (HCl.responseStatus res) headers body Some notes on this are available at: * http://hackage.haskell.org/package/wai-3.0.2.3/docs/Network-Wai.html#t:Application * http://www.yesodweb.com/book/web-application-interface#web-application-interface_resource_allocation On Fri, Mar 6, 2015 at 10:58 AM Jos van den Oever wrote: Hello all, > > I'm studying the Yesod book by Michael Snoyman and I'm slowly coming to > grips > with Haskell for the web. > > My current goal is to write an http(s) proxy that does filtering and > caching. > I've found a nice example by Snoyman on github: > https://gist.github.com/snoyberg/8779671 > > This code does not compile with wai >= 3 because that does not have > responseSourceBracket any more. What is the best way to replace it? > > --- > Wai.responseSourceBracket (HCl.responseOpen req2 man) (HCl.responseClose) $ > \res -> do > let body = mapOutput (Chunk . fromByteString) $ > HCC.bodyReaderSource $ > HCl.responseBody res > headers = filter safeResHeader $ HCl.responseHeaders res > return (HCl.responseStatus res, headers, body) > ---- > > Best regards, > Jos van den Oever > _______________________________________________ > web-devel mailing list > web-devel at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/web-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jos at vandenoever.info Sat Mar 21 09:32:37 2015 From: jos at vandenoever.info (Jos van den Oever) Date: Sat, 21 Mar 2015 10:32:37 +0100 Subject: [web-devel] proxy with wai In-Reply-To: References: <2532726.txKQVhyJZM@joga> Message-ID: <1819736.cOMVWQpjGK@joga> On Sunday 08 March 2015 07:28:30 Michael Snoyman wrote: > I've updated that Gist to be compatible with WAI 3.0. Thank you very much. I've been studying that code and have successfully made a proxy on top of Warp and am now adding a user interface on top with Yesod. I've made a tweak to the code a bit. In the gist you throw out most of the request and response headers. I've found that it's enough to only throw away the content-encoding and content-length headers: headers = filter removeEncodingHeaders $ HCl.responseHeaders res respond $ WC.responseSource (HCl.responseStatus res) headers body where -- remove encoding information removeEncodingHeaders (k, _) = k `notElem` [ "content-encoding", "content- length" ] Cheers, Jos From michael at snoyman.com Tue Mar 24 07:01:39 2015 From: michael at snoyman.com (Michael Snoyman) Date: Tue, 24 Mar 2015 07:01:39 +0000 Subject: [web-devel] proxy with wai In-Reply-To: <1630943.aBsKPoqIFY@joga> References: <2532726.txKQVhyJZM@joga> <1630943.aBsKPoqIFY@joga> Message-ID: On Sun, Mar 22, 2015 at 10:01 AM Jos van den Oever wrote: > On Sunday 08 March 2015 07:28:30 you wrote: > > I've updated that Gist to be compatible with WAI 3.0. The basic changes I > > made were: > > > > 1. Change the way Warp settings are applied (no longer use record syntax, > > but explicit set* functions). > > 2. conduit is no longer the standard streaming interface for WAI, so > > imported Network.Wai.Conduit and used helper functions from there. > > 3. The specific question you asked about: the semantics for how to do > > resource allocation in an application have changed. There were some holes > > in the previous approach that allowed async exceptions to leak in at the > > wrong time. Instead, WAI 3.0 uses a similar interface to most resource > > allocation functions in Haskell (like bracket or withFile). Specifically, > > this looks like: > > > > > > HCl.withResponse req2 man $ \res -> do > > let body = mapOutput (Chunk . fromByteString) $ > > HCC.bodyReaderSource $ HCl.responseBody res > > headers = filter safeResHeader $ HCl.responseHeaders res > > respond $ responseSource (HCl.responseStatus res) headers body > > I'd like my proxy to be a caching proxy so each request shoule be saved to > a > file. I've tried adding an additional sink, (sinkFile) or conduit > (conduitFie) > to the HCC.bodyReaderSource, but cannot it right. What would be a good way > to > do this? > > > What have you tried so far? Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From jos at vandenoever.info Thu Mar 26 19:10:24 2015 From: jos at vandenoever.info (Jos van den Oever) Date: Thu, 26 Mar 2015 20:10:24 +0100 Subject: [web-devel] proxy with wai In-Reply-To: References: <2532726.txKQVhyJZM@joga> <1630943.aBsKPoqIFY@joga> Message-ID: <7115280.UuOaKPKk8s@joga> On Tuesday 24 March 2015 07:01:39 Michael Snoyman wrote: > On Sun, Mar 22, 2015 at 10:01 AM Jos van den Oever > > wrote: > > On Sunday 08 March 2015 07:28:30 you wrote: > > > I've updated that Gist to be compatible with WAI 3.0. The basic changes > > > I > > > made were: > > > > > > 1. Change the way Warp settings are applied (no longer use record > > > syntax, > > > but explicit set* functions). > > > 2. conduit is no longer the standard streaming interface for WAI, so > > > imported Network.Wai.Conduit and used helper functions from there. > > > 3. The specific question you asked about: the semantics for how to do > > > resource allocation in an application have changed. There were some > > > holes > > > in the previous approach that allowed async exceptions to leak in at the > > > wrong time. Instead, WAI 3.0 uses a similar interface to most resource > > > allocation functions in Haskell (like bracket or withFile). > > > Specifically, > > > > > > this looks like: > > > HCl.withResponse req2 man $ \res -> do > > > > > > let body = mapOutput (Chunk . fromByteString) $ > > > > > > HCC.bodyReaderSource $ HCl.responseBody res > > > > > > headers = filter safeResHeader $ HCl.responseHeaders res > > > > > > respond $ responseSource (HCl.responseStatus res) headers body > > > > I'd like my proxy to be a caching proxy so each request shoule be saved to > > a > > file. I've tried adding an additional sink, (sinkFile) or conduit > > (conduitFie) > > to the HCC.bodyReaderSource, but cannot it right. What would be a good way > > to > > do this? > > What have you tried so far? This is the code I have so far. I've annotated with a types. This code gives a compile error because of the line 'source2 = bodySource C.=$= fileSaver'. The MonadResource is not arising from the use in fileSaver. Somehow, I've to get runResourceT in there. === HCl.withResponse req2 man $ \res -> do --saver <- CB.conduitFile "/tmp/out" let path = "/tmp/out" :: FilePath fileSaver :: MonadResource m => C.Conduit S8.ByteString m S8.ByteString fileSaver = CB.conduitFile path bodyReader :: HCl.BodyReader bodyReader = HCl.responseBody res bodySource :: MonadIO m => C.ConduitM () S8.ByteString m () bodySource = HCC.bodyReaderSource bodyReader source2 = bodySource C.=$= fileSaver chunk :: S8.ByteString -> C.Flush Builder chunk = C.Chunk . fromByteString body :: C.ConduitM () (C.Flush Builder) IO() body = C.mapOutput chunk source2 headers = filter removeEncodingHeaders $ HCl.responseHeaders res time <- getPOSIXTime runSqlPool (insert_ $ Response (round time) reqid Nothing) pool respond $ WC.responseSource (HCl.responseStatus res) headers body === Cheers, Jos From michael at snoyman.com Fri Mar 27 05:03:18 2015 From: michael at snoyman.com (Michael Snoyman) Date: Fri, 27 Mar 2015 05:03:18 +0000 Subject: [web-devel] proxy with wai In-Reply-To: <7115280.UuOaKPKk8s@joga> References: <2532726.txKQVhyJZM@joga> <1630943.aBsKPoqIFY@joga> <7115280.UuOaKPKk8s@joga> Message-ID: Can you provide: * A complete file * The error messages you're getting On Thu, Mar 26, 2015 at 9:10 PM Jos van den Oever wrote: > On Tuesday 24 March 2015 07:01:39 Michael Snoyman wrote: > > On Sun, Mar 22, 2015 at 10:01 AM Jos van den Oever > > > > > wrote: > > > On Sunday 08 March 2015 07:28:30 you wrote: > > > > I've updated that Gist to be compatible with WAI 3.0. The basic > changes > > > > I > > > > made were: > > > > > > > > 1. Change the way Warp settings are applied (no longer use record > > > > syntax, > > > > but explicit set* functions). > > > > 2. conduit is no longer the standard streaming interface for WAI, so > > > > imported Network.Wai.Conduit and used helper functions from there. > > > > 3. The specific question you asked about: the semantics for how to do > > > > resource allocation in an application have changed. There were some > > > > holes > > > > in the previous approach that allowed async exceptions to leak in at > the > > > > wrong time. Instead, WAI 3.0 uses a similar interface to most > resource > > > > allocation functions in Haskell (like bracket or withFile). > > > > Specifically, > > > > > > > > this looks like: > > > > HCl.withResponse req2 man $ \res -> do > > > > > > > > let body = mapOutput (Chunk . fromByteString) $ > > > > > > > > HCC.bodyReaderSource $ HCl.responseBody res > > > > > > > > headers = filter safeResHeader $ HCl.responseHeaders res > > > > > > > > respond $ responseSource (HCl.responseStatus res) headers > body > > > > > > I'd like my proxy to be a caching proxy so each request shoule be > saved to > > > a > > > file. I've tried adding an additional sink, (sinkFile) or conduit > > > (conduitFie) > > > to the HCC.bodyReaderSource, but cannot it right. What would be a good > way > > > to > > > do this? > > > > What have you tried so far? > > This is the code I have so far. I've annotated with a types. This code > gives a > compile error because of the line 'source2 = bodySource C.=$= fileSaver'. > The > MonadResource is not arising from the use in fileSaver. Somehow, I've to > get > runResourceT in there. > > === > HCl.withResponse req2 man $ \res -> do > --saver <- CB.conduitFile "/tmp/out" > > let path = "/tmp/out" :: FilePath > fileSaver :: MonadResource m => C.Conduit S8.ByteString m > S8.ByteString > fileSaver = CB.conduitFile path > bodyReader :: HCl.BodyReader > bodyReader = HCl.responseBody res > bodySource :: MonadIO m => C.ConduitM () S8.ByteString m () > bodySource = HCC.bodyReaderSource bodyReader > source2 = bodySource C.=$= fileSaver > chunk :: S8.ByteString -> C.Flush Builder > chunk = C.Chunk . fromByteString > body :: C.ConduitM () (C.Flush Builder) IO() > body = C.mapOutput chunk source2 > headers = filter removeEncodingHeaders $ HCl.responseHeaders > res > > time <- getPOSIXTime > runSqlPool (insert_ $ Response (round time) reqid Nothing) pool > respond $ WC.responseSource (HCl.responseStatus res) headers body > === > > Cheers, > Jos > > > > _______________________________________________ > web-devel mailing list > web-devel at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/web-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jos at vandenoever.info Fri Mar 27 08:01:44 2015 From: jos at vandenoever.info (Jos van den Oever) Date: Fri, 27 Mar 2015 09:01:44 +0100 Subject: [web-devel] proxy with wai In-Reply-To: References: <2532726.txKQVhyJZM@joga> <7115280.UuOaKPKk8s@joga> Message-ID: <6909664.ToJUOar1MJ@joga> On Friday 27 March 2015 05:03:18 Michael Snoyman wrote: > Can you provide: > > * A complete file > * The error messages you're getting Of course. ===================== No instance for (MonadResource IO) arising from a use of `fileSaver' In the second argument of `(C.=$=)', namely `fileSaver' In the expression: bodySource C.=$= fileSaver In an equation for `source2': source2 = bodySource C.=$= fileSaver HttpWrite.hs /proxy/src line 35 Haskell Problem ===================== I know that I should somehow put some of the code a runResourceT, but I cannot figure out how to combine it with Wai.Application. Cheers, Jos -------------- next part -------------- A non-text attachment was scrubbed... Name: HttpWrite.hs Type: text/x-haskell Size: 2204 bytes Desc: not available URL: From michael at snoyman.com Fri Mar 27 09:17:11 2015 From: michael at snoyman.com (Michael Snoyman) Date: Fri, 27 Mar 2015 09:17:11 +0000 Subject: [web-devel] proxy with wai In-Reply-To: <6909664.ToJUOar1MJ@joga> References: <2532726.txKQVhyJZM@joga> <7115280.UuOaKPKk8s@joga> <6909664.ToJUOar1MJ@joga> Message-ID: Probably the most expedient thing is to use `withFile` to get a Handle, and then use `conduitHandle` instead of `conduitFile`. However, if you want to use ResourceT, it's certainly possible, but a bit hairier: runResourceT $ withInternalState $ \is -> do respond $ WC.responseSource (HCl.responseStatus res) headers $ C.transPipe (flip runInternalState is) body On Fri, Mar 27, 2015 at 11:01 AM Jos van den Oever wrote: > On Friday 27 March 2015 05:03:18 Michael Snoyman wrote: > > Can you provide: > > > > * A complete file > > * The error messages you're getting > > Of course. > > ===================== > No instance for (MonadResource IO) > arising from a use of `fileSaver' > In the second argument of `(C.=$=)', namely `fileSaver' > In the expression: bodySource C.=$= fileSaver > In an equation for `source2': source2 = bodySource C.=$= fileSaver > HttpWrite.hs /proxy/src line 35 Haskell Problem > ===================== > > I know that I should somehow put some of the code a runResourceT, but I > cannot > figure out how to combine it with Wai.Application. > > Cheers, > Jos > _______________________________________________ > web-devel mailing list > web-devel at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/web-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kanirudh54 at gmail.com Sat Apr 25 03:15:11 2015 From: kanirudh54 at gmail.com (K Sai Anirudh) Date: Fri, 24 Apr 2015 23:15:11 -0400 Subject: [web-devel] Yesod Mform and hamlet Message-ID: Hi, I am new to yesod and following the documentation to make a form. In the documentation the form template was created in .hs file itself. But I have a separate hamlet where I want to customize. I want to access "fields" in my hamlet file. The expected type of 'generateFormPost' is (xml, Enctype) . Can anybody tell me what I should be returning from 'tableMform extra' . I think it should be in xml format. But I think I should not be using toWidget as in below example of documentation. tableMform extra = do fields <- forM lis (\(w,h) -> mopt intField "this is not used" (Just h) ) return (fields) ---I know this line has the type error. Can anybody suggest how to deal with it {- --I am referring this code from yesod website to make my form. In this it was using runFormGet, but I want use generateFormPost and moreover it was creating a widget which is used in displaying the website. I don't want to create the widget here but in my hamlet file where the 'fields' is accessed via interpolation. personForm :: Html -> MForm Handler (FormResult Person, Widget) personForm extra = do (nameRes, nameView) <- mreq textField "this is not used" Nothing (ageRes, ageView) <- mreq intField "neither is this" Nothing let personRes = Person <$> nameRes <*> ageRes let widget = do toWidget [lucius| ##{fvId ageView} { width: 3em; } |] [whamlet| #{extra}

Hello, my name is # ^{fvInput nameView} \ and I am # ^{fvInput ageView} \ years old. # |] return (personRes, widget) -} getHomeR :: Handler Html getHomeR = defaultLayout $ do -- Generate the form to be displayed (fields, enctype) <- generateFormPost tableMform let (fires,fiview) = unzip fields $(widgetFile "layout") |] Please let me know if there is any misunderstanding. I have idea of how to get the form from the way done in the documentation, but I want to use a separate hamlet file, as I want to customize the look of the form. -- Thanks Sai Anirudh Kondaveeti -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Sat Apr 25 17:53:33 2015 From: michael at snoyman.com (Michael Snoyman) Date: Sat, 25 Apr 2015 17:53:33 +0000 Subject: [web-devel] Yesod Mform and hamlet In-Reply-To: References: Message-ID: I've asked for some clarification on the relevant SO question: http://stackoverflow.com/questions/29859284/yesod-mform-and-hamlet On Sat, Apr 25, 2015 at 6:15 AM K Sai Anirudh wrote: > Hi, > > I am new to yesod and following the documentation to make a form. In the > documentation the form template was created in .hs file itself. But I have > a separate hamlet where I want to customize. > > I want to access "fields" in my hamlet file. The expected type of > 'generateFormPost' is (xml, Enctype) . Can anybody tell me what I should be > returning from 'tableMform extra' . I think it should be in xml format. But > I think I should not be using toWidget as in below example of documentation. > > tableMform extra = do > fields <- forM lis (\(w,h) -> mopt intField "this is not used" (Just h) ) > return (fields) ---I know this line has the type error. Can anybody suggest how to deal with it > > {- > --I am referring this code from yesod website to make my form. In this it was using runFormGet, but I want use generateFormPost and moreover it was creating a widget which is used in displaying the website. I don't want to create the widget here but in my hamlet file where the 'fields' is accessed via interpolation. > > personForm :: Html -> MForm Handler (FormResult Person, Widget) > personForm extra = do > (nameRes, nameView) <- mreq textField "this is not used" Nothing > (ageRes, ageView) <- mreq intField "neither is this" Nothing > let personRes = Person <$> nameRes <*> ageRes > let widget = do > toWidget > [lucius| > ##{fvId ageView} { > width: 3em; > } > |] > [whamlet| > #{extra} >

> Hello, my name is # > ^{fvInput nameView} > \ and I am # > ^{fvInput ageView} > \ years old. # > > |] > return (personRes, widget) > > -} > > getHomeR :: Handler Html > getHomeR = defaultLayout $ do > -- Generate the form to be displayed > (fields, enctype) <- generateFormPost tableMform > let (fires,fiview) = unzip fields > $(widgetFile "layout") > |] > > Please let me know if there is any misunderstanding. I have idea of how to > get the form from the way done in the documentation, but I want to use a > separate hamlet file, as I want to customize the look of the form. > > -- > Thanks > Sai Anirudh Kondaveeti > _______________________________________________ > web-devel mailing list > web-devel at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/web-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex323 at gmail.com Sat May 16 12:03:10 2015 From: alex323 at gmail.com (Alex) Date: Sat, 16 May 2015 08:03:10 -0400 Subject: [web-devel] Monad transformers with Warp/WAI Message-ID: <20150516080310.7987e42c@gmail.com> Hello: I am writing a small application which receives HTTP requests, translates them to JSON, and queues the requests using RabbitMQ. I created a Monad transformer stack (ReaderT AppConfig IO a) to carry around my application configuration and AMQP connection handle (MVar Connection within AppConfig), but I am having difficulty determining how to integrate it with my Warp application. The function which is responsible for accepting Requests and returning Responses (app :: Application) needs to call functions which require AppConfig. For example: (sendToRabbitMQ :: RPCRequest -> MyApp ByteString) is a blocking call which requires the AMQP connection handle found within AppConfig, which is why it returns a MyApp ByteString as opposed to a IO ByteString. If I want to call `sendToRabbitMQ' from `app', then the type of `app' needs to change from Application to something else, but I am not sure what that should be. What's the best way to proceed? -- Alex From michael at snoyman.com Sat May 16 18:30:31 2015 From: michael at snoyman.com (Michael Snoyman) Date: Sat, 16 May 2015 18:30:31 +0000 Subject: [web-devel] Monad transformers with Warp/WAI In-Reply-To: <20150516080310.7987e42c@gmail.com> References: <20150516080310.7987e42c@gmail.com> Message-ID: Typically it would look something like this: myApp :: AppConfig -> Application main = do appConfig <- getAppConfig run 3000 $ myApp appConfig Within myApp, you can now access the AppConfig value and use runReaderT to unwrap your MyApp transformer. On Sat, May 16, 2015 at 3:03 PM Alex wrote: > Hello: > > I am writing a small application which receives HTTP requests, > translates them to JSON, and queues the requests using RabbitMQ. > > I created a Monad transformer stack (ReaderT AppConfig IO a) to carry > around my application configuration and AMQP connection handle (MVar > Connection within AppConfig), but I am having difficulty determining how > to integrate it with my Warp application. > > The function which is responsible for accepting Requests and returning > Responses (app :: Application) needs to call functions which require > AppConfig. For example: (sendToRabbitMQ :: RPCRequest -> MyApp > ByteString) is a blocking call which requires the AMQP connection > handle found within AppConfig, which is why it returns a MyApp > ByteString as opposed to a IO ByteString. If I want to call > `sendToRabbitMQ' from `app', then the type of `app' needs to change > from Application to something else, but I am not sure what that should > be. > > What's the best way to proceed? > > -- > Alex > _______________________________________________ > web-devel mailing list > web-devel at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/web-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex323 at gmail.com Sat May 16 19:05:48 2015 From: alex323 at gmail.com (Alex) Date: Sat, 16 May 2015 15:05:48 -0400 Subject: [web-devel] Monad transformers with Warp/WAI In-Reply-To: References: <20150516080310.7987e42c@gmail.com> Message-ID: <20150516150548.0c8c047b@gmail.com> On Sat, 16 May 2015 18:30:31 +0000 Michael Snoyman wrote: > Typically it would look something like this: > > myApp :: AppConfig -> Application > > main = do > appConfig <- getAppConfig > run 3000 $ myApp appConfig > > Within myApp, you can now access the AppConfig value and use > runReaderT to unwrap your MyApp transformer. > Is a consequence of this design that I have to use runReaderT every time I want to use a function of the type (Foo -> MyApp Bar) from within myApp? Is it better/easier to simply rewrite the all functions myApp calls so that they accept an AppConfig parameter instead of returning a MyApp Bar? -- Alex From michael at snoyman.com Sat May 16 19:15:33 2015 From: michael at snoyman.com (Michael Snoyman) Date: Sat, 16 May 2015 19:15:33 +0000 Subject: [web-devel] Monad transformers with Warp/WAI In-Reply-To: <20150516150548.0c8c047b@gmail.com> References: <20150516080310.7987e42c@gmail.com> <20150516150548.0c8c047b@gmail.com> Message-ID: On Sat, May 16, 2015 at 10:05 PM Alex wrote: > On Sat, 16 May 2015 18:30:31 +0000 > Michael Snoyman wrote: > > > Typically it would look something like this: > > > > myApp :: AppConfig -> Application > > > > main = do > > appConfig <- getAppConfig > > run 3000 $ myApp appConfig > > > > Within myApp, you can now access the AppConfig value and use > > runReaderT to unwrap your MyApp transformer. > > > > Is a consequence of this design that I have to use runReaderT every > time I want to use a function of the type (Foo -> MyApp Bar) from within > myApp? Is it better/easier to simply rewrite the all functions myApp > calls so that they accept an AppConfig parameter instead of returning a > MyApp Bar? > > -- > Alex > That's one approach. You can also do something like: myApp appConfig req respond = flip runReaderT appConfig $ do someFunc ... someFunc :: MyApp () -------------- next part -------------- An HTML attachment was scrubbed... URL: From felipe.lessa at gmail.com Fri May 22 23:06:18 2015 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Fri, 22 May 2015 20:06:18 -0300 Subject: [web-devel] ANN: nonce package Message-ID: <555FB66A.9000904@gmail.com> (Please forgive me if you received multiple copies of this e-mail.) Hello, The nonce package [1] contains functions to easily generate cryptographic nonces for many situations. Some places where these generated nonces can be used include: - Password recovery e-mail tokens. - XSRF protection tokens. - Session IDs sent on cookies. - Initialization vectors. It uses an AES CPRNG periodically reseeded from /dev/urandom (or equivalent). It has no frills, no knobs, so it's hard to misuse. It's been available for an year but I just realized I've never properly announced it. Regrettably, I've seen many uses of the random package (System.Random) when generating nonces. It's a bad choice: it is not a cryptographically secure PRNG, contains low entropy (64-bit state), and its default usage is seeded predictably (using a constant seed). Please avoid using the random package for generating nonces at all costs. In its stead, use the nonce package or something similar. Cheers, [1] http://hackage.haskell.org/package/nonce -- Felipe. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From thomas at koch.ro Sat May 23 13:49:07 2015 From: thomas at koch.ro (Thomas Koch) Date: Sat, 23 May 2015 15:49:07 +0200 Subject: [web-devel] [Haskell-cafe] no Web-Security component in Haskell? In-Reply-To: <2608800.UApO9Nzphg@x121e> References: <2608800.UApO9Nzphg@x121e> Message-ID: <3365849.1UF3EEsXps@x121e> // moving the question with more info from haskell-cafe to web-devel Hallo, I already wrote a message with the same subject to haskell-cafe without reply. I did not found anything comparable to Spring Security[1][2] (Java) or Symfony Security[3] (PHP) in Haskell. Both components are used in web applications to grant or deny access to resources based on roles, ACLs or custom voters. [1] http://projects.spring.io/spring-security [2] http://docs.spring.io/autorepo/docs/spring-security/3.1.7.RELEASE/apidocs [3] http://api.symfony.com/master/Symfony/Component/Security/Core/SecurityContext.html A naive strategy would be to port the concepts of both components, which are very similar, to Haskell. They represent a lot of accumulated knowledge from many experts about web security. Or are there better ways to do web security in a powerful language like Haskell? There was some unfinished role-based-access-control effort in snap[4] that has been removed from git now. [4] https://groups.google.com/forum/#!topic/snap_framework/yUgSEVpP2GE There seem to be a more modern (and more complex) thing than Role-Based- Access-Control now, XACML[5] which is used inside Red Hats JBoss[6]. [5] http://en.wikipedia.org/wiki/XACML [6] http://picketlink.org/about Regards, Thomas Koch From ajnsit at gmail.com Tue Jun 9 22:54:12 2015 From: ajnsit at gmail.com (Anupam Jain) Date: Wed, 10 Jun 2015 04:24:12 +0530 Subject: [web-devel] ANN: Wai routes 0.7 Message-ID: Hi all, I have just released v0.7 of wai-routes, the typesafe urls framework for wai. After letting the code rot for several months, I finally managed to carve out some time to do a bit of housekeeping. The code now compiles with ghc 7.8 and 7.10, and is compatible with wai-3.0. The dependency on yesod-routes has also been removed, as that package was deprecated, and its code has been folded into wai-routes. I also took the opportunity to add a few long pending features - 1. Subsites! Simpler than the corresponding concept in Yesod, though probably less powerful as well. This is still an evolving experimental feature. 2. Ability to get information about the currently executing route, including the Route Attributes (which is exactly the same thing as in Yesod). Get it at - [http://hackage.haskell.org/package/wai-routes] [https://github.com/ajnsit/wai-routes]. Feedback would be greatly appreciated, especially from people using wai-routes in their projects! -- Anupam From ajnsit at gmail.com Wed Jun 10 19:18:45 2015 From: ajnsit at gmail.com (Anupam Jain) Date: Thu, 11 Jun 2015 00:48:45 +0530 Subject: [web-devel] [Yesod] Re: ANN: Wai routes 0.7 In-Reply-To: <29ca0d82-527a-4060-9304-3d67b2c7efc2@googlegroups.com> References: <29ca0d82-527a-4060-9304-3d67b2c7efc2@googlegroups.com> Message-ID: You are right. The example in the README is meant to be more of a template which gives you a flavor of what the code looks like. It also has chunks of code missing (and with ellipses in its place) that would need to be filled in before it would compile. The code in the examples/ directory on github has working code examples with cabal files (https://github.com/ajnsit/wai-routes/blob/master/examples/Subsites.hs). I am working on improving the documentation, and adding more examples. To answer your other questions - 1. I just released v0.7 today. Docs on Hackage are built periodically, and we should have proper documentation generated soon. 2. The TH code generates a "resource" for your route which is like an abstract representation of your route declaration. It can be reused in other parts of the code. Notably it is useful when you want to separate the declaration for the Route datatype and the dispatching code. In your example, since the resource is created but not used or exported, it generates a warning. For now you can safely ignore it. 3. "HandlerS sub master" is the type of a handler for a Subsite "sub" running within a master site "master". Unfortunately that type is not very easy to work with. "HandlerM" is a Monadic type that provides easy access to all wai-routes functionality, and can then be converted to a HandlerS using runHandlerM. When you don't have a subsite, the type is simply "HandlerM sub master", which is aliased to "Handler master". That's why in your example, the handlers all have the type "Handler MyRoute". 4. "RouteM" is another Monadic type which makes it easy to compose multiple routes and middleware together to create a final wai application. This along with "nested routes", and "subsites", helps you better organise your application. HTH -- Anupam On Wed, Jun 10, 2015 at 8:38 PM, Njagi Mwaniki wrote: > It could be just me but the example in your README is totally broken. It > needs at least the extensions like QuasiQotes and TemplateHaskell. Also > where does DB (used in your example) come from? > > Anyway using other examples from your README I got a minimal working example > here: https://gist.github.com/urbanslug/58a584c002f54ad75c02 > > I have a few questions regarding the types. > > * The haddocks on hackage don't work yet, do they? > * in myRoute L21 I get the warning `Defined but not used: > ?resourcesMyRoute?` can you help with that? > * I'm confused about this type signature "runHandlerM :: HandlerM sub master > () -> HandlerS sub master" > * What are HandlerM and RouteM and sub and master? They are in many type > signatures and I don't get them. > > Thank you. > > On Wednesday, 10 June 2015 01:54:33 UTC+3, Anupam wrote: >> >> Hi all, >> >> I have just released v0.7 of wai-routes, the typesafe urls framework >> for wai. After letting the code rot for several months, I finally >> managed to carve out some time to do a bit of housekeeping. The code >> now compiles with ghc 7.8 and 7.10, and is compatible with wai-3.0. >> The dependency on yesod-routes has also been removed, as that package >> was deprecated, and its code has been folded into wai-routes. >> >> I also took the opportunity to add a few long pending features - >> 1. Subsites! Simpler than the corresponding concept in Yesod, though >> probably less powerful as well. This is still an evolving experimental >> feature. >> 2. Ability to get information about the currently executing route, >> including the Route Attributes (which is exactly the same thing as in >> Yesod). >> >> Get it at - >> [http://hackage.haskell.org/package/wai-routes] >> [https://github.com/ajnsit/wai-routes]. >> >> Feedback would be greatly appreciated, especially from people using >> wai-routes in their projects! >> >> -- Anupam > > -- > You received this message because you are subscribed to the Google Groups > "Yesod Web Framework" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to yesodweb+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. From greg at gregweber.info Fri Jun 12 16:26:43 2015 From: greg at gregweber.info (Greg Weber) Date: Fri, 12 Jun 2015 09:26:43 -0700 Subject: [web-devel] [Yesod] Re: ANN: Wai routes 0.7 In-Reply-To: References: <29ca0d82-527a-4060-9304-3d67b2c7efc2@googlegroups.com> <9b45722f-3ec2-4968-9568-6116ef149819@googlegroups.com> Message-ID: On Fri, Jun 12, 2015 at 9:10 AM, Anupam Jain wrote: > Glad you figured it out! The html function accepts Bytestring instead > of Text to be compatible with blaze-html. I will probably add a > htmlText function which supports Text instead and works seamlessly > with Hamlet et all. > Hamlet itself uses blaze-html so I think you should be able to avoid encodings altogether > > One minor thing I notices in your code - it converts from Lazy Text -> > Strict Text -> Strict ByteString -> Lazy ByteString > If you use encodeUtf8 from Data.Text.Lazy.Encoding, you can go > directly from Lazy ByteString -> Lazy Text. > > -- Anupam > > > On Fri, Jun 12, 2015 at 5:16 PM, Njagi Mwaniki > wrote: > > Never mind. I found a way to make it work here: > > https://github.com/urbanslug/cats/blob/master/Handler/Home.hs > > > > > > On Friday, 12 June 2015 12:08:44 UTC+3, Njagi Mwaniki wrote: > >> > >> Hey, I am trying to use shakesperean templates with this. I just can't > get > >> it to work. Even in a quasiqote widget kind of way. What am I doing > wrong? > >> or is this not supported at all. I would like to finally use external > files > >> for hamlet lucius and julius. I could show you my code but it's just a > ball > >> of wool so I won't even bother. > >> > >> On Wednesday, 10 June 2015 22:19:06 UTC+3, Anupam wrote: > >>> > >>> You are right. The example in the README is meant to be more of a > >>> template which gives you a flavor of what the code looks like. It also > >>> has chunks of code missing (and with ellipses in its place) that would > >>> need to be filled in before it would compile. The code in the > >>> examples/ directory on github has working code examples with cabal > >>> files > >>> (https://github.com/ajnsit/wai-routes/blob/master/examples/Subsites.hs > ). > >>> I am working on improving the documentation, and adding more examples. > >>> > >>> To answer your other questions - > >>> > >>> 1. I just released v0.7 today. Docs on Hackage are built periodically, > >>> and we should have proper documentation generated soon. > >>> > >>> 2. The TH code generates a "resource" for your route which is like an > >>> abstract representation of your route declaration. It can be reused in > >>> other parts of the code. Notably it is useful when you want to > >>> separate the declaration for the Route datatype and the dispatching > >>> code. In your example, since the resource is created but not used or > >>> exported, it generates a warning. For now you can safely ignore it. > >>> > >>> 3. "HandlerS sub master" is the type of a handler for a Subsite "sub" > >>> running within a master site "master". Unfortunately that type is not > >>> very easy to work with. "HandlerM" is a Monadic type that provides > >>> easy access to all wai-routes functionality, and can then be converted > >>> to a HandlerS using runHandlerM. When you don't have a subsite, the > >>> type is simply "HandlerM sub master", which is aliased to "Handler > >>> master". That's why in your example, the handlers all have the type > >>> "Handler MyRoute". > >>> > >>> 4. "RouteM" is another Monadic type which makes it easy to compose > >>> multiple routes and middleware together to create a final wai > >>> application. This along with "nested routes", and "subsites", helps > >>> you better organise your application. > >>> > >>> HTH > >>> > >>> -- Anupam > >>> > >>> > >>> > >>> On Wed, Jun 10, 2015 at 8:38 PM, Njagi Mwaniki > >>> wrote: > >>> > It could be just me but the example in your README is totally broken. > >>> > It > >>> > needs at least the extensions like QuasiQotes and TemplateHaskell. > Also > >>> > where does DB (used in your example) come from? > >>> > > >>> > Anyway using other examples from your README I got a minimal working > >>> > example > >>> > here: https://gist.github.com/urbanslug/58a584c002f54ad75c02 > >>> > > >>> > I have a few questions regarding the types. > >>> > > >>> > * The haddocks on hackage don't work yet, do they? > >>> > * in myRoute L21 I get the warning `Defined but not used: > >>> > ?resourcesMyRoute?` can you help with that? > >>> > * I'm confused about this type signature "runHandlerM :: HandlerM sub > >>> > master > >>> > () -> HandlerS sub master" > >>> > * What are HandlerM and RouteM and sub and master? They are in many > >>> > type > >>> > signatures and I don't get them. > >>> > > >>> > Thank you. > >>> > > >>> > On Wednesday, 10 June 2015 01:54:33 UTC+3, Anupam wrote: > >>> >> > >>> >> Hi all, > >>> >> > >>> >> I have just released v0.7 of wai-routes, the typesafe urls framework > >>> >> for wai. After letting the code rot for several months, I finally > >>> >> managed to carve out some time to do a bit of housekeeping. The code > >>> >> now compiles with ghc 7.8 and 7.10, and is compatible with wai-3.0. > >>> >> The dependency on yesod-routes has also been removed, as that > package > >>> >> was deprecated, and its code has been folded into wai-routes. > >>> >> > >>> >> I also took the opportunity to add a few long pending features - > >>> >> 1. Subsites! Simpler than the corresponding concept in Yesod, though > >>> >> probably less powerful as well. This is still an evolving > experimental > >>> >> feature. > >>> >> 2. Ability to get information about the currently executing route, > >>> >> including the Route Attributes (which is exactly the same thing as > in > >>> >> Yesod). > >>> >> > >>> >> Get it at - > >>> >> [http://hackage.haskell.org/package/wai-routes] > >>> >> [https://github.com/ajnsit/wai-routes]. > >>> >> > >>> >> Feedback would be greatly appreciated, especially from people using > >>> >> wai-routes in their projects! > >>> >> > >>> >> -- Anupam > >>> > > >>> > -- > >>> > You received this message because you are subscribed to the Google > >>> > Groups > >>> > "Yesod Web Framework" group. > >>> > To unsubscribe from this group and stop receiving emails from it, > send > >>> > an > >>> > email to yesodweb+u... at googlegroups.com. > >>> > For more options, visit https://groups.google.com/d/optout. > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Yesod Web Framework" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to yesodweb+unsubscribe at googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "haskell-wai" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to haskell-wai+unsubscribe at googlegroups.com. > To post to this group, send email to haskell-wai at googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/haskell-wai/CAKit5aCsbqp_gmhxFzSnKDz8d0eO4tEFRiMgmMcQ0miBusHL8w%40mail.gmail.com > . > For more options, visit https://groups.google.com/d/optout. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at gregweber.info Fri Jun 12 16:28:57 2015 From: greg at gregweber.info (Greg Weber) Date: Fri, 12 Jun 2015 09:28:57 -0700 Subject: [web-devel] [Yesod] ANN: Wai routes 0.7 In-Reply-To: References: Message-ID: To me, wai-routes seems like a full web framework and a re-implementation of Yesod (I am not suggesting that it is a bad thing). Is that its goal? On Tue, Jun 9, 2015 at 3:54 PM, Anupam Jain wrote: > Hi all, > > I have just released v0.7 of wai-routes, the typesafe urls framework > for wai. After letting the code rot for several months, I finally > managed to carve out some time to do a bit of housekeeping. The code > now compiles with ghc 7.8 and 7.10, and is compatible with wai-3.0. > The dependency on yesod-routes has also been removed, as that package > was deprecated, and its code has been folded into wai-routes. > > I also took the opportunity to add a few long pending features - > 1. Subsites! Simpler than the corresponding concept in Yesod, though > probably less powerful as well. This is still an evolving experimental > feature. > 2. Ability to get information about the currently executing route, > including the Route Attributes (which is exactly the same thing as in > Yesod). > > Get it at - > [http://hackage.haskell.org/package/wai-routes] > [https://github.com/ajnsit/wai-routes]. > > Feedback would be greatly appreciated, especially from people using > wai-routes in their projects! > > -- Anupam > > -- > You received this message because you are subscribed to the Google Groups > "Yesod Web Framework" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to yesodweb+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at gregweber.info Sat Jun 13 18:53:59 2015 From: greg at gregweber.info (Greg Weber) Date: Sat, 13 Jun 2015 11:53:59 -0700 Subject: [web-devel] [Yesod] ANN: Wai routes 0.7 In-Reply-To: References: Message-ID: Thanks for the explanation. I have a small function for applying different middleware to different routes that I put up on a pull request now. https://github.com/yesodweb/wai/pull/384 On Fri, Jun 12, 2015 at 11:09 AM, Anupam Jain wrote: > Ah great question! One that I keep revisiting in my mind every time I > think of adding something to wai-routes. Short answer - No. Long > answer follows. > > Wai-routes' stated goal is to "provide a similar level of typesafe URL > functionality to Wai applications as is available to Yesod > applications". The feature list may make it seem like a larger > framework, but it's really all just features provided by the routing > code from yesod! Writing plain wai apps is tough though, so wai-routes > provides a thin veneer over some of the rough edges, just enough to > make it pleasant. > > Sometimes the simplicity of wai-routes makes it easier to use than > Yesod. For example, it is really easy to have multiple independent > route sets that match one after the other, so you can better logically > group your app, instead of putting all routes in one big file. You can > also apply different middleware to the different route sets. I'm > currently not aware of any way to do that in Yesod. > > The de-coupling from wai also insulates the user from changes to the > wai api. So the same wai-routes code continued to work when Wai-3.0 > changed to a CPS style. ...Though that leaves the user vulnerable to > changes in the wai-routes api... which happens quite more often... So, > forget I said that! :) > > -- Anupam > > > On Fri, Jun 12, 2015 at 9:58 PM, Greg Weber wrote: > > To me, wai-routes seems like a full web framework and a > re-implementation of > > Yesod (I am not suggesting that it is a bad thing). Is that its goal? > > > > On Tue, Jun 9, 2015 at 3:54 PM, Anupam Jain wrote: > >> > >> Hi all, > >> > >> I have just released v0.7 of wai-routes, the typesafe urls framework > >> for wai. After letting the code rot for several months, I finally > >> managed to carve out some time to do a bit of housekeeping. The code > >> now compiles with ghc 7.8 and 7.10, and is compatible with wai-3.0. > >> The dependency on yesod-routes has also been removed, as that package > >> was deprecated, and its code has been folded into wai-routes. > >> > >> I also took the opportunity to add a few long pending features - > >> 1. Subsites! Simpler than the corresponding concept in Yesod, though > >> probably less powerful as well. This is still an evolving experimental > >> feature. > >> 2. Ability to get information about the currently executing route, > >> including the Route Attributes (which is exactly the same thing as in > >> Yesod). > >> > >> Get it at - > >> [http://hackage.haskell.org/package/wai-routes] > >> [https://github.com/ajnsit/wai-routes]. > >> > >> Feedback would be greatly appreciated, especially from people using > >> wai-routes in their projects! > >> > >> -- Anupam > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "Yesod Web Framework" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an > >> email to yesodweb+unsubscribe at googlegroups.com. > >> For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Yesod Web Framework" group. > > > > To unsubscribe from this group and stop receiving emails from it, send an > > email to yesodweb+unsubscribe at googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "haskell-wai" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to haskell-wai+unsubscribe at googlegroups.com. > To post to this group, send email to haskell-wai at googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/haskell-wai/CAKit5aAcYFP4v24-9ZqV-XdZkgk5VOZR4cbgyzjPBT5jmKBdrg%40mail.gmail.com > . > For more options, visit https://groups.google.com/d/optout. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajnsit at gmail.com Fri Jun 12 16:10:17 2015 From: ajnsit at gmail.com (Anupam Jain) Date: Fri, 12 Jun 2015 21:40:17 +0530 Subject: [web-devel] [Yesod] Re: ANN: Wai routes 0.7 In-Reply-To: <9b45722f-3ec2-4968-9568-6116ef149819@googlegroups.com> References: <29ca0d82-527a-4060-9304-3d67b2c7efc2@googlegroups.com> <9b45722f-3ec2-4968-9568-6116ef149819@googlegroups.com> Message-ID: Glad you figured it out! The html function accepts Bytestring instead of Text to be compatible with blaze-html. I will probably add a htmlText function which supports Text instead and works seamlessly with Hamlet et all. One minor thing I notices in your code - it converts from Lazy Text -> Strict Text -> Strict ByteString -> Lazy ByteString If you use encodeUtf8 from Data.Text.Lazy.Encoding, you can go directly from Lazy ByteString -> Lazy Text. -- Anupam On Fri, Jun 12, 2015 at 5:16 PM, Njagi Mwaniki wrote: > Never mind. I found a way to make it work here: > https://github.com/urbanslug/cats/blob/master/Handler/Home.hs > > > On Friday, 12 June 2015 12:08:44 UTC+3, Njagi Mwaniki wrote: >> >> Hey, I am trying to use shakesperean templates with this. I just can't get >> it to work. Even in a quasiqote widget kind of way. What am I doing wrong? >> or is this not supported at all. I would like to finally use external files >> for hamlet lucius and julius. I could show you my code but it's just a ball >> of wool so I won't even bother. >> >> On Wednesday, 10 June 2015 22:19:06 UTC+3, Anupam wrote: >>> >>> You are right. The example in the README is meant to be more of a >>> template which gives you a flavor of what the code looks like. It also >>> has chunks of code missing (and with ellipses in its place) that would >>> need to be filled in before it would compile. The code in the >>> examples/ directory on github has working code examples with cabal >>> files >>> (https://github.com/ajnsit/wai-routes/blob/master/examples/Subsites.hs). >>> I am working on improving the documentation, and adding more examples. >>> >>> To answer your other questions - >>> >>> 1. I just released v0.7 today. Docs on Hackage are built periodically, >>> and we should have proper documentation generated soon. >>> >>> 2. The TH code generates a "resource" for your route which is like an >>> abstract representation of your route declaration. It can be reused in >>> other parts of the code. Notably it is useful when you want to >>> separate the declaration for the Route datatype and the dispatching >>> code. In your example, since the resource is created but not used or >>> exported, it generates a warning. For now you can safely ignore it. >>> >>> 3. "HandlerS sub master" is the type of a handler for a Subsite "sub" >>> running within a master site "master". Unfortunately that type is not >>> very easy to work with. "HandlerM" is a Monadic type that provides >>> easy access to all wai-routes functionality, and can then be converted >>> to a HandlerS using runHandlerM. When you don't have a subsite, the >>> type is simply "HandlerM sub master", which is aliased to "Handler >>> master". That's why in your example, the handlers all have the type >>> "Handler MyRoute". >>> >>> 4. "RouteM" is another Monadic type which makes it easy to compose >>> multiple routes and middleware together to create a final wai >>> application. This along with "nested routes", and "subsites", helps >>> you better organise your application. >>> >>> HTH >>> >>> -- Anupam >>> >>> >>> >>> On Wed, Jun 10, 2015 at 8:38 PM, Njagi Mwaniki >>> wrote: >>> > It could be just me but the example in your README is totally broken. >>> > It >>> > needs at least the extensions like QuasiQotes and TemplateHaskell. Also >>> > where does DB (used in your example) come from? >>> > >>> > Anyway using other examples from your README I got a minimal working >>> > example >>> > here: https://gist.github.com/urbanslug/58a584c002f54ad75c02 >>> > >>> > I have a few questions regarding the types. >>> > >>> > * The haddocks on hackage don't work yet, do they? >>> > * in myRoute L21 I get the warning `Defined but not used: >>> > ?resourcesMyRoute?` can you help with that? >>> > * I'm confused about this type signature "runHandlerM :: HandlerM sub >>> > master >>> > () -> HandlerS sub master" >>> > * What are HandlerM and RouteM and sub and master? They are in many >>> > type >>> > signatures and I don't get them. >>> > >>> > Thank you. >>> > >>> > On Wednesday, 10 June 2015 01:54:33 UTC+3, Anupam wrote: >>> >> >>> >> Hi all, >>> >> >>> >> I have just released v0.7 of wai-routes, the typesafe urls framework >>> >> for wai. After letting the code rot for several months, I finally >>> >> managed to carve out some time to do a bit of housekeeping. The code >>> >> now compiles with ghc 7.8 and 7.10, and is compatible with wai-3.0. >>> >> The dependency on yesod-routes has also been removed, as that package >>> >> was deprecated, and its code has been folded into wai-routes. >>> >> >>> >> I also took the opportunity to add a few long pending features - >>> >> 1. Subsites! Simpler than the corresponding concept in Yesod, though >>> >> probably less powerful as well. This is still an evolving experimental >>> >> feature. >>> >> 2. Ability to get information about the currently executing route, >>> >> including the Route Attributes (which is exactly the same thing as in >>> >> Yesod). >>> >> >>> >> Get it at - >>> >> [http://hackage.haskell.org/package/wai-routes] >>> >> [https://github.com/ajnsit/wai-routes]. >>> >> >>> >> Feedback would be greatly appreciated, especially from people using >>> >> wai-routes in their projects! >>> >> >>> >> -- Anupam >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> > Groups >>> > "Yesod Web Framework" group. >>> > To unsubscribe from this group and stop receiving emails from it, send >>> > an >>> > email to yesodweb+u... at googlegroups.com. >>> > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "Yesod Web Framework" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to yesodweb+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. From ajnsit at gmail.com Fri Jun 12 18:09:32 2015 From: ajnsit at gmail.com (Anupam Jain) Date: Fri, 12 Jun 2015 23:39:32 +0530 Subject: [web-devel] [Yesod] ANN: Wai routes 0.7 In-Reply-To: References: Message-ID: Ah great question! One that I keep revisiting in my mind every time I think of adding something to wai-routes. Short answer - No. Long answer follows. Wai-routes' stated goal is to "provide a similar level of typesafe URL functionality to Wai applications as is available to Yesod applications". The feature list may make it seem like a larger framework, but it's really all just features provided by the routing code from yesod! Writing plain wai apps is tough though, so wai-routes provides a thin veneer over some of the rough edges, just enough to make it pleasant. Sometimes the simplicity of wai-routes makes it easier to use than Yesod. For example, it is really easy to have multiple independent route sets that match one after the other, so you can better logically group your app, instead of putting all routes in one big file. You can also apply different middleware to the different route sets. I'm currently not aware of any way to do that in Yesod. The de-coupling from wai also insulates the user from changes to the wai api. So the same wai-routes code continued to work when Wai-3.0 changed to a CPS style. ...Though that leaves the user vulnerable to changes in the wai-routes api... which happens quite more often... So, forget I said that! :) -- Anupam On Fri, Jun 12, 2015 at 9:58 PM, Greg Weber wrote: > To me, wai-routes seems like a full web framework and a re-implementation of > Yesod (I am not suggesting that it is a bad thing). Is that its goal? > > On Tue, Jun 9, 2015 at 3:54 PM, Anupam Jain wrote: >> >> Hi all, >> >> I have just released v0.7 of wai-routes, the typesafe urls framework >> for wai. After letting the code rot for several months, I finally >> managed to carve out some time to do a bit of housekeeping. The code >> now compiles with ghc 7.8 and 7.10, and is compatible with wai-3.0. >> The dependency on yesod-routes has also been removed, as that package >> was deprecated, and its code has been folded into wai-routes. >> >> I also took the opportunity to add a few long pending features - >> 1. Subsites! Simpler than the corresponding concept in Yesod, though >> probably less powerful as well. This is still an evolving experimental >> feature. >> 2. Ability to get information about the currently executing route, >> including the Route Attributes (which is exactly the same thing as in >> Yesod). >> >> Get it at - >> [http://hackage.haskell.org/package/wai-routes] >> [https://github.com/ajnsit/wai-routes]. >> >> Feedback would be greatly appreciated, especially from people using >> wai-routes in their projects! >> >> -- Anupam >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Yesod Web Framework" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to yesodweb+unsubscribe at googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "Yesod Web Framework" group. > > To unsubscribe from this group and stop receiving emails from it, send an > email to yesodweb+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. From ajnsit at gmail.com Mon Jun 29 03:00:52 2015 From: ajnsit at gmail.com (Anupam Jain) Date: Mon, 29 Jun 2015 08:30:52 +0530 Subject: [web-devel] [Yesod] ANN: Wai routes 0.7 In-Reply-To: References: Message-ID: On Sun, Jun 28, 2015 at 10:18 AM, Njagi Mwaniki wrote: > Another question for you. How can I or recreate the results of functions > like widgetFile in yesod? I want to use julius, lucius and hamlet in my > wai-routes app. You don't need a widgetFile function to use Julius and Lucius in wai-routes. Take a look at this small example - https://github.com/ajnsit/wai-routes/blob/master/examples/Hamlet.hs - on how to render Cassius from an external file. The process for including Julius or Lucius should be fairly similar to Cassius. Note that Wai-routes 0.7.1 includes a function called `showRouteQuery` (http://hackage.haskell.org/package/wai-routes-0.7.1/docs/Network-Wai-Middleware-Routes-Routes.html#v:showRouteQuery) which is a route renderer in the format that Shakespearean templates expect. -- Anupam From kazu at iij.ad.jp Thu Jul 23 04:11:17 2015 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Thu, 23 Jul 2015 13:11:17 +0900 (JST) Subject: [web-devel] Warp now supports HTTP/2 Message-ID: <20150723.131117.1755788681719467512.kazu@iij.ad.jp> Hi, We have released Warp v3.1.0 and WarpTLS v3.1.0 which fully support HTTP/2. http://www.yesodweb.com/blog/2015/07/http2 --Kazu From felipe.lessa at gmail.com Thu Jul 23 15:14:18 2015 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Thu, 23 Jul 2015 12:14:18 -0300 Subject: [web-devel] Warp now supports HTTP/2 In-Reply-To: <20150723.131117.1755788681719467512.kazu@iij.ad.jp> References: <20150723.131117.1755788681719467512.kazu@iij.ad.jp> Message-ID: <55B104CA.30909@gmail.com> Em 23-07-2015 01:11, Kazu Yamamoto (????) escreveu: > Hi, > > We have released Warp v3.1.0 and WarpTLS v3.1.0 which fully support > HTTP/2. > > http://www.yesodweb.com/blog/2015/07/http2 Awesome is not enough to describe this. Thanks, -- Felipe. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From kazu at iij.ad.jp Wed Jul 29 00:32:37 2015 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Wed, 29 Jul 2015 09:32:37 +0900 (JST) Subject: [web-devel] Warp now supports HTTP/2 In-Reply-To: References: <20150723.131117.1755788681719467512.kazu@iij.ad.jp> Message-ID: <20150729.093237.1475255631302338341.kazu@iij.ad.jp> Hi, > Incredible work! Out of curiousity, are there any plans to add > support for server push to the WAI interface? Or is there a way to > do it already that I don?t realize? Sorry for this late response. I was in summver vacation. Please give a look at this issue: https://github.com/yesodweb/wai/issues/402 I explained some ideas. --Kazu From felipe.lessa at gmail.com Wed Aug 5 19:29:23 2015 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Wed, 5 Aug 2015 16:29:23 -0300 Subject: [web-devel] esqueleto-2.4.0 released Message-ID: <55C26413.7010805@gmail.com> Hey! :) I've just released the first major bump of esqueleto in a long time. This was needed in order to change the signatures of all functions that took IsString arguments to the new SqlString type class. Now you can make your newtypes instances of SqlString without bothering with IsString. And, finally, Maybe is an instance of SqlString, so string-related functions will work with nullable types out-of-the-box. If you had a custom IsString instance previously, you may now need to make it an instance of SqlString as well: instance SqlString FooBar where -- This is not a typo, there are no class methods. If you had generic functions that took a data type that implements IsString, you may need to change them to SqlString. Your code should otherwise work fine without any changes. Cheers, PS: Shhhh, just ignore esqueleto-2.3.0. :) -- Felipe. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From michael at snoyman.com Thu Oct 22 05:13:31 2015 From: michael at snoyman.com (Michael Snoyman) Date: Thu, 22 Oct 2015 08:13:31 +0300 Subject: [web-devel] More collaboration in web development Message-ID: I originally kicked this off as an email to the maintainers of some of the other WAI web frameworks. After some initial brainstorming and some broad consensus to find some more shared common ground, we decided to open this up to a broader discussion. I think the primary forum for this discussion will likely be the web-devel mailing list, though I'm cross-posting to haskell-wai and yesodweb as well for those interested. Please feel free to share with other mailing lists also. (We debated whether to use web-devel or haskell-wai for this discussion and didn't come to a decision, I'm fine moving it elsewhere.) Based on the discussion, it seems like our best next step will be putting together a package containing some form of a Handler monad that could be shared by multiple web frameworks, hopefully making it easier to write code that can move between various frameworks. By contrast, we also seem to be in agreement that the high level routing code will end up being framework-specific, though we may be able to share some common low-level Trie-based dispatch code. I'll leave it to other participants to restate points they made in the initial private discussion. * * * Hi all, When I was in San Francisco a few months ago, Greg and I discussed the state of Haskell web development. It's clear that there's a lot of great stuff going on. Both of us have a strong desire to find as much common ground for all web framework authors to work on as possible, without detracting from meaningful distinctions between the various frameworks. Greg and I have discussed this point off and on for the past few months, and haven't come up with very many concrete ideas. The recent work on http-api-data[1] would be one possible example of collaboration. Other possible ideas that Greg and I brainstormed were some kind of shared library for efficient dispatch (that could be used under the surface for the various high-level interface different libraries already provide), or some kind of a common Handler-like monad (which from what I've seen many people seem to reimplement all over the place). Some concrete benefits we can see from this: * Previously, Persistent users were complaining that their types did not serialize in servant. http-api-data addresses this. * A common Handler would allow a higher layer abstraction for web apps, much like WAI provides at a low level. With something like that, sharing code like authentication logic becomes a reality * We already have precedence for other such shared libraries: client-session, server-session, cookie, and authenticate, as a few examples. These are just ideas to kick off some thoughts, I'm sure some discussion could bring out some better ideas. Overall, it seems like we have a lot of opportunity to improve the situation for everyone if we focus on such collaboration. Having a shared low-level HTTP interface (WAI) has already helped this out considerably, I'm hoping there's something else we can do in this vein as well. Michael [1] http://hackage.haskell.org/package/http-api-data -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkarni at gmail.com Fri Oct 23 15:00:08 2015 From: jkarni at gmail.com (Julian Arni) Date: Fri, 23 Oct 2015 17:00:08 +0200 Subject: [web-devel] web-devel Digest, Vol 71, Issue 1 In-Reply-To: References: Message-ID: Thanks again for starting the discussion! As I mentioned, for Servant I think it's unlikely we'd completely move away from our current handlers, since we don't want to lose all the type information we have, and don't want to impose such information on others. So I'm hoping the next best thing might be achievable - allowing the new-style handlers to be run directly, and having conversion functions from our current handlers to the new style. I think the first is easy, and the second possible. Since there isn't enough information at the value-level to establish where it is our handlers are getting their arguments from (query string, headers, request body, etc.), we'd need a Proxy argument for the relevant part of the api. Something like: convert :: (CanConvert api x) => Proxy api -> x -> NewHanderM () Where 'convert' would need to walk down the arguments of x and pull arguments from the appropriate places. E.g., if x ~ Int -> Person -> ExceptT ServantErr IO (), and api ~ Header "H" Int :> ReqBody '[JSON] Person -> Post '[] () we'd have 'convert' conceptually doing: convertExceptT $ liftM2 x (parseHeader <$> getHeader "H") (decode <$> getBody), where getHeader and getBody are functions in the new handler monad (/class). (This isn't quite right, since decoding failures need to be handled). Though as I mentioned before, since for servant at least in one direction it'd be a conversion rather than direct usage of the new handler, and since we can already convert any servant handler plus appropriate Proxy into an Application, and can use any Application as a handler, for us it'd be a lot easier to just use Application. As far as I can tell, this is also true in a couple of other frameworks. Indeed, one of the great things about the Application signature, in my opinion, is that it works well both as the signature for an entire Application and for a handler (that gets a modified request). The only problem we've come across with that idea is that the type of failure of the handler is opaque to the outer framework - so e.g., there's no easy way to tell whether re-routing needs to be triggered because the handler failed to match. This, however, would still be a problem in the model mentioned above. Having something like Application, but with return type IO (Either ReroutePlz ResponseReceived), would likely suffice (as would settling on an exception type). On Thu, Oct 22, 2015 at 2:00 PM, wrote: > Send web-devel mailing list submissions to > web-devel at haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.haskell.org/cgi-bin/mailman/listinfo/web-devel > or, via email, send a message with subject or body 'help' to > web-devel-request at haskell.org > > You can reach the person managing the list at > web-devel-owner at haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of web-devel digest..." > > > Today's Topics: > > 1. More collaboration in web development (Michael Snoyman) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 22 Oct 2015 08:13:31 +0300 > From: Michael Snoyman > To: web-devel , haskell-wai at googlegroups.com, > "yesodweb at googlegroups.com" > Subject: [web-devel] More collaboration in web development > Message-ID: > NFqA-+g at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > I originally kicked this off as an email to the maintainers of some of the > other WAI web frameworks. After some initial brainstorming and some broad > consensus to find some more shared common ground, we decided to open this > up to a broader discussion. > > I think the primary forum for this discussion will likely be the web-devel > mailing list, though I'm cross-posting to haskell-wai and yesodweb as well > for those interested. Please feel free to share with other mailing lists > also. (We debated whether to use web-devel or haskell-wai for this > discussion and didn't come to a decision, I'm fine moving it elsewhere.) > > Based on the discussion, it seems like our best next step will be putting > together a package containing some form of a Handler monad that could be > shared by multiple web frameworks, hopefully making it easier to write code > that can move between various frameworks. By contrast, we also seem to be > in agreement that the high level routing code will end up being > framework-specific, though we may be able to share some common low-level > Trie-based dispatch code. > > I'll leave it to other participants to restate points they made in the > initial private discussion. > > * * * > > Hi all, > > When I was in San Francisco a few months ago, Greg and I discussed the > state of Haskell web development. It's clear that there's a lot of great > stuff going on. Both of us have a strong desire to find as much common > ground for all web framework authors to work on as possible, without > detracting from meaningful distinctions between the various frameworks. > > Greg and I have discussed this point off and on for the past few months, > and haven't come up with very many concrete ideas. The recent work on > http-api-data[1] would be one possible example of collaboration. Other > possible ideas that Greg and I brainstormed were some kind of shared > library for efficient dispatch (that could be used under the surface for > the various high-level interface different libraries already provide), or > some kind of a common Handler-like monad (which from what I've seen many > people seem to reimplement all over the place). Some concrete benefits we > can see from this: > > * Previously, Persistent users were complaining that their types did not > serialize in servant. http-api-data addresses this. > * A common Handler would allow a higher layer abstraction for web apps, > much like WAI provides at a low level. With something like that, sharing > code like authentication logic becomes a reality > * We already have precedence for other such shared libraries: > client-session, server-session, cookie, and authenticate, as a few > examples. > > These are just ideas to kick off some thoughts, I'm sure some discussion > could bring out some better ideas. Overall, it seems like we have a lot of > opportunity to improve the situation for everyone if we focus on such > collaboration. Having a shared low-level HTTP interface (WAI) has already > helped this out considerably, I'm hoping there's something else we can do > in this vein as well. > > Michael > > [1] http://hackage.haskell.org/package/http-api-data > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://mail.haskell.org/pipermail/web-devel/attachments/20151022/20be59ea/attachment-0001.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > web-devel mailing list > web-devel at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/web-devel > > > ------------------------------ > > End of web-devel Digest, Vol 71, Issue 1 > **************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at gregweber.info Fri Oct 23 22:54:33 2015 From: greg at gregweber.info (Greg Weber) Date: Fri, 23 Oct 2015 15:54:33 -0700 Subject: [web-devel] web-devel Digest, Vol 71, Issue 1 In-Reply-To: References: Message-ID: On Fri, Oct 23, 2015 at 8:00 AM, Julian Arni wrote: > Thanks again for starting the discussion! > > As I mentioned, for Servant I think it's unlikely we'd completely move > away from our current handlers, since we don't want to lose all the type > information we have, and don't want to impose such information on others. > So I'm hoping the next best thing might be achievable - allowing the > new-style handlers to be run directly, and having conversion functions from > our current handlers to the new style. I think the first is easy, and the > second possible. Since there isn't enough information at the value-level to > establish where it is our handlers are getting their arguments from (query > string, headers, request body, etc.), we'd need a Proxy argument for the > relevant part of the api. Something like: > > convert :: (CanConvert api x) => Proxy api -> x -> NewHanderM () > > Where 'convert' would need to walk down the arguments of x and pull > arguments from the appropriate places. E.g., if > > x ~ Int -> Person > -> ExceptT ServantErr IO (), and > api ~ Header "H" Int :> ReqBody '[JSON] Person -> Post '[] () > > we'd have 'convert' conceptually doing: convertExceptT $ liftM2 x > (parseHeader <$> getHeader "H") (decode <$> getBody), where getHeader and > getBody are functions in the new handler monad (/class). (This isn't quite > right, since decoding failures need to be handled). > > > Though as I mentioned before, since for servant at least in one direction > it'd be a conversion rather than direct usage of the new handler, and since > we can already convert any servant handler plus appropriate Proxy into an > Application, and can use any Application as a handler, for us it'd be a lot > easier to just use Application. As far as I can tell, this is also true in > a couple of other frameworks. Indeed, one of the great things about the > Application signature, in my opinion, is that it works well both as the > signature for an entire Application and for a handler (that gets a modified > request). The only problem we've come across with that idea is that the > type of failure of the handler is opaque to the outer framework - so e.g., > there's no easy way to tell whether re-routing needs to be triggered > because the handler failed to match. This, however, would still be a > problem in the model mentioned above. Having something like Application, > but with return type IO (Either ReroutePlz ResponseReceived), would likely > suffice (as would settling on an exception type). > I think that for an Application to be shared it needs to be mountable to an arbitrary route (e.g. "/auth"). And any request that matches the mounted route should be dispatched to just the mounted Application. Inside that mounted route the Application can then do additional routing. But if it does not match, it should return a 404, and that should be sent all the way to the client. Or is this too restrictive? What exactly is the need to interpret a 404 as meaning "try a different route"? > > On Thu, Oct 22, 2015 at 2:00 PM, wrote: > >> Send web-devel mailing list submissions to >> web-devel at haskell.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://mail.haskell.org/cgi-bin/mailman/listinfo/web-devel >> or, via email, send a message with subject or body 'help' to >> web-devel-request at haskell.org >> >> You can reach the person managing the list at >> web-devel-owner at haskell.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of web-devel digest..." >> >> >> Today's Topics: >> >> 1. More collaboration in web development (Michael Snoyman) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Thu, 22 Oct 2015 08:13:31 +0300 >> From: Michael Snoyman >> To: web-devel , haskell-wai at googlegroups.com, >> "yesodweb at googlegroups.com" >> Subject: [web-devel] More collaboration in web development >> Message-ID: >> > NFqA-+g at mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> I originally kicked this off as an email to the maintainers of some of the >> other WAI web frameworks. After some initial brainstorming and some broad >> consensus to find some more shared common ground, we decided to open this >> up to a broader discussion. >> >> I think the primary forum for this discussion will likely be the web-devel >> mailing list, though I'm cross-posting to haskell-wai and yesodweb as well >> for those interested. Please feel free to share with other mailing lists >> also. (We debated whether to use web-devel or haskell-wai for this >> discussion and didn't come to a decision, I'm fine moving it elsewhere.) >> >> Based on the discussion, it seems like our best next step will be putting >> together a package containing some form of a Handler monad that could be >> shared by multiple web frameworks, hopefully making it easier to write >> code >> that can move between various frameworks. By contrast, we also seem to be >> in agreement that the high level routing code will end up being >> framework-specific, though we may be able to share some common low-level >> Trie-based dispatch code. >> >> I'll leave it to other participants to restate points they made in the >> initial private discussion. >> >> * * * >> >> Hi all, >> >> When I was in San Francisco a few months ago, Greg and I discussed the >> state of Haskell web development. It's clear that there's a lot of great >> stuff going on. Both of us have a strong desire to find as much common >> ground for all web framework authors to work on as possible, without >> detracting from meaningful distinctions between the various frameworks. >> >> Greg and I have discussed this point off and on for the past few months, >> and haven't come up with very many concrete ideas. The recent work on >> http-api-data[1] would be one possible example of collaboration. Other >> possible ideas that Greg and I brainstormed were some kind of shared >> library for efficient dispatch (that could be used under the surface for >> the various high-level interface different libraries already provide), or >> some kind of a common Handler-like monad (which from what I've seen many >> people seem to reimplement all over the place). Some concrete benefits we >> can see from this: >> >> * Previously, Persistent users were complaining that their types did not >> serialize in servant. http-api-data addresses this. >> * A common Handler would allow a higher layer abstraction for web apps, >> much like WAI provides at a low level. With something like that, sharing >> code like authentication logic becomes a reality >> * We already have precedence for other such shared libraries: >> client-session, server-session, cookie, and authenticate, as a few >> examples. >> >> These are just ideas to kick off some thoughts, I'm sure some discussion >> could bring out some better ideas. Overall, it seems like we have a lot of >> opportunity to improve the situation for everyone if we focus on such >> collaboration. Having a shared low-level HTTP interface (WAI) has already >> helped this out considerably, I'm hoping there's something else we can do >> in this vein as well. >> >> Michael >> >> [1] http://hackage.haskell.org/package/http-api-data >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://mail.haskell.org/pipermail/web-devel/attachments/20151022/20be59ea/attachment-0001.html >> > >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> web-devel mailing list >> web-devel at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/web-devel >> >> >> ------------------------------ >> >> End of web-devel Digest, Vol 71, Issue 1 >> **************************************** >> > > > _______________________________________________ > web-devel mailing list > web-devel at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/web-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkarni at gmail.com Fri Oct 23 23:27:00 2015 From: jkarni at gmail.com (Julian Arni) Date: Sat, 24 Oct 2015 01:27:00 +0200 Subject: [web-devel] web-devel Digest, Vol 71, Issue 1 In-Reply-To: References: Message-ID: So let's say we have: /auth ---> application mounted here POST /auth/subauth --> normal handler POST /auth ---> normal handler If a GET to "auth/subauth" arrives, it gets dispatched to the Application. If the Application doesn't have a subauth endpoint, it 404s. But the response we want is 405, since there is something that matches the URL (but not the method). If the Application responded with essentially any other error besides 404, however, or with a successful response, we don't want to override it with a 405. Moreover, if a POST to /auth arrives, where do we send it to - the normal handler or the Application? The handler just because we know that matches? Or the Application because it showed up first in the code, even though it might not match? Essentially, we just don't know how to route, given that everything inside Application is opaque. We can try sending things to the Application and checking the first line of the response. However, not all 404s are created equal. If the handler decides to 404 because the request body contains an ID for a User in the database that happens to not exist, rerouting would probably be misleading (returning a 405 would definitely be). Also, that solution just generally feels very hacky! To some extent we can just warn in the documentation against handlers that might overlap with the mounted Application (or even do static checks to prevent that), but this isn't very nice when e.g. one web framework is meant to "stand in front" of another, in the sense that anything that doesn't get matched by the one framework should fall through into the other (the mounted Application one), which I imagine being a decently common use-case. (Because the problem also exists in that direction, where the Application is the last tried thing - if we reroute to the Application because the best we got was a 405, the Application might respond with a 404, confusing everybody...) It also doesn't really allow for one framework handling a GET, and another (via application) a POST on the same URL, say, without the same issues. Anyhow, these things seems like something to consider if integrating between frameworks via Application becomes a more heavily used feature. Not sure if this makes it any clearer - let me know if not! On Sat, Oct 24, 2015 at 12:54 AM, Greg Weber wrote: > > > On Fri, Oct 23, 2015 at 8:00 AM, Julian Arni wrote: > >> Thanks again for starting the discussion! >> >> As I mentioned, for Servant I think it's unlikely we'd completely move >> away from our current handlers, since we don't want to lose all the type >> information we have, and don't want to impose such information on others. >> So I'm hoping the next best thing might be achievable - allowing the >> new-style handlers to be run directly, and having conversion functions from >> our current handlers to the new style. I think the first is easy, and the >> second possible. Since there isn't enough information at the value-level to >> establish where it is our handlers are getting their arguments from (query >> string, headers, request body, etc.), we'd need a Proxy argument for the >> relevant part of the api. Something like: >> >> convert :: (CanConvert api x) => Proxy api -> x -> NewHanderM () >> >> Where 'convert' would need to walk down the arguments of x and pull >> arguments from the appropriate places. E.g., if >> >> x ~ Int -> Person >> -> ExceptT ServantErr IO (), and >> api ~ Header "H" Int :> ReqBody '[JSON] Person -> Post '[] () >> >> we'd have 'convert' conceptually doing: convertExceptT $ liftM2 x >> (parseHeader <$> getHeader "H") (decode <$> getBody), where getHeader and >> getBody are functions in the new handler monad (/class). (This isn't quite >> right, since decoding failures need to be handled). >> >> >> Though as I mentioned before, since for servant at least in one direction >> it'd be a conversion rather than direct usage of the new handler, and since >> we can already convert any servant handler plus appropriate Proxy into an >> Application, and can use any Application as a handler, for us it'd be a lot >> easier to just use Application. As far as I can tell, this is also true in >> a couple of other frameworks. Indeed, one of the great things about the >> Application signature, in my opinion, is that it works well both as the >> signature for an entire Application and for a handler (that gets a modified >> request). The only problem we've come across with that idea is that the >> type of failure of the handler is opaque to the outer framework - so e.g., >> there's no easy way to tell whether re-routing needs to be triggered >> because the handler failed to match. This, however, would still be a >> problem in the model mentioned above. Having something like Application, >> but with return type IO (Either ReroutePlz ResponseReceived), would likely >> suffice (as would settling on an exception type). >> > > I think that for an Application to be shared it needs to be mountable to > an arbitrary route (e.g. "/auth"). And any request that matches the mounted > route should be dispatched to just the mounted Application. Inside that > mounted route the Application can then do additional routing. But if it > does not match, it should return a 404, and that should be sent all the way > to the client. Or is this too restrictive? What exactly is the need to > interpret a 404 as meaning "try a different route"? > > >> >> On Thu, Oct 22, 2015 at 2:00 PM, wrote: >> >>> Send web-devel mailing list submissions to >>> web-devel at haskell.org >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/web-devel >>> or, via email, send a message with subject or body 'help' to >>> web-devel-request at haskell.org >>> >>> You can reach the person managing the list at >>> web-devel-owner at haskell.org >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of web-devel digest..." >>> >>> >>> Today's Topics: >>> >>> 1. More collaboration in web development (Michael Snoyman) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Thu, 22 Oct 2015 08:13:31 +0300 >>> From: Michael Snoyman >>> To: web-devel , haskell-wai at googlegroups.com, >>> "yesodweb at googlegroups.com" >>> Subject: [web-devel] More collaboration in web development >>> Message-ID: >>> >> NFqA-+g at mail.gmail.com> >>> Content-Type: text/plain; charset="utf-8" >>> >>> I originally kicked this off as an email to the maintainers of some of >>> the >>> other WAI web frameworks. After some initial brainstorming and some broad >>> consensus to find some more shared common ground, we decided to open this >>> up to a broader discussion. >>> >>> I think the primary forum for this discussion will likely be the >>> web-devel >>> mailing list, though I'm cross-posting to haskell-wai and yesodweb as >>> well >>> for those interested. Please feel free to share with other mailing lists >>> also. (We debated whether to use web-devel or haskell-wai for this >>> discussion and didn't come to a decision, I'm fine moving it elsewhere.) >>> >>> Based on the discussion, it seems like our best next step will be putting >>> together a package containing some form of a Handler monad that could be >>> shared by multiple web frameworks, hopefully making it easier to write >>> code >>> that can move between various frameworks. By contrast, we also seem to be >>> in agreement that the high level routing code will end up being >>> framework-specific, though we may be able to share some common low-level >>> Trie-based dispatch code. >>> >>> I'll leave it to other participants to restate points they made in the >>> initial private discussion. >>> >>> * * * >>> >>> Hi all, >>> >>> When I was in San Francisco a few months ago, Greg and I discussed the >>> state of Haskell web development. It's clear that there's a lot of great >>> stuff going on. Both of us have a strong desire to find as much common >>> ground for all web framework authors to work on as possible, without >>> detracting from meaningful distinctions between the various frameworks. >>> >>> Greg and I have discussed this point off and on for the past few months, >>> and haven't come up with very many concrete ideas. The recent work on >>> http-api-data[1] would be one possible example of collaboration. Other >>> possible ideas that Greg and I brainstormed were some kind of shared >>> library for efficient dispatch (that could be used under the surface for >>> the various high-level interface different libraries already provide), or >>> some kind of a common Handler-like monad (which from what I've seen many >>> people seem to reimplement all over the place). Some concrete benefits we >>> can see from this: >>> >>> * Previously, Persistent users were complaining that their types did not >>> serialize in servant. http-api-data addresses this. >>> * A common Handler would allow a higher layer abstraction for web apps, >>> much like WAI provides at a low level. With something like that, sharing >>> code like authentication logic becomes a reality >>> * We already have precedence for other such shared libraries: >>> client-session, server-session, cookie, and authenticate, as a few >>> examples. >>> >>> These are just ideas to kick off some thoughts, I'm sure some discussion >>> could bring out some better ideas. Overall, it seems like we have a lot >>> of >>> opportunity to improve the situation for everyone if we focus on such >>> collaboration. Having a shared low-level HTTP interface (WAI) has already >>> helped this out considerably, I'm hoping there's something else we can do >>> in this vein as well. >>> >>> Michael >>> >>> [1] http://hackage.haskell.org/package/http-api-data >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: < >>> http://mail.haskell.org/pipermail/web-devel/attachments/20151022/20be59ea/attachment-0001.html >>> > >>> >>> ------------------------------ >>> >>> Subject: Digest Footer >>> >>> _______________________________________________ >>> web-devel mailing list >>> web-devel at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/web-devel >>> >>> >>> ------------------------------ >>> >>> End of web-devel Digest, Vol 71, Issue 1 >>> **************************************** >>> >> >> >> _______________________________________________ >> web-devel mailing list >> web-devel at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/web-devel >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at gregweber.info Sat Oct 24 00:05:02 2015 From: greg at gregweber.info (Greg Weber) Date: Fri, 23 Oct 2015 17:05:02 -0700 Subject: [web-devel] web-devel Digest, Vol 71, Issue 1 In-Reply-To: References: Message-ID: Yes, that is all very clear. My contention is that one should not have overlapping routes, particularly when mounting an Application. If an Application is mounted at /route, then it should be clear that /route* should belong to the Application. For example, with Yesod, Yesod "stands in front", but one often mounts wai-app-static at /static and Yesod will statically enforce that you don't create another static/* route anywhere else. What is the use case for having one framework "stand in front" such that it requires overlapping, or what is the use case for overlapping otherwise? On Fri, Oct 23, 2015 at 4:27 PM, Julian Arni wrote: > So let's say we have: > > /auth ---> application mounted here > POST /auth/subauth --> normal handler > POST /auth ---> normal handler > > If a GET to "auth/subauth" arrives, it gets dispatched to the Application. > If the Application doesn't have a subauth endpoint, it 404s. But the > response we want is 405, since there is something that matches the URL (but > not the method). If the Application responded with essentially any other > error besides 404, however, or with a successful response, we don't want to > override it with a 405. > > Moreover, if a POST to /auth arrives, where do we send it to - the normal > handler or the Application? The handler just because we know that matches? > Or the Application because it showed up first in the code, even though it > might not match? Essentially, we just don't know how to route, given that > everything inside Application is opaque. > > We can try sending things to the Application and checking the first line > of the response. However, not all 404s are created equal. If the handler > decides to 404 because the request body contains an ID for a User in the > database that happens to not exist, rerouting would probably be misleading > (returning a 405 would definitely be). Also, that solution just generally > feels very hacky! > > To some extent we can just warn in the documentation against handlers that > might overlap with the mounted Application (or even do static checks to > prevent that), but this isn't very nice when e.g. one web framework is > meant to "stand in front" of another, in the sense that anything that > doesn't get matched by the one framework should fall through into the other > (the mounted Application one), which I imagine being a decently common > use-case. (Because the problem also exists in that direction, where the > Application is the last tried thing - if we reroute to the Application > because the best we got was a 405, the Application might respond with a > 404, confusing everybody...) It also doesn't really allow for one framework > handling a GET, and another (via application) a POST on the same URL, say, > without the same issues. Anyhow, these things seems like something to > consider if integrating between frameworks via Application becomes a more > heavily used feature. > > Not sure if this makes it any clearer - let me know if not! > > > On Sat, Oct 24, 2015 at 12:54 AM, Greg Weber wrote: > >> >> >> On Fri, Oct 23, 2015 at 8:00 AM, Julian Arni wrote: >> >>> Thanks again for starting the discussion! >>> >>> As I mentioned, for Servant I think it's unlikely we'd completely move >>> away from our current handlers, since we don't want to lose all the type >>> information we have, and don't want to impose such information on others. >>> So I'm hoping the next best thing might be achievable - allowing the >>> new-style handlers to be run directly, and having conversion functions from >>> our current handlers to the new style. I think the first is easy, and the >>> second possible. Since there isn't enough information at the value-level to >>> establish where it is our handlers are getting their arguments from (query >>> string, headers, request body, etc.), we'd need a Proxy argument for the >>> relevant part of the api. Something like: >>> >>> convert :: (CanConvert api x) => Proxy api -> x -> NewHanderM () >>> >>> Where 'convert' would need to walk down the arguments of x and pull >>> arguments from the appropriate places. E.g., if >>> >>> x ~ Int -> Person >>> -> ExceptT ServantErr IO (), and >>> api ~ Header "H" Int :> ReqBody '[JSON] Person -> Post '[] () >>> >>> we'd have 'convert' conceptually doing: convertExceptT $ liftM2 x >>> (parseHeader <$> getHeader "H") (decode <$> getBody), where getHeader and >>> getBody are functions in the new handler monad (/class). (This isn't quite >>> right, since decoding failures need to be handled). >>> >>> >>> Though as I mentioned before, since for servant at least in one >>> direction it'd be a conversion rather than direct usage of the new handler, >>> and since we can already convert any servant handler plus appropriate Proxy >>> into an Application, and can use any Application as a handler, for us it'd >>> be a lot easier to just use Application. As far as I can tell, this is also >>> true in a couple of other frameworks. Indeed, one of the great things about >>> the Application signature, in my opinion, is that it works well both as the >>> signature for an entire Application and for a handler (that gets a modified >>> request). The only problem we've come across with that idea is that the >>> type of failure of the handler is opaque to the outer framework - so e.g., >>> there's no easy way to tell whether re-routing needs to be triggered >>> because the handler failed to match. This, however, would still be a >>> problem in the model mentioned above. Having something like Application, >>> but with return type IO (Either ReroutePlz ResponseReceived), would likely >>> suffice (as would settling on an exception type). >>> >> >> I think that for an Application to be shared it needs to be mountable to >> an arbitrary route (e.g. "/auth"). And any request that matches the mounted >> route should be dispatched to just the mounted Application. Inside that >> mounted route the Application can then do additional routing. But if it >> does not match, it should return a 404, and that should be sent all the way >> to the client. Or is this too restrictive? What exactly is the need to >> interpret a 404 as meaning "try a different route"? >> >> >>> >>> On Thu, Oct 22, 2015 at 2:00 PM, wrote: >>> >>>> Send web-devel mailing list submissions to >>>> web-devel at haskell.org >>>> >>>> To subscribe or unsubscribe via the World Wide Web, visit >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/web-devel >>>> or, via email, send a message with subject or body 'help' to >>>> web-devel-request at haskell.org >>>> >>>> You can reach the person managing the list at >>>> web-devel-owner at haskell.org >>>> >>>> When replying, please edit your Subject line so it is more specific >>>> than "Re: Contents of web-devel digest..." >>>> >>>> >>>> Today's Topics: >>>> >>>> 1. More collaboration in web development (Michael Snoyman) >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> >>>> Message: 1 >>>> Date: Thu, 22 Oct 2015 08:13:31 +0300 >>>> From: Michael Snoyman >>>> To: web-devel , haskell-wai at googlegroups.com, >>>> "yesodweb at googlegroups.com" >>>> Subject: [web-devel] More collaboration in web development >>>> Message-ID: >>>> >>> NFqA-+g at mail.gmail.com> >>>> Content-Type: text/plain; charset="utf-8" >>>> >>>> I originally kicked this off as an email to the maintainers of some of >>>> the >>>> other WAI web frameworks. After some initial brainstorming and some >>>> broad >>>> consensus to find some more shared common ground, we decided to open >>>> this >>>> up to a broader discussion. >>>> >>>> I think the primary forum for this discussion will likely be the >>>> web-devel >>>> mailing list, though I'm cross-posting to haskell-wai and yesodweb as >>>> well >>>> for those interested. Please feel free to share with other mailing lists >>>> also. (We debated whether to use web-devel or haskell-wai for this >>>> discussion and didn't come to a decision, I'm fine moving it elsewhere.) >>>> >>>> Based on the discussion, it seems like our best next step will be >>>> putting >>>> together a package containing some form of a Handler monad that could be >>>> shared by multiple web frameworks, hopefully making it easier to write >>>> code >>>> that can move between various frameworks. By contrast, we also seem to >>>> be >>>> in agreement that the high level routing code will end up being >>>> framework-specific, though we may be able to share some common low-level >>>> Trie-based dispatch code. >>>> >>>> I'll leave it to other participants to restate points they made in the >>>> initial private discussion. >>>> >>>> * * * >>>> >>>> Hi all, >>>> >>>> When I was in San Francisco a few months ago, Greg and I discussed the >>>> state of Haskell web development. It's clear that there's a lot of great >>>> stuff going on. Both of us have a strong desire to find as much common >>>> ground for all web framework authors to work on as possible, without >>>> detracting from meaningful distinctions between the various frameworks. >>>> >>>> Greg and I have discussed this point off and on for the past few months, >>>> and haven't come up with very many concrete ideas. The recent work on >>>> http-api-data[1] would be one possible example of collaboration. Other >>>> possible ideas that Greg and I brainstormed were some kind of shared >>>> library for efficient dispatch (that could be used under the surface for >>>> the various high-level interface different libraries already provide), >>>> or >>>> some kind of a common Handler-like monad (which from what I've seen many >>>> people seem to reimplement all over the place). Some concrete benefits >>>> we >>>> can see from this: >>>> >>>> * Previously, Persistent users were complaining that their types did not >>>> serialize in servant. http-api-data addresses this. >>>> * A common Handler would allow a higher layer abstraction for web apps, >>>> much like WAI provides at a low level. With something like that, sharing >>>> code like authentication logic becomes a reality >>>> * We already have precedence for other such shared libraries: >>>> client-session, server-session, cookie, and authenticate, as a few >>>> examples. >>>> >>>> These are just ideas to kick off some thoughts, I'm sure some discussion >>>> could bring out some better ideas. Overall, it seems like we have a lot >>>> of >>>> opportunity to improve the situation for everyone if we focus on such >>>> collaboration. Having a shared low-level HTTP interface (WAI) has >>>> already >>>> helped this out considerably, I'm hoping there's something else we can >>>> do >>>> in this vein as well. >>>> >>>> Michael >>>> >>>> [1] http://hackage.haskell.org/package/http-api-data >>>> -------------- next part -------------- >>>> An HTML attachment was scrubbed... >>>> URL: < >>>> http://mail.haskell.org/pipermail/web-devel/attachments/20151022/20be59ea/attachment-0001.html >>>> > >>>> >>>> ------------------------------ >>>> >>>> Subject: Digest Footer >>>> >>>> _______________________________________________ >>>> web-devel mailing list >>>> web-devel at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/web-devel >>>> >>>> >>>> ------------------------------ >>>> >>>> End of web-devel Digest, Vol 71, Issue 1 >>>> **************************************** >>>> >>> >>> >>> _______________________________________________ >>> web-devel mailing list >>> web-devel at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/web-devel >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkarni at gmail.com Mon Oct 26 13:30:18 2015 From: jkarni at gmail.com (Julian Arni) Date: Mon, 26 Oct 2015 14:30:18 +0100 Subject: [web-devel] web-devel Digest, Vol 71, Issue 1 In-Reply-To: References: Message-ID: (Sorry for the delay, was away for the weekend.) On Sat, Oct 24, 2015 at 2:05 AM, Greg Weber wrote: > Yes, that is all very clear. My contention is that one should not have > overlapping routes, particularly when mounting an Application. > If an Application is mounted at /route, then it should be clear that > /route* should belong to the Application. > > For example, with Yesod, Yesod "stands in front", but one often mounts > wai-app-static at /static and Yesod will statically enforce that you don't > create another static/* route anywhere else. > > What is the use case for having one framework "stand in front" such that > it requires overlapping, or what is the use case for overlapping otherwise? > > Well, my thought was that Application is, modulo this one problem, already a way of sharing handlers (or sets of handlers) between frameworks. If overlaps are handled nicely, one can combine different web frameworks very neatly. This seems to achieve the original aim, but maybe I'm missing some of the motivation for a common handler? As for a use case for standing-in-front, it's sort of a nice way to have something like a reverse proxy that captures some endpoints rather than proxying them to the underlying service, without the actual overhead of external requests. I imagine there are other use-cases. Finally, it seems like if we had a good story about Applications working anywhere - in particular, converting one or more endpoints to Application and then mounting them in the same place not changing the behaviour of the overall Application - it would be quite easy for all web frameworks to apply Middleware to a subset of endpoints rather than all of them. -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at gregweber.info Mon Oct 26 14:04:38 2015 From: greg at gregweber.info (Greg Weber) Date: Mon, 26 Oct 2015 07:04:38 -0700 Subject: [web-devel] web-devel Digest, Vol 71, Issue 1 In-Reply-To: References: Message-ID: On Mon, Oct 26, 2015 at 6:30 AM, Julian Arni wrote: > (Sorry for the delay, was away for the weekend.) > > > > On Sat, Oct 24, 2015 at 2:05 AM, Greg Weber wrote: > >> Yes, that is all very clear. My contention is that one should not have >> overlapping routes, particularly when mounting an Application. >> If an Application is mounted at /route, then it should be clear that >> /route* should belong to the Application. >> >> For example, with Yesod, Yesod "stands in front", but one often mounts >> wai-app-static at /static and Yesod will statically enforce that you don't >> create another static/* route anywhere else. >> >> What is the use case for having one framework "stand in front" such that >> it requires overlapping, or what is the use case for overlapping otherwise? >> >> Well, my thought was that Application is, modulo this one problem, > already a way of sharing handlers (or sets of handlers) between frameworks. > If overlaps are handled nicely, one can combine different web frameworks > very neatly. This seems to achieve the original aim, but maybe I'm missing > some of the motivation for a common handler? > This is the aim, the question is just whether overlapping routes are useful. > > As for a use case for standing-in-front, it's sort of a nice way to have > something like a reverse proxy that captures some endpoints rather than > proxying them to the underlying service, without the actual overhead of > external requests. I imagine there are other use-cases. > It seems like a 404 response would be sufficient for something behaving like a proxy. > Finally, it seems like if we had a good story about Applications working > anywhere - in particular, converting one or more endpoints to Application > and then mounting them in the same place not changing the behaviour of the > overall Application - it would be quite easy for all web frameworks to > apply Middleware to a subset of endpoints rather than all of them. > It should be easy enough to apply a middleware to selected applications. If they are already combined with routing one can still use a Routed Middleware: https://github.com/yesodweb/wai/blob/master/wai-extra/Network/Wai/Middleware/Routed.hs So I am still looking for a very concrete (code) example where overlapping routing is desirable. I can point you to the yesod-scaffold where we explicitly avoid overlapping routes and have applications at /auth and /static https://github.com/yesodweb/yesod-scaffold/blob/postgres/config/routes -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Sun Nov 1 22:33:44 2015 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 1 Nov 2015 23:33:44 +0100 (CET) Subject: [web-devel] simple library for HTML form generation and processing Message-ID: I like to get your advice about a simple library for web form generation and processing. So far I tried digestive-functors and reform. Both of them are advertised as being good in separating data from view. However, I am interested in one-off forms, that is, form data will always be rendered in one way. Thus I would like to save the efforts to combine data and view after they have been carefully separated. Formerly I have also used autolib-cgi: http://autolat.imn.htwk-leipzig.de/haddock/autolib-cgi-1.2/ It allowed me to generate the form and fetch and validate the data in one (monadic) go. The blaze-markup type MarkupM is a monad anyway, thus it seems to be straight-forward to use the monadic results for the data entered to the form. Is there a library that supports this style of web form handling?