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

[Christopher Done]

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
/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 <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
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!