[web-devel] More power, more configurable subsites

[Matt Brown]

Michael,

This all sounds great, especially the ability to use WAI apps as
subsites.  Would this also mean yesod sites could be deployed as
subsites, since they're converted to WAI apps?

I don't see any major problems between the proposed routing changes
and the existing subsite implementation.  My patch for dynamic
subsites allows routes to subsites to contain dynamic pieces, but as
long as the subsite dispatch remains independent of parsing the route
to the subsite, that detail should be transparent.

If I understand correctly, the new dispatch process would look like:
1) identify the subsite / parse the route to the subsite
2) global site preparation
3) dispatch to the subsite
3a) identify the subsite handler / parse the route
3b) subsite preparation
3c) dispatch to the subsite handler

I put the preparation steps after identification, so that preparation
could be run within the handler (with handlerRoute set).  Is that what
you had in mind?

-matt

On Thu, Jan 20, 2011 at 10:51 PM, Michael Snoyman <michael at snoyman.com> wrote:
> 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
>