[web-devel] More power, more configurable subsites

[Michael Snoyman]

Hi Matt (and the whole web-devel list),

Now that Warp is out, and now that the Hamlet decisions have been
made, I can (finally) start focusing on yesod-core. Most of the
changes we want are already made I think, there are only two open
issues that I'm aware of:

* Proper request body parsing[1], which is *almost* done.
* Disabling sessions for subsites[2]

On the second point, I want to broaden our scope: I want to make it
possible to run a full WAI application as a subsite. I'll give my
current use case: I just wrote a fully-featured wai-app-static
application, which takes care of redirecting from "/foo/directory" to
"/foo/directory/" and other such things. Now, let's say I have a
directory named "my.folder" or a file named "file". In Yesod, the URL
cleaning will remove the trailing slash from the former, and add the
trailing slash to the latter. However, wai-app-static will do the
exact opposite, resulting in an infinite redirect loop.

One possible solution to this predicament is to hard-code /static as a
special prefix, and not do URL cleaning. But this is a horrible, ugly,
evil hack that makes unicorns cry and babies vomit (trust me, I have
two kids, you don't want to know what happened hear after I added that
commit). What we *really* want is to give subsites much more control
over their execution. As the Yesod dispatch functions are written
right now, that's not really possible: we do all path cleanup first
and then start routing.

So here is a possible proposal for how Yesod dispatch should work:

* Break up the pathinfo (/static/directory/) into pieces (["static",
"directory", ""], the empty string at the end indicates a trailing
slash).
* Dispatch to subsites only. In other words, we'll keep a list of
subsite prefixes separate from other routes, and check those against
the unmodified pieces.
* If there are any matches, we strip out the relevant prefix from the
pieces and pass off control to the subsite.
* Subsites created with normal Yesod functions (mkYesodSub) will then
go right back into the dispatch function, but now the specific
settings for that subsite will be in place. This means that they can
control how cleanup is done, whether sessions are on, etc.
* You can also write your own subsite code directly and bypass Yesod's
dispatch system. This will also make it possible to write a
appToSubSite function so that plain WAI applications can be included
directly. (I'm hoping that with the release of Warp, there will be
more non-Yesod WAI apps out there.)

I haven't looked at implementing this yet, but it doesn't sound too
hard. I wanted to ask what you thought about how this would interact
with your more modular subsite code already.

One other thing that comes up as related: Aristid Breitkreuz emailed
me and asked why Yesod is a typeclass and not a record type. I gave an
answer[3], but I wouldn't mind other people looking into it as well.
I'm starting to think about using the records approach on the
YesodSubSite typeclass at least and see how that works out. But I have
not given this much thought, and this is really an orthogonal- albeit
related- question.

Michael

[1] http://wiki.yesodweb.com/Proper%20request%20body%20parsing
[2] https://github.com/snoyberg/yesod/issues#issue/24
[3] http://wiki.yesodweb.com/Yesod%20as%20typeclass%20or%20record