2

I have a project of legacy code that I've nearly successfully converted to use an autoloader rather than a bazillion include and require statements.

The only remaining issue that I have is a config file that sets up some global config stuff. As it is now, it's just a straight PHP that loads variables the application requires.

My idea to make this work is to convert it to a class with class constants for the "global" data. Making the class constant calls will trigger the autoloading of the config class and put everything under the control of the autoloader.

My question is whether this is the best way to approach this and if others have done something similar?

So in my application rather than calling something like this to access the config variables.

$GLOBALS['conf']['thingy'];

That would become something like this.

Config::THINGY

Where things is a class const.

class Config {
   const THINGY = 'yes, this is it';
}

This approach also gets rid of global data references, which I think is always a good thing.

Halfstop
  • 1,710
  • 17
  • 34
  • I like the syntax `Config::THINGY`. See: http://stackoverflow.com/questions/3724584/what-is-the-best-way-to-save-config-variables-in-a-php-web-app – KIKO Software Mar 03 '15 at 22:01
  • I usually solve this by saving config files in one (or more) specific directories, and then referencing those directories using an interface constant. You can then put the interface on any class that needs to load config files to make the path available. – mopsyd Mar 03 '15 at 22:13

1 Answers1

1

You are definitely on the right track. As with anything related to programming, there are 1 million + 1 ways to skin a cat, here a a few options /w some info.

Yaml: Heavily used by frameworks such as Symfony. If you don't use the SF framework, you can easily implement the stand along SF Yaml parser. Supports hierarchies.

JSON: Great way to maintain config options, highly portable. Supports hierarchies.

ini: You can use the built-in parse_ini_file function for loading your config settings, however hierarchies within ini files are difficult to maintain, and only achievable using an arbitrary namespacing convention.

database: You could actually store settings within the database (with a cache layer between permanent store and the app), this is useful if you want to create a web gui for users to change values, without having to push code.

class constants: Nothing wrong with this approach at all, however it can be argued that either of the config options would be a tad 'cleaner', and more portable.

Mike Purcell
  • 19,847
  • 10
  • 52
  • 89
  • 1
    Good choices. I think I may have mis-identified what I'm working with. It's actually not entirely straight config data, it's also application initialization stuff that's calculated with PHP. I have most of the actual config stuff in a database, to eliminate the need to configure a hard path to the "config" file, I moved that hard path into my database configuration table. It's not the most ideal solution, but I'm trying to use a scalpel with this code to avoid too much disruption. Rewriting the whole thing isn't an option. Professional turd polisher. – Halfstop Mar 04 '15 at 14:52
  • You are definitely doing the right thing, and I think we have all been in that same sitch, trying to clean up a mess b/c someone didn't have the foresight nor the inclination to consider shelf life. Symfony uses sfConfig::get('some_config_value'), and with that we can override the get method and have it try memcache, then db / file (yaml). – Mike Purcell Mar 04 '15 at 18:25
  • 1
    Yeah, my goal is to move as much legacy code and all new code into Symfony. It's been the most enjoyable framework to work with. It's really easy to keep things clean and tidy. – Halfstop Mar 04 '15 at 21:45