> 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     | ralph.schind...@zend.com
Zend Framework        | http://framework.zend.com/


Reply via email to