When configure was reworked and config file format readers were added in 2.0, I made the stupid mistake of not including functionality to write configuration files. I'm hoping to fix that in 2.2. While I don't think its reasonable to modify the underlying interface as doing that will cause issues for people upgrading. Instead I think conditionally checking for a `dump` method on the attached reader objects. These also have bad names now, but I think that's something that will need to be solved in a future version. Changing the names now would be nice, but causes additional pain when upgrading.
So far I have things working, but wanted to double check the API I was considering.
Configure::dump($filename, $config = 'default');
Dumps all the data stored in Configure into $filename. The $config reader is used to serialize the data into the appropriate format. I wonder if Configure should be writing files, or simply returning the string version of the data, and let the end developer dump the configuration into a file/save to the database.
I have the changes in a branch, you can see the diffs at:
I missed this feature and never got around to adding it myself, thanks Mark for adding it. :)
The writing of the file could perhaps be handled differently. As i commented on github by default I would prefer to have the file being written into the directory pointed by reader's $_path property instead of having to provide full path each time. Having the data returned instead of being written to file could also be useful so perhaps add a third param $return for it?
> When configure was reworked and config file format readers were added in > 2.0, I made the stupid mistake of not including functionality to write > configuration files. I'm hoping to fix that in 2.2. While I don't think > its reasonable to modify the underlying interface as doing that will cause > issues for people upgrading. Instead I think conditionally checking for a > `dump` method on the attached reader objects. These also have bad names > now, but I think that's something that will need to be solved in a future > version. Changing the names now would be nice, but causes additional pain > when upgrading.
> So far I have things working, but wanted to double check the API I was > considering.
> Dumps all the data stored in Configure into $filename. The $config reader > is used to serialize the data into the appropriate format. I wonder if > Configure should be writing files, or simply returning the string version > of the data, and let the end developer dump the configuration into a > file/save to the database.
> I have the changes in a branch, you can see the diffs at:
ADmad: Not a problem, it was easier than I thought it would be.
I've added another commit to make the file writing happen in the adapters/reader classes. Thanks for the feedback on that guys :)
I'm wondering if it makes sense to also allow only saving a set of keys, so Configure::dump('config.ini', 'ini', array(...)); This would only dump the defined top level keys. Defining no keys includes all of them. I think always dumping all of the configuration values might not always be what's wanted in a configuration persistence tool. I'm thinking of a CMS/application setup where you need to ask the user for some specific data, that you want to load in later requests. You probably don't want to save out all of the current Configure state, and just the keys that section of the application requires.
On Saturday, 21 April 2012 08:39:54 UTC-4, ADmad wrote:
> I missed this feature and never got around to adding it myself, thanks > Mark for adding it. :)
> The writing of the file could perhaps be handled differently. As i > commented on github by default I would prefer to have the file being > written into the directory pointed by reader's $_path property instead of > having to provide full path each time. Having the data returned instead of > being written to file could also be useful so perhaps add a third param > $return for it?
> -ADmad
>> When configure was reworked and config file format readers were added in >> 2.0, I made the stupid mistake of not including functionality to write >> configuration files. I'm hoping to fix that in 2.2. While I don't think >> its reasonable to modify the underlying interface as doing that will cause >> issues for people upgrading. Instead I think conditionally checking for a >> `dump` method on the attached reader objects. These also have bad names >> now, but I think that's something that will need to be solved in a future >> version. Changing the names now would be nice, but causes additional pain >> when upgrading.
>> So far I have things working, but wanted to double check the API I was >> considering.
>> Dumps all the data stored in Configure into $filename. The $config >> reader is used to serialize the data into the appropriate format. I wonder >> if Configure should be writing files, or simply returning the string >> version of the data, and let the end developer dump the configuration into >> a file/save to the database.
>> I have the changes in a branch, you can see the diffs at:
On Sunday, April 22, 2012 6:44:37 AM UTC+5:30, mark_story wrote:
> ADmad: Not a problem, it was easier than I thought it would be.
> I've added another commit to make the file writing happen in the > adapters/reader classes. Thanks for the feedback on that guys :)
> I'm wondering if it makes sense to also allow only saving a set of keys, > so Configure::dump('config.ini', 'ini', array(...)); This would only dump > the defined top level keys. Defining no keys includes all of them. I think > always dumping all of the configuration values might not always be what's > wanted in a configuration persistence tool. I'm thinking of a > CMS/application setup where you need to ask the user for some specific > data, that you want to load in later requests. You probably don't want to > save out all of the current Configure state, and just the keys that section > of the application requires.
> -Mark
> On Saturday, 21 April 2012 08:39:54 UTC-4, ADmad wrote:
>> I missed this feature and never got around to adding it myself, thanks >> Mark for adding it. :)
>> The writing of the file could perhaps be handled differently. As i >> commented on github by default I would prefer to have the file being >> written into the directory pointed by reader's $_path property instead of >> having to provide full path each time. Having the data returned instead of >> being written to file could also be useful so perhaps add a third param >> $return for it?
>> -ADmad
>>> When configure was reworked and config file format readers were added in >>> 2.0, I made the stupid mistake of not including functionality to write >>> configuration files. I'm hoping to fix that in 2.2. While I don't think >>> its reasonable to modify the underlying interface as doing that will cause >>> issues for people upgrading. Instead I think conditionally checking for a >>> `dump` method on the attached reader objects. These also have bad names >>> now, but I think that's something that will need to be solved in a future >>> version. Changing the names now would be nice, but causes additional pain >>> when upgrading.
>>> So far I have things working, but wanted to double check the API I was >>> considering.
>>> Dumps all the data stored in Configure into $filename. The $config >>> reader is used to serialize the data into the appropriate format. I wonder >>> if Configure should be writing files, or simply returning the string >>> version of the data, and let the end developer dump the configuration into >>> a file/save to the database.
>>> I have the changes in a branch, you can see the diffs at:
On Sunday, 22 April 2012 14:26:01 UTC-4, ADmad wrote:
> I very much like the idea of being able to save only specific set of keys. > As you mentioned that would be a common use case in CMS/applications.
> -ADmad
> On Sunday, April 22, 2012 6:44:37 AM UTC+5:30, mark_story wrote:
>> ADmad: Not a problem, it was easier than I thought it would be.
>> I've added another commit to make the file writing happen in the >> adapters/reader classes. Thanks for the feedback on that guys :)
>> I'm wondering if it makes sense to also allow only saving a set of keys, >> so Configure::dump('config.ini', 'ini', array(...)); This would only dump >> the defined top level keys. Defining no keys includes all of them. I think >> always dumping all of the configuration values might not always be what's >> wanted in a configuration persistence tool. I'm thinking of a >> CMS/application setup where you need to ask the user for some specific >> data, that you want to load in later requests. You probably don't want to >> save out all of the current Configure state, and just the keys that section >> of the application requires.
>> -Mark
>> On Saturday, 21 April 2012 08:39:54 UTC-4, ADmad wrote:
>>> I missed this feature and never got around to adding it myself, thanks >>> Mark for adding it. :)
>>> The writing of the file could perhaps be handled differently. As i >>> commented on github by default I would prefer to have the file being >>> written into the directory pointed by reader's $_path property instead of >>> having to provide full path each time. Having the data returned instead of >>> being written to file could also be useful so perhaps add a third param >>> $return for it?
>>> -ADmad
>>>> When configure was reworked and config file format readers were added >>>> in 2.0, I made the stupid mistake of not including functionality to write >>>> configuration files. I'm hoping to fix that in 2.2. While I don't think >>>> its reasonable to modify the underlying interface as doing that will cause >>>> issues for people upgrading. Instead I think conditionally checking for a >>>> `dump` method on the attached reader objects. These also have bad names >>>> now, but I think that's something that will need to be solved in a future >>>> version. Changing the names now would be nice, but causes additional pain >>>> when upgrading.
>>>> So far I have things working, but wanted to double check the API I was >>>> considering.
>>>> Dumps all the data stored in Configure into $filename. The $config >>>> reader is used to serialize the data into the appropriate format. I wonder >>>> if Configure should be writing files, or simply returning the string >>>> version of the data, and let the end developer dump the configuration into >>>> a file/save to the database.
>>>> I have the changes in a branch, you can see the diffs at:
