ZF2beta5 + injections

[Eugene Poleacov]

Hi.
I try to start on my project based on ZF2beta5 and DoctrineMongoODMModule.
And i was afflicted when i could not inject 'doctrine.documentmanager.odm_default' alias inside of my custom class by ZF2 configuration:
 'di' => array(
        'instance' => array(
            'aliases'=> array(
                'model' => 'MyApp\Model\Model1',
            ),
            'model' => array(
                'parameters' => array(
                    'dm'=>'doctrine.documentmanager.odm_default',
                )
            ),
        )
    )

In previous versions of ZF2 and DoctrineMongoODMModule that was worked perfect, what happens now?
And how i can do that by config using only?

[cmple]

try this:

<?php
return array(
        'service_manager' => array(
                'factories' => array(
                        'model' => function($serviceManager){
                                $parameters = array(
                                        'dm' => 'doctrine.documentmanager.odm_default'
                                );
                                return new MyApp\Model\Model1($parameters);
                        },
                ),
        ),
);


MyApp\Controller\MyController:
$model = $this->getServiceLocator()->get('model');

[Marco Pivetta]

It should actually work, and even with just `Doctrine\ODM\MongoDB\DocumentManager` (no need for the custom key). Can you please share your code?
Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    

On 14 July 2012 17:27, cmple [via Zend Framework Community] <[hidden email]> wrote:

try this:

<?php
return array(
        'service_manager' => array(
                'factories' => array(
                        'model' => function($serviceManager){
                                $parameters = array(
                                        'dm' => 'doctrine.documentmanager.odm_default'
                                );
                                return new MyApp\Model\Model1($parameters);
                        },
                ),
        ),
);


MyApp\Controller\MyController:
$model = $this->getServiceLocator()->get('model');

---

If you reply to this email, your message will be added to the discussion below:

http://zend-framework-community.634137.n4.nabble.com/ZF2beta5-injections-tp4655776p4655777.html

To unsubscribe from Zend Framework Community, click here.
NAML

[Eugene Poleacov]

Hi Marco.
Sorry for late answer.

So i have next config:
https://gist.github.com/3177507
and next PageController source:
https://gist.github.com/3177529
but i take next exception, for both controllers 'page' and 'banner':
PHP Catchable fatal error:  Argument 1 passed to Blog\\Controller\\BannerController::__construct() must be an instance of Blog\\Model\\Banner, none given,

Actually i'm little bit confused with current version of config.
But anyway i want to understand how to do that right.

[Eugene Poleacov]

Eugene Poleacov wrote

Hi Marco.
Sorry for late answer.

So i have next config:
https://gist.github.com/3177507
and next PageController source:
https://gist.github.com/3177529
but i take next exception, for both controllers 'page' and 'banner':
PHP Catchable fatal error:  Argument 1 passed to Blog\\Controller\\BannerController::__construct() must be an instance of Blog\\Model\\Banner, none given,

Actually i'm little bit confused with current version of config.
But anyway i want to understand how to do that right.

How i see that's impossible, because invokables classes created without parameters.
I tried with aliases and same fail result, I don't know yet why, but when ServiceManager want to create controller from aliases, he hasn't aliases at all.

[Eugene Poleacov]

It seems a bug in RC1.
$controllerLoader = $application->getServiceManager()->get('ControllerLoader');
$controlelrLoader - has instance with empty configuration by default, and could not create controllers from aliases.

Or i'm wrong and that required additional configs?
But actually nothing said in docs about that.

[dlu-gs]

Hi, I think my blog post called Getting dependencies into ZF2 controllers should help you out. If your controller has constructor parameters, you have to configure it in your Module class in the getControllerConfig() method. Please see the blog post, there is a code snippet demonstrating exactly this.

[Marco Pivetta]

@David This is a bit messy... At least until the API of the project isn't stable, working with Di can be a big advantage in my opinion.

@Eugene: Can you try with simple dependencies first? Such as `public function __construct(\stdClass $something){}`?
It may be that a dependency cannot be resolved for your model (and the model should NOT come from a DIC/Factory!)
Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    

On 26 July 2012 09:53, dlu-gs [via Zend Framework Community] <[hidden email]> wrote:

Hi, I think my blog post called Getting dependencies into ZF2 controllers should help you out. If your controller has constructor parameters, you have to configure it in your Module class in the getControllerConfig() method. Please see the blog post, there is a code snippet demonstrating exactly this.

