The primary goal here is to get templates rendered more like our "regular"
templates, by using more of the standard tools to do so rather than roll our
own.
* Use TemplateResponse. This requires less boilerplate and ensures the
rendering runs through our local context processors.
* Use the existing definition of fundgoal_lookup.
This middleware is a bit of a mess anyway, since it's basically using
static files as templates. However, we definitely don't want to add any
GET query parameters rendered into the path name.
The base template now has access to the fund-raising goal that will be
displayed site-wide. The view here must provide it in the context for
access everywhere.
Furthermore, we need a local context processor to make sure it's in
context everywhere, and we have to make sure that context is properly
passed along.
This code is a bit cargo-culted in, based on what I read in various
places about adding the Request context.
The urls.py is of course only evaluated once: at Apache load time, which
means the data in the template became stale and is not dynamic.
This change should cause the lookup to happen at each page view.
This seems to be the best approach to pass a fundraising goal record to
a template. While the static hack that tmarble implemented probably
needs work anyway, this is probably the best way currently to interface
certain general data that we seek to place on many different pages
through the templates.
I looked into a templatetags solution, but this seemed more
straightforward and more fitting with Django principles (I think :).
