Diff CSS for fundraiser-percentage w/ progressbar.

If Javascript is present to generate the pogressbar, then the CSS really
should be radically different.

Graceful degradation.

Rework to simply call with new kwargs.

Redo call so that I just get my own at call time.

Rework fundgoal lookup urls data.

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.

Use caching to, ironically, prevent caching.

Now that I'm updating the database out of band with information about
the fundraiser, I've found that the page does not properly update.

This change will hopefully fix the issue.

Leave text w/ percentage when no progressbar

The progressbar is generated by Javascript. As such, the text here
won't have a progressbar formatted around it when the browser doesn't
support Javascript.

However, since the Javascript does update the text, we can format the
Django template to put in place text that we wish will appear when no
Javascript is turned on, and then allow the Javascript to make it right
when it's available.

Graceful degradation: I may be its last proponent.

Convert VMware fundraiser to new dynamic content.

Use the new dynamic content fundgoal stuff for VMware fundraiser.

Use supporter-page.js & its formatting conventions

The npoacct campaign was launched before the Supporter program, and
parts of its functionality were incorporated into supporter-page.js
ultimately. This commit hopefully now backports that functionality to
npoacct campaign.

Function to compute how far to the goal we are.

This is also inserted by the Javascript code as well, but no reason we
can't compute it server side, too.

Convert npoacct fundraiser to use dynamic content

If this new model works, we should be able to update the fundraiser
amounts in the Django database instead of the HTML.

Correct get call to use arg properly.

This was just a typo in from previous commit, more or less.

Fundraising goal lookup for template: 1st attempt

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 :).

Make defaults for BooleanFields.

According to django-admin check,

(1_6.W002) BooleanField does not have a default value.
HINT: Django 1.6 changed the default value of BooleanField from False to None. See https://docs.djangoproject.com/en/1.6/ref/models/fields/#booleanfield for more information.

Just quit it with this relative import stuff.

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.

Initial hack at a fundraising goal application.

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.

Add list of those who support the action to FAQ.

Also, note that when people donate, they may also want to make public
statements of support.

Image inside FAQ should scale to size.

Some have complained that the image inside the FAQ does not scale to
size. This corrects that problem.

Move progressbar CSS to CSS file, not hard code.

Also, increase size of progress bar (HT tmarble)

Don't hard code style; use class and improve CSS

This changes the hard-coded style for what I'm calling the
content-with-donate-sidebar. The advantage of not hard-coding style are
obvious, but I'm doing this now rather than later so that I can add
changes to the CSS that causes the width to extend to 100% on smaller
screen media when the donate bar disappears (the latter of which is
already implemented).

Require browser even a bit bigger before left dt.

(HT jgay)

Adjust widths slightly when these are combined.

When we have both dt's and the donate-sidebar floating around, things
get tight. Perhaps there is a better solution than this (e.g., can you
set the @media conditional on there being a donate-sidebar at all?), but
this should be a reasonable hack to fix the problem.

Avoid left floating dt's on small screens.

Set the min-width for the left-floating dt's to 550px, so that small
screens just get everything in one column.

Note that the formatting previously used is now moved purely to @media,
which I don't know how that will impact browsers that don't support
@media in CSS, but OTOH, I believe the graceful degradation is done
correctly here.

Make FAQ entry done in dt look better with CSS.

This is accomplished by three key changes:

* use em rather than px sizes, so that font changes are accomodated.

* Add a margin to the dt.

* center the text in the dt's rather than right align.

Remove footnote about t-shirt shipment

Remove footnote since t-shirts are being shipped already.

Sure up wording for ambiguous modifier

HT jackhill for this suggestion.