Re: [web-devel] Type-safe URL handling

26 Mar 2010


      The latest version of the code is now at:

http://src.seereason.com/web-routes/

- jeremy

On Fri, Mar 26, 2010 at 5:36 AM, Victor Nazarov
wrote:
...
On Thu, Mar 25, 2010 at 11:31 PM, Jeremy Shaw 
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@gmail.com>
...
wrote:
...
On Thu, Mar 25, 2010 at 6:48 AM, Michael Snoyman 
wrote:
...
On Wed, Mar 24, 2010 at 3:36 PM, Jeremy Shaw 
wrote:
...
On Mon, Mar 22, 2010 at 9:41 PM, Michael Snoyman <
michael@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