DoctrineModule and Options classes.

[SpiffyJr]

As most of you know Doctrine is a highly configurable library and, as such, the module used to integrate it with ZF2 has to be as configurable. The problem I'm currently facing is whether or not to use the Zend\Stdlib\Options class to discretely define options available to each of the service factories. I'll briefly outline the pros/cons as I see them and then humbly request recommendations, concerns, and any other discussion.

Pros:

 - Discretely defined options which can be quickly and easily located.

 - Guaranteed defaults for every option and a *guarantee* that the option is set (vs using isset and potential notices).

 - Self-documenting code. I can comment on the variables and link the options class directly in the documentation.

 - If a user adds a option that is available to Doctrine and it is *not* present in the service option class an exception is thrown indicating that the feature should be implemented (or, they can quickly scan the option class and see if they used an incorrect name for the config variable).

Cons:

 - Adds more classes which, to many, means more "bloat."

For me, the obvious choice is to use Options classes but I wanted to get more of a feel from other contributors before potentially wasting time on a feature that only I view important.

Thanks,

Kyle S

Blog | GitHub | Twitter

"There is a tide in the affairs of men. Which, taken at the flood, leads on to fortune; Omitted, all the voyage of their life Is bound in shallows and in miseries." - WIlliam Shakespeare

[Sascha-Oliver Prolic]

2012/6/14 Kyle S <[hidden email]>:

> As most of you know Doctrine is a highly configurable library and, as such,
> the module used to integrate it with ZF2 has to be as configurable. The
> problem I'm currently facing is whether or not to use the
> Zend\Stdlib\Options class to discretely define options available to each of
> the service factories. I'll briefly outline the pros/cons as I see them and
> then humbly request recommendations, concerns, and any other discussion.
>
> Pros:
>  - Discretely defined options which can be quickly and easily located.
>  - Guaranteed defaults for every option and a *guarantee* that the option is
> set (vs using isset and potential notices).
>  - Self-documenting code. I can comment on the variables and link the
> options class directly in the documentation.
>  - If a user adds a option that is available to Doctrine and it is *not*
> present in the service option class an exception is thrown indicating that
> the feature should be implemented (or, they can quickly scan the option
> class and see if they used an incorrect name for the config variable).
>
> Cons:
>  - Adds more classes which, to many, means more "bloat."
>
> For me, the obvious choice is to use Options classes but I wanted to get
> more of a feel from other contributors before potentially wasting time on a
> feature that only I view important.
>
> Thanks,
>
> Kyle S
> Blog | GitHub | Twitter
>
> "There is a tide in the affairs of men. Which, taken at the flood, leads on
> to fortune; Omitted, all the voyage of their life Is bound in shallows and
> in miseries." - WIlliam Shakespeare
>

I am +1 for Zend\Stdlib\Options usage !

Sasa

--
Sascha-Oliver Prolic

[weierophinney]

-- Kyle S <[hidden email]> wrote
(on Wednesday, 13 June 2012, 10:55 PM -0500):
> Cons:
>  - Adds more classes which, to many, means more "bloat."

In a talk I gave recently, I actually had a bullet point addressing
concerns like this one: get over it. :)

Truly, though -- in 5.4, object creation is no more expensive than
calling a function (and potentially faster). While there may be more
classes, the benefits you outlined clearly outweigh this concern.

--
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

[EvanDotPro]

On Wed, Jun 13, 2012 at 8:55 PM, Kyle S <[hidden email]> wrote:
> Cons:
>  - Adds more classes which, to many, means more "bloat."

Possibly another con: If you have a lot of places (classes) in your
module that need access to configuration values / settings, then you
will end up having to inject this Options class all over the place.
This is currently the case in ZfcUser.

That said, I like the idea of using option classes, and I'd love to
see this work. As stated, there's a lot of advantages to this method.
It also goes along with he options RFC that we approved a while back,
and consistency certainly doesn't hurt.

[Jurian Sluiman-3]

2012/6/15 Evan Coury <[hidden email]>

Possibly another con: If you have a lot of places (classes) in your

module that need access to configuration values / settings, then you
will end up having to inject this Options class all over the place.
This is currently the case in ZfcUser.

You have that either way.

Now you have probably a configuration key in your module.config.php and in every factory, you need to pull the "config" service, get to the appropriate key and inject that config into the service you are instantiating. The new way would be to pull the "zfcuser_options" service and have that injected into the service you are instantiating. Both methods require you in service factories to pull configuration/options and inject them into the service.

The only difference is for the first you need to know the config key for every factory, as for the second you only use the key for your options class and have that factory figure out which config key to use. So for me it's a +1 to use options classes for modules as well, completely in line with options classes for components.

PS. I know ZfcUser works with the "old" static getOoption() class, but afaik ideally you use SM for configuration as well.
--
Jurian Sluiman

[Sascha-Oliver Prolic]

2012/6/15 Jurian Sluiman <[hidden email]>:

