Currently, any sysadmin who understands PHP can put *any*
valid PHP statement in the config files -- something I
consider quite useful (for example, specifying the time out
as a product).
If PGV switches over to INI files, not only do we lose that
functionality, but the INI still has to be translated into
PHP _somewhere_.
In the end, most of these variables are handled through the
admin web interface, so it shouldn't matter how they are stored.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The current system is very dificult to expand since all
config charges are done with an regexp. Also, the number of
global variables should be reduced, not continuly expanded.
An ini file could be imported into a nested array and easly
expanded without variable clashes with other scripts.
I wouldn't mind as much if the config values were defines.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As far as expandability, it only takes me all of 2 minutes to
add a new config variable. Most of that is spent writing the
pgv_lang variables for it and updating the language change
logs.
Config charges would either use regexp with an ini file or use
some sort of library function to convert an array to a ini string
(I think that PHP has a built-in way to convert from INI to an
array and back again). INI files would also increase program
start time because all of the PHP files would first be parsed
by the PHP parser, including the INI parser. The INI parser
would then run and load in the files and create an array.
The only reason to convert the config vars from PHP to INI (or
XML or any other type) would be for compatibility with other
systems. Since no other system needs to read the PGV
configuration files, there is no reason to do it.
Defines increase file parsing time for all other files and I've
never been a big fan of using defines ;) I think they make the
code harder to read, but that is my personal preference.
I am leaning toward having all config vars in a $PGV_CONFIG
array. It would simplify the global calls inside the functions
(not sure if this would be bad for the stack size though. I
would hate to see the entire config array copied onto the
stack for each function call. It should just reference a global
memory location). It would easily seperate config vars from
other vars. It would prevent the cross-scripting var conflicts.
I would probably divide them up between two arrays
$PGV_CONFIG and $PGV_CONFIG_GEDCOM.
--John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That would be fine, it's just very dificult right now to
port modules (or use PGV as a module) due to conflict.
As for adding a ver option, you also need to add the line to
the config file, otherwise you get an error when saving the
config. So, every config upgrade needs the admin to manualy
add the line unless I'm missing something.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the case of adding a new var to the config.php file (which
happens very rarely) the session.php can be used to default
it to make sure that it is set. The config version number can
also be used to know if the config.php file needs to have new
vars added the next time it is edited.
--John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=1278885
Currently, any sysadmin who understands PHP can put *any*
valid PHP statement in the config files -- something I
consider quite useful (for example, specifying the time out
as a product).
If PGV switches over to INI files, not only do we lose that
functionality, but the INI still has to be translated into
PHP _somewhere_.
In the end, most of these variables are handled through the
admin web interface, so it shouldn't matter how they are stored.
Logged In: YES
user_id=157163
The current system is very dificult to expand since all
config charges are done with an regexp. Also, the number of
global variables should be reduced, not continuly expanded.
An ini file could be imported into a nested array and easly
expanded without variable clashes with other scripts.
I wouldn't mind as much if the config values were defines.
Logged In: YES
user_id=300048
As far as expandability, it only takes me all of 2 minutes to
add a new config variable. Most of that is spent writing the
pgv_lang variables for it and updating the language change
logs.
Config charges would either use regexp with an ini file or use
some sort of library function to convert an array to a ini string
(I think that PHP has a built-in way to convert from INI to an
array and back again). INI files would also increase program
start time because all of the PHP files would first be parsed
by the PHP parser, including the INI parser. The INI parser
would then run and load in the files and create an array.
The only reason to convert the config vars from PHP to INI (or
XML or any other type) would be for compatibility with other
systems. Since no other system needs to read the PGV
configuration files, there is no reason to do it.
Defines increase file parsing time for all other files and I've
never been a big fan of using defines ;) I think they make the
code harder to read, but that is my personal preference.
I am leaning toward having all config vars in a $PGV_CONFIG
array. It would simplify the global calls inside the functions
(not sure if this would be bad for the stack size though. I
would hate to see the entire config array copied onto the
stack for each function call. It should just reference a global
memory location). It would easily seperate config vars from
other vars. It would prevent the cross-scripting var conflicts.
I would probably divide them up between two arrays
$PGV_CONFIG and $PGV_CONFIG_GEDCOM.
--John
Logged In: YES
user_id=157163
That would be fine, it's just very dificult right now to
port modules (or use PGV as a module) due to conflict.
As for adding a ver option, you also need to add the line to
the config file, otherwise you get an error when saving the
config. So, every config upgrade needs the admin to manualy
add the line unless I'm missing something.
Logged In: YES
user_id=300048
In the case of adding a new var to the config.php file (which
happens very rarely) the session.php can be used to default
it to make sure that it is set. The config version number can
also be used to know if the config.php file needs to have new
vars added the next time it is edited.
--John