Removing Dolibarr Global Variables

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.

The construction of the Alixar project

Basically, Alixar is a fork of refactoring the Dolibarr free ERP/CRM, using the MVC design pattern and technical improvements to make it more sustainable.

The objective of the project is to use modern programming techniques, to completely refactor the Dolibarr project, whose code uses obsolete techniques, and turn it into a modern and sustainable application.

In this blog, you will explain step by step, the processes (sometimes, very, very long), that will have to be given to achieve this goal.

The first task, and one of the longest and most complicated, is to analyze the code and document (in my poor English), practically without making any changes, adapting the structure of the directories, and preparing everything to have a single entry point in the index.php of the htdocs directory.

Integration with Alxarafe

The only changes that will be made during this process is the removal of the code that is already developed in Alxarafe, which will simplify the subsequent update; among them, the database engine, the management of the configuration file, the integration with a template manager and the translator.

Access to the Source Code of Alixar

You can find the details of all the changes in the project’s GitHub repository:

https://github.com/rsanjoseo/alixar

If you wish, you can contribute in different ways:

If you detect any bugs, suggestions, or requests for improvement, you can raise an issue on GitHub.

https://github.com/rsanjoseo/alixar/issues

If you want to participate in code development, you can create a branch and pull request over the repository.