[url removed, login to view] is a custom written PHP website used to enroll people in dental insurance and keep track of a call center doing the same. It provides “Dental Insurance Applications” aimed at visitors of the site, outside sales agents, and data entry operators. It displays lists of those applications to various users responsible for manipulating or counting the records.
There are a few different coding conventions used throughout as the scope of the project expanded, starting with procedural, then converted to OO in most places. Most classes are StudlyCaps, most methods, functions and variables are camelCase.
Most pages visible to the user are in the root of a given subdirectory. Most pages that process data in some way are in the include directory within that subdirectory. For example, a user login is processed like this:
/subdirectory/index ->POST-> /subdirectory/include/processLogin
This segregation allowed quick duplication in the early, procedural days of the site. It is very WET and inefficient, but the site’s production schedule necessitated new areas fairly regularly and on short notice.
Users are maintained through cookies and session. We’ll a user of class Employee as an example here.
Every subdirectory directly below the root that requires login has a [url removed, login to view] file that contains a login form. The employee login form is then POSTed to employees/include/[url removed, login to view] which simply instantiates an object of class Employee and calls the public method Employee->authenticate($username, $password, $remember). The method compares $password to the entry in the employees table and does 3 things on success:
It loads all user information from database to current object
It updates the hash column in the employees table with a new random string
It redirects to [url removed, login to view] on success or calls the global function handleError() on failure
Each page that requires the user to be logged in implements require_once ‘/include/[url removed, login to view]’ to load the class of user applicable to that page. It then starts the session and checks for $_SESSION[‘LoggedIn’] and redirects the user to index if it’s missing. Next it instantiates an object of the Employee class. Then it calls the calling the Employee->validateHash() method which compares the randomly generated hash stored in $_COOKIE[‘User’] to see if it matches the value stored in the employees table of the database. On a match, the method calls the Employee->load() method which loads the user variables into the current Employee object from the database. If a page has content that should only be viewed by certain users, it is filtered by using PHP conditional statements that compare the value of Employee->department and Employee->accessLevel.
Applications are handled as an object during entry and as a database row during retrieval and display. There are many types of applications including in-house, duplicate and external. Examples here are based on the in-house apps entered by the data entry users at /employees/[url removed, login to view]
Reports are handled as objects that have methods to echo a list for viewing in the browser, on the printed page, and downloaded as a csv. These are filtered based on a starting and ending date range to reduce load time. In the browser, they are formatted as tables and enhanced using the DataTables jQuery extension.
Generating a Report
Printing a Report
Downloading a CSV
Suggested Improvements and Refactoring