Page 1 of 3

Settings

Posted: Thu Nov 24, 2005 3:14 pm
by Ree
Where do you store settings of your applications - file or database? Of course, I want to allow users to edit those via web interface.

Posted: Thu Nov 24, 2005 4:01 pm
by neophyte
If they are editible on the web best to put them in the db. I ran across someone elses app the other day that used files for storing content. The file permissions were set to 0777 and they were stored in the web/public directory. Bad idea. Anyone who knew the name of the files could then overwrite them remotely.

Posted: Thu Nov 24, 2005 6:00 pm
by pickle
Most (read: all) of my applications are one-offs that only I deal with. That said, I almost always put configuration variables in a config file. I think there's slightly less over head because to retrieve them from the DB, I need to do a query, parse the results and store them in variables. By storing the variables in a file, the variables are declared whenever that file is included.

If you want the variables to be editable by a user though - it'll be much easier to pull and store in a database rather than a file.

Posted: Thu Nov 24, 2005 10:21 pm
by Ambush Commander
It depends. For instance, database credentials can't be stored in a database (big surprise...)

So here's what I do: make a local_settings.php that takes a Plugin object and sets lots of configurations (db login, fairly static config options)

Posted: Thu Nov 24, 2005 10:36 pm
by John Cartwright
pickle wrote:Most (read: all) of my applications are one-offs that only I deal with. That said, I almost always put configuration variables in a config file. I think there's slightly less over head because to retrieve them from the DB, I need to do a query, parse the results and store them in variables. By storing the variables in a file, the variables are declared whenever that file is included.

If you want the variables to be editable by a user though - it'll be much easier to pull and store in a database rather than a file.
I typically like to avoid this situation as much as possible, since variables that appear out of nowhere lean towards bugs (atleast in my personal experience) I prefer to use a config table in a database at the expense of a slight overhead which can be called at any time throughout my application through a configuration controller class of some type. This lets me know exactly where my variables are coming from.

Either way including configuration variable isn't a bad way of doing things, but I don't consider it good either.

Ambush Commander wrote:It depends. For instance, database credentials can't be stored in a database (big surprise...)

So here's what I do: make a local_settings.php that takes a Plugin object and sets lots of configurations (db login, fairly static config options)
Of course at some point your going to have to hard code some creditials, and as mentioned before I like to minimize the amount of data stored in files (fyi. these usually should be outside the webroot) so in most of my applications I have left this file strictly for database credentials -- whatever else that needs to be configurable may be done so through the database.

Posted: Fri Nov 25, 2005 6:52 am
by Chris Corbyn
Jcart wrote:I typically like to avoid this situation as much as possible, since variables that appear out of nowhere lean towards bugs (atleast in my personal experience) I prefer to use a config table in a database at the expense of a slight overhead which can be called at any time throughout my application through a configuration controller class of some type. This lets me know exactly where my variables are coming from.
Something I did recently, in order to avoid that sort of thing. I'll probably decide it wasn't ideal later.

Code: Select all

class settings
{
    const DBServer = 'localhost';
    const DBUser = 'username';
    const DBPass = 'password';
    const DBName = 'whatever';

    const showIcons = 1;
    //etc etc
}
Now, with an __autoload() function that works nicely on it's own. But you can also put that at the bottom of your object hierarchy:

Code: Select all

class DB extends settings
{
    private $DBConn;
    
    function __construct()
    {
        //Conect to database yadda yadda
    }
}

class core extends DB
{
    //and the structure goes on 
}
Generally, I prefer files for things that configure the app initially, and database to hold things like user preferences.

Posted: Fri Nov 25, 2005 6:55 am
by Chris Corbyn
Moved to theory and Design at risk of having a healthy discussion ;)

Posted: Fri Nov 25, 2005 7:23 am
by malcolmboston
i have just started doing what d11wq has been doing lately, namely in this format

Code: Select all

class SomeClass
{
     function SomeClass ()
     {
          // legacy constructor
          $this->Config(); // auto-load class config
          $this->CheckConfig(); // Check that the config is valid
          // CheckConfig is useful in case a number of options are available to select and
          // you need to verify that an option is of an allowed string (eg HIGH | MED | LOW)
     }

     function Config ()
     {
          define ("ConfigValue", "value"); // define a class configuration variable
     }

     function CheckConfig ()
     {
          if (!is_string(ConfigValue))
          {
               // my class actually calls an error class but...
               print "Unexpected variable type";
               exit;
          }
     }
}
I am loving this new way, it allows for a very obvious method of defining configurations on a per-class basis, unfortunately as you can imagine, configuration settings are all over the place but i think it makes more sense that an class-specific config should be contained within this class

your $0.02 please

