Create a configuration management class

[pkiraly]

tasks:

• [x] create a Configuration class, which manages all config settings
• [x] move all references from the $configuration array to this object (both setters and getters)
• [x] take care of multitenant flag, and set values accordingly
• [x] update documentation

[nichtich]

How is multitenant model related to #114? In particular when the multitenant configuration contains multiple settings such as dir[a], dir[b], dir[c], how does index.php get which of a, b, c is to be used for a given request URL?

There also seems to be two different meanings of catalogue in the documentation. For instance one may host two Loc catalogues, one with public data, the other with internal data, so the configuration would be:

catalogue=loc  
dir[public]=... # some loc data
dir[internal]=... # some other loc data

Both public/internal and loc are referred to as "catalogue", this is confusing.

[pkiraly]

It is two different issue.

1. the separation of the datasets

Let's see the following scenario:

The application qa-catalogue-web locates in a directory which is not inside the web directory

/home/qa-user/git/qa-catalogue-web/

We would like to have two instances for the web UI: public and internal. In the Apache web directory we create two symbolic links to the application's directory:

$ sudo -u www-data ln -s /home/qa-user/git/qa-catalogue-web/ /var/www/html/public
$ sudo -u www-data ln -s /home/qa-user/git/qa-catalogue-web/ /var/www/html/internal
$ ls -la /var/www/html/
public -> /home/qa-user/git/qa-catalogue-web
internal -> /home/qa-user/git/qa-catalogue-web

You can access them as https://MY.SERVER/public and https://MY.SERVER/internal. It will execute /home/qa-user/git/qa-catalogue-web/index.php, which analyses the request and extract public and internal. This will be saved to a variable called $db. This variable is used by the Configuration manager class in selecting the config settings.

2. Naming conventions in the documentation.

Yes, you are right. it is not explained well. I used <catalogue> as the selector, but it is not right, we should use <db> instead. When I refreshed the README yesterday I was thinking about that, but did not do it, because I would like to emphasis two things at the same time, but I did not find the good way to express it. a) you can customize the settings by catalogue b) the catalogue is identified by a variable, and also we have another variable called also catalogue, and it is also a machine name, but of the PHP class. Maybe we should call the first variable id, and replace <catalogue> with <id>.

[pkiraly]

I renamed db to id. The db settings is still supported for compatibility reason, however within the code it is named as id. It involved a number of files in the project. I hope now the picture is much clearer.

[nichtich]

Thanks! I've further changed README.md to better differentiate installation directory ($APPDIR) and name of the catalogue class ($CATALOG). The default values of indexName, dirName could be described better still, and #107 is required to solve how image directory must be configured. Anyway, introduction of configuration class is much cleaner than before!

[nichtich]

In index.php the $id is passed to configuration class but also to the subclass of BaseTab where it is used directly (see git grep 'this->id' classes/*.php). These uses should be removed in favor of existing, more specific accessors of the configuration class (getDirName, getIndexName...).