[web-devel] web-routes-quasi

[Michael Snoyman]

On Mon, Apr 12, 2010 at 1:17 AM, Peter Robinson <thaldyron at gmail.com> wrote:

> 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. :)
>
> Wow, I can't believe anyone was able to follow that code ;). My hat's off
to you.

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!


> >> - 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
> >> part
> >> of the resource information is unavailable inside the handler. Do you
> have
> >> any
> >> 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
> createRoutes
> and make the resources a top level declaration, which wouldn't require any
> changes on your part...)
>
> 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.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/web-devel/attachments/20100412/c299eec5/attachment-0001.html