[web-devel] Type-safe URL handling

Michael Snoyman michael at snoyman.com
Fri Mar 19 18:43:09 EDT 2010


On Fri, Mar 19, 2010 at 2:31 PM, Jeremy Shaw <jeremy at n-heptane.com> wrote:

> On Thu, Mar 18, 2010 at 5:17 PM, Michael Snoyman <michael at snoyman.com>wrote:
>
>> Based on everything you've said, and some thought I've had on my own, I
>> agree that the base function should involve no typeclasses and not break up
>> the path into pieces. Here's a proposal for the entire core:
>>
>> newtype AbsPath = AbsPath { unAbsPath :: String }
>> newtype PathInfo = PathInfo { unPathInfo :: String }
>>
>
> Can you provide some simples examples of the types of mistakes we might
> make if we didn't use newtypes here?
>
> One potentially nice thing about having the function, showURL :: (url ->
> String) instead of (url -> AbsPath) is that it works with most of the html
> 'templating' solutions with out any extra fusing around. For example, with
> Text.Html
>
>  a ! [href (showURL Foo)]
>
> Which is kind of nice.
>
> But I also like using newtypes when it helps avoid problems.
>
>
> I think I've said it before: I'm on the fence about this one. The newtypes
are just doing what they usually do: prevent you from making silly mistakes
and ensure more type safety. I have no incredibly persuasive examples.


> handleWai :: (PathInfo -> Failing url)
>>           -> (url -> PathInfo)
>>           -> (PathInfo -> AbsPath)
>>           -> (url -> (url -> AbsPath) -> Application)
>>           -> Application
>> handleWai parsePI buildPI buildAbsPath dispatch req = do
>>     let pi = PathInfo $ S.unpack $ pathInfo req
>>     case parsePI pi of
>>         Success url -> dispatch url (buildAbsPath . buildPI) req
>>         Failure errors -> return $ Response Status404 [] $ Right $ fromLBS
>>                                  $ L.pack $ unlines errors
>>
>
> Depends on which 'core' we are talking about. I still intend to use urlt
> with happstack, which does not yet have fully integration with Wai. So I
> will need:
>
> handleHappstack.. or some variant. And I can imagine other non-Wai people
> want to use urlt as well. So I imagine we will have:
>
> urlt-wai
> urlt-happstack
> etc
>
> so at the real core that would just leave, PathInfo and AbsPath ? Unless we
> get rid of them.. then there is nothing at the core, only optional things :p
>
>
> If all we're aiming for here is a method for type-safe URLs, then this
would work. I'm trying to broaden the scope to including pluggable web
pieces; for this, a unified request/response type are a must.

That said, we *could* make the Application type be polymorphic and then
provide handleWai, handleCgi, handleHappstack, etc, and then have plugins
specific for each of those systems. But I'd rather see us standardize on WAI
(that is the purpose of it) and provide compatibility wrappers.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/web-devel/attachments/20100319/26e1eb2f/attachment.html


More information about the web-devel mailing list