thaldyron at gmail.com
Mon Apr 12 04:17:46 EDT 2010
On 11 April 2010 07:00, Michael Snoyman <michael at snoyman.com> wrote:
>> - Wouldn't it be simpler to automatically derive an instance of Show for
>> the MyRoute type? (Since MyRoute is created on the fly anyway, I don't
>> see why anyone would want to derive a different Show instance.)
> Multiple problems:
> * The rest of web-routes doesn't use Show that way.
> * Usually, we'll need another parameter to create this function, such as the
> application root.
> * Show is usually the inverse of Read. I suppose we could make the Read
> instance the other side, but that we're just not following what is normally
> expected of these instances, which is to return Haskell-formatted data.
Right. I've noticed that your newest approach uses an "explode" function
which makes the type signature of handler functions shorter. :)
>> - About the possibility of querying the supported methods: The use case
>> scenario I have in mind is having a default handler for handling OPTIONS
>> that returns the available methods. Currently this won't work since that
>> of the resource information is unavailable inside the handler. Do you have
>> thoughts on how to change the design to make this possible?
> Well, the simplest thing I can do is make the [Resource] result from the
> quasi-quoting available, which would give you enough information to write
> something to intercept OPTIONS requests before handing them to the rest of
> the application. Does that sound good enough?
Yes, sounds good. (Alternatively, I could separate parseRoutes from
and make the resources a top level declaration, which wouldn't require any
changes on your part...)
More information about the web-devel