• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
What the logic behind config files being classes?

For Sprint, I created a Settings library that had 2 "drivers": one database and one config. Unless told otherwise, it would check first the database to see if the setting existed, then, if not, try to grab it from a config file. This worked very nicely to allow the application to be setup one way through config files, and then overwritten by the users through the Settings library, all fairly transparent from the developer's standpoint.

That sounds kind of like what you're describing, but isn't anything that the core framework has provided.

Also, they are public class properties, so you can modify them as you need within memory at run-time, just like you always could. The only difference here is that there isn't a central class holding all of the values for you. Instead, you'd want to create an instance of the config class in the controller, then pass it to any libraries that needed it. That's cleaner anyway, since you're injecting the dependency, instead of relying on a central warehouse.

Messages In This Thread
RE: What the logic behind config files being classes? - by kilishan - 04-21-2016, 08:08 AM

Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  

  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2020 MyBB Group.