What is LMS? =============== LMS is an acronym for Library Management System considering that I set out make one or a close parody at least. I have laid out this document to cover most (if not all) of the assumptions and considerations that came into play while developing this application. I intend to make it bigger, better and more useful so any form of contribution or criticism is welcome. You could send me an email (omojolasolomon@gmail). A pull request on would more than excite me! I managed to host a working instance at http://fibonacci-lms.herokuapp.com. Project Structure ==================== I did not use any framework in developing this application but I tried to structure it like a typical MVC application. Data, logic and presentation are handled in different parts of the projects. I believe this is beneficial for the following reasons among others: > loose coupling, > reusability, > easy debugging > overall ease ofcsystem development/implementation Files/Directory structure ============================ The files that made up this project are structured as follows: Project root (library\) ++++++++++++++++++++++++ Files that make up the model live in the classes\ directory; files that make up the view live in the pages\ directory while files that make up the controller live in the scripts\ directory. The last directory in the root of the project - the helper directory contains some files with code that is frequently required by the model and controller but not to the view. The config.php file is where database connection details are defined as well as the name of the project. The index.php file serves as the entry point to the application. it redirects to the general home page when the URL doesn’t specify any page. classes\ +++++++++ Each file in this directory (except DataModel.php, Reminder.php and Search.php) contains a PHP class that defines a database table with the properties of these classes representing table fields in the actual database. Each of these classes extends a class named DataModel.php (also in the same directory) which is an abstract class that provides data access methods for each model. Methods defined in this class enable every table-representing class to perform CRUD operations on the database. This is an abstraction from regular SQL as it provides a cleaner and more convenient PHP API for data access from the controllers(which live in the scripts\ directory). Reminder.php contains a class from which a reminder object is instantiated for a given user at a given time. Search.php contains a class that instantiates a search object from a query string. The search object contain a result property which is provided to a search result view through the appropriate controller. helper\ ++++++++ This directory contains files that are useful in most parts of the Model and Controller, but by themselves do not constitute a model or controller. admin_logged_in.php: this file contains code to check if the admin is logged in. This check in frequently required by various parts of the application to determine permissions and page content that are accessible by the current user. funtions.php: this file contains functions that are used in some parts of the application (excluding the view). The decision is a result of refactoring to make every function used in the project to be accessible in a common location. All other functions in the application are class methods and can easily be traced to the classes to which they belong. It is also noteworthy that all classes are in a common location. is_logged_in.php: this file contains code that checks if a regular user (student) is logged in. retrieve_data.php: this file contains code that is included at different points in the DataModel class to retrieve data from the database. It is in this file that select queries are built and executed on the given database. pages\ +++++++ Files pertaining to the View component of the application live in this directory. There’s an includes\ directory which contains the bootstrap\ directory (where the bootstrap framework lives) and files that are used by the views including the template.php file which contains majorly HTML code that defines the layout common across the entire application; changing the look and feel of the entire website basically just requires changing the content of this file alone. This is one of the numerous benefits of the adopted architecture. Files in the includes\ directory are so classified because none of them actually constitute a view. Every other file in the pages directory constitutes a unique view and corresponds to exactly one URL. Pages that are only accessible by the admin are prefixed with “admin_” while pages only accessible by students are prefixed with “user_”. Every other file (with the exception of the logout.php file which ends up redirecting to the appropriate login page) are general views that are common to both admin and student and are accessible even by unregistered visitors. scripts\ +++++++++ This directory contains files that pertain to the controller component of the application. These files handle user requests and perform the necessary to generate output. This directory contains two subdirectories user\ and admin\ which contains controller for requests unique to students and admin respectively. Other files are controllers common to students and admin as well as unregistered user as is with the pages\ directory mentioned above. Files in the pages directory could also have been further divided into sub directories, but since a URL router was no implemented and controllers are accessible by typing the page file location in the browser, the prefixes were used to avoid too many slashes in the URL. How requests are processed ============================= When a URL is typed into the browser (e.g. [host root]/library/pages/index.php), the URL corresponds to a specific file in the pages\ directory. Each of these files includes its corresponding controller (which lives in the scripts\ directory) at the top. This implies that code in the controller is first executed to handle the request and perform all computation required to generate an output. In this controller, context variables are set to be used when control is handed over back to the view. The view continues execution after the controller has finished and uses the set variables to build html for the page content. Every pages generates its own content as a string and stores it in a variable called $content. The template.php file is included at the bottom of every page file. Inside the template.php the $content variable is rendered as proper HTML with the necessary styling and layout. Pages titles and page description are also set in the page file and are stored in the variables $pgTitle and $pgDesc respectively. Problems encountered during coding process ============================================= Owing to the adopted development pattern, I initially struggled with file inclusion in some parts of the project. This caused some problems as some files ended up being included twice thereby resulting in some sort of conflict. An instance of such is when two data classes are needed to be worked upon in the controller. Each of the classes includes the DataModel class, so including both data classes would mean that DataModel would be included twice. This problem was solved by using PHP’s include_once() function throughout the project. Implementing the query builder in the DataModel class also posed lots of challenges, but one bug after the other provided a lot of learning opportunity. The debugging process made the project all the more interesting. I hope you find this README useful If you made it this far and bothered to look at my code, please feel free to contact me if you have any questions.