Im not sure what you mean exactly by "run the scaffolder", (just to be clear, I am not exactly sure what technically scaffolding is apart from it being referenced once or twice in your documentation)
I assume you are talking about setting up the handlers for a specific route, and then creating that single route on its own (instead of all at once with mkYesod)? On Mon, May 2, 2011 at 11:30 PM, Michael Snoyman <mich...@snoyman.com>wrote: > 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