Robin Johnson a écrit :
On Mon, 8 Apr 2002, Marc Delisle wrote:
I am not against using functions, but:
- what about the existing arrays in config.inc.php3?
That is the reason I was
using serialize and unserialize to store the
data. Those functions preserve arrays perfectly.
Ok.
- implementing pma_getvariable() all over the
code will be a lot of
work, so I suggest before starting this, to think also about a possible
User Preferences module (db-stored also).
Could we decide on which of the options
in the current configuration
should be available to each user in their personal preferences?
For example, let's talk about $cfgShowBlob and assume that this can be
a master and a user pref.
I guess you have put a "ShowBlob" field in the config_master table.
It would be more flexible not to have the actual cfg variable names
as fields, but as data, so the config_master table would have 2 fields:
the cfg variable name, and the cfg variable value (possibly serialized).
Maybe a third field to indicate if this can be overriden by the user
(indicating a possible search in config_user).
This is because we have to think about future PMA upgrades and avoid
users having to add fields to config_master.
What do you think of that?
Since it will just be the redefinition of some of the options from the
main configuration, I propose doing it like this:
Read in the master 'config_master' table.
Read in a client override table 'config_user' which is contains all the
fields of 'config_master' plus one additional field for the username.
The options for 'config_user' are set over the existing 'config_master'
options.
Voila! You have user preferences. But we would need to put some security
on that 'config_user' table, as there are probably some things that we do
not want the user being able to change.
Also, looking at the security functions of this, as well as the speed
considerations, using a database configuration system will REQUIRE a
system that supports sessions, otherwise you risk poor performance
(re-reading the configuration data on each page). By using sessions, it
could be loaded once on login, and then re-loaded if the user changes
preferences.
It is ok for me to require sessions for this, you are right about performance,
and also because this will be an optional configuration mecanism.
Keep on the good work!
--
Marc Delisle