... and now that's done :-). You can use whatever methods you want now, and it also solves the annoying issue when importing both Web.Routes.Quasi and Network.Wai. Michael On Sun, Apr 4, 2010 at 10:16 AM, Michael Snoyman wrote:

Because I want to eventually get rid of the Method datatype entirely and allow arbitrary methods ;).

Michael

On Sat, Apr 3, 2010 at 9:53 AM, Peter Robinson wrote:

...

Nice work!

Is there a specific reason for excluding HEAD and OPTIONS?

Peter

...

web-routes-quasi is now at the point where it can be used for sites, and I'd love to hear some feedback. I've put together a little sample that demonstrates how you can use quasi-quoting and define your routes, embed subsites and serve the resulting application via WAI. (My example uses WAI, but the package itself is not tied to WAI.) The code is on github[1]; the main function for the blog is in blog.hs (with the lowercase b). I believe this just depends on Jeremy's web-routes package, wai and wai-extra. Note that I did not use web-routes-wai; I think there are some problems in there for breaking up the pathinfo, and I didn't have time to dig

On 3 April 2010 00:51, Michael Snoyman wrote: through

...

it. Also, this package currently ignores entirely the defaultPage component of Site, though if there is desire support can be added for it. One minor bug is that you can't have an alternate GET, POST, PUT or DELETE constructor imported; hopefully that will get cleaned up. Any comments and suggestions are welcome! My goal is to port Yesod over to this as soon as the web-routes set of packages are released, so if you're interested in Yesod, you should be interested in this too ;). Michael [1] http://github.com/snoyberg/web-routes-quasi _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

It's like you read my mind... I very consciously designed this in such a way that it would be possible to do this. More to the point: I think it would be possible to use web-routes-quasi to create a RESTful API and then auto-generate the basic API documentation. I'd like to eventually figure out a way to support GET and POST parameters as well for this. Anyway, for the basic [String] methods, I can add support for it in the future; I'd rather wait until we have the rest of web-routes settled down first. (Of course, a patch is always welcome.) Michael On Tue, Apr 6, 2010 at 1:16 AM, Peter Robinson wrote:

Again, nice work! :) The web-routes-quasi package makes writing routes quite enjoyable. One thing that I was wondering about is, is it possible to get the list of supported methods (as [String]) for a given url?

Peter

...

... and now that's done :-). You can use whatever methods you want now, and it also solves the annoying issue when importing both Web.Routes.Quasi and Network.Wai. Michael

On Sun, Apr 4, 2010 at 10:16 AM, Michael Snoyman wrote:

...

Because I want to eventually get rid of the Method datatype entirely and allow arbitrary methods ;). Michael

On Sat, Apr 3, 2010 at 9:53 AM, Peter Robinson wrote:

...

Nice work!

Is there a specific reason for excluding HEAD and OPTIONS?

Peter

On 3 April 2010 00:51, Michael Snoyman wrote:

...

web-routes-quasi is now at the point where it can be used for sites, and I'd love to hear some feedback. I've put together a little sample that demonstrates how you can use quasi-quoting and define your routes, embed subsites and serve the resulting application via WAI. (My example

uses

...

...

...

WAI, but the package itself is not tied to WAI.) The code is on github[1]; the main function for the blog is in blog.hs (with the lowercase b). I believe this just depends on Jeremy's web-routes package, wai and wai-extra. Note that I did not use web-routes-wai; I think there are some

On 4 April 2010 20:34, Michael Snoyman wrote: problems

...

...

...

...

in there for breaking up the pathinfo, and I didn't have time to dig through it. Also, this package currently ignores entirely the defaultPage component of Site, though if there is desire support can be added for it. One minor bug is that you can't have an alternate GET, POST, PUT or DELETE constructor imported; hopefully that will get cleaned up. Any comments and suggestions are welcome! My goal is to port Yesod over to this as soon as the web-routes set of packages are released, so if you're interested in Yesod, you should be interested in this too ;). Michael [1] http://github.com/snoyberg/web-routes-quasi _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

On 6 April 2010 21:38, Michael Snoyman wrote:

It's like you read my mind... I very consciously designed this in such a way that it would be possible to do this. More to the point: I think it would be possible to use web-routes-quasi to create a RESTful API and then auto-generate the basic API documentation. I'd like to eventually figure out a way to support GET and POST parameters as well for this. Anyway, for the basic [String] methods, I can add support for it in the future; I'd rather wait until we have the rest of web-routes settled down first. (Of course, a patch is always welcome.)

Here are some more thoughts on the above point: The handler functions take the user supplied type, a function (MyRoute -> String), and the fields of the corresponding MyRoute constructors as parameters. - 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.) - 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? Peter

