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