[web-devel] Type-safe URL handling

[Victor Nazarov]

On Thu, Mar 25, 2010 at 11:31 PM, Jeremy Shaw <jeremy at n-heptane.com> wrote:
> Hello Victor,
> The current version of urlt already has template haskell code for
> automatically generating the url from the data type. There is an example of
> that in WaiExample.hs.
> I find that the TH is great when developing the application, because it
> 'just works'. But when the app gets closer to release, I sometimes want to
> customize the way the urls look. (for seo, etc). The nice part is that I can
> just write some custom instances of PathInfo instead of deriving them, and
> all of the other code just works.
> Is there something more that you wanted the TH code to do?

It sounds just like what I want. Where is the latest code to check it out?

>
> On Thu, Mar 25, 2010 at 12:11 PM, Victor Nazarov <asviraspossible at gmail.com>
> wrote:
>>
>> On Thu, Mar 25, 2010 at 6:48 AM, Michael Snoyman <michael at snoyman.com>
>> wrote:
>> >
>> >
>> > 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.
>> >>
>> > I don't have time right now to look at the code, but I will soon (I'm in
>> > the
>> > middle of traveling *again*). Regarding the mkResource issue, I think
>> > it's
>> > slightly more complicated, and what I was thinking of was a combination
>> > of
>> > TemplateHaskell and QuasiQuotes to address it:
>> > * The quasi-quoted content will follow mostly the same syntax, though
>> > allowing you to specify the name of the constructor you wish to assign
>> > to
>> > each resource pattern.
>> > * Since we now will need to have multiple top-level definitions being
>> > generated, quasi-quoting alone won't solve the issue. So I will have a
>> > quasi-quote function to convert the YAML syntax to a StringObject, and
>> > then
>> > a TH function to convert the StringObject to:
>> >   1) A datatype for the URL.
>> >   2) A pair to to/from functions.
>> >   3) A dispatch function.
>> > This is the point at which having WebPlug/HandleT becomes useful.
>> > If that was too vague, just let me know and I'll clarify ;).
>>
>> Hello, everybody.
>>
>> I haven't been following the entire thread. But I think that typed
>> URLs are great. When I started thinking about typed URLs, I thought
>> about using only data type definition and dropping quosi-quotation
>> entirely in favour of template haskell. I wanted to write some
>> template haskell function to work on data-type declaration, it would
>> use data-constructors names and arguments and build path components
>> from their names. So we will need no new notation to describe
>> application resources, we will never be conserned with URL generator
>> and parser, we will work with our own, carefully defined data-type as
>> it IS a URL.
>>
>> --
>> Victor Nazarov
>
>



-- 
Victor Nazarov