Trip Views

class fyt.trips.views.AssignLeader(**kwargs)

Assign a leader to a trip.

The trip’s pk is passed in the url kwargs.

The template is passed a list of tuples of the form (LeaderApplication, assign_url, triptype_pref, section_pref)

• assign_url will be None if the leader is already assigned to a trip.
• triptype_pref - ‘prefer’ or ‘available’
• section_pref - ‘prefer’ or ‘available’

get_assign_url(leader, trip)

Return the url used to assign leader to trip

get_context_data(**kwargs)

Compute whether each leader prefers or is available for this trip’s section and triptype. We use the through fields of the M2M models because prefetch_related pulls in all related objects–and all fields of the related objects–which is a huge query and kills performance.

See AssignTrippee for a similar situation and more explanation.

model

alias of GeneralApplication

class fyt.trips.views.AssignTrippee(**kwargs)

Assign trippees to a trip.

The trip’s pk is passed in the url arg.

Each trippee passed to the context has the following properties:

• assignment_url - the url to assign trippee to this trip
• triptype_pref - ‘first choice’, ‘prefer’, or ‘available’
• section_pref - ‘prefer’ or ‘available’
• bus_available - True if trippee requested a bus and it is scheduled this section, otherwise False

Because of our database structure, preferences are not easy to compute efficiently. See below...

get_context_data(**kwargs)

In order to compute each trippee’s triptype or section preference,

Initially I tried using prefetch_related to load all preferred_triptypes, available_triptypes, etc. However, this requires the database to load each trip, in the worst case, on every tripppee, up to O(n) times for the entire, queryset. Multiply this by the total number of trips, and there goes performance.

Perhaps a SQL guru can figure out a clever way to compute this in-database, but I could not.

The solution: use the through objects created by M2M fields. We iterate through these objects for the sections and triptypes in question and save each trippee’s preference in a dict. This technique is O(1) for queries and O(n) for in-memory processing, which is quite acceptable. See http://goo.gl/QbK99D

get_queryset()

All trippees who prefer, are available, or chose this trip as their first choice.

Only pull in required fields because a whole application queryset is big enough to slow down performance.

model

alias of IncomingStudent

class fyt.trips.views.Checklists(**kwargs)

Central list of all checklists”

class fyt.trips.views.LeaderChecklist(**kwargs)

All leaders for a section.

model

alias of GeneralApplication

class fyt.trips.views.LeaderPacket(**kwargs)

All information that leader’s need: schedule, directions, medical info, etc.

model

alias of Trip

class fyt.trips.views.LeaderTrippeeIndexView(**kwargs)

Show all Trips with leaders and trippees.

Links to pages to assign leaders and trippees.

model

alias of Trip

class fyt.trips.views.MedicalInfoForSection(**kwargs)

Packets for croos, by section.

Contains leader and trippee med information.

class fyt.trips.views.PacketsForSection(**kwargs)

All leader packets for a section.

model

alias of Trip

class fyt.trips.views.RemoveAssignedTrip(**kwargs)

Remove a leader’s assigned trip

model

alias of GeneralApplication

class fyt.trips.views.TrippeeChecklist(**kwargs)

Checklist of a trippees for a section.

model

alias of IncomingStudent

class fyt.trips.views.TrippeeLeaderCounts(**kwargs)

Shows a matrix of the number of tripees and leaders for all trips