foobar == a module. ex: people, events, or inventory

index: main page. list of all foobars
show: main page for a single foobar
edit: generates and returns form for editing a single foobar
update: takes the user - filled form from edit and updates DB
new: generate and returns form for creating a single foobar
create: takes the user - filled form from new and inserts into DB
delete: deletes a single foobar


two underscores before a function denotes its an internal("private" in C + +
                                                          terms) function that shouldn't be called outside of the class

__can_VERB returns Ture or False depending on whether the given session is
allowed to VERB. Sometimes takes an id as well, which is the id of the target
resource

__db_DBVERB_ * will DBVERB(probably one of select, insert, update, delete
                           based on context) the given type of resource

__create_ * is a "sub function" of create and will call __db_insert_ * as needed

__update_ * is a "sub function" of update and will call __db_ * _ * as needed

__validate * takes form data and returns a validated copy of it and any errors in
an array of errors. "validated" means the output data dictionary SHOULD have all
possible fields, and unspecified / empty ones SHOULD be None. The array of errors
has length of zero when there were no errors. The caller MUST NOT touch the DB
if len(errs) is not zero. For resources that have sub types, the sub - type's
validate MUST call the generic's validate. For example, a meeting is a type of
event. __validate_meeting MUST call __validate_event and pass on all data / errors
it gets from __validate_event. The generic type MAY be called 'generic' instead
of, in this example, 'event'.

Even if a validate function doesn't seem to do anything other than manually
copying a dict key - by - key, it's at least converting from an immutable dict to a
dict.