These approaches will definitely work, but I'm worried that creating a whole set of datatypes to represent URLs is overkill. In Yesod (I'm sure many of you have seen) I use quasi-quoting for defining the resources, like such:<div>
<br></div><div>[$mkResources|</div><div>/user:</div><div> GET: userList</div><div>/user/find/#userid</div><div> GET: userFind</div><div>/user/name/$username</div><div> GET: userName</div><div>|]</div><div><br></div>
<div>And so on and so forth. I don't think defining UserRoute adds much, besides making the job of the library writer a little bit easier by pushing the work off to the user. I think the six lines above succinctly:</div>
<div><br></div><div>* define the valid routes</div><div>* define the data types for arguments</div><div>* define the appropriate mapping to handler functions for each request method</div><div><br></div><div>Chris mentioned earlier to me the idea of using quasi-quoting on the link generation side, perhaps like:</div>
<div><br></div><div>[$link|/user/find/6]</div><div><br></div><div>I think the only piece of the puzzle missing to combine these two together is to have mkResources output something along the lines of:</div><div><br></div>
<div>data RoutePiece = StaticPiece String | IntPiece | StringPiece</div><div>_validRoutes :: [[RoutePiece]]</div><div>_validRoutes =</div><div> [ [StaticPiece "user"]</div><div> , [StaticPiece "user", StaticPiece "find", IntPiece]</div>
<div> , [StaticPiece "user", StaticPiece "name", StringPiece]</div><div> ]</div><div><br></div><div>Now if you write</div><div><br></div><div>[$link|/user/find/michael]</div><div><br></div><div>link can look up in _validRoutes that there is no matching route and complain at compile time.</div>
<div><br></div><div>Advantages: less typing by the user.</div><div>Disadvantages: we'll have to restrict the data types allowed, but in practice I think people will usually want only strings and ints anyway. Also, this approach is more complex.</div>
<div><br></div><div>Michael</div><div><br><div class="gmail_quote">On Tue, Mar 16, 2010 at 7:04 AM, Chris Eidhof <span dir="ltr"><<a href="mailto:chris@eidhof.nl">chris@eidhof.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I have the feeling it adds a lot of complexity. I agree with you that, if you want modularity, your components should only provide relative URLs and need to be parameterized over how to build an absolute URL. I didn't think of that problem, and using a custom monad transformer is definitely a solution.<br>
<br>
However, I'm always hesitant to build up stacks of monad transformers, it adds a lot of complexity. I would rather use something like typeclass, but I'm not sure yet how to do that.<br>
<font color="#888888"><br>
-chris<br>
</font><div><div></div><div class="h5"><br>
On 16 mrt 2010, at 14:29, Jeremy Shaw wrote:<br>
<br>
> Hello,<br>
><br>
> It looks nearly identical, but without the URLT monad transformer.<br>
><br>
> Instead of ToURL I have the class:<br>
><br>
> class AsURL a where<br>
> toURLS :: a -> ShowS<br>
> fromURLC :: Consumer String (Failing a)<br>
><br>
> With is basically the same. Except toURLS returns a ShowS instead of [String]. fromURLC consumes a list of [String]. These functions are wrapped up to provide:<br>
><br>
> toURL :: (AsURL a) => a -> String<br>
> fromURL :: (AsURL a) => String -> Failing a<br>
><br>
> I do not have generics based url printing/parsing, but there is no reason it could not be added. I do have template haskell based code though.<br>
><br>
> <a href="http://src.seereason.com/urlt/URLT/TH.hs" target="_blank">http://src.seereason.com/urlt/URLT/TH.hs</a><br>
><br>
> The thing you don't have is the URLT monad transformer:<br>
><br>
> <a href="http://src.seereason.com/urlt/URLT/Base.hs" target="_blank">http://src.seereason.com/urlt/URLT/Base.hs</a><br>
><br>
> Here is why you want it. Imagine you write an image gallery library:<br>
><br>
> data ImageURL = Upload | ViewImage Int<br>
><br>
> when you call toURL, you are going to get urls like, /Upload, /ViewImage/1, etc.<br>
><br>
> Now let's say I try to use your library in my application. So at first I try:<br>
><br>
> data MyApp = Upload | FooBar<br>
><br>
> But when a URL comes in, how do I know if I should decode it as MyApp or ImageURL? Do I try both and see which one succeeds? Except we both have a constructor Upload, so both will succeed. There is no way to tell with Upload the path "/Upload" is referring to.<br>
><br>
> So now I try:<br>
><br>
> data MyApp = Upload | FooBar | Images ImageURL<br>
><br>
> now I know that all incoming urls are decoded as MyApp. But there is still a problem. In my code I could write:<br>
><br>
> toUrl (Images (ViewImage 1))<br>
><br>
> but in your library code, you don't know anything about the Images constructor. So you just call,<br>
><br>
> toURL (ViewImage 1)<br>
><br>
> which generates /ViewImage/1 instead of the required /Images/ViewImage/1.<br>
><br>
> What I need is someway to tell your library code what prefix to add at the beginning. That is exactly what the URLT monad does. It just holds a function that adds a prefix to the URL.<br>
><br>
> so in your library you have:<br>
><br>
> image :: ImageURL -> URLT ImageURL m ()<br>
> image Upload =<br>
> do ...<br>
> u <- showURL (ViewImage n)<br>
> ...<br>
> image (ViewImage num) = ...<br>
><br>
> Instead of calling toURL, it calls showURL, which adds the context to the URL and then calls toURL on it.<br>
><br>
> And in my code I have:<br>
><br>
> myApp :: MyAPP -> URLT MyApp m ()<br>
> mpApp Upload = ...<br>
> myApp FooBar = ...<br>
> myApp (Images subURL) = nestURL Images $ images subURL<br>
><br>
> the 'nextURL Images' adds the Images context to the URLT environment. It can be used to nest multiple levels if needed:<br>
><br>
> nestURL A $ nestURL B $ nestURL Images $ showURL (ViewImage 1)<br>
><br>
> would get turned into something like:<br>
><br>
> "/A/B/Images/ViewImage/1"<br>
><br>
> What do you think?<br>
><br>
> - jeremy<br>
><br>
><br>
> On Tue, Mar 16, 2010 at 3:52 AM, Chris Eidhof <<a href="mailto:chris@eidhof.nl">chris@eidhof.nl</a>> wrote:<br>
> Hey everyone,<br>
><br>
> I just wrote down some of my ideas about type-safe URL handling on github, it's at <a href="http://gist.github.com/333769" target="_blank">http://gist.github.com/333769</a><br>
><br>
> I think it's similar to what Jeremy is doing with his urlt package [1].<br>
><br>
> -chris<br>
><br>
> [1]: <a href="http://src.seereason.com/~jeremy/SimpleSite1.html" target="_blank">http://src.seereason.com/~jeremy/SimpleSite1.html</a><br>
><br>
> _______________________________________________<br>
> web-devel mailing list<br>
> <a href="mailto:web-devel@haskell.org">web-devel@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/web-devel" target="_blank">http://www.haskell.org/mailman/listinfo/web-devel</a><br>
><br>
<br>
_______________________________________________<br>
web-devel mailing list<br>
<a href="mailto:web-devel@haskell.org">web-devel@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/web-devel" target="_blank">http://www.haskell.org/mailman/listinfo/web-devel</a><br>
</div></div></blockquote></div><br></div>