[web-devel] Type-safe URL handling
michael at snoyman.com
Thu Mar 25 13:29:13 EDT 2010
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
* 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
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.
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
> 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
> 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...
More information about the web-devel