[web-devel] Type-safe URL handling
jeremy at n-heptane.com
Mon Mar 29 12:18:32 EDT 2010
On Mon, Mar 29, 2010 at 8:47 AM, Michael Snoyman <michael at snoyman.com>wrote:
> We'd been discussing the PathInfo class previously; I understand now what
> you're trying to achieve with it, but I think for a lot of use cases using a
> parser like that will be unnecesary. For those cases, I'd hate to introduce
> a parsec dependency, especially given the 2/3 split we're dealing with right
Well, parsec is in the haskell platform, so it's really a question of can be
it implemented so that it works with both 2 and 3.
> I know it's painful to split this up into even more packages, but we do you
> think of adding web-routes-parser?
I would consider it, but I don't understand how that would work...
So far you have been pretty unexcited about the parsing having a type
[String] -> (Either String a, [String])
because it is often 'unnecessary'. But the problem with, [String] -> (Either
String a), is that, as far as I can tell, it won't work in the cases where
it *is* necessary. And you can't simply switch to, [String] -> (Either
String a, [String]), when that happens.. But perhaps I am missing something
> Also, question about the Site datatype: Did we want the formatLink and
> parseLink functions to work on [String] instead of String? I think I see
> advantages either way. Also, I'm not sure if I sent this previously, but I
> think the defaultPage function is redundant; that should probably be
> specified by 'parseLink ""'.
I will have to think about [String] vs String more. I don't want using Site
to mean you have to use PathInfo, but switching to [String] wouldn't have
that effect, and would mean that people would not have to worry about those
pesky encoding issues. The only real use case I have for not using PathInfo
is if you wanted to create a function like: gfromPathSegments :: (Data url)
=> PathInfo -> Either String url. And that can be done most easily if
PathInfo = [String]. So I think I'll make that change. In the old code base,
where there was no url encoding done by the library, it did not really make
Regarding defaultPage, not all methods of generating formatLink / parseLink
lend themselves to handling "" very easily, so it seemed nice to have a
single place that can add that case in, rather than add similar code to all
the parsers.. Also, I think that I sometimes changes the landing page of my
site. But I think I will make 'defaultPage' a Maybe value, and bill it as a
way to 'override' where "" resolves to.
> I'll try to get started on porting the Yesod mkResources code over to
> web-routes now.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the web-devel