Type: yesod init
It will ask you some questions and then generate a bootstrap site. Michael On Mon, May 2, 2011 at 4:40 PM, Mathew de Detrich <dete...@gmail.com> wrote: > 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