> 2012/6/15 Evan Coury <[hidden email]>
>>
>> Possibly another con: If you have a lot of places (classes) in your
>> module that need access to configuration values / settings, then you
>> will end up having to inject this Options class all over the place.
>> This is currently the case in ZfcUser.
>
>
> You have that either way.
>
> Now you have probably a configuration key in your module.config.php and in
> every factory, you need to pull the "config" service, get to the appropriate
> key and inject that config into the service you are instantiating. The new
> way would be to pull the "zfcuser_options" service and have that injected
> into the service you are instantiating. Both methods require you in service
> factories to pull configuration/options and inject them into the service.
>
> The only difference is for the first you need to know the config key for
> every factory, as for the second you only use the key for your options class
> and have that factory figure out which config key to use. So for me it's a
> +1 to use options classes for modules as well, completely in line with
> options classes for components.
>
> PS. I know ZfcUser works with the "old" static getOoption() class, but afaik
> ideally you use SM for configuration as well.
> --
> Jurian Sluiman

Agree with Jurian,

the options class should _only_ be used in service manager, so you get
configured services back. I don't want to see these options classes in
the service layer. services should be correctly configured, and should
not have a dependency on any options class. this is the reponsibility
of the service manager.

Sascha

--
Sascha-Oliver Prolic

[weierophinney]

-- Sascha-Oliver Prolic <[hidden email]> wrote
(on Friday, 15 June 2012, 03:47 PM +0200):

> 2012/6/15 Jurian Sluiman <[hidden email]>:
> > 2012/6/15 Evan Coury <[hidden email]>
> > > Possibly another con: If you have a lot of places (classes) in your
> > > module that need access to configuration values / settings, then you
> > > will end up having to inject this Options class all over the place.
> > > This is currently the case in ZfcUser.
> >
> >
> > You have that either way.
> >
> > Now you have probably a configuration key in your module.config.php and in
> > every factory, you need to pull the "config" service, get to the appropriate
> > key and inject that config into the service you are instantiating. The new
> > way would be to pull the "zfcuser_options" service and have that injected
> > into the service you are instantiating. Both methods require you in service
> > factories to pull configuration/options and inject them into the service.
> >
> > The only difference is for the first you need to know the config key for
> > every factory, as for the second you only use the key for your options class
> > and have that factory figure out which config key to use. So for me it's a
> > +1 to use options classes for modules as well, completely in line with
> > options classes for components.
>
> Agree with Jurian,
>
> the options class should _only_ be used in service manager, so you get
> configured services back. I don't want to see these options classes in
> the service layer. services should be correctly configured, and should
> not have a dependency on any options class. this is the reponsibility
> of the service manager.

I disagree. The Options classes are provided for a variety of purposes:

 * Eliminate a lot of boilerplate accessors and mutators surrounding
   configuration; this allows classes to focus on the functionality, not
   the configuration.

 * Validate and normalize options to ensure they can actually be
   consumed by the consuming class.

 * Provide default values. (This means you can also extend options
   classes to provide alternate or context-specific defaults.)

These are not something the SM should be doing. The service manager and
factories are really about wiring objects -- injecting configuration
and dependencies, etc, but not necessarily validating them.

--
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

[Sascha-Oliver Prolic]

2012/6/15 Matthew Weier O'Phinney <[hidden email]>:

> -- Sascha-Oliver Prolic <[hidden email]> wrote
> (on Friday, 15 June 2012, 03:47 PM +0200):
>> 2012/6/15 Jurian Sluiman <[hidden email]>:
>> > 2012/6/15 Evan Coury <[hidden email]>
>> > > Possibly another con: If you have a lot of places (classes) in your
>> > > module that need access to configuration values / settings, then you
>> > > will end up having to inject this Options class all over the place.
>> > > This is currently the case in ZfcUser.
>> >
>> >
>> > You have that either way.
>> >
>> > Now you have probably a configuration key in your module.config.php and in
>> > every factory, you need to pull the "config" service, get to the appropriate
>> > key and inject that config into the service you are instantiating. The new
>> > way would be to pull the "zfcuser_options" service and have that injected
>> > into the service you are instantiating. Both methods require you in service
>> > factories to pull configuration/options and inject them into the service.
>> >
>> > The only difference is for the first you need to know the config key for
>> > every factory, as for the second you only use the key for your options class
>> > and have that factory figure out which config key to use. So for me it's a
>> > +1 to use options classes for modules as well, completely in line with
>> > options classes for components.
>>
>> Agree with Jurian,
>>
>> the options class should _only_ be used in service manager, so you get
>> configured services back. I don't want to see these options classes in
>> the service layer. services should be correctly configured, and should
>> not have a dependency on any options class. this is the reponsibility
>> of the service manager.
>
> I disagree. The Options classes are provided for a variety of purposes:
>
>  * Eliminate a lot of boilerplate accessors and mutators surrounding
>   configuration; this allows classes to focus on the functionality, not
>   the configuration.
>
>  * Validate and normalize options to ensure they can actually be
>   consumed by the consuming class.
>
>  * Provide default values. (This means you can also extend options
>   classes to provide alternate or context-specific defaults.)
>
> These are not something the SM should be doing. The service manager and
> factories are really about wiring objects -- injecting configuration
> and dependencies, etc, but not necessarily validating them.
>
> --
> 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

Hi Matthew,

probably my last post was kind of confusing for some. I am not against
options classes. I just don't want a module's options class, like
"public static function ZfcUser\Module::getOption($option)" and let
this one flying around all other classes in that module.

--
Sascha-Oliver Prolic