> by allowing each component 'defaults'
I don't think this is a good idea; Currently there is a discussion on
Sitepoint's PAD about a configuration issue, and posts suggest using
defaults also.
A better solution would be for the container in question (Registry in this
case) to be aware of how to create the required object instead. Obviously
this container would have to be aware of what to create, once called upon,
so you delegate the creation process off to separate Factories.
Therefore a given Factory creates what it needs, and passes it back to the
container, where it's stored for later use if need be. When your container
executes a Factory, it passes an instance of it's self, to the Factory...
Thus the Factory is aware of configuration for example. Here is an example,
// ...
public function get( $classname ) {
if( !array_key_exists( $classname = strtolower(
$classname ), $this ->
registry ) ) {
$constructor = 'create'.$classname;
$this -> registry[$classname] = $this ->
factory -> $constructor( $this
);
}
return $this -> registry[$classname];
}
// a Factory...
final public function createLogger() {
return new QLogger( new QLogger_Assembly( $this,
$this -> cfg['logger']['srce'],
$this -> cfg['logger']['type'] ) );
}
final public function createCfg() {
return $this -> cfg;
}
// ... etc ...
So,
$container = new QContext( new QApplication_Factory( $cfg /* configuration
*/ ) );
// do as you like with it
Hope this helps :)
Simon Mundy wrote:
>
> Hi All
>
> One of the strategies I'd like to see ZF heading toward is the ability
> to pass single Zend_Config container to components in the bootstrap to
> set up an application.
>
> Currently many of the components all a $config->toArray() or similar
> to achieve this, but I think it would be excellent to allow a more
> seamless approach with components recognising a Zend_Config instance
> and then pulling out the specific values. It would create a much more
> organised, lean bootstrap and create better consistency when utilising
> ZF components.
>
> For this work, I'd see the following steps needed:-
>
> * Review the existing 'defaults' proposal by Gavin that partially
> addresses this issue (by allowing each component 'defaults')
> * Compile a list of components that use configs and review their usage
> (E.g. Routes, Mail, Db, Cache... etc.)
> * Some interest by the community for this to happen! :)
> * Draw up a proposal (I'll put up my hand on this)
> * Review documentation and look at a consistent way of documenting
> component config defaults/attributes
>
> I don't think we would need to pass the _whole_ config to each
> component, as this may interfere with developers' naming schemes - it
> would be a matter of identifying individual sections within a config
> and passing them over:-
>
> E.g.
>
> $db = Zend_Db::factory($config->db);
> $cache = Zend_Cache::factory($config->cache);
> $mail = new Zend_Mail($config->myMailSection);
>
> However the 'keys' or 'attributes' within each module would, of
> course, need to adhere to a strict naming scheme. Most components
> already document this in some form or other, but I thought perhaps
> each component's documentation could include a table of attributes at
> the start of their respective sections to make tracking this down
> somewhat easier (as well as an appendix somewhere on the ZF docs).
>
> Any thoughts? It would be nice to fast-track a proposal to see how
> quickly it could be tackled. A slim chance for 1.1 or maybe 1.2?
>
>
> --
>
> Simon Mundy | Director | PEPTOLAB
>
> """ " "" """""" "" "" """"""" " "" """"" " """"" " """""" "" "
> 202/258 Flinders Lane | Melbourne | Victoria | Australia | 3000
> Voice +61 (0) 3 9654 4324 | Mobile 0438 046 061 | Fax +61 (0) 3 9654
> 4124
> http://www.peptolab.com
>
>
>
--
View this message in context:
http://www.nabble.com/Config-driven-framework-components-tf4149276s16154.html#a11844827
Sent from the Zend Framework mailing list archive at Nabble.com.
