Re: Conf files

On May 25, 2005, at 9:41, Jean-Christophe Michel wrote:

> B. Kamer wrote:
>
>>> I don't think the name similarity is enforced in any way. It's  
>>> only a
>>> recommandation. Being is a dir conf/ is not really necesary imho  
>>> since
>>> the name ends with .conf.xml.
>>>
>>
>>
>> well, from Conf::_loadConfiguration()
>>
>>         $dir = dir(BC_PATH_INCLUDE . '/binarycloud/');
>>         while ($entry = $dir->read()) {
>>             $filename = BC_PATH_INCLUDE . '/binarycloud/' . $entry .
>> '/' . $entry . '.conf.xml';
>>
>> and
>>
>>         $dir = dir(BC_PATH_INCLUDE . '/vortex/');
>>         while ($entry = $dir->read()) {
>>             $filename = BC_PATH_INCLUDE . '/vortex/' . $entry .   
>> '/' .
>> $entry . '.conf.xml';
>>
>> this means [package name] / [package name] .conf.xml. only 1
>> configuration per package can be loaded.
>>
>
> You're right. I vote for reading all files in WORKSPACE/conf/
>
>
>>>> all vortex packages keep there conf files in a separate  
>>>> directory and
>>>> are thus never cached...
>>>>
>>>
>>> If it's true it's a real problem. Please explain more.
>>>
>>
>> most vortex modules keep there factory conf files in a vortex/
>> [package]/conf/[package].conf.xml. The above code never reads there.
>>
>
> No, conf files in vortex/ are example files only. It's up to the  
> user to
> copy & alter the files in his workspace. It's not an error, it's a
> feature :p


What defines a FACTORY and WORKSPACE value?

I thought all files from binarycloud/* & vortex/* should be loaded  
automaticly into the FACTORY realm. This way vortex modules will work  
with default (FACTORY) settings. Then when the user needs modified  
configuration then he must copy it to WORKSPACE/conf and modify that  
file.

If this i true why would it be a feature NOT to load vortex FACTORY  
settings? What's the use of this feature? Disabled until conf comes  
from a database?

>>>> I would like to change this logic to:
>>>>
>>>> FACTORY configuration files are in one of these;
>>>> {{{
>>>>    binarycloud/*/conf/*.conf.xml
>>>>    vortex/*/conf/*.conf.xml
>>>> }}}
>>>>
>>>> No change would be done to the workspace files.
>>>>
>
> I don't agree for vortex/, see above. You need to have a way to  
> modify a
> factory conf.

The user would never have to modify FACTORY setting? He should copy  
the file to WORKSPACE/conf and modify tha one. The Conf::get() will  
get the highest available level.

>> If we decide to have a separate directory 'conf' per package [1] and
>> read all files in that directory [2] i think we would benefit in   
>> these
>> ways.
>>
>> [1] The conf files would be nicely seperated from other files and
>> directories which seems cleared. Most part of an package have  
>> there  own
>> directory, why not configuration files too?
>>
>
> Since the file name tells it's a conf file, why add a dir?

consistency between the three places

either binarcyloud/*.conf.xml should move to binarcyloud/conf/ 
*.conf.xml or vortex/conf/*.conf.xml to vortex/*.conf.xml

>> [2] It would illiminate the minor point from above. The hardcoded   
>> path
>> to the binarycloud.conf.xml wouldn't be necessary anymore since  all
>> file ending on .conf.xml (and are possibly in /conf/) are cached.
>>
>> We do have to make a liitle effort anyway since the factory vortex
>> configuration files are not read. Either moving them to their package
>> root or change the code to use the 'conf' directory. Why then do  
>> we  in
>> binarycloud/* use a conf directory and in vortex not?
>>
>
> I agree if your changes allow to implement FACTORY/WORKSPACE conf  
> level
> as defined in Conf.php. I think these changes were intended for a sql
> based conf, and xml was consciously limited to read values in  
> workspace.

If all file in the packages binarycloud/vortex/apps are consider  
FACTORY settings (whether automatically read or not) and manually  
placed conf files placed in WORKSPACE/conf nothing would change here...

sorry to be a bit neurotic on this, i just think looking at the code  
should make it clear how thinks work (especially since the docs are  
old). Exceptions are fine, but the fewer the better.


Bas
_______________________________________________
dev mailing list
dev-PnctHDZWAvB/Cz2I37pSEPZ4XP/[email protected]
http://lists.binarycloud.com/mailman/listinfo/dev