[web-devel] ANN: url-generic-0.1: Parse/format generic key/value URLs from record data types.

Christopher Done chrisdone at googlemail.com
Tue Jun 21 01:12:01 CEST 2011

On 21 June 2011 00:03, Jeremy Shaw <jeremy at n-heptane.com> wrote:
> On Mon, Jun 20, 2011 at 2:50 PM, Christopher Done
> <chrisdone at googlemail.com> wrote:
>> 1) Erm, it's actually documented? ;-)
> I am planning to write documentation for web-routes this week or next
> week. There is an additional web-routes extension I need to finish up
> first. In fact, I was working on that code when I got distracted by
> this thread :p

Ah, good. Honestly I've tried several times to figure out how to
actually start using web-routes and failed. I understand each module
individually, but I don't know how it's supposed to be used as a
whole, I figured I'd wait for more documentation. I noticed that it
allowed for custom URL-formatting, so I thought I'd do this. As I said
up there, I didn't know how this would interact with web-routes. I
thought I'd try to set an example a bit by putting extra effort into
documenting url-generic. :-P

> So, I would be happy to work with you to create a web-routes-syb
> package that uses your set of encoding rules. (Actually, that modified
> code on hpaste plus a  little extra glue code is all you really need).

That would be cool. I was hoping it could be used with web-routes.

> You allow the fields to be specified in any order -- but that makes it
> difficult to support record types that contain other record types,
> doesn't it?

Does it? Why?

/foo/x/1/y/a/1/b/2/z/2 seems no more ambiguous than /foo/y/b/1/a/2/z/2/x/1

I'd think the problem stopping embedded types is optional fields.

> I am not sure why arbitrary ordering is more valuable than nested
> records.

Mostly I'm thinking about users (and myself) composing these URLs. I
initially had strict ordering but then composing the URLs to (from the
user perspective) a strict "arbitrary" ordering is annoying and kind
of needless. This is partly why optionality is nice. Maybe I want to
go to /event/1234, and I don't want to specify

But yeah, I don't see why nested records can't be accomplished with
arbitrary ordering.

Vladimir also brought this up:

On 20 June 2011 13:37, Vladimir Zlatanov <vlado at dikini.net> wrote:
> To be honest I'm not sure. But if we use '/' as white space, and have
> only left associativie combinators/constructors, with no variadic
> arguments, the result should be unambiguous. It will be possibly
> comprehendible (is it a word?) by humans for short urls.
> I would use the constructors like:
> /Event/id/1/Rec/one/a/two/b
> This makes it unambiguous what we mean, in case we have the same field
> names, but slightly more verbose.
> /Event/1/Rec/a/b
> would work as well, but you need the source or specs to read it

It seems like we don't need to mention the constructors, we can just
write out the structure as in JSON.

/foo/x/1/y/a/1/b/2/z/2 => {foo:{x:1,y:{a:1,b:2},z:2}}

If you know how many fields a record should have you know how many to
count. I suppose we could also stick the constructor in there for

/event/id/1/pagination/limit/5/offset/6/scope/true =>

I guess that is more readable. :-)

> If you are using the library to generate the urls, then you
> already know the order.

As above, I don't think order matters when you have the names and the count

> If you wanted to extend Layout with a constructor that takes an argument;
> data Layout = Wide | Thin | Collapsed | Arbitrary Integer
> Then you are kind of stuck? If you get rid of variable field ordering,
> then you can encode a much larger range of URL types.

Again, is it relevant? The question seems more like how do you encode
that field? Like this?


Is that any harder to parse than /event/layout/arbitrary/1/id/1?

I think if it is then one's parser is faulty. It's a bit late, I have
an inexplicable headache. Maybe I'm missing something on this.

> Anyway, I highly recommend you build on top of web-routes. web-routes
> is a pretty lightweight dependency and it already solves the problems
> of low-level URL encoding, escaping, etc. It also provides integration
> with yesod, happstack, hsp, and more. That means you can just focus on
> the high-level issue of deriving a nice looking URL scheme using SYB.
> If there is someway in which web-routes in not suitable to build on, I
> would love to fix it.

That's what I was hoping to do anyway. I've been putting off doing any
URL thing for hpaste until I'm happy with the right library. Sadly
there isn't a Snap web-routes thingie. Greg Collins said he was
working on one but I think that never fruited. Once I grok how
web-routes work I doubt I'll have a problem laying it ontop of Snap. I
hope that I can merely derive MonadRoute (or whatever it was) for my
monad stack and that I don't have to use lifts and stuff. I think
there was some RouteT monad with functions with concrete RouteT types
instead of classes which can be a pain but I can't remember. I'm going
to bed!

Anyway, looking forward to some documentation, even though it's my
fault for being lazy and impatient. ;-)


More information about the web-devel mailing list