Jump to content

Site Config, class or global?


Stooney

Recommended Posts

I'm trying to decide between having my site config info as a global array or a class (or even another better way).  The config holds info such as database prefix and whatnot.

 

In my config.php gather this information (whether it's hardcoded, from db, etc) and store into a global $CONFIG array which I can then call from wherever, or should I use a class to encapsulate it all like this:

class Config{
    public $db_prefix;
    public $admin_level;
    //etc.  I'm not sure of any useful methods I could have for this class aside from the construct to set the variables.
}

 

I know globals should be avoided, but it would seem like unnecessary work to pass a config value to another class each time I need something.

 

I did just consider the fact that the db_prefix should probably be in the database class.  But there's still the others.

Link to comment
Share on other sites

I would definately use it as a global array.  Unless there is specific methods you want to do with the data (aside from what you do in other object classes), which it doesn't sound like from your sample source.

Link to comment
Share on other sites

Someone just recommended use of globals? :) You're crazy!

 

1) Objects properties should always be private

2) Globals are bad, mkay?

 

I know globals should be avoided, but it would seem like unnecessary work to pass a config value to another class each time I need something.

 

Give an example of where this would be necessary and I will help you with the design.

Link to comment
Share on other sites

One example would be CONFIG['admin_level'].  I may have a method inside of a class which requires admin privileges.  The class needs to use the $CONFIG['admin_level'] variable to know what level that is.

example:

 

public function something{
    if($auth->level == $CONFIG['admin_level']){      //$CONFIG would have to be globalized to access it here.
        //user is admin, do whatever
    }
}

Link to comment
Share on other sites

The way I have it set up now is an Auth class and a User class.  Maybe I should combine them into 1 class.

 

The Auth class has the userid, level, logged_in, etc along with login, logout methods. 

The User class has their username, real name, email, etc along with methods for changing their personal data, passwords, updating their last actions.

 

So the 'user type' is their user level which is stored in the Auth class.  I use this to determine what they can do/see.

 

KeeB, I'm assuming that you're suggesting I should have a User class, then extend that class to the user type they are.  (ex 'class Admin extends User').  I hadn't really thought about this.  If this is what you mean, should I just have both my Auth and User class combined into this design?

Link to comment
Share on other sites

Errr..... You realize a constant is just a static variable right?  Those are still held in memory.

 

Edit:  I guess theoretically a variable could take more memory, but I don't think it would be noticable in the case of some simple configuration settings.

Link to comment
Share on other sites

It does (as far as I know) take less memory... plus why have it as a variable when it's a site-wide setting. That way you have to pass it to every function that might use it, or pass an object/array - bit of a waste - where you can just use a constant.

 

Eg in my classes I often use

<?php
define('DEBUG',true);
public function ($foo) {
if(SET_DEBUG == true)
{
  //code
}
}
?>

 

etc, where with a variable it would need this, which needs a class set up, then the class sent to the function. Although it does allow one argument to pass several settings.

<?php
class globals()
{
public $debug = true;
}
$globals = new globals;

public function ($foo,$globals) {
if($globals->debug == true)
{
  //code
}
}
?>

 

Or even if I just had one global variable I needed this, which is faster to set up, but just as much hassle to pass to every function (with proportionally more hassle as you add more variables)

<?php
$debug = true;

public function ($foo,$debug) {
if($debug == true)
{
  //code
}
}
?>

 

Even with just one variable and one function it's more typing to pass a variable, to allow several variables and several functions would be tiresome to say the least. And what when your program expands to having several dozen "setting" variables and upwards of a hundred functions?

 

Save yourself some time with constants :)

Link to comment
Share on other sites

I would never use a class of variables for config....

 

I would just use a plain array....

 

I would do:

 


$CONFIG = array(
     'SomeKey' => 'SomeValue',
);

//or, one could always do $GLOBALS['CONFIG'] and not have to set it global every time the scope changed

function DoSomething() {
     global $CONFIG;
     echo $CONFIG['SomeKey'];
}

 

It's annoying to have to globalize an array so often, but I personally am not a huge fan of constants.  Settting them and using them looks tacky to me :(.  Little OCD thing I guess lol.

Link to comment
Share on other sites

It's still less typing (and technically correct - a setting is constant - it doesn't change)

 

Surely something which changes is a variable, since it's variable; and something which is constant is a constant. Kinda in the name I guess :)

 

Makes it easier to recognise what are settings aswell.

 

I like it because I can add more without using array_push, eg I define sql info and debug level (script settings someone working on the script would use) in one place.

 

Then I can define local settings (site name, user related settings, max message length etc) in another place (often an sql table to allow an admin to access it through a control panel)

 

Then I define other settings (eg the directory seperator and other similar options to allow cross-platform usage) in another location. That way the user can set some things, the admin of the site can go into more detail, and there are some settings that change depending on the environment, but dont need to be changed. I don't have to add them to an array, and I can seperate them. That way the end user doesn't cock up my includes by changing the directory seperator.

 

So, constants work like a "Super Global" state?

 

You can access a constant from within a class/method without first sending it to the class is what im asking.

Yes. That's the main reason I started using them :)

 

Just make sure you exit and re-enter strings to use them.

 

With a variable you can use

print "Debug level : $debug_level";

with a constant you'd have to use

print "Debug level : ".DEBUG_LEVEL;

 

Not really much harder, and that's only if they're inside double or single quoted strings.

 

It looks funny if you're only used to coding in PHP because you want to put a $ in front of it, but you soon get used to it.

Link to comment
Share on other sites

I've never really used constants too much, here and there kind of thing... and yes I know what you mean wanting to throw a $ in front of it (Just doesnt look right otherwise!! this always bugs me when Im programming in Python, and don't get me started on pythons if/else syntax!!)

 

That is neat.

 

so you could do like

 

config.php

<?php
$config_item = "val"; // enter the value of whatever config is, reader friendly for the novice compared to setting a constant
?>

then in your "global.php" include file (I always use this for handling all includes of classes and basic functions and etc.)
[code=php:0]<?php
include "config.php";
define('CONFIG_ITEM',$config_item);
echo CONFIG_ITEM; // will display "val" in this example.
?>

 

Link to comment
Share on other sites

Yes.

 

For example in my above mentioned examples I set the site path. So I work it out under a variable, then store it under a constant. Like so.

 

<?php
define ('DIR_SEP', DIRECTORY_SEPARATOR);
// Get site path
$site_path = realpath(dirname(__FILE__) . DIR_SEP . '..' . DIR_SEP);
define ('SITE_PATH', $site_path);
?>

 

Then when including I can use

<?php
include(SITE_PATH."inc".DIR_SEP."file.php");
?>

 

(Note, you don't have to! I just like to keep it so I can use it on (virtually) any system - but you get the theory hopefully)

Link to comment
Share on other sites

Question:

 

My db connection is a singleton, and I access it such as

 

$db = dbconn::getInstance();

 

So can I define a constant like:

 

define('db',dbconn::getInstance())

 

and then use it like:

 

// 
    public function doSomething()
    {
        db->sql_query("UPDATE whatever SET whatever=whatever WHERE whatever");
    }

 

 

Would that work okay or would I run into issues?

 

 

Link to comment
Share on other sites

Errr.... why? It's not a good idea to have a million constants, and there is a reason they only accept scalar types. (Other languages have this same case).

 

What's wrong with

<?php
dbconn::getInstance()->query("UPDATE whatever SET whatever=whatever WHERE whatever");
?>

Link to comment
Share on other sites

This is an OOP forum not a teach the man terrible programming habit forum :)

 

Globals ARE bad. I don't care if your favorite package uses them, they're bad.

 

I also don't care if your global is an array of values. That's worse.

 

I'm still not getting what needs to be configured. I can't help you with a good design if you don't tell me when you're trying to do.

 

I don't recommend hardcoding configuration options. Use an INI or XML file. But, if you insist on using constants, at least use CLASS constants.

 

I agree here.

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.