[web-devel] Type-safe URL handling
michael at snoyman.com
Fri Mar 19 18:22:37 EDT 2010
On Fri, Mar 19, 2010 at 2:42 PM, Jeremy Shaw <jeremy at n-heptane.com> wrote:
> On Fri, Mar 19, 2010 at 4:22 PM, Michael Snoyman <michael at snoyman.com>wrote:
>> As an example of both a unified URL creation framework and persistence
>> framework, I've put together a little example of how we could create an
>> "authentication plugin." For the purposes of our discussion here, we could
>> ignore the persistence piece for now, though I would like to eventually
>> discuss how we could make that better.
> Yeah, I gotta finish the urlt stuff first before I think about something
> else ;)
I'd prefer to do that too in general, but I'm going to be doing a project
next that involves a lot of DB code. I already did one site that used direct
SQL generation, and I'd really rather avoid going that route again.
I wrote a small blog post describing the system. The code relevant for
>> our discussion is broken into two files: WebPlug.hs defines the interface
>> and auth-example.hs is the actual example.
>> In this version of WebPlug.hs, I've included WebPlug as a datatype instead
>> of a typeclass. I don't actually *use* that datatype here, but I think it
>> would be very useful for higher-level utilities like the quasi-quoter to be
>> able to access the three related functions together.
> Right. I already have a similar datatype in URLT.HandleT. My type also
> includes a 'defaultPage' type which can be used to specify what value "/"
> should be mapped to. Though, in mine, the dispatch / handleLink function is
> based on URLT, but that can probably be generalized. As a bonus you also get
> a Functor instance, and a runSite function that uses the type..
> You should really check out URLT sometime :p
> I thought I had, just didn't realize that HandleT was relevant to the
low-level bit. I'll try to get through the rest of urlt today.
> I am not going to have time to look at this again until Saturday or Sunday.
> There are a few minor details that have been swept under the rug that need
> to be addressed. For example, when exactly does should url encoding /
> decoding take place. It's not good if that happens twice or not at all.
> Just to confuse the topic even more: if we do real URL encoding/decoding, I
believe we would have to assume a certain character set. I had to deal with
a site that was encoded in non-UTF8 just a bit ago, and dealing with query
parameters is not fun.
That said, perhaps we should consider making the type of PathInfo "PathInfo
ByteString" so we make it clear that we're doing no character encoding.
Another issue in the same vein is dealing with leading and trailing slashes,
though I think this is fairly simple in practice: the web app knows what to
do about the trailing slashes, and each plugin should always pass a leading
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the web-devel