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

OK, here are my initial code comments: * Do we want to move everything into Web.URLT? More to the point, I'm not sure I see the point of calling this URLT, since it doesn't really require any monad transformers; maybe we should call it web-routes and then the module would be Web.Routes? * I like the PathInfo class and to/fromPathSegments. Perhaps we should bundle that with the decode/encodePathInfo into a single module? * I'd like to minimize dependencies as much as possible for the basic package. The two dependencies I've noticed are Consumer and applicative-extras. I think the type signatures would be clearer *without* those packages included, eg: fromPathSegments :: [String] -> Either ErrMsg a I'm not certain what exactly the type of ErrMsg should be here; I don't really have a problem using [String], which would be close to the definition of Failing. * I think it's very important to allow users to supply customized 404 pages. Essentially, we need to augment handleWai (possibly others) with a (ErrMsg -> Application) parameter. * It might be nice to have "type WaiSite url = Site url String Application". By the way, are you certain you want to allow parameterization over the pathInfo type? The only packages that I feel qualified to speak about then are urlt and urlt-wai, and my recommendation would be: urlt contains decode/encodePathInfo, PathInfo class and related functions, Site and related functions. If you agree on allowing the parameterization of 404 errors, then also provide a default 404 error. urlt-wai contains WaiSite, handleWai and related functions. I have not actually tested the code to make sure it's doing the right thing, but I'm sure it's perfect and bug-free ;). I'll do thorough testing when I have more than 10 minutes at the computer. Michael PS: In case you're wondering, we're visiting my in-laws in northern California right now and are driving down to my parents in southern California in a few hours, thus the erratic schedule... On Wed, Mar 24, 2010 at 3:36 PM, Jeremy Shaw wrote:

On Mon, Mar 22, 2010 at 9:41 PM, Michael Snoyman wrote:

...

If I'm not mistaken, I think that addresses all the issues on the table; is there anything left to decide? I look forward to seeing a sample URLT :).

There were other issues that came up, but nothing exciting enough to talk about.

I have pushed a patch which I think brings the code up to date in terms of functionality. See WaiExample for a detail of everything that is currently supported (aside from the happstack / hsp stuff).

The next steps are to:

1. change the names of any functions or types that we do not currently like 2. add the haddock documentation 3. split the package into separate packages so that you don't have to pull in extra dependencies that you aren't going to use 4. turn the WaiExample into a literate tutorial / blog post 5. add a (simple) happstack example as well

So take a look and let me know what you think. Especially in regards to #1.

Then we can also look into how to extend the yesod mkResources stuff to work with this new code.

from a parsing point of view, we almost don't have to do anything, we could just do:

[mkResource| "/foo/:int/:int" = \i j -> mySite (Foo i j) |]

or whatever the syntax is. But that does not solve the issue of how to go from (Foo 1 2) back to /foo/1/2 and ensure that it is the inverse operation.

- jeremy