<br><br><div class="gmail_quote">On Mon, Apr 12, 2010 at 1:17 AM, Peter Robinson <span dir="ltr"><<a href="mailto:thaldyron@gmail.com">thaldyron@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 11 April 2010 07:00, Michael Snoyman <<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>> wrote:<br>
>> - Wouldn't it be simpler to automatically derive an instance of Show for<br>
>> the MyRoute type? (Since MyRoute is created on the fly anyway, I don't<br>
>> see why anyone would want to derive a different Show instance.)<br>
>><br>
> Multiple problems:<br>
> * The rest of web-routes doesn't use Show that way.<br>
> * Usually, we'll need another parameter to create this function, such as the<br>
> application root.<br>
> * Show is usually the inverse of Read. I suppose we could make the Read<br>
> instance the other side, but that we're just not following what is normally<br>
> expected of these instances, which is to return Haskell-formatted data.<br>
<br>
</div>Right. I've noticed that your newest approach uses an "explode" function<br>
which makes the type signature of handler functions shorter. :)<br>
<div class="im"><br></div></blockquote><div>Wow, I can't believe anyone was able to follow that code ;). My hat's off to you.</div><div><br></div><div>Someone (maybe you) mentioned earlier that web-routes-quasi is geared more towards framework writers; I think this is probably very true. Nonetheless, before release I'll put in proper documentation about the type signatures of all the parameters, since the whole thing can be very tricky. I myself had trouble figuring it out for integration into Yesod, and I wrote all the packages involved!</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
>> - About the possibility of querying the supported methods: The use case<br>
>> scenario I have in mind is having a default handler for handling OPTIONS<br>
>> that returns the available methods. Currently this won't work since that<br>
>> part<br>
>> of the resource information is unavailable inside the handler. Do you have<br>
>> any<br>
>> thoughts on how to change the design to make this possible?<br>
><br>
> Well, the simplest thing I can do is make the [Resource] result from the<br>
> quasi-quoting available, which would give you enough information to write<br>
> something to intercept OPTIONS requests before handing them to the rest of<br>
> the application. Does that sound good enough?<br>
<br>
</div>Yes, sounds good. (Alternatively, I could separate parseRoutes from<br>
createRoutes<br>
and make the resources a top level declaration, which wouldn't require any<br>
changes on your part...)<br>
<font color="#888888"><font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#888888"><br></font></font></font></blockquote><div>Actually, that sounds like a much better idea. I'm trying to ensure that web-routes-quasi generated code compiles without warnings on -Wall, and exporting information that won't be used normally would generate an unused warning.</div>
<div><br></div><div>Michael</div></div>