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

On 21 June 2011 00:03, Jeremy Shaw wrote:

On Mon, Jun 20, 2011 at 2:50 PM, Christopher Done 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 /event/1234/scope/false. 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 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 readability. /event/id/1/pagination/limit/5/offset/6/scope/true => {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? /event/id/1/layout/arbitrary/1 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. ;-) Ciao!