## evoCore FrameWork

# `/inc` folder

This folder originally held the includes needed by the main PHP entry points. For example, this folder holds the `_main.inc.php` file which handles the main initializations for the application.

In recent versions, this folder also holds a series of sub-folders. Each of these sub-folder is a "module" that groups files pertaining to a specific functionality set (e-g: file management).

Each module follows an MVC (Model - View - Controller) paradigm.

This folder (and its sub-folders) only needs to be accessed by PHP. It does not need to be accessed through the web directly.

## Controllers

Each module may contain one or more controllers identified by their suffix of `.ctrl.php`

Each controller is a PHP include file which implements the logic for manipulating a particular "set" of data. For example there could be a controller to handle general settings and another controller to handle local settings. Those two controllers may be found within the "settings" module.

Each HTTP request will typically get routed to precisely one controller (except for stub controllers) which means there will be one PHP include for that controller. Therefore it seems reasonable to make each controller as small as possible in order to minimize parsing/compiling/memory usage overhead. However, different actions on the same "set" of data -- like creating, editing and deleting the same data -- are closely related and, though they are not invoked at the same time, separating these actions into different controllers makes it harder to maintain the application over time when new fields or constraints are added to that set of data.

Thus, it is recommended to try and find the right tradeoff between the size of the controller and the logical grouping of actions into the same controller.

## Model

Each module has a `/model` folder holding the Data Model for the module.

The Data Model is the translation of the "real world" data into how this data is processed in the computer memory. In other words, it is also a PHP representation of the SQL DBMS data.

There will typically be one PHP Class for each DB table. Each object (instance of that class) roughly maps to a row in the table. Of course the Class may/should implement more integrity rules than the DB table alone.

There may also typically be one PHP Cacheing Object/Class (a Class with a single instance actually) for many tables in the DB. The Cache object will optimize accesses the DB by avoiding repeated queries on the same data.

It is important to note that the Data Model may also include data manipulation functions that do not take the form of a class.

## Views

Each module has a `/views` folder holding the Views for the module.

This folder holds PHP include files which output visible data (HTML) to the user. In other words, these views are PHP templates.

It is very important to understand that these views are very rough templates. For example a view may decide to output a list of users with 3 columns (Name, Login and Group). In another scenario it may output a list of Firstnames and Lastnames and group these by user Group. BUT either way, there are still additional layers of presentation which determine the exact rendering of the View (see the Admin skins `/skins_adm` folder).

It is also important to understand that a specific View can be called by different controllers. A contextual help block would be an example of that (provided the content is dynamic).

A single controller can also be calling several views in a row. (The controller can assemble multiple views).

A global overview of the codebase can be found here.