[ekerazha]

Sometimes I would prefer to change and save the yii config (i.e. into the Db). If you look at many webapps, you usually have a file containing the Db config, then settings etc. are saved to the Db. I think that it would be nice to add the opportunity to save the yii config in the Db (only the Db config - db server, user, pass etc. - would be stored into a file).

[alex-w]

Wouldn't this just complicate things and cause constant querying of the database.

I can understand the benefit if it's settings that change a lot but after it's initially set how often do you change things in the config.

[ekerazha]

alex-w, on 07 October 2011 - 09:26 AM, said:

Wouldn't this just complicate things and cause constant querying of the database.

Caching enabled

Quote

I can understand the benefit if it's settings that change a lot but after it's initially set how often do you change things in the config.

You can have benefits if you develop a web application for Average Joe with customizable settings.

[samdark]

Do you really want to allow average Joe to be able to configure components and stuff? If these are all application settings it's better to handle it via a separate component.

[ekerazha]

samdark, on 10 October 2011 - 03:03 PM, said:

Do you really want to allow average Joe to be able to configure components and stuff?

Of course.

Site name, caching settings etc. are common settings for the Average Joe user and, actually, they are "hardcoded" into the yii config file (a file that the Average Joe shouldn't touch).

[ekerazha]

Cue http://www.yiiframew...945#entry147945

[phpnode]

There are indeed scenarios where you want the user to be able to edit *some* of the settings via a web interface. In my opinion it's better to stick with the current approach though because it's much faster and more flexible than loading stuff from the db. A different approach is to allow the admin backend to edit certain application config files. I've had some success with this approach in the past, you can just effectively do:

$newSettings = array("components" => array("foo" => array("class" => "Foo")));
file_put_contents(Yii::getPathOfAlias('application.config.custom').'.php', '<?php return '.var_export($newSettings,true).';');

Although this does scrub any comments in the config file.

The real problem with either approach is building the UI. You end up needing a separate form model for literally every component that you want the user to be able to configure, as well as form models for any components which that editable component users. So for example, if you want to make the URL manager configurable you need a model for the url manager itself, a model for url rules and a UI that ties it all together. I've actually done this, it's thousands of lines of code just for 2 components. Add the db, cache, session handler, auth manager, asset manager, client script etc, not to mention custom components, and you end up with a lot of code to write and maintain.

But the biggest problem of all - making this UI intuitive to end users. It's all very well allowing them to configure e.g. $defaultParams on an URL rule but how do you explain that to them in a way non developers can understand? and can you do that for every configurable property of every configurable component?

Don't underestimate the difficulty of this task

[ekerazha]

Couldn't you just serialize/unserialize or json_encode/json_decode arrays into/from the database? So instead of having a file with arrays, you just store those arrays into the db and you can also cache them. You keep the current approach but you add the capability to store the config data into the db for an easier management. There could be a gii component to manage the values.

This post has been edited by ekerazha: 11 April 2012 - 08:22 AM

[phpnode]

ekerazha, on 11 April 2012 - 08:16 AM, said:

There could be a gii component to manage the values.

This is the hard bit. The other hard bit is deciding which things can be configured, because obviously if you're loading the config from the db, the db itself cannot be configurable, nor can the cache since presumably you'll be caching these values.

[ekerazha]

Ideally the db config would be the only file-stored data, if you look at the most popular webapps (Invision Board, phpBB etc.) they work this way (if they didn't change it recently).

[phpnode]

what advantage does storing the config in the db really offer though? as i mentioned before, it's trivial to parse and write the existing config files, and this is a LOT simpler than loading from the db etc.

[ekerazha]

In my opinion it's simpler to query the Db instead of having to parse and write back a text file. Moreover you avoid issues like filesystem permission issues. I think my opinion is pretty popular as virtually any popular webapp stores the config data into the Db. Is there any popular webapp which parses and writes the config data into a text file? Writing a parser doesn't sound very immediate to me, could you provide some code?

This post has been edited by ekerazha: 12 April 2012 - 12:53 PM

[phpnode]

ekerazha, on 12 April 2012 - 12:46 PM, said:

Writing a parser doesn't sound very immediate to me, could you provide some code?

I already did, but to recap:

Here's the parser

$config = include "path/to/file.php";

Here's the writer:

$newSettings = array("components" => array("foo" => array("class" => "Foo")));
file_put_contents('path/to/file.php', '<?php return '.var_export($newSettings,true).';');

Anyway, you haven't addressed my points about UI...

[ekerazha]

phpnode, on 12 April 2012 - 01:11 PM, said:

Here's the parser

$config = include "path/to/file.php";

How do you use that $config var? Yeah we can just import the config file but we have to read the config values every time and overwrite the config file everytime and if you add config values you have to change the reading function to read the new values... haven't we?

[phpnode]

You use it just the same way you do now, in your index.php, it is the exact same method Yii currently uses to load its config, I'm just saying you can write files in this format too with 1 line of code. You don't need to change your read / write functions when config changes, it's just literally:

1. Read the config into an array using 1 line of code
2. Manipulate the array to your liking via a UI - THIS IS THE HARD BIT
3. ? ? ?
4. Write the array back to the file using 1 line of code
5. Profit

It's very simple. But again, you don't respond about the UI difficulties.

[ekerazha]

Finally at home

phpnode, on 13 April 2012 - 04:26 AM, said:

1. Read the config into an array using 1 line of code

Yeah I didn't remember that there is a "root array" for all the config keys. If it was a file with many different arrays it would have been more difficult.

Quote

2. Manipulate the array to your liking via a UI - THIS IS THE HARD BIT

What should be hard?

However... I think there are two approaches...

1) Simpler: json_encode config into the Db, but you can do the same thing using your approach (with the exception of possible filesystem permission issues). P.S. Thank you for the hint.

2) Harder: have a proper Db structure where every config value has its own row etc.