[web-devel] Type-safe URL handling
jeremy at n-heptane.com
Thu Mar 25 16:31:53 EDT 2010
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?
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>
> > On Wed, Mar 24, 2010 at 3:36 PM, Jeremy Shaw <jeremy at n-heptane.com>
> >> 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
> >>> 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
> >> about.
> >> I have pushed a patch which I think brings the code up to date in terms
> >> functionality. See WaiExample for a detail of everything that is
> >> 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
> >> from (Foo 1 2) back to /foo/1/2 and ensure that it is the inverse
> > I don't have time right now to look at the code, but I will soon (I'm in
> > middle of traveling *again*). Regarding the mkResource issue, I think
> > slightly more complicated, and what I was thinking of was a combination
> > 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
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the web-devel