[#ZF-2061] Add a seal() method to Zend_Config - Zend Framework Issue Tracker

Zend Framework

Add a seal() method to Zend_Config

Created: 12/Oct/07 09:59 AM Updated: 23/Jan/08 03:22 PM

Component/s:

Zend_Config

Affects Version/s:

1.0.2

Fix Version/s:

1.0.3

Time Tracking:

Not Specified

Description

« Hide

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.

All

Comments

Work Log

Change History

FishEye

Crucible

Sort Order:

Ascending order - Click to sort in descending order

[ Permlink | « Hide ]

Thomas Weidner - 15/Oct/07 01:47 PM

Assigned to Rob

[ Permlink | « Hide ]

Darby Felton - 17/Oct/07 07:49 AM

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.

[ Permlink | « Hide ]

Rob Allen - 18/Oct/07 02:15 AM

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 ?

[ Permlink | « Hide ]

Nico Edtinger - 19/Oct/07 03:35 PM

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.

[ Permlink | « Hide ]

Darby Felton - 19/Oct/07 03:45 PM

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

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.

[ Permlink | « Hide ]

Nico Edtinger - 19/Oct/07 05:02 PM

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.

[ Permlink | « Hide ]

Darby Felton - 07/Nov/07 01:01 PM

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

[ Permlink | « Hide ]

Rob Allen - 15/Nov/07 10:28 AM

Hi Nico,

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

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

[ Permlink | « Hide ]

Rob Allen - 23/Nov/07 05:48 PM

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?

[ Permlink | « Hide ]

Rob Allen - 27/Nov/07 02:51 PM

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

[ Permlink | « Hide ]

Wil Sinclair - 23/Jan/08 03:22 PM

Fixing Fix Version to follow issue tracker conventions.