<div>The latest version of the code is now at:</div><div><br></div><div><a href="http://src.seereason.com/web-routes/">http://src.seereason.com/web-routes/</a></div><div><br></div><div>- jeremy</div><br><div class="gmail_quote">
On Fri, Mar 26, 2010 at 5:36 AM, Victor Nazarov <span dir="ltr"><<a href="mailto:asviraspossible@gmail.com">asviraspossible@gmail.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 Thu, Mar 25, 2010 at 11:31 PM, Jeremy Shaw <<a href="mailto:jeremy@n-heptane.com">jeremy@n-heptane.com</a>> wrote:<br>
> Hello Victor,<br>
> The current version of urlt already has template haskell code for<br>
> automatically generating the url from the data type. There is an example of<br>
> that in WaiExample.hs.<br>
> I find that the TH is great when developing the application, because it<br>
> 'just works'. But when the app gets closer to release, I sometimes want to<br>
> customize the way the urls look. (for seo, etc). The nice part is that I can<br>
> just write some custom instances of PathInfo instead of deriving them, and<br>
> all of the other code just works.<br>
> Is there something more that you wanted the TH code to do?<br>
<br>
</div>It sounds just like what I want. Where is the latest code to check it out?<br>
<div><div></div><div class="h5"><br>
><br>
> On Thu, Mar 25, 2010 at 12:11 PM, Victor Nazarov <<a href="mailto:asviraspossible@gmail.com">asviraspossible@gmail.com</a>><br>
> wrote:<br>
>><br>
>> On Thu, Mar 25, 2010 at 6:48 AM, Michael Snoyman <<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>><br>
>> wrote:<br>
>> ><br>
>> ><br>
>> > On Wed, Mar 24, 2010 at 3:36 PM, Jeremy Shaw <<a href="mailto:jeremy@n-heptane.com">jeremy@n-heptane.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> On Mon, Mar 22, 2010 at 9:41 PM, Michael Snoyman <<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>><br>
>> >> wrote:<br>
>> >>><br>
>> >>> If I'm not mistaken, I think that addresses all the issues on the<br>
>> >>> table;<br>
>> >>> is there anything left to decide? I look forward to seeing a sample<br>
>> >>> URLT :).<br>
>> >><br>
>> >> There were other issues that came up, but nothing exciting enough to<br>
>> >> talk<br>
>> >> about.<br>
>> >> I have pushed a patch which I think brings the code up to date in terms<br>
>> >> of<br>
>> >> functionality. See WaiExample for a detail of everything that is<br>
>> >> currently<br>
>> >> supported (aside from the happstack / hsp stuff).<br>
>> >> The next steps are to:<br>
>> >> 1. change the names of any functions or types that we do not currently<br>
>> >> like<br>
>> >> 2. add the haddock documentation<br>
>> >> 3. split the package into separate packages so that you don't have to<br>
>> >> pull in extra dependencies that you aren't going to use<br>
>> >> 4. turn the WaiExample into a literate tutorial / blog post<br>
>> >> 5. add a (simple) happstack example as well<br>
>> >> So take a look and let me know what you think. Especially in regards to<br>
>> >> #1.<br>
>> >> Then we can also look into how to extend the yesod mkResources stuff to<br>
>> >> work with this new code.<br>
>> >> from a parsing point of view, we almost don't have to do anything, we<br>
>> >> could just do:<br>
>> >> [mkResource| "/foo/:int/:int" = \i j -> mySite (Foo i j) |]<br>
>> >> or whatever the syntax is. But that does not solve the issue of how to<br>
>> >> go<br>
>> >> from (Foo 1 2) back to /foo/1/2 and ensure that it is the inverse<br>
>> >> operation.<br>
>> >><br>
>> > I don't have time right now to look at the code, but I will soon (I'm in<br>
>> > the<br>
>> > middle of traveling *again*). Regarding the mkResource issue, I think<br>
>> > it's<br>
>> > slightly more complicated, and what I was thinking of was a combination<br>
>> > of<br>
>> > TemplateHaskell and QuasiQuotes to address it:<br>
>> > * The quasi-quoted content will follow mostly the same syntax, though<br>
>> > allowing you to specify the name of the constructor you wish to assign<br>
>> > to<br>
>> > each resource pattern.<br>
>> > * Since we now will need to have multiple top-level definitions being<br>
>> > generated, quasi-quoting alone won't solve the issue. So I will have a<br>
>> > quasi-quote function to convert the YAML syntax to a StringObject, and<br>
>> > then<br>
>> > a TH function to convert the StringObject to:<br>
>> > 1) A datatype for the URL.<br>
>> > 2) A pair to to/from functions.<br>
>> > 3) A dispatch function.<br>
>> > This is the point at which having WebPlug/HandleT becomes useful.<br>
>> > If that was too vague, just let me know and I'll clarify ;).<br>
>><br>
>> Hello, everybody.<br>
>><br>
>> I haven't been following the entire thread. But I think that typed<br>
>> URLs are great. When I started thinking about typed URLs, I thought<br>
>> about using only data type definition and dropping quosi-quotation<br>
>> entirely in favour of template haskell. I wanted to write some<br>
>> template haskell function to work on data-type declaration, it would<br>
>> use data-constructors names and arguments and build path components<br>
>> from their names. So we will need no new notation to describe<br>
>> application resources, we will never be conserned with URL generator<br>
>> and parser, we will work with our own, carefully defined data-type as<br>
>> it IS a URL.<br>
>><br>
>> --<br>
>> Victor Nazarov<br>
><br>
><br>
<br>
<br>
<br>
</div></div>--<br>
<font color="#888888">Victor Nazarov<br>
</font></blockquote></div><br>