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

__dbDBVERB * 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 __dbinsert 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.