Zend\ServiceManager\Factory\FactoryInterface does not use Psr\Container\ContainerInterface yet

[RalfEggert]

I want to make my factories to use Psr\Container\ContainerInterface in an Zend\Expressive project. But the Zend\ServiceManager\Factory\FactoryInterface does not use Psr\Container\ContainerInterface yet.

What are the plans about this?

[kynx]

psr-11.md says this is coming in v4. Makes sense - it's a BC break - but an over-eager search-and-replace at work broke lots of stuff for me ;)

[RalfEggert]

Ok, then I guess this should include a warning:

http://zendframework.github.io/zend-expressive/reference/migration/to-v2/#psr-11-support

[RalfEggert]

Added an issue for Zend\Expressive : zendframework/zend-expressive#466

[asgrim]

Note; probably an assumption (at least on my side) but I'd expect DelegatorFactoryInterface and AbstractFactoryInterface should be updated to use Psr\Container\* at the same time as this.

[weierophinney]

Just a couple notes:

• We pin to a version of container-interop that extends the official PSR-11 interfaces.
• zend-servicemanager v3 pins to container-interop, as it pre-dates the completion of PSR-11.
• zend-servicemanager allows arbitrary callables for factories and delegators, so long as they have the minimum required arguments (a factory requires a container; delegators require a container, the service name, and a callback). The arguments do not need to follow the same typehints, however, which means they can typehint against the PSR-11 interface. (This is true for initializers as well, but you should NEVER use those.)
• Abstract factories are the only ones in wide use in Expressive that do not fit this paradigm, as we require an interface implementation; this is due to the additional method for testing if the factory can create an instance of the requested service.

Thus, the migration path is to:

• remove implementation of zend-servicemanager interfaces in your factories and delegators.
• change ContainerInterface imports to use PSR-11 in those classes.

When it comes to abstract factories, I'd argue you should likely try not to use them. They are one of the configuration types that are non-portable between different containers. Consider using the expressive factory:create tool for each class that you were previously using an abstract factory for, or, alternately, mapping each class that can be served by the abstract factory directly to it as a factory (as the implementations we directly support all accept the service name argument to the factory).

