[web-devel] Type-safe URL handling
jeremy at n-heptane.com
Fri Mar 26 19:01:57 EDT 2010
A variation which is more obviously hierarchical in nature:
data User = User LastName FirstName
data Section = Recent | TopRated
data UserHomeURL = Wall Section | Profile
data UserURL = ViewHome User UserHome
Which would be used to construct urls like:
On Fri, Mar 26, 2010 at 5:44 PM, Jeremy Shaw <jeremy at n-heptane.com> wrote:
> On Fri, Mar 26, 2010 at 5:13 PM, Michael Snoyman <michael at snoyman.com>wrote:
>> Can you give me any real-world examples where you would have URL routes
>> built up like that? It seems like this is an optimization for the abnormal
> I am not sure I would consider it an 'optimization' -- with out this change
> the desired behavior can not be expressed as far as I can tell.
> Off the top of my head, I have the following type in my image gallery
> data GalleryCommon
> = ViewImage ImageId [Transform]
> deriving (Eq, Ord, Show, Read, Data, Typeable)
> The ImageId and Transform properties are used in other url components (not
> shown here). They have PathInfo instances already.
> The Template Haskell or Regular libraries would generate a parser that
> looks a bit like:
> fromPathSegments = (string "ViewImage" *> ViewImage) <$> fromPathSegments
> <*> fromPathSegments
> Without the changes to the type, the TH code would not be able to reuse the
> existing PathInfo ImageId instance, but would instead be forced to handle
> the ImageId argument explicitly.. That is really unfortunate, because the
> path generated by the PathInfo ImageId instance is much cleaner than what TH
> would generate.
> It seems to me that the primary purpose of the PathInfo class is to allow
> you to build composable parsers / generates for urls. It seems odd to limit
> the composableness to only the last argument of a constructor..
> - jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the web-devel