ZF Home Page
Issue Tracker
Code Browser
Wiki Dashboard
on the top right of the page you're viewing.
Page Operations
Browse SpaceZend Framework: Zend_Config_Configurable (interface) Component Proposal
| Proposed Component Name | Zend_Config_Configurable (interface) |
|---|---|
| Developer Notes | http://framework.zend.com/wiki/display/ZFDEV/Zend_Config_Configurable (interface) |
| Proposers | Lars Strojny |
| Zend Liaison | Ralph Schindler |
| Revision | 0.1 - 26 December 2007: Initial submission. (wiki revision: 12) |
Table of Contents
1. Overview
Zend_Config_Configurable is an interface indicating configuration facilities of a component. It will unify all components which consume Zend_Config objects for their internal configuration.
2. References
- Inversion of Control Containers and the Dependency Injection pattern (used in examples)
- Repository pattern (used in the examples)
3. Component Requirements, Constraints, and Acceptance Criteria
- This interface will enforce the way components handle configuration
- This interface will unify the way components handle configuration
- This interface allows other Zend components/user defined classes to find out weither an object is configurable
- This interface is implemented by various current classes
- This interface will direct others how to implement configurability with Zend_Config
4. Dependencies on Other Framework Components
- Zend_Config (for type hinting)
- Zend_Db_Adapter_Abstract
- Zend_Layout
- Zend_Filter_Inflector
- Zend_Controller_Router_Rewrite
- Zend_Controller_Router_Route_Interface
- Zend_Controller_Router_Route_Regex
- Zend_Controller_Router_Route_Module
- Zend_Controller_Router_Route_Static
5. Theory of Operation
6. Milestones / Tasks
- Milestone 1: Get feedback
- Milestone 2: Implement interface Zend_Config_Configurable and commit to incubator
- Milestone 3: Edit implementors to handle configurations the way Zend_Config_Configurable enforces it (in incubator)
- Milestone 4: Edit unit test of the implementers
- Milestone 5: Document Zend_Config_Configurable with good examples
7. Class Index
- Zend_Config_Configurable
8. Use Cases
| UC-01 |
|---|
9. Class Skeletons
This is a good improvement i think. I am using some sort of this code at my projects.
Is it possible that a component uses more than one config object, because you used addConfig. If only one i think it would be better to use setConfig instead.
Greetz Tom
Posted by This would be useful in Zend_Build. I'm not that enthused about 'configure' as an factory method name, but that's a minor quibble.
This seems to be a good idea. Ive recently seen similar at Doctrine.
As mentioned by Wil 'configure' can be renamed to 'newInstance' like 'getInstance' at the Singleton pattern, 'setInstance' from the Registry or even 'newInstance' from spl's 'ReflectClass'.
Configuration of components are often very similar, so maybe an abstract class is an alternative.
As I replied to will, I don't mind changing configure() to a better name, while I had the feeling that configure() hits the purpose pretty well. "newInstance()" is a bit too generic, as it does not explain the pre-condition for the instanciation (which is having a configuration object). "getConfigured()" is long and not easy to spot. So, until now I'm just undecided.
btw: can you explain the idea of the abstract class a bit further as I can't imagine how you mean it.
I dont know, if its useful to force a configuration object on configure()/getInstance(). So if the object can be omitted, getInstance() would fit again 
A very simple example
Sry, ive send my post to early
What i want to say: Setting and retrieving of options will be very similar in classes, which implement the interface, so it is possible to solve it in a class, which these classes could extends instead. The example ive posted are really simple. So an idea might be to set an option to a set*-method, if one exists. Or a option is only set, if the key is already found in the options-array. I think, the solutions how the interface would be implemented will be very similar.
Dont know, if im understandable now ^^
Greetz, Sebastian
This is out of scope of this proposal. "Setting and retrieving options" is a more general concept of object configuration, this proposal tries to achieve a generalization of object configuration with Zend_Config objects. As concrete object configuration is a domain specific problem Zend_Config_Configurable is and can be only an interface not an implementation blueprint.
A remark to your example: I think the setProperty($key, $value)/getProperty($key) pattern isn't the best idea as it complicates the API. setPropertySomething($value) is much easier to understand and document.
An abstract class (presumably with default implementations of the interface methods) would probably not be a good idea, since it could break many established class hierarchies. There are plenty of configurable objects that already have parent class that should not be changed.
Of course, if we had mixins, this wouldn't be an issue... 
I think it's a good idea.
I'm also for changing name from configure() to something conveying the factory idea better. Maybe actually configure() is a better name for addConfig()
Thanks. I'm not sure about the idea of replacing addConfig() with configure(). Your are right, it seems more to follow the "describe a decent behaviour"-paradigm, while the Zend Framework often adopts the "object as a datastructure" paradigm. That's why I chose addConfig().
What about a small vote just to give me a more structured feedback. We have two topics, the factory method for retrieving a configured object and the addConfig()/setConfig()-question. So here are the options:
Topic 1 (factory)
- configure(Zend_Config $config)
- getConfigured(Zend_Config $config)
- newInstance(Zend_Config $config)
Topic 2 (set configuration)
- setConfig(Zend_Config $config)
- addConfig(Zend_Config $config)
- configure(Zend_Config $config)
I'll write in getConfigurable() on 1, since that's what you're actually doing. I like configure() to replace addConfig() since add- or setConfig() don't make it clear that the state of the object will likely significantly change. Ultimately, configuring is the important thing that this method does, not really setting the config attribute.
I need something like this for Zend_Build, so I will put it in the Zend_Build component in the hope that you'll be able to get this in to 1.5 and refactor it before the GA. Let me know as soon as you're ready for the core team review.
You have in mind that changing it to configure() would require to break the API for Zend_Layout::setConfig(), Zend_Controller_Router_Rewrite::addConfig() and Zend_Filter_Inflector::setConfig()? I don't care for this but since you have stated that you want to keep the API stable this is maybe an issue.
Sorry, forgot about getConfigurable(). I think this is inappropriate as it seems like it would return an object which is configurable not a configured object what is actually does.
Re: factory method name
getConfiguredInstance() is probably the best choice, but that's a lot of typing. getConfigured() is a good compromise.
Re: set configuration
configure(), definitely. No API break necessary (at least immediately) in Layout or Rewrite Router--just throw an E_USER_NOTICE and return self::configure($configuration); Then remove those methods in 1.7 or 1.8.
My Vote:
1: 2
2: 3
I also think that add or setConfig sounds more than a pure setter for a member variable. Configure() makes clear that something is done with the component. As Wil said already above.
Perhaps one would like to add a more statful component, for that, one wants to add the config object first, without configuring the component and at a later state he wants to trigger configuration of it. So, for that case configure() would be better instead of set/addConfig. I hope you can follow that, since my english is not the best.
I would like to see this in 1.5. Keep up the good work.
Lars, this proposal has lots of community feedback on it, and it may be simple enough to get in to 1.6. Is it ready for recommendation? If so, please move it to that section.
,Wil
 | Zend Official Comment This proposal has been moved back to Ready for Review Since this proposal is attempting to solve a problem that has far and wide reaching consequences, and since we are approaching 1.6 release, we would like to send this proposal back to Ready For Review. The reasoning is such that we can continue discourse on what the best course of action is, as well as ensure we have the time and resources to dedicate to a proposal like this. |
I really like the idea of having a standard interface for configuring objects. However, I don't understand the value of the factory method. What problem is does it solve or benefit does it provide? IMO, we could just drop it, and keep the interface as a nice simple marker for configurable objects, while standardizing the method name. I think the factory just confuses the component's purpose.
Another thing to consider, is that many "configurable" objects in ZF follow a pseudo-standard whereby they accept either an array or a Zend_Config object. IMHO, that is a good practice to preserve, and probably should be reflected in this API.
As for the method name configure() ultimately makes the most sense, but setConfig() is already used and well-understood in the framework.
There are a number of other components which may implement this interface in the future. The web service consumer components, Zend_Cache, Zend_Translate just to name a few.