[web-devel] Type-safe URL handling

[Michael Snoyman]

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 <jeremy at n-heptane.com> wrote:

> On Mon, Mar 22, 2010 at 9:41 PM, Michael Snoyman <michael at snoyman.com>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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/web-devel/attachments/20100325/7b35d202/attachment-0001.html