...... You tell me this now ;)
I was actually wanting to look at scaffolding, but the section for it in the Yesod book is not completed yet (http://www.yesodweb.com/book/scaffold) Well that was like 4 hours wasted Do you have a quick example of how scaffolding is done with mkYesodData and mkYesodDispatch (I only need something trivial)? On Mon, May 2, 2011 at 11:18 PM, Michael Snoyman <mich...@snoyman.com>wrote: > Actually, there's a much simpler solution already implemented in the > scaffolded site: instead of using mkYesod, use mkYesodData and > mkYesodDispatch. mkYesod is really just a combination of the two. The > former defines your route datatype, and the latter creates the > YesodDispatch instance. This allows you to create your route in one > module, put your handlers in their own modules, and then import those > handlers in the final module that calls mkYesodDispatch. > > HTH, > Michael > > On Mon, May 2, 2011 at 4:14 PM, Mathew de Detrich <dete...@gmail.com> > wrote: > > Ok I have found the source issue, in my case it was an issue that ended > up > > turning into how the modules for my Webserver is organized, and that > > compiler error (about an ambiguous type) occurred because my main > webserver > > datatype was not instantiated yet in that module (using where aproot). > > In essence there were 2 issues > > The original problem (with the ambigous type error) was fixed by just > simply > > providing a type (in this case RepHtml) to the function definition > > Once this was done, the second problem occured due to using splicing with > > Template Haskell (from mkYesod). What I was attempting to do is to > seperate > > the handlers (of the form get/post****R) from the routes created with > > mkYesod. This wasn't originally an issue until I tried to create widgets, > > and it was due to the use of defaultLayout. > > Handlers using defaultLayout needs to be placed *after* the instantiation > of > > yesod (where you do instance yesod *** where aproot *****) however, the > > mkYesod requires the handlers (of the form get/post****R) to be placed > > before the routes. Handlers without a defaultLayout do not require the > Yesod > > instantiation to compile (which is why the error never came up before, I > > never used defaultLayout prior to attempting to use widgets). This > created > > some horrific cyclic module dependably, where I was forced to use hs-boot > > files along with creating a dummy module which just contains the instance > > Yesod ** where ****** by itself. Splitting off that instantiation into > > a separate module was required since hs-boot files don't work with > functions > > that do splicing due to template haskell > > Of course if GHC supported cyclic module dependencies out of the box (and > > support for function splices with template haskell in those hs-boot files > > are added) then this would have been much less painful, is there any plan > to > > support automatic creating of hs-boot files to GHC anytime soon? > > On Sun, May 1, 2011 at 11:00 PM, Michael Snoyman <mich...@snoyman.com> > > wrote: > >> > >> Without seeing the actual code that's causing the breakage, there's > >> not much I can tell you. (If you'd like me to take a look off-list, > >> feel free to send me a private email.) My best recommendation is to > >> try putting a type signature on getRootR. > >> > >> As a general issue: polymorphic Hamlet is a very convenient feature, > >> but I think it leads to too much complexity in the type system. I've > >> added some code for non-polymorphic Hamlet to the Github repo and will > >> be releasing it as its own module (Text.Hamlet.NonPoly) in the next > >> release. Assuming all goes well, it will be replacing the current > >> Hamlet. That essentially means that you'll need to replace your code > >> with something like: > >> > >> getRootR = defaultLayout $ do > >> setTitle "Polymorphic Hamlet" > >> addHtml [$html|<p>I was added with addHtml|] > >> addHamlet [$hamlet|<p>I was added with addHamlet|] > >> addWidget [$whamlet|<p>I was added with addWidget|] > >> > >> And just to make everyone curious: I've also added i18n support to > >> non-poly Hamlet. I've got a long train ride on Tuesday, and I'm > >> planning on documenting it then. > >> > >> Michael > >> > >> On Sun, May 1, 2011 at 6:50 AM, Mathew de Detrich <dete...@gmail.com> > >> wrote: > >> > Ok so I have a problem that was described here > >> > (http://permalink.gmane.org/gmane.comp.lang.haskell.web/1431) in > regards > >> > to > >> > returning a "Ambiguous type variable `a0' in the constraint error" > when > >> > compiling. Originally I thought it was due to the way I was coding > that > >> > part > >> > of the code (or to be more accurate the code specifically for creating > >> > the > >> > so called widgets with addHTML/addWidget,addHamlet). So I copied the > >> > example > >> > code given here exactly (http://www.yesodweb.com/book/example-widgets > ). > >> > Compiling this worked fine, so at the next point I changed the > >> > definition > >> > of getRootR to > >> > getRootR = defaultLayout $ wrapper $ do > >> > setTitle "Polymorphic Hamlet" > >> > addHtml [$hamlet|<p>I was added with addHtml|] > >> > addHamlet [$hamlet|<p>I was added with addHamlet|] > >> > addWidget [$hamlet|<p>I was added with addWidget|] > >> > and then to > >> > getRootR = defaultLayout $ do > >> > setTitle "Polymorphic Hamlet" > >> > addHtml [$hamlet|<p>I was added with addHtml|] > >> > addHamlet [$hamlet|<p>I was added with addHamlet|] > >> > addWidget [$hamlet|<p>I was added with addWidget|] > >> > Both times compiled fine, so the issue wasn't what I originally > thought > >> > that > >> > it was (as described > >> > in http://permalink.gmane.org/gmane.comp.lang.haskell.web/1431). The > >> > problem > >> > is, that when I use the above example code in my WebServer, I get this > >> > Ambigious type error when compiling (even though I have set up the > route > >> > the > >> > exact same way). Unfortunatley I can't provide the code for my > >> > webserver, > >> > since its commercially owned (and it would be pointless because its > just > >> > renamed variables, but otherwise its the same), so does anyone have > any > >> > ideas what could possibly cause such an error (such as a missing/extra > >> > import or some package or something), or possibly some missing > >> > instances? > >> > Also sorry for creating another mailing list, but its a different > issue > >> > then > >> > what I thought it was originally (and I also wanted to put it on > >> > haskell-cafe since its a more general issue) > >> > _______________________________________________ > >> > web-devel mailing list > >> > web-de...@haskell.org > >> > http://www.haskell.org/mailman/listinfo/web-devel > >> > > >> > > > > > >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe