ZF-6455: Zend_Application allows loading 2 configs and disallow module bootstrap "config"

Issue Type: Bug Created: 2009-04-28T15:08:46.000+0000 Last Updated: 2012-11-20T20:53:18.000+0000 Status: Closed Fix version(s): Reporter: Sebastian Krebs (kingcrunch) Assignee: None Tags: - Zend_Application

Related issues: Attachments:


I dont know, if its really a issue. To me it seems a strange behaviour, but its at least an undocumented feature ;)

<pre class="highlight">        if (null !== $options) {
            if (is_string($options)) {
                $options = $this->_loadConfig($options);
            } elseif ($options instanceof Zend_Config) {
                $options = $options->toArray();
            } elseif (!is_array($options)) {
                throw new Zend_Application_Exception('Invalid options provided; must be location of config file, a config object, or an array');


if $options is a string, the config will be loaded from file and then given to setOptions().

<pre class="highlight">        if (!empty($options['config'])) {
            $options += $this->_loadConfig($options['config']);

If there is a key 'config' in the file Ive loaded before, setOptions() tries to load a second config file.

On the other hand, if there is a module 'config' with a module-bootstrap, its not configurable, because Zend_Application finds the key 'config' and tries to load ... something.

<pre class="highlight">

The other predefined values 'includepaths', 'autoloadernamespaces', 'bootstrap', 'resources' and so on are also not useable as modules with module-bootstrap.

Version is trunk rev 15242



### Comments

Posted by Ben Scholzen (dasprid) on 2009-04-29T01:32:19.000+0000

Matthew, I'd suggest a "module" key in the root options which childs are handled like module bootstrap options in the parent. The current way of defining module specific bootstrap options should stay, but this one would be a fallback which can be used when somebody has modules which conflict with our reserved keys.



Posted by Sebastian Krebs (kingcrunch) on 2009-04-29T06:26:35.000+0000

I would like to see the this :)

Meanwhile I found, that the other behaviour -- the "second config file" -- is quiet useful, even if its only useable, when the second constructor argument is a string. This allows something like this

    <pre class="highlight">

    <pre class="highlight">

Currently its not working as expected caused by another bug: <>



Posted by Ben Scholzen (dasprid) on 2009-04-29T06:38:32.000+0000

The actual idea behind the config option-key was, that you can specify specific options via an array, but additionally load a config file. But nice that it also finds other useful cases.



Posted by Sebastian Krebs (kingcrunch) on 2009-04-29T07:53:12.000+0000

If you pass an array to the constructor the "hack" wont work, because it load a config file only once (in \_loadConfig()). It can confuse somebody, if he will change a string-to-a-file to a array later and wondering, that the "additional file" is not loaded anymore.



Posted by Marek (xorock) on 2009-05-31T04:43:34.000+0000

My question is why are You working with arrays not objects? I think \_loadConfig() should additionally write protected $\_config variable with reference to loaded $config or return merged data. Currently there is no way to get configuration file in it's original state - there is only getOptions() method with options already transformed to array. I think some of us might need this for further prcoessing and pushing data:

    <pre class="highlight">
    protected function _initConfig() {
        $config = new Zend_Config($this->getOptions());
        Zend_Registry::set('config', $config);

back to Zend\_Config is really stupid.



Posted by Matthew Weier O'Phinney (matthew) on 2009-05-31T09:19:28.000+0000

We're using arrays as it makes it easier to do comparisons, and to manipulate the keys in order to do comparisons; additionally, it offers better compatibility throughout various framework components.

First, in Zend\_Application, keys are case insensitive. However, because Zend\_Config uses object properties, the keys are case sensitive. This makes it difficult, if not impossible, to test accurately for the existence of given keys. As a result, in our tests, we found there were many cases where existing keys were simply not matched. Casting to an array and storing as an array internally ensures we can transform those keys and do case insensitive matching.

Second, many framework accept an array of options to the constructor and/or a factory. Many also accept Zend\_Config objects, but in all such cases, also accept arrays. It's thus easier to simply cast to an array within Zend\_Application, as the arrays will be able to be used with any component.

Finally, the reason that you can pass a "config" key to the Zend\_Application options is to allow you to provide local overrides of the keys in your configuration file. These are, clearly, going to be passed as an array -- which means that any value in $\_config as you propose would be non-representative of the actual configuration.



Posted by Rob Allen (rob) on 2012-11-20T20:53:18.000+0000

Bulk change of all issues last updated before 1st January 2010 as "Won't Fix".

Feel free to re-open and provide a patch if you want to fix this issue.



Have you found an issue?

See the Overview section for more details.


© 2006-2018 by Zend, a Rogue Wave Company. Made with by awesome contributors.

This website is built using zend-expressive and it runs on PHP 7.