Issue

ZF-2061: Add a seal() method to Zend_Config

Issue Type: New Feature Created: 2007-10-12T09:59:24.000+0000 Last Updated: 2008-01-23T15:22:46.000+0000 Status: Resolved Fix version(s): - 1.0.3 (30/Nov/07)

Reporter: Nico Edtinger (nico) Assignee: Rob Allen (rob) Tags: - Zend_Config

Related issues: Attachments:

Description

I tried to use the new merge() method, but had the problem, that our main config object was read-only. Adding allowModifications to the Zend_Config constructor was easy, but now it's also writable outside of our front-controller. It would be nice if Zend_Config could be sealed (setting Zend_Config::_allowModifications to false) after the init phase.

Comments

Posted by Thomas Weidner (thomas) on 2007-10-15T13:47:39.000+0000

Assigned to Rob

Posted by Darby Felton (darby) on 2007-10-17T07:49:26.000+0000

I like the idea of post-construction configurability, but I would instead recommend the solution to be adding a setAllowModifications(boolean $enabled) method or similar, though maybe there is better name for $enabled.

Posted by Rob Allen (rob) on 2007-10-18T02:15:28.000+0000

setAllowModifications() implies that a Zend_Config object can be made writable at will.

Maybe something like setReadOnly() so that it's a one-way operation ?

Posted by Nico Edtinger (nico) on 2007-10-19T15:35:14.000+0000

I also think disallowing modifications should be one-way as it's something you'd do to enforce code standards. The name (seal() or setReadOnly()) doesn't matter to me.

Posted by Darby Felton (darby) on 2007-10-19T15:45:50.000+0000

If I understand correctly, this is trivially accomplished by extending Zend_Config:

<pre class="highlight">
class MyConfig extends Zend_Config
{
    public function seal()
    {
        $this->_allowModifications = false;
        return $this;
    }
}

Considering the above comments and the fact that it could also be harmful to allow only seal()/setReadOnly() - many people would have the opposite problem (needing write access to a locked object) - it would seem that this is best done in userland instead of bloating the framework component with possibly problematic functionality.

Posted by Nico Edtinger (nico) on 2007-10-19T17:02:52.000+0000

It's not that easy because you need to apply the change recursively. And that's currently not possible because __construct() and __set() use new Zend_Config instead of new self and therefor all childs won't have a seal method.

Posted by Darby Felton (darby) on 2007-11-07T13:01:25.000+0000

Yes, of course, I missed that. What would the implementation look like, now that I committed SVN r6767?

Posted by Rob Allen (rob) on 2007-11-15T10:28:24.000+0000

Hi Nico,

Does Darby's change in SVN r6767 allow you to solve your problem if you write the userland class :

<pre class="highlight">class MyConfig extends Zend_Config
{
    public function seal()
    {
        $this->_allowModifications = false;
        return $this;
    }
}

Posted by Rob Allen (rob) on 2007-11-23T17:48:52.000+0000

I'd like to resolve this issue one way or another if possible.

Choices are:

  1. Resolve as "Won't Fix" or "Not an Issue" and users will have to create a user-land class.
  2. Add a setReadOnly() function to Zend_Config.

Personally, I'm tending towards (2) as merging multiple config files into a single Zend_Config doesn't strike me as that unusual a use-case and with merge() we are implicitly endorsing this use-case anyway. May as well tidy up after ourselves!

Thoughts?

Posted by Rob Allen (rob) on 2007-11-27T14:51:13.000+0000

Added setReadOnly() in svn 6967 on the trunk and svn 6968 on the release-1.0 branch.

Posted by Wil Sinclair (wil) on 2008-01-23T15:22:46.000+0000

Fixing Fix Version to follow issue tracker conventions.

Have you found an issue?

See the Overview section for more details.

Copyright

© 2006-2021 by Zend by Perforce. Made with by awesome contributors.

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

Contacts