On Fri, Mar 19, 2010 at 2:42 PM, Jeremy Shaw
<jeremy@n-heptane.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[1] describing the system. The code relevant for our discussion is broken into two files: WebPlug.hs[2] defines the interface and auth-example.hs[3] 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 slash.
Michael