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

[Vladimir Zlatanov]

>> expressions possible. For example having a compound page with several
>> different posts in it, expressed in the url. This language gives
>> control to the user to express exactly what content they want combined
>> and how. This power is often under estimated. The scenarios are too
>> many to mention.
>
> For example? What's an example of a compound page, expressed in the url?

Ok. Let's try. I'll simplify it a bit. This will assume that we have a
product combinator type

data Comb a b = Comb { left::a, right::b } deriving (Data,Typeable,Show)

Let's have a page which includes two different pieces of content side
by side, let's say product comparison.

The product type could be something like

data Product = Prouct { productId::Integer }

We should be able to form values of type

type TwoProducts = Comb Product Product

That type could be expressed in a URL like:
   http://example.com/Comb/Product/12/Product/14

The whole idea is to have the primitive resources as types, and to
provide the the necessary combinators - product, and maybe a sum one.



>> data Event = Event { eventId     :: Maybe Integer -- ^ The event id.
>>                    , eventScope  :: Bool          -- ^ Show the scope?
>>                    , eventLayout :: Layout        -- ^ Layout for the page.
>>                    , eventRec :: Rec
>>                    }
>> deriving (Data,Typeable,Show)
>>
>> data Rec = Rec { one :: Int, two :: Int }    deriving (Data,Typeable,Show)
>>
>> Would it be possible to express the above in a URL? I understand that
>> at the moment it is not, but what are your thoughts on how far it
>> would be reasonable to push the encoding.
>
> How would you expect that to be represented? I thought a little about
> it… it seems like if it was
>
>> data Rec = Rec { one :: Int, two :: Int }    deriving (Data,Typeable,Show)
>
> Then you could represent it as
>
> /event/id/1/one/a/two/b
>
> or
>
> /event/id/1/rec-one/a/rec-two/b
>
> The former could be a problem as it may lead to ambiguities, unless
> you decided that sub-types' fields would have precedence?

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