Re: [web-devel] Type-safe URL handling

I'm sorry that I didn't have time to read and reply to everything, but Michael, if you decide to go the TH way, why use an intermediate datatype at all? Why not just map the /user/#userid directly to a |handleUser| function? I guess it's really a matter of personal preference. I don't really like TH, and try to avoid it as much as possible (which is why I did the Regular stuff). However, once you go TH, you can go all the way. -chris On 1 apr 2010, at 23:27, Michael Snoyman wrote:

On Thu, Apr 1, 2010 at 12:13 PM, Jeremy Shaw wrote: On Thu, Apr 1, 2010 at 12:19 PM, Michael Snoyman wrote: Minor update: I think that YAML syntax for these kinds of routes is a little bit verbose; any thoughts on this syntax:

/ Home GET /user/#userid User GET PUT DELETE /static Static StaticRoutes staticRoutes /foo/*slurp Foo /bar/$barparam Bar

First column is the pattern, second is the constructor name, and after that you have three possibilities:

Nothing is a handler function for any request method. Above, the fourth and fifth entries. A list of request methods will allow a handler function for each request method. Above, the first and second entries. A datatype and function name, allowing a subsite datatype and subsite function. Above,the third entry. I'll need to develop this one a bit more.

How would this pattern be translated to the new scheme ?

/entries/$entryId/$filename: GET: media

I am guessing:

/entries/$entryId/$filename Media GET

And the Media constructor would be:

| Media String String

?

- jeremy

/entries/$entryId/$filename:

Exactly, with the dispatch function being:

getMedia :: String -> String -> Application

(Actually, there's most likely going to be some type of argument datatype as well, which is where the complication I alluded to with subsites comes from. However, I'll address this more clearly when there's some actual code to back it up.)

Michael