> -----Original Message-----
> From: Ralph Schindler [mailto:[EMAIL PROTECTED]
> Having a zendframework.ini that components globally
> know about introduces coupling (at the component level) that
> I simply cannot agree with.
I agree with you Ralph, I am not sure I agree with a "defaults"
mechanism. We already have support for configuration files, and a
config object can be stored in the registry.
One of the goals of ZF is to avoid creating multiple solutions for the
same task. I do understand the difference between defaults versus
config applied to a given object instance, but still the difference is
subtle enough that it's hard to articulate why a defaults mechanism
would exist in addition to the Config+Registry mechanism.
I also dislike Zend_Db::factory() (that is, absence of args means that
it uses the defaults). Put yourself in the position of a programmer
taking over responsibility for code written in this way. How do you
know where the factory's args are defined? How do you debug (you can't
var_dump the args to the factory because they exist somewhere else in
the app)? How do you know if it's safe to change a value in the
defaults, without breaking someone else's app?
> I'd like to see methods (determined on a component by
> component basis) implement
>
> Zend_Component::[\w]Config[\w](Zend_Config $config)
>
> type methods that can be used at will.
That's a good idea, but there are a few cases where it gets complicated.
For instance in Zend_Db, some config options must be specified at the
time the database connection object is instantiated. I'm sure there are
other cases too. What should a component do if config parameters are
given at a time later than they can be used? Ignore them? Throw an
exception?
I do see a benefit in allowing a Zend_Config object to be passed as an
argument in place of options arrays. Then you could do any of the
following:
// current behavior: specifying literals
$db = Zend_Db::factory('mysqli', array(...));
// current behavior: specifying values from config
$db = Zend_Db::factory($config->db->adapter,
$config->db->options->toArray());
// new behavior: factory knows how to recognize Zend_Config object
$db = Zend_Db::factory($config->db);
The factory and constructor methods of individual components would need
to define some names of config elements, but this is no different and no
more difficult than defining names of keys in the $options arrays.
And I think we should make sure that no components require a Config
object. It's a good feature that distinguishes ZF from other frameworks
that it does not require configuration files. So anything you can
specify with a Config object must be specifiable with traditional
arguments, as in the Zend_Db::factory() example above.
Regards,
Bill Karwin