zend-servicemanager v4 will implement PSR-11 directly, and the various interfaces consuming a container will typehint against it as well. Most likely, we will allow v4 within Expressive as well as v3 once it is released, as the consumer aspects will be the same. (That said, we may do something different with aliases and invokables for v4; if we do, we'll have a v3 minor release that provides forwards compatibility, just as we did when prepping v3.)

[holtkamp]

Encountered this as well when trying to use PHP-DI as a DIC. PHP-DI already uses PSR-11, while https://github.com/zendframework/zend-servicemanager/blob/release-2.7.11/src/AbstractPluginManager.php#L12 does not, causing an error.

zend-servicemanager v4 will implement PSR-11 directly, and the various interfaces consuming a container will typehint against it as well.

This should do the trick, any plans for v4 already? It seems the development branch is not yet migrated to using PSR-11...

https://github.com/zendframework/zend-servicemanager/blob/dev-4.0/src/AbstractPluginManager.php#L10

See elie29/zend-di-config#25 for a complete description

[thomasvargiu]

@holtkamp if you need compatibility with libraries that still use Interop Container you can decorate your PSR container:

<?php

declare(strict_types=1);

namespace App;

use Interop\Container\ContainerInterface;
use Psr\Container\ContainerInterface as PsrContainer;

class InteropContainerDecorator implements ContainerInterface
{
    /** @var PsrContainer */
    private $container;

    public function __construct(PsrContainer $container)
    {
        $this->container = $container;
    }

    public function get($id)
    {
        return $this->container->get($id);
    }
    
    public function has($id)
    {
        return $this->container->has($id);
    }
}

And register it as with a factory:

return [
    'dependencies' => [
        'aliases' => [
            \Interop\Container\ContainerInterface::class => \App\InteropContainerDecorator::class,
        ],
    ],
];

[holtkamp]

Thanks for the suggestions, tried a bit and this seems not to work.

Apparently Zend\Expressive\ZendView\HelperPluginManagerFactory::__construct() already adopted PSR-11 and therefore injects a Psr\Container\ContainerInterface instance, while ZendServiceManager does not.

Array
(
    [type] => 1
    [message] => Uncaught Zend\ServiceManager\Exception\InvalidArgumentException: Zend\ServiceManager\AbstractPluginManager expects a ConfigInterface or ContainerInterface instance as the first argument; received DI\Container in /user/project/vendor/zendframework/zend-servicemanager/src/AbstractPluginManager.php:59
Stack trace:
#0 /user/project/vendor/zendframework/zend-view/src/HelperPluginManager.php(253): Zend\ServiceManager\AbstractPluginManager->__construct(Object(DI\Container), Array)
#1 /user/project/vendor/zendframework/zend-expressive-zendviewrenderer/src/HelperPluginManagerFactory.php(20): Zend\View\HelperPluginManager->__construct(Object(DI\Container))
#2 [internal function]: Zend\Expressive\ZendView\HelperPluginManagerFactory->__invoke(Object(DI\Container))
#3 /user/project/vendor/p
    [file] => /user/project/vendor/zendframework/zend-servicemanager/src/AbstractPluginManager.php
    [line] => 59
)

For now using an fork of DI\Container which ALSO implements \Interop\Container\ContainerInterface does the "trick" / hack.

class Container implements \Psr\Container\ContainerInterface, \Interop\Container\ContainerInterface, FactoryInterface, InvokerInterface {
 /* rest of code */
}

A minor new release of ZendServiceManager which also accepts a PSR-11 container would be nice.

[thomasvargiu]

Oh, you're right. I think the bug is here Because HelperPluginManagerFactory is accepting a PSR container and injecting it to the HelperPluginManager which can accept only the Interop container.

So, you can use zend-view HelperPluginManager only with zend-servicemanager.

The only thing you can do at this moment is to try to use the decorated container and create your factory to instantiate the HelperPluginManager.

[elie29]

You can add in the container an alias from interop container to Psr container without the need of decorator.

[thomasvargiu]

@elie29 with PHP-DI 6.0 the container only implements the Psr container, while zend-view and other services (zend-hydrator for me) requires the interop container. Just an alias is not enough.

The decorator allowed me to use an interop container for factories that requires an interop container, but in this case I think is more a bug of zend-expressive-zendviewrenderer which its factory use a psr container but inject it to a service that requires a interop container.

[holtkamp]

@thomasvargiu thanks for the effort and ideas!

@elie29 yeah, tried that in dependencies.global.php of the skeleton Zend Expressive application:

'aliases' => [
            // Fully\Qualified\ClassOrInterfaceName::class => Fully\Qualified\ClassName::class,
            //\Interop\Container\ContainerInterface::class => \Psr\Container\ContainerInterface::class,
            \Psr\Container\ContainerInterface::class => \Interop\Container\ContainerInterface::class,
        ],

Hower it seems that Zend\Expressive\ZendView\HelperPluginManagerFactory is instantiated at the moment that the DI Container is being assembled / built by the DI ContainerBuilder => at that time the alias is not available yet...

What did function is to use the PHP-DI ContainerBuilder->wrapContainer() functionality and use the InteropContainerDecorator:

namespace Zend\DI\Config;

use App\InteropContainerDecorator;
use DI\ContainerBuilder;
use Psr\Container\ContainerInterface;
use Zend\DI\Config\ConfigInterface;

class ContainerFactory
{

    public function __invoke(ConfigInterface $config): ContainerInterface
    {
        $builder = new ContainerBuilder();
        $config->configureContainer($builder);

        $wrapperContainer = new InteropContainerDecorator();
        $builder->wrapContainer($wrapperContainer);

        $psrContainer = $builder->build();

        $wrapperContainer->setPsrContainer($psrContainer);

        return $wrapperContainer;
    }
}

But that is quite specific to https://github.com/elie29/zend-di-config, I think for now I should leave this and wait for a update to ZendServiceManager to actually use PSR-11.

[elie29]

You can kick off the container in the front controller so it is ready before other dependencies. However, phpdi is Psr compliant but not interop. So we need to wait for zend service v4