My best advice is to just run the scaffolder. Any other examples I can point you to (like the Haskellers source code) will contain a lot of extra information that won't necessarily apply to your case.
Michael On Mon, May 2, 2011 at 4:28 PM, Mathew de Detrich <dete...@gmail.com> wrote: > ...... > 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 >> >> > >> >> > >> > >> > > > > _______________________________________________ > 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