Re: Conf: argue !

Ok. I can agree with this.
Help me: is there a difference between $array[0] and $array['0'] ?

To do: 
1. correct the errors in the current conf.xml and test if corrections 
doesn't break BC.
2. amend the dtd to detect these errors.

Cheers,
wim niemans


On 25 Feb 2005 at 9:53, Jean-Christophe Michel wrote:

> Wim Niemans ri wrote:
> 
> >>>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.
> > 
> > 
> > I could agree to this. Sounds oke.
> > The following example will blow it away:
> > 
> > Say in version 2.0 the value for 'currrency_rate' is an integer.
> > In version 3.0 that is changed into a float.
> > Both versions are available in base_config. That's the idea though?
> > And....btw...all conf_values are stored in php, like 
> > array('currency_rate'  => '123'), so what's the difference ?
> 
> an integer should be cached in php as 'currency' => (int) 123,
> whereas a string should be 'currency' => (string) '123'.
> 
> > I noticed in some xml files the occurrence of:
> > 
> > <section name="plugins_dir">
> >    <property type="raw">BC_PATH_BASE . '/smarty/libs/plugins'</property>
> >    <property type="raw">BC_PATH_BASE . '/smarty-plugins'</property>
> > 
> > The path is 'smarty/plugins_dir' for two properties.
> 
> It's an error, there should be a param name.
> 
> > To my opinion Conf:: could handle this as an array, *or* as two properties 
> > with the same path (but a different id). Think about it.
> 
> No, too complex, no real need for this.
> 
> > See also the above example of one path with different type and version.
> > And it is always a good idea to have a separate id as pk and use that for 
> > update. Just in case.........
> 
> The type change between version will have to be adressed. However I 
> don't see why a numeric additional pk would solve it.
> 
> -- 
> Jean-Christophe Michel
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe-zNu2Yekbks92Brm55YPRC3dfcadvtA/[email protected]
> For additional commands, e-mail: dev-help-zNu2Yekbks92Brm55YPRC3dfcadvtA/[email protected]
> 
>