Re: Conf: argue !

Wim Niemans ri wrote:
> On 24 Feb 2005 at 18:45, Jean-Christophe Michel wrote:
>>Manuel Holtgrewe wrote:
>>
>>
>>>I like the idea of "core settings cannot be changed on the fly"... And 
>>>what about people who do not have a database?
>>
>>They'll have to put their conf values in xml and call 
>>tools/cli/reload-confs.php instead of tools/web/reload-confs.php :-)
> 
> So, the proposed method myConf->set(path,value) shoud evaporate than?

No, the set method will be used by the web gui to edit db. But the 
script evoqued here would make a dump of all values for caching.

>>I mean that we can check bad names in conf when rebuilding the cache.
>>No need to wait for running the site.
> 
> Check for bad names? What's the definition of a 'bad name' ?
> To my humble opnion conf can't check nothing while loading.

 From xml: that constants in "raw" exist. That xml is valid.
 From db or xml: that there's not a unicity name conflict. That an 
overriding value (a dev value over core one) doesn't change type.

>>>>property::path should already be unique. Of course this makes a long 
>>>>pkey, but since all db is cached into a php array, why have a numeric id?
>>>
>>>Because you might decide to shift things and path is volatile in this 
>>>respect. However, you are right, id is a candidate key - a *possible* key.
> 
> You will need an 'id' when updating, since you can't guarantee that a path 
> is unique. Stronger, a unique integer-id is required.

Disagree. A path must be unique. If not what is a path useful for?

-- 
Jean-Christophe Michel