Welcome Guest, Not a member yet? Register   Sign In
What the logic behind config files being classes?
#1

I noticed the configuration files are being switched from arrays to actual classes (of course I realize nothing is in stone yet)

What is the logic behind this and will we still be able to override certain values with new values in environmental config "folders"?

For example in /config/application.php I could have
$config['show full name'] = true;
$config['show login'] = true;

In /config/production/application.php I override just the one value
$config['show full name'] = false;

Currently it loads /config/application.php and merges /config/production/application.php over it that way I get all the settings in a single array.

I extended MY_Loader to add a "database" config layer to override the other 2 as needed as well as manage this with CodeIgniter's cache system which allows me to make a single call to cache the entire (all 3 layers & all config files) merged config array and one call to get everything out (no need to load file after file after file...).

Do you think this will still be do able and just as fast as the array method as well as cacheable?
I can't image making everything a object will actually be faster and just as flexible but, I could be wrong?


DMyers
Reply
#2

(This post was last modified: 04-20-2016, 08:24 PM by kilishan.)

Environment-based configuration values are handled differently, now. Since we were using classes (I'll get to why in a second) we had to find a different way to do it, so we went with .env files. This is a good way to help keep them completely separate per environment, as well as keep the security up a little since they should never be put in the repo. Here's a good article about why using .env files is a good thing.

When we first started discussing the configuration changes the idea was to decentralize the files themselves into more individual files that held only the settings needed for one part of the application. Since we were breaking away from the singleton pattern in the framework, we wanted to break away from a central, global config file, as much as possible. Each library would get the information that it needed only. As we talked more, using a single simple class was the simplest solution. It minimized the number of files that were needed, because you only ever had the single class, instead of having one for the environment and one global. It reduced file access time since we didn't have to scan different sets of folders for possible versions. Additionally, it made it so that the file could be loaded from anywhere the autoloader could find it, which might mean shared folder between applications, or in a module-like setup. Finally, it is as close to native PHP as we can get, without any additional abstractions, which is usually a good thing, also.

For performance - I don't think we lose much, if any. PHP 7's handling of objects and arrays is stellar compared to the 5.x branches, which is where a lot of it's performance improvements come from. I can't think of a way off the top of my head, though, where you would be able to cache the config files together.

And performance is something I'm trying very hard to keep similar to CI3. Due to "cleaner" architecture, there have been a little bit of slowdown, though we're still much closer to CI3 than any of the big-name frameworks. And it's something I'll take a deep-dive into at some point to see what other things I can find to boost performance. That said, running in a stock Homestead Improved virtual machine, under NGINX, I'm seeing 3 ms load times for the framework's welcome page. That's running on my 5 year old iMac, too. Running under MAMP Pro and Apache (which is very much not optimized) with xdebug off, I'm seeing around 9ms page load for the welcome page.

Actually, just fired up my base CI3 install under Apache and am seeing around 12ms page load times. Might be a fluke for the evening, but we're actually running faster currently. Definitely not too worried about the performance, then. Smile

EDIT: Holy cow. Just to try it out, I turned opcode caching on in PHP7 under my Apache install and tried again. PHP7 screams, guys - I'm getting 1ms -- or less! -- page loads to the welcome page. That's for both CI3 and CI4.
Reply
#3

I would like to see it make into the config class for developers to be able to read plus write to the config.

This way we change the config on the fly for our use.
What did you Try? What did you Get? What did you Expect?

Joined CodeIgniter Community 2009.  ( Skype: insitfx )
Reply
#4

(04-21-2016, 03:59 AM)InsiteFX Wrote: I would like to see it make into the config class for developers to be able to read plus write to the config.

This way we change the config on the fly for our use.

If you are changing it on the fly that just needs to be an in memory change, right? What's the use case you're thinking about?
Reply
#5

I don't think that there is huge difference between class / object / array configs.

How ever in such class as https://github.com/lonnieezell/CodeIgnit...rvices.php
I don't like all of those static method definitions. Configs should be as cleanest as possible (even if they are classes).

And its a little bit of strange to have such important things outside the system. As I see it, it is +1 dependency for the system to work.
In CI 3 it was index.php > SYSTEM && APP , and now it is index.php > System && Config && App

I think that the flow should be:
index > init System (no configs here) > init App (configs && app)
Best VPS Hosting : Digital Ocean
Reply
#6

(04-21-2016, 05:20 AM)sv3tli0 Wrote: I don't think that there is huge difference between class / object / array configs.

How ever in such class as https://github.com/lonnieezell/CodeIgnit...rvices.php
I don't like all of those static method definitions. Configs should be as cleanest as possible (even if they are classes).

That "config" file acts more like a factory than a standard config file, and the static methods aid in usability. Services::routes() vs new Config\Services()->routes(); Static methods are not always evil, not matter what the internet might like to say. They just make testing a little more difficult. For cases like these, they work great.

(04-21-2016, 05:20 AM)sv3tli0 Wrote: And its a little bit of strange to have such important things outside the system. As I see it, it is +1 dependency for the system to work.
In CI 3 it was index.php > SYSTEM && APP , and now it is index.php > System && Config && App

I think that the flow should be:
index > init System (no configs here) > init App (configs && app)

I believe we've had this discussion before.... but we allow the application folder to act as a namespace, and we allow that namespace to be changed by the user. The only clean way to do that is to have Config always stay the same so system files can find it.
Reply
#7

(This post was last modified: 04-21-2016, 08:04 AM by dmyers.)

I read your user manual entry here: https://github.com/lonnieezell/CodeIgnit...ration.rst and must say it is very well written.

Allowing the application administrator the ability to add and/or change certain config values I/we have without getting the developer involved certain will need a completely new approach in order to load my "database config layer" and override the config files "fast" certainly will be a challenge.

For example I'll set the "default" when I "ship" the application in the config files.
$config['send email on new user'] = true;
$config['email user on account deactivation'] = true;
$config['allow comments on notes'] = true;

Sometimes this could be 100+ values.

Then the administrator can change these at will without getting me involved just to change the code.

Can you think of a easy way to query and loop over the configs to change these when the application is loaded or do you think this will need to be on a as needed bases (ie 100's of db calls)
Right now it's 1 DB call if it's not cached and 0 if it is.

DMyers
Reply
#8

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.
Reply
#9

kilishan, Thank you for the input and your hard work I look forward to working with it.
Reply
#10

What I meant about writing to the config files was being able to create and keep our own configs on the fly, say from an Admin Dashboard.
What did you Try? What did you Get? What did you Expect?

Joined CodeIgniter Community 2009.  ( Skype: insitfx )
Reply




Theme © iAndrew 2016 - Forum software by © MyBB