Core Views

class fyt.db.views.DatabaseLandingPage(**kwargs)

Landing page of a particular trips_year in the database

TODO: should this display the Trips index?

class fyt.db.views.DatabaseUpdateView(**kwargs)

Base view for updating an object in the database.

If ‘delete_button’ is True, a link to the delete view for this object will be added to the form’s button holder.

get_form_helper(form)

Add Submit and delete buttons to the form.

class fyt.db.views.MigrateForward(**kwargs)

Migrate the database to the next ``trips_year`

class fyt.db.views.RedirectToCurrentDatabase(*args, **kwargs)

Redirect to the trips database for the current year.

This view is the target of database urls.

class fyt.db.views.TripsYearMixin

Mixin for trips_year.

Filters objects by the trips_year named group in the url.

Plugs into ModelViews. The url is a database url of the form /something/{{trips_year}}/something. The ListView will only display objects for the specified trips_year.

dispatch(request, *args, **kwargs)

Make sure the request is for a valid trips year.

Requesting a trips_year that don’t exist in the db will cause problems. Block ‘em here.

form_valid(form)

Called for valid forms - specifically Create and Update

This deals with a corner case of form validation. Uniqueness constraints don’t get caught til the object is saved and raises an IntegrityError.

We catch this error and pass it to form_invalid.

TODO: parse and prettify the error message. Can we look at object._meta.unique_together? Can we make sure it is a uniqueness error?

get_context_data(**kwargs)

Add the trips_year for this request to the context.

get_form_class()

Restricts the choices in foreignkey form fields to objects with the same trips year.

This would be straightforward if F() objects were supported in limit_choices_to, but they’re not.

get_queryset()

Filter objects for the trips_year of the request.

get_trips_year()

Pull trips_year out of url kwargs.