On 11 April 2010 07:00, Michael Snoyman 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 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...) Peter

On 12 April 2010 17:02, Michael Snoyman wrote:

On Mon, Apr 12, 2010 at 1:17 AM, Peter Robinson wrote:

...

On 11 April 2010 07:00, Michael Snoyman 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.

Well, using -ddump-splices it turned out to be an educative experience as it helped me to understand template haskell and quasi-quoting. The current implementation in GHC seems to be quite different from the one described in the original papers, so reading your code helped me fill in the blanks! :)

Someone (maybe you) mentioned earlier that web-routes-quasi is geared more towards framework writers; I think this is probably very true.

It wasn't me, but I do agree. ;) Nevertheless, I think web-routes-quasi together with a templating package will facilitate writing small web apps a lot.

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.

Ok, then let's leave it that way. Peter

On Mon, Apr 12, 2010 at 1:44 AM, Alberto G. Corona wrote:

Hi Michael,

I´m involved in the development of an application server (not a framework) with rather different goals than Yessod (its´nt so elegant). I will tell more about it whenever there is something solid enough to play with it.

Just a few questions to clarify my mind:

When you mention WAI you mean Web Access Initiative? I checked your Network.WAI package and it seems that gzip facilities and so on have nothing in common with usability and accesibility issues.

No, it stands for Web Application Interface. It's a standardized interface between web applications and web servers, so you can write an application once and have it run on multiple backends, eg CGI, FastCGI, stand-alone server.

- Could you point me to documentation about web-routes? I´m in the internet business since a few years, so I suspect that I know this with another name.

Thank you a lot.

web-routes is not yet released; the code is available at http://src.seereason.com/web-routes/. I believe Jeremy will be releasing it in the not-too-distant future, and there will be more documentation available then. I also just wrote a blog entry[1] that tangentially addressed it.

Michael [1] http://www.snoyman.com/blog/entry/whats-cooking-with-yesod/

2010/4/3 Michael Snoyman

...

web-routes-quasi is now at the point where it can be used for sites, and I'd love to hear some feedback. I've put together a little sample that demonstrates how you can use quasi-quoting and define your routes, embed subsites and serve the resulting application via WAI. (My example uses WAI, but the package itself is not tied to WAI.)

The code is on github[1]; the main function for the blog is in blog.hs (with the lowercase b). I believe this just depends on Jeremy's web-routes package, wai and wai-extra.

Note that I did not use web-routes-wai; I think there are some problems in there for breaking up the pathinfo, and I didn't have time to dig through it. Also, this package currently ignores entirely the defaultPage component of Site, though if there is desire support can be added for it.

One minor bug is that you can't have an alternate GET, POST, PUT or DELETE constructor imported; hopefully that will get cleaned up.

Any comments and suggestions are welcome! My goal is to port Yesod over to this as soon as the web-routes set of packages are released, so if you're interested in Yesod, you should be interested in this too ;).

Michael

[1] http://github.com/snoyberg/web-routes-quasi

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

Cool. I agree that other types would be interesting, but as you said, implementation is a little tricky. I'm still in the process of modifying it as I integrate it with Yesod. In particular, support for subsites is getting better. I'm hoping it gets to the point of proper web plugins. Michael On Fri, Apr 16, 2010 at 4:09 PM, Jeremy Shaw wrote:

Hello,

I poked at it a bit, but don't have anything especially interesting to say.

Obviously, I would like it if there was ways to do things like map integers to newtyped values. Or to allow the use of 'variables' other than strings and ints. But, I am not actually clear that those things can be implemented :)

Once I actually try to use quasi for a project I will likely have more feedback.

- jeremy

On Apr 2, 2010, at 5:51 PM, Michael Snoyman wrote:

web-routes-quasi is now at the point where it can be used for sites, and I'd love to hear some feedback. I've put together a little sample that demonstrates how you can use quasi-quoting and define your routes, embed subsites and serve the resulting application via WAI. (My example uses WAI, but the package itself is not tied to WAI.)

The code is on github[1]; the main function for the blog is in blog.hs (with the lowercase b). I believe this just depends on Jeremy's web-routes package, wai and wai-extra.

Note that I did not use web-routes-wai; I think there are some problems in there for breaking up the pathinfo, and I didn't have time to dig through it. Also, this package currently ignores entirely the defaultPage component of Site, though if there is desire support can be added for it.

One minor bug is that you can't have an alternate GET, POST, PUT or DELETE constructor imported; hopefully that will get cleaned up.

Any comments and suggestions are welcome! My goal is to port Yesod over to this as soon as the web-routes set of packages are released, so if you're interested in Yesod, you should be interested in this too ;).

Michael

[1] http://github.com/snoyberg/web-routes-quasi