I don't know if this code is left over from previous versions or what, but
it's not doing anything now. custom_index doesn't pass kwargs to anything
else, so there's no need to fiddle with the dict so much.
With a valid URL, a past donor can upgrade to a supporter by donating
the rest of the amount. Django validates the data and, if it passes,
puts it in the form. The JavaScript does most of the work from there.
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.
While I think these relative imports seem to be valid for the running
application, I am having trouble with the django-admin applications
regarding them. I don't see this syntactic sugar as absolutely
essential, so I'm just going to change it now.
This simple application will simply store the code name and the to goal
of each fundraiser. The so_far number will likely just be updated by
some external script, modifying the appropriate entry in the SQL
database.
The pagination support changed, and as was previously done a few commits
ago for news, I'm trying a similar solution for blogs.
In this case, I'm trying to use the existing custom_index() method we
have and adapt it to properly support pagination in the way we want.
I'm not completely sure this will work, but I think it's at least close.
The urls setup of old gave us various arguments at call time for
custom_index(), and some where useful. Hopefully, listing() can support
the same type of system, over time, once adapted. Here's an attempt to
get it started, first by supporting paginate_by.
I don't believe custom_index() should be used anymore given that we have
this new listing setup. At least, that's what I surmise based on
current error messages. I may bring this back if removing it breaks
something else.
Hitherto the supporters list has been committed directly to the static
sponsors/index.html file. This was never ideal and a quick hack to
build Conservancy's supporters list at the beginning of the supporters
program.
With this change, a Django app now exists that dynamically generates the
supporters list.
The database rows must be built from Conservancy's internal Ledger file,
which will be done in a separate script.