Posted: Fri Nov 25, 2005 7:35 am
by Maugrim_The_Reaper
At present I write initial config values (database, etc.) to a class file - similar to that above. After that I instantiate the object to use the values...

Less fundamental config options I'm more likely to push to a database, with an optional caching mechanism.

Re: Settings

Posted: Fri Nov 25, 2005 8:14 am
by Roja
Ree wrote:Where do you store settings of your applications - file or database? Of course, I want to allow users to edit those via web interface.
For my game, I wanted virtually every variable to be real-time editable (is that even a word?!?!).

As a result, I used an ini file format for the initial store, and then import it into a db. The database values can be edited realtime, and you can then output from the db to a new ini if you want to save your settings across resets.

I would have gone with xml (I love the stuff), but the quality of xml parsing and output varies *tremendously* from php-4 to php-5. Since many hosts dont have the latest php, or many extensions installed, I really have to program using mostly core features. Given a choice between using a backend xml library or using native ini parsing, it was a no-brainer. Hopefully before long, most hosts will move to php5, and it won't be a concern. Until then, ini "just works".

Posted: Fri Nov 25, 2005 10:33 am
by BDKR
Settings that are key or critical to the app should be stored in a file as far as I'm concerned. Otherwise, what do you do when the DB takes one in the gut?

Posted: Fri Nov 25, 2005 11:28 am
by Roja
BDKR wrote:Settings that are key or critical to the app should be stored in a file as far as I'm concerned. Otherwise, what do you do when the DB takes one in the gut?
Reload it from the ini file.

Posted: Fri Nov 25, 2005 12:34 pm
by Ambush Commander
See, there's a handy problem: deciding at what point is a configuration variable important (and static) enough to be put in the config file. I suppose that for every configuration variable, there are three main choices:

1. Hardcoded PHP (fastest read/difficult write, private)
2. INI file (read/write, but must be protected if secret)
3. Database (slower read/write, private)

Some very common configuration:

* Database Credentials -> definitely PHP
* Library Locations (if the application uses external libraries and doesn't come packaged with them, you'll have to point it to them) -> probably PHP
* Web Path (so when you do stuff like mod_rewrite to turn /index.php?action=edit&id=123 to /edit/123) -> well, I have it in PHP, but this is something you might want to automatically configure or store in database...
* SMTP server -> I use PHP, but...
* Cookie/Session Cookie names -> I use PHP, but...
* Default skin -> I use PHP, but...
* Site name -> I use PHP, but...

It occurs to me that most of these lie on fuzzy lines, so you should allow the user to migrate values from DB to file or vice versa. I presume that a select query on the configuration table would look like...

Code: Select all

SELECT `key`, `value` FROM `configuration`
Since trying to lazy load configuration variables would be a recipe for disaster, or at least, really slow applications.

From my experience with other applications...

* MediaWiki - primarily file based, but messages and extra css can be edited via the Wiki interface in namespace MediaWiki:. Dubious configuration stuffs in the file: scriptPath (web path), enable/disable image uploads, TeX config, licensing, time offset, user permissions. Configuration is done by the creation of global variables
* Futallaby - completely file based. Dubious configuration stuffs in the file: max img dimensions and sizes, floodchecking, etc. Done by define()
* phpBB - completely file based, but the funny thing is that it seems to allow editing config (which means editing php) (hand editors beware!) Done by a single global configuration array.
* JoomLa - completely file based, also allows editing
* Gallery2 - minimal configuration in file, but has setup password (low level installer), location of gallery in filesystem, debugging/profiling and embedded mode. Does it by invoking setConfig() on a $gallery object.
* WebCalendar - ini file wrapped in PHP tags (throws parse error, but should offer security).

Very interesting...

Posted: Fri Nov 25, 2005 3:00 pm
by John Cartwright
Ambush Commander wrote:

Code: Select all

SELECT `key`, `value` FROM `configuration`
Since trying to lazy load configuration variables would be a recipe for disaster, or at least, really slow applications.
I disagree that is a recipe for disaster. I have never had any performance issues before.. perhaps your idea of this design is flawed.
Let me remind you that is application configurations, and not user preferences. :?

Typically at the beginning of my application I run a query to gather these configurations, and then I cache them. (This of course eliminates your idea of performance issues). Once again, I'm talking about configurations that are required for the application to run.. these ALL have to be loaded so I wouldn't neccesarily call that lazy.

Posted: Fri Nov 25, 2005 3:04 pm
by Ambush Commander
Well, you have to get all the essential configs in one swoop, I don't disagree with you there. What I'm saying is if you do that, go the whole hog and grab all the configs. Otherwise, later in the application, when you realize that you need a certain config you don't already have loaded, you have execute another query. Essentially ripple-loading.

I don't think I understand you...