> > This is more or less how you see the setOptions() implementation in a few > classes currently. The idea that you proxy the key to a mutator (setter) > setSomething($value) method. >
Yep, except it's in one place instead of several with tiny variations. And it works with static setters. -Matt On Fri, Jan 16, 2009 at 9:12 AM, Ralph Schindler <[email protected]>wrote: > > > The primary problem with configuration in Zend Framework is that > configuration > > is left up to each class and so each class handles it differently. The > > primary problem with PHP is lack of mixins, which would elegantly solve > the > > first problem. I solved the issue at my job like this: > > > The initial problem is that each class solves the configuration without any > regard to how other components solve the configuration issue (the common > convention). This thus creates a somewhat ambiguous API. I think one of > the stories I'd like to see told with ZF2 is more one of API consistency, > fewer statics, and those statics that are used are part of an acceptable > list of static usages... All for the purpose of keeping things consistent. > > > > public static function setConfig($caller, $config, $section = null) > > { > > $config = self::getOptionsFromConfig($config, $section); > > > > foreach ($config as $option => $value) { > > $method = 'set' . ucfirst($option); > > > > if (method_exists($caller, $method)) { > > if ($value instanceof Zend_Config) { > > $value = $value->toArray(); > > } > > > > if (is_object($caller)) { > > $caller->$method($value); > > } else { > > call_user_func(array($caller, $method), $value); > > } > > } > > } > > > > return $config; > > } > > > This is more or less how you see the setOptions() implementation in a few > classes currently. The idea that you proxy the key to a mutator (setter) > setSomething($value) method. > > > > This is a pretty flexible approach that allows instance or static method > calls > > on the caller and does not distinguish between Zend_Config objects and > arrays. > > In my experience there is no practical benefit, and some drawbacks, to > > distinguishing between separate setConfig() and setOptions() methods. If > you > > must store the configuration in the object, for example to allow a > generic > > getOption($optionName) method, the logic is still off-loaded to the other > > class. > > > > > The major difference I think Matthew W.O. Was trying to demonstrate is that > those methods have different signatures: > > Public function setConfig(Zend_Config $config); > Public function setOptions(Array $options); > > This creates a very loose coupling on Zend_Config for instances where one > would like to use Zend_Config. In other cases, an associative array is just > fine. > > -ralph > > -- > Ralph Schindler > Software Engineer | [email protected] > Zend Framework | http://framework.zend.com/ >
