Welcome Guest, Not a member yet? Register   Sign In
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

Theme © iAndrew 2016 - Forum software by © MyBB