The truth is that trying to create a first MVC version of Dolibarr, keeping more or less the current code, is becoming quite a complicated task.
Right now, the code is totally shattered. It just doesn’t work. It’s normal, it doesn’t worry me at all, as very profound changes are being made to the structure of the application.
Set a single entry point
At this point, we have already managed to establish a single entry point, accessing exclusively through htdocs/index.php, instead of entering from each php file.
The code to be executed is established by the GET variables module and controller.
A Dolibarr folder has been created where the original code will be, with very few changes, organized into classes and libraries. The libraries will be in a class passing the original functions, to be methods of that class, which will be called statically. Organizing it in this way will make it easier for us to use Namespaces.
The DolibarrGlobals class
When organizing the code, one of the first things we have to do is to eliminate the global variables. To achieve this goal, all the variables that are necessary at different points of the application will be defined in the DolibarrGlobals class.
It is necessary to be able to load a global variable from any point, and that in addition, the variable is the same instance.
To do this, these variables are created as static variables within the DolibarrGlobals class, the constructor will assign them in the correct order, because there may be dependencies between them, and later, we will have a getVariableName method for each of them, which will return the instance we want to have.
For example, getLangs() will return an instance of the translator. Wherever the translator needs to be used, we can use DolibarrGlobals::getLangs() to get an instance of it:
$langs = DolibarrGlobals::getLangs();
I haven’t bothered to improve the code yet. At the moment, I’m reorganizing it. In the medium term, any class that starts with Dolibarr will be eliminated and replaced by totally new code.