OK, here are my initial code comments:<div><br></div><div>* 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?</div>
<div><br></div><div>* I like the PathInfo class and to/fromPathSegments. Perhaps we should bundle that with the decode/encodePathInfo into a single module?</div><div><br></div><div>* 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:</div>
<div><br></div><div> fromPathSegments :: [String] -> Either ErrMsg a</div><div><br></div><div>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.</div>
<div><br></div><div>* 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.</div><div><br></div>
<div>* 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?</div><div><br></div><div>The only packages that I feel qualified to speak about then are urlt and urlt-wai, and my recommendation would be:</div>
<div><br></div><div>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.</div>
<div><br></div><div>urlt-wai contains WaiSite, handleWai and related functions.</div><div><br></div><div><br></div><div>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.</div>
<div><br></div><div>Michael</div><div><br></div><div>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...</div>
<div><br><div class="gmail_quote">On Wed, Mar 24, 2010 at 3:36 PM, Jeremy Shaw <span dir="ltr"><<a href="mailto:jeremy@n-heptane.com">jeremy@n-heptane.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Mon, Mar 22, 2010 at 9:41 PM, Michael Snoyman <span dir="ltr"><<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a>></span> wrote:<br></div><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>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 :).</div>
<div><br></div></blockquote><div><br></div></div><div>There were other issues that came up, but nothing exciting enough to talk about.</div><div><br></div><div>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).</div>
<div><br></div><div>The next steps are to:</div><div><br></div><div> 1. change the names of any functions or types that we do not currently like</div><div> 2. add the haddock documentation</div><div> 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</div>
<div> 4. turn the WaiExample into a literate tutorial / blog post</div><div> 5. add a (simple) happstack example as well</div><div><br></div><div>So take a look and let me know what you think. Especially in regards to #1.</div>
<div><br></div><div>Then we can also look into how to extend the yesod mkResources stuff to work with this new code.</div><div><br></div><div>from a parsing point of view, we almost don't have to do anything, we could just do:</div>
<div><br></div><div> [mkResource| "/foo/:int/:int" = \i j -> mySite (Foo i j) |]</div><div><br></div><div>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.</div>
<div><br></div><font color="#888888"><div>- jeremy</div></font></div>
</blockquote></div><br></div>