Development discussion for the Yesod Web Framework. ()

headers

Arthur Clemens | 9 Sep 2012 13:15

Re: Abstracting permissions with Yesod

/admin AdminR:
/product/#ProductId AdminProductR GET POST
...

So if I have:

/admin AdminR:

/ AdminRootR GET

/categories AdminCategoriesR GET

and the handlers are specified as:

getAdminRootR :: Handler RepHtml

getAdminRootR = do

getAdminCategoriesR :: Handler RepHtml

getAdminCategoriesR = do

what more is needed to create links?

Currently I use <a href= <at> {AdminRootR}> but that results in

Handler/Admin.hs:14:22:

Not in scope: data constructor `AdminRootR'

Arthur

headers

Michael Snoyman | 9 Sep 2012 13:40

Re: Abstracting permissions with Yesod

On Sun, Sep 9, 2012 at 2:15 PM, Arthur Clemens
<arthurclemens@...> wrote:
> /admin AdminR:
>    /product/#ProductId AdminProductR GET POST
>    ...
>
>
> So if I have:
>
> /admin AdminR:
>     / AdminRootR GET
>     /categories AdminCategoriesR GET
>
> and the handlers are specified as:
>
> getAdminRootR :: Handler RepHtml
> getAdminRootR = do
>     ..
>
> getAdminCategoriesR :: Handler RepHtml
> getAdminCategoriesR = do
>     ..
>
> what more is needed to create links?
> Currently I use <a href= <at> {AdminRootR}> but that results in
>
> Handler/Admin.hs:14:22:
>     Not in scope: data constructor `AdminRootR'
>
> Arthur

You'll need the AdminR constructor: AdminR AdminRootR. If you use
-ddump-splices when compiling, GHC will spit out the generated
code/data types, which should give a good idea of what's going on
under the surface.

Michael

headers

Arthur Clemens | 9 Sep 2012 16:48

Re: Abstracting permissions with Yesod

You'll need the AdminR constructor: AdminR AdminRootR.

It doesn't work in the scaffolded site, whereas it works as expected in a single file site like https://github.com/yesodweb/yesod/wiki/Hierarchical-routes-and-breadcrumbs

I created a new scaffolded site, used add-handler to create Handler/Admin.hs, and changed the route in config/routes to

/admin AdminR:

/ AdminRootR GET

yesod devel results in Application.hs:27:1: Not in scope: data constructor `AdminRootR'

changing that to

/admin AdminRootR GET

runs without errors.

If you use
-ddump-splices when compiling, GHC will spit out the generated
code/data types, which should give a good idea of what's going on
under the surface.

I can't, it results in

Import.hs:10:2: lexical error at character 'i'

Using ghc -cpp -ddump-splices main.hs

results in Model.hs:13:1: Parse error: naked expression at top level

Arthur

headers

Michael Snoyman | 10 Sep 2012 08:56

Re: Abstracting permissions with Yesod

On Sun, Sep 9, 2012 at 5:48 PM, Arthur Clemens <arthurclemens-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

You'll need the AdminR constructor: AdminR AdminRootR.

It doesn't work in the scaffolded site, whereas it works as expected in a single file site like https://github.com/yesodweb/yesod/wiki/Hierarchical-routes-and-breadcrumbs

I created a new scaffolded site, used add-handler to create Handler/Admin.hs, and changed the route in config/routes to

/admin AdminR:

/ AdminRootR GET

yesod devel results in Application.hs:27:1: Not in scope: data constructor `AdminRootR'

changing that to

/admin AdminRootR GET

runs without errors.

Just to confirm: does your `cabal` file state Yesod version 1.0 or 1.1?

If you use
-ddump-splices when compiling, GHC will spit out the generated
code/data types, which should give a good idea of what's going on
under the surface.

I can't, it results in

Import.hs:10:2: lexical error at character 'i'

Using ghc -cpp -ddump-splices main.hs

results in Model.hs:13:1: Parse error: naked expression at top level

Arthur

Sorry, I should have clarified: you can do something like:

cabal configure --ghc-option=-ddump-splices

Then `cabal build` will pass in that option. You get the "naked expression" error because TemplateHaskell isn't enabled.

Michael

headers

Arthur Clemens | 10 Sep 2012 09:09

Re: Abstracting permissions with Yesod

> Just to confirm: does your `cabal` file state Yesod version 1.0 or 1.1?

I have yesod-1.1.0.2

Arthur

headers

Michael Snoyman | 10 Sep 2012 11:54

Re: Abstracting permissions with Yesod

On Mon, Sep 10, 2012 at 9:56 AM, Michael Snoyman <michael-cq0OxgmGHj5BDgjK7y7TUQ@public.gmane.org> wrote:

On Sun, Sep 9, 2012 at 5:48 PM, Arthur Clemens <arthurclemens-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

You'll need the AdminR constructor: AdminR AdminRootR.

It doesn't work in the scaffolded site, whereas it works as expected in a single file site like https://github.com/yesodweb/yesod/wiki/Hierarchical-routes-and-breadcrumbs

I created a new scaffolded site, used add-handler to create Handler/Admin.hs, and changed the route in config/routes to

/admin AdminR:

/ AdminRootR GET

yesod devel results in Application.hs:27:1: Not in scope: data constructor `AdminRootR'

changing that to

/admin AdminRootR GET

runs without errors.

Just to confirm: does your `cabal` file state Yesod version 1.0 or 1.1?

Actually, I bet I know what the problem is: the export list in Foundation.hs doesn't include the AdminR datatype. Try adding:

AdminR (..)

If you use
-ddump-splices when compiling, GHC will spit out the generated
code/data types, which should give a good idea of what's going on
under the surface.

I can't, it results in

Import.hs:10:2: lexical error at character 'i'

Using ghc -cpp -ddump-splices main.hs

results in Model.hs:13:1: Parse error: naked expression at top level

Arthur

Sorry, I should have clarified: you can do something like:

cabal configure --ghc-option=-ddump-splices

Then `cabal build` will pass in that option. You get the "naked expression" error because TemplateHaskell isn't enabled.

Michael

headers

Arthur Clemens | 10 Sep 2012 12:09

Re: Abstracting permissions with Yesod

Actually, I bet I know what the problem is: the export list in Foundation.hs doesn't include the AdminR datatype. Try adding:

AdminR (..)

Yes, now it works.

That's quite a gotcha.

Arthur

headers

Michael Snoyman | 10 Sep 2012 12:34

Re: Abstracting permissions with Yesod

On Mon, Sep 10, 2012 at 1:09 PM, Arthur Clemens <arthurclemens-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Actually, I bet I know what the problem is: the export list in Foundation.hs doesn't include the AdminR datatype. Try adding:

AdminR (..)

Yes, now it works.

That's quite a gotcha.

Arthur

I agree it's a gotcha, but I'm not sure there's anything we can do to avoid the issue. I suppose we could get rid of the export list in Foundation.hs, but that's not really a good practice in general. Best bet is likely to keep wiki documentation up to date. Which based on the Github newsfeeds, it seems you've been doing a very good job of, thank you. :)

Michael