-- Gary Hockin <
[hidden email]> wrote
(on Tuesday, 26 June 2012, 04:19 PM +0100):
> I understand that constructor options should now be using the Zend\Stdlib\
> Options class, I'm a little bit confused as how this should work.
>
> Say I'm working on creating a Hello World class, and I've already defined the
> Options class as HelloWorldOptions, how do I pass default options in
> the constructor to HelloWorld? Do I pass as an array and HelloWorld then
> creates a HelloWorldOptions class from that array, or am I expected to pass a
> HelloWorldOptions class myself?
This part is a bit confusing from the RFC, TBH, and I've seen both
approaches.
In terms of default options, one of the ideas with the Options RFC is
that by having an Options class, you can extend it to specify default
options, and pass that extension to the component:
class MyOptions extends ComponentOptions
{
protected $foo = 'myfoo'; // new default!
}
$component = new Component(new MyOptions);
Alternately, the Options classes allow you to pass options to their
constructors:
$options = new ComponentOptions(array(
'foo' => 'myfoo',
));
$component = new Component($options);
Typically, it's easier for DI if we can use typehints, so specifying the
base options class to use via a typehint will be easier. However, with
DI being deprecated in favor of using the ServiceManager, this isn't
strictly necessary. That said, anything that makes DI easier is probably
"A Good Idea" (tm). :)
> Secondly, if I want to change an option at runtime, how is that handled? Does
> HelloWorld proxy it's HelloWorldOptions class so I can access the setter
> defined there in the format:
>
> $helloWorld->options->setWorldName('earth');
>
> Or should HelloWorld create it's own setters that allow me to change options.
> If the latter is true, should setWorldName exist in both HelloWorld and
> HelloWorldOptions?
Typically, you should only set options on the options class, and have
the component pull options from that as needed. As such, your first
suggestion is correct -- pull the options class (or use the instance if
you still have it around), and change the options there.
There are a lot of times, however, where changing an option can lead to
volatility within a component -- in such cases, the component should
likely only pull from the options class _once_, during construction, and
not proxy its calls to the options container for such options. As such,
you wouldn't be able to change them. (Good examples include cache
storage adapters, where changing an option may not be possible once a
connection to the cache service is made.)
--
Matthew Weier O'Phinney
Project Lead |
[hidden email]
Zend Framework |
http://framework.zend.com/PGP key:
http://framework.zend.com/zf-matthew-pgp-key.asc
Locked
