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.
