[web-devel] Type-safe URL handling
Chris Eidhof
chris at eidhof.nl
Sat Apr 3 16:37:45 EDT 2010
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 <jeremy at n-heptane.com> wrote:
> On Thu, Apr 1, 2010 at 12:19 PM, Michael Snoyman <michael at snoyman.com> 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
More information about the web-devel
mailing list