David Lukas (dlu-gs)
www.zfdaily.com

---

If you reply to this email, your message will be added to the discussion below:

http://zend-framework-community.634137.n4.nabble.com/ZF2beta5-injections-tp4655776p4655933.html

To unsubscribe from Zend Framework Community, click here.
NAML

[Eugene Poleacov]

@David:
Thank your for reply. But by RFC i think i could use ServiceManager aliases for setup controllers instances without php code support from Module.php (actually that worked fine before). Anyway by php i can do anything of course, but that's not goal of ZF2 ServiceManager. :)

@Marco:
I will try thanks.
Also ControllerManager used Zend\ServiceManager\ConfigurationInterface as typehint of constructor parameter, but it was renamed to Zend\ServiceManager\ConfigInterface, that's can be a problem (bug in RC1).

[dlu-gs]

@Marco: What's messy? I thought working with SM is preferred to DI (ZF2 itself uses SM heavily and I think exclusively). And please what API are you talking about? Do I understand correctly that you discourage (for the time being) usage of SM for controller configuration?

Marco Pivetta wrote

@David This is a bit messy... At least until the API of the project isn't
stable, working with Di can be a big advantage in my opinion.

[Marco Pivetta]

No, I don't discourage use of SM, but in my case I need to change controller constructors, setters, getters, service dependencies, oh my! (and this multiplied per number of controllers and number of services!)

So what I basically do is having good IOC principles and Di. That works and gives me enough during development. Once I'm ready to get things freezed, I can write everything as factories.

Btw, the controller loader uses Di when SM can't do. Di is kept as a fallback because of its obvious performance drawbacks (which are anyway solved if you use my compiler).

Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    

On 26 July 2012 11:03, dlu-gs [via Zend Framework Community] <[hidden email]> wrote:

@Marco: What's messy? I thought working with SM is preferred to DI (ZF2 itself uses SM heavily and I think exclusively). And please what API are you talking about? Do I understand correctly that you discourage (for the time being) usage of SM for controller configuration?

Marco Pivetta wrote

@David This is a bit messy... At least until the API of the project isn't
stable, working with Di can be a big advantage in my opinion.

David Lukas (dlu-gs)
www.zfdaily.com

---

If you reply to this email, your message will be added to the discussion below:

http://zend-framework-community.634137.n4.nabble.com/ZF2beta5-injections-tp4655776p4655936.html

To unsubscribe from Zend Framework Community, click here.
NAML

[Eugene Poleacov]

Actually i'm agree with Marco.
I'm just waiting from ZF2 what Marco described.
And i'm was confused when this thing doesn't works in my project based on ZF2RC1.

Yeah of course ZF2 should be flexible and support many solutions, but IOC by simple config + autowiring required as well.

Marco Pivetta wrote

No, I don't discourage use of SM, but in my case I need to change
controller constructors, setters, getters, service dependencies, oh my!
(and this multiplied per number of controllers and number of services!)

So what I basically do is having good IOC principles and Di. That works and
gives me enough during development. Once I'm ready to get things freezed, I
can write everything as factories.

Btw, the controller loader uses Di when SM can't do. Di is kept as a
fallback because of its obvious performance drawbacks (which are anyway
solved if you use my compiler).

Marco Pivetta

http://twitter.com/Ocramius

http://marco-pivetta.com



On 26 July 2012 11:03, dlu-gs [via Zend Framework Community] <
[hidden email]> wrote:

> @Marco: What's messy? I thought working with SM is preferred to DI (ZF2
> itself uses SM heavily and I think exclusively). And please what API are
> you talking about? Do I understand correctly that you discourage (for the
> time being) usage of SM for controller configuration?
>
> Marco Pivetta wrote
> @David This is a bit messy... At least until the API of the project isn't
> stable, working with Di can be a big advantage in my opinion.
>
>  David Lukas (dlu-gs)
> www.zfdaily.com
>
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://zend-framework-community.634137.n4.nabble.com/ZF2beta5-injections-tp4655776p4655936.html
>  To unsubscribe from Zend Framework Community, click here<http://zend-framework-community.634137.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=634137&code=b2NyYW1pdXNAZ21haWwuY29tfDYzNDEzN3wxNzE0OTI1MTk4>
> .
> NAML<http://zend-framework-community.634137.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>

[dlu-gs]

@Eugene: SM won't resolve the dependencies automagically for you (THAT is not the goal of the SM) and SM aliases won't help you with this either. If that's what you want, you will really have to use the DiC. If the constructor of your class requires a parameter, you will have to configure the SM *by hand* somewhere (i.e. you will have to use PHP code and not a pure configuration) to create an instance of this class with a specific parameter. Do you want convenience and magic or speed? Your call :)

Could you provide a link to the RFC you are talking about? SM configuration is described here:
http://packages.zendframework.com/docs/latest/manual/en/modules/zend.service.manager.quick.start.html
And as for the controller configuration, please read Evan's PR#1695 comments here:
https://github.com/zendframework/zf2/pull/1695

Eugene Poleacov wrote

@David:
Thank your for reply. But by RFC i think i could use ServiceManager aliases for setup controllers instances without php code support from Module.php (actually that worked fine before). Anyway by php i can do anything of course, but that's not goal of ZF2 ServiceManager. :)

[Marco Pivetta]

Eugene, could you possibly share your current exception in a gist? Looks like you're instantiating via SM instead of DIC

Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    

On 26 July 2012 11:31, dlu-gs [via Zend Framework Community] <[hidden email]> wrote:

@Eugene: SM won't resolve the dependencies automagically for you (THAT is not the goal of the SM) and SM aliases won't help you with this either. If that's what you want, you will really have to use the DiC. If the constructor of your class requires a parameter, you will have to configure the SM *by hand* somewhere (i.e. you will have to use PHP code and not a pure configuration) to create an instance of this class with a specific parameter. Do you want convenience and magic or speed? Your call :)

Could you provide a link to the RFC you are talking about? SM configuration is described here:
http://packages.zendframework.com/docs/latest/manual/en/modules/zend.service.manager.quick.start.html
And as for the controller configuration, please read Evan's PR#1695 comments here:
https://github.com/zendframework/zf2/pull/1695

Eugene Poleacov wrote

@David:
Thank your for reply. But by RFC i think i could use ServiceManager aliases for setup controllers instances without php code support from Module.php (actually that worked fine before). Anyway by php i can do anything of course, but that's not goal of ZF2 ServiceManager. :)

David Lukas (dlu-gs)
www.zfdaily.com

---

If you reply to this email, your message will be added to the discussion below:

http://zend-framework-community.634137.n4.nabble.com/ZF2beta5-injections-tp4655776p4655940.html

To unsubscribe from Zend Framework Community, click here.
NAML

[Eugene Poleacov]

@David:
@Marco:
Seems i'm was wrong. Yeah i'm used SM for autowiring.
But could you explain in short words, what's goal of SM if i can't create instance with many dependencies by config using him?

Why was included service manager if DI make same things?

[dlu-gs]

@Marco: Ahh, now it makes sense! That's of course a good use of the DiC (development). I thought you were refering to the controller configuration via SM, when you said it was messy, and about some ZF2 API, when you said it was unstable. Silly me :)

Marco Pivetta wrote

No, I don't discourage use of SM, but in my case I need to change
controller constructors, setters, getters, service dependencies, oh my!
(and this multiplied per number of controllers and number of services!)

So what I basically do is having good IOC principles and Di. That works and
gives me enough during development. Once I'm ready to get things freezed, I
can write everything as factories.

Btw, the controller loader uses Di when SM can't do. Di is kept as a
fallback because of its obvious performance drawbacks (which are anyway
solved if you use my compiler).

[Marco Pivetta]

ServiceManager was included for three main reasons:

1 - flexibility - When your model becomes complex, or not DIC friendly, you need to override Zend\Di, thus you end up with a closure/factory. That's also where I still use SM over Di in those cases where things get tricky.
2 - security - Di allows instantiating ANYTHING. So this becomes threatening when your routing configuration allows any user to ask for a (silly example) `DeleteAllFilesClassWithStupidConstructor`, or `ReGenerateDatabaseClassWithStupidConstructor`.
3 - speed - Di is slow. This has been solved with OcraDiCompiler, but at the time the Di -> SM move was made, Di was really a problem (can't wait 500msecs for an instance of EntityManager!).

Does that clear it?
Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    

On 26 July 2012 11:44, Eugene Poleacov [via Zend Framework Community] <[hidden email]> wrote:

@David:
@Marco:
Seems i'm was wrong. Yeah i'm used SM for autowiring.
Bu could you explain in short words, what's goal of SM if i can't create instance with many dependencies by config using his?

Why was included service manager if DI make same things?

http://github.com/zendmaniacs

---

If you reply to this email, your message will be added to the discussion below:

http://zend-framework-community.634137.n4.nabble.com/ZF2beta5-injections-tp4655776p4655943.html

To unsubscribe from Zend Framework Community, click here.
NAML

[Eugene Poleacov]

@Marco:
Yeah, everything is clear now.

@David:
@Marco:
Thank you very much for discussion and helpful messages.

Marco Pivetta wrote

ServiceManager was included for three main reasons:

1 - flexibility - When your model becomes complex, or not DIC friendly, you
need to override Zend\Di, thus you end up with a closure/factory. That's
also where I still use SM over Di in those cases where things get tricky.
2 - security - Di allows instantiating ANYTHING. So this becomes
threatening when your routing configuration allows any user to ask for a
(silly example) `DeleteAllFilesClassWithStupidConstructor`, or
`ReGenerateDatabaseClassWithStupidConstructor`.
3 - speed - Di is slow. This has been solved with OcraDiCompiler, but at
the time the Di -> SM move was made, Di was really a problem (can't wait
500msecs for an instance of EntityManager!).

Does that clear it?
Marco Pivetta

http://twitter.com/Ocramius

http://marco-pivetta.com



On 26 July 2012 11:44, Eugene Poleacov [via Zend Framework Community] <
[hidden email]> wrote:

> @David:
> @Marco:
> Seems i'm was wrong. Yeah i'm used SM for autowiring.
> Bu could you explain in short words, what's goal of SM if i can't create
> instance with many dependencies by config using his?
>
> Why was included service manager if DI make same things?
> http://github.com/zendmaniacs
>
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://zend-framework-community.634137.n4.nabble.com/ZF2beta5-injections-tp4655776p4655943.html
>  To unsubscribe from Zend Framework Community, click here<http://zend-framework-community.634137.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=634137&code=b2NyYW1pdXNAZ21haWwuY29tfDYzNDEzN3wxNzE0OTI1MTk4>
> .
> NAML<http://zend-framework-community.634137.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>

[dlu-gs]

You can also view the difference between DiC and SM as DiC being smart and slow whereas SM is dumb and fast.

DiC goes and sniffs aroung your codebase and tries to figure out how your classes fit together, so it's generaly able to give you back instances although you haven't told it explicitly how to construct them. It just knows. You pay for this with processing power of course.

SM won't give you back anything you haven't previously explicitly put in it (save for the default fallback to DI of course). But it does it damn quick.

If you are unsure which way to go (at least in production), take a hint from ZF2 itself. Guess which of the two it uses internally? :)

Eugene Poleacov wrote

@David:
@Marco:
Seems i'm was wrong. Yeah i'm used SM for autowiring.
But could you explain in short words, what's goal of SM if i can't create instance with many dependencies by config using him?

Why was included service manager if DI make same things?

[Marco Pivetta]

Just because the default Mvc application does use SM because of a performance issue doesn't mean using Di is wrong. As said, my current process involves using Di until I need to deploy :)

Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    

On 26 July 2012 12:27, dlu-gs [via Zend Framework Community] <[hidden email]> wrote:

You can also view the difference between DiC and SM as DiC being smart and slow whereas SM is dumb and fast.

DiC goes and sniffs aroung your codebase and tries to figure out how your classes fit together, so it's generaly able to give you back instances although you haven't told it explicitly how to construct them. It just knows. You pay for this with processing power of course.

SM won't give you back anything you haven't previously explicitly put in it (save for the default fallback to DI of course). But it does it damn quick.

If you are unsure which way to go (at least in production), take a hint from ZF2 itself. Guess which of the two it uses internally? :)

Eugene Poleacov wrote

@David:
@Marco:
Seems i'm was wrong. Yeah i'm used SM for autowiring.

But could you explain in short words, what's goal of SM if i can't create instance with many dependencies by config using him?

Why was included service manager if DI make same things?

David Lukas (dlu-gs)
www.zfdaily.com

---

If you reply to this email, your message will be added to the discussion below:

http://zend-framework-community.634137.n4.nabble.com/ZF2beta5-injections-tp4655776p4655947.html

To unsubscribe from Zend Framework Community, click here.
NAML