In my app I have a get class which brings back things like page name, page access method, commonly used directories, current URL's, ect.. so I thought that rather than including the config file everywhere I needed a config option, I would make a function in my get class which returned a requested option from the config file
Accessing Constants through include() - not finding them
Moderator: General Moderators
I am writing a blogging application/ framework (it's still in its first stages), and I have an external file which has all the configuration in constants, I will eventually make the transition to options stored in a databse, although because it is so early in the design process I need them to be in an actual file (I haven't even begun the database access class yet...
).
In my app I have a get class which brings back things like page name, page access method, commonly used directories, current URL's, ect.. so I thought that rather than including the config file everywhere I needed a config option, I would make a function in my get class which returned a requested option from the config file
In my app I have a get class which brings back things like page name, page access method, commonly used directories, current URL's, ect.. so I thought that rather than including the config file everywhere I needed a config option, I would make a function in my get class which returned a requested option from the config file
Did you try manually including your file like I said?
Code: Select all
include('path/to/config.php') ;
return constant($num) ;yes, still no luck. file_exists() brought the obvious as well, the file is there... I also tossed an echo statement in the external file only to see it show up rendered when I view my script... so now I am even more confused, greatBegby wrote:Did you try manually including your file like I said?
Code: Select all
include('path/to/config.php') ; return constant($num) ;
Then you don't want constants. Constants are not supposed to be dynamic, they stay constant throughout the app and shouldn't be created at run time. A dynamic config, which changes on page load or with options stored in a database, should use a config class like you are thinking, but should not use constants. Set it up like this maybe and use an xml file or something similar for your configorbstra wrote:I am writing a blogging application/ framework (it's still in its first stages), and I have an external file which has all the configuration in constants, I will eventually make the transition to options stored in a databse, although because it is so early in the design process I need them to be in an actual file (I haven't even begun the database access class yet...).
In my app I have a get class which brings back things like page name, page access method, commonly used directories, current URL's, ect.. so I thought that rather than including the config file everywhere I needed a config option, I would make a function in my get class which returned a requested option from the config file
Code: Select all
class Config
{
private $options = array() ;
public function __construct()
{
// create your options array here using an xml file or a database query
}
public function get($option)
{
return $this->options[$option] ;
}
}
// usage
$config = new Config() ;
echo $config->get('someOption') ;If you want this to be a static class you can use a singleton as well to make sure the file or database is only read once
Code: Select all
class Config
{
private static $options = array() ;
private function __construct() {} // private to make sure this stays static
private static function getOptions()
{
if (sizeof(self::$options)==0)
{
// Create self::$options here from db or xml file
}
return self::$options ;
}
public static function get($option)
{
$options = self::getOptions() ;
return $options[$option] ;
}
}
// usage
echo Config::get('someOption') ;I still really really want to know what is going on with those constants though.... its making my head itch.
Edit: One note: constants are ok for config if you have a file that the user can edit or whatever and you access those constants directly through your app, but the config class makes a lot more sense since, even though the setup is static right now, you are converting it to a dynamic solution in the near future.
Don't think constants are bad for configuration, but if you aren't accessing them directly by name in your app then something is not right.
Edit: One note: constants are ok for config if you have a file that the user can edit or whatever and you access those constants directly through your app, but the config class makes a lot more sense since, even though the setup is static right now, you are converting it to a dynamic solution in the near future.
Don't think constants are bad for configuration, but if you aren't accessing them directly by name in your app then something is not right.
Last edited by Begby on Wed Jan 03, 2007 10:23 am, edited 1 time in total.
- jayshields
- DevNet Resident
- Posts: 1912
- Joined: Mon Aug 22, 2005 12:11 pm
- Location: Leeds/Manchester, England
head and shoulders.. but XML is in some cases better than consants and DB because it is ALOT simpler to set up a GUI to edit the options if they are in an XML file than a database, and constants are literally impossible to edit through a GUI, you would have to go into the file manually, which would require network access, or FTP which is hated for simple option editing.. in my opinionjayshields wrote:Use some anti-dandruff shampooBegby wrote:its making my head itch.