aimfeld / zenddicompiler Goto Github PK

In php 7, type errors are thrown. These should be caught and a code-rescan should be triggered to re-generate the GeneratedServiceLocator.

• Zend\Mvc\MvcEvent
• Zend\Mvc\Application
• Zend\ServiceManager\ServiceManager
• Zend\EventManager\EventManager

These services can then be constructor injected in every class created by di-wrapper.

Code scanning should report problems and list classes for which no factory method could be generated and why.

There should be no writes in the module directory: http://framework.zend.com/manual/2.1/en/modules/zend.module-manager.best-practices.html

It would be nice to get information about component dependencies. I.e. which components inject which classes of other components. This helps with software design and helps layering components.

I found your package from a Stack Overflow comment of yours. I like the idea, and thought I would try to use it... but alas, not possible. It appears your library actually requires zend-mvc, as well as zend-servicemanager.

I've building an application that's very, very slim. And I'm being extremely limited as to what I import. I can't import the entire zend-mvc stack, I'm afraid.

Can you update your composer.json to mention these dependencies? I would have passed this up if I had noticed it required zend-event and zend-mvc (and what ever else...)

Thanks,

Setter injection is not supported yet. Neither is interface injection. The default introspection strategy only supports constructor injection. Supporting setter injection should be feasible, though.

GlobalEventManager is deprecated as uf ZF 2.5.3 and should be replaced here by $application->getEventManager()

When using the DICompiler, my ServiceManager throws a fatal because of:

An abstract factory could not create an instance of zendviewstrategyjsonstrategy(alias: Zend\View\Strategy\JsonStrategy

Without the DI compiler everything works fine. The strategy is registered here:

    'view_manager' => array(
        'strategies' => array(
            'Zend\View\Strategy\JsonStrategy',
            'Ui\Strategy\PhpRendererStrategy'
        )
    ),

When I remove the strategy the next strategy fails. When I remove the PhpRendererStrategy, some other service fails (with the same exception).

In my application.config.php, ZendDiCompiler is the last entry. The GeneratedServiceLocator in /data looks like this:

<?php

namespace ZendDiCompiler;

use Zend\Di\ServiceLocator;

/**
 * Generated by ZendDiCompiler\Generator (2014-01-15 11:55:21)
 */
class GeneratedServiceLocator extends ServiceLocator
{

    public $services = array();

    /**
     * @param string $name
     * @param array $params
     * @param bool $newInstance
     * @return mixed
     */
    public function get($name, array $params = array(), $newInstance = false)
    {
        if (!$newInstance && isset($this->services[$name])) {
            return $this->services[$name];
        }

        switch ($name) {

            default:
                return parent::get($name, $params);
        }
    }


}

Which probably causes the problem. Here's how all of my DI definitions look like:

    'di' => [
        'allowed_controllers' => [
            __NAMESPACE__ . '\Controller\FlagController'
        ],
        'definition' => [
            'class' => [
                __NAMESPACE__ . '\Manager\FlagManager' => [
                    'setClassResolver' => [
                        'required' => 'true'
                    ],
                    'setTypeManager' => [
                        'required' => 'true'
                    ],
                    'setObjectManager' => [
                        'required' => 'true'
                    ],
                    'setModuleOptions' => [
                        'required' => true
                    ],
                ],
                __NAMESPACE__ . '\Controller\FlagController' => [
                    'setFlagManager' => [
                        'required' => 'true'
                    ],
                ]
            ]
        ],
        'instance' => [
            'preferences' => [
                __NAMESPACE__ . '\Manager\FlagManagerInterface' => __NAMESPACE__ . '\Manager\FlagManager'
            ]
        ]
    ],

All setters (yes I know, now hard dependencies..) use interfaces for type hinting:

    /**
     * The type manager
     *
     * @var TypeManagerInterface
     */
    protected $typeManager;

    /**
     * Gets the type manager
     *
     * @return TypeManagerInterface $typeManager
     */
    public function getTypeManager()
    {
        return $this->typeManager;
    }

    /**
     * Sets the type manager
     *
     * @param TypeManagerInterface $typeManager            
     * @return void
     */
    public function setTypeManager(TypeManagerInterface $typeManager)
    {
        $this->typeManager = $typeManager;
    }

The info file is empty as well:

Component dependency info - generated by ZendDiCompiler (2014-01-15 11:55:21)

Scanned classes are grouped into components (e.g. the Zend\Mvc\MvcEvent class belongs to the Zend\Mvc component).
For every component, all constructor-injected classes are listed. This helps you analyze which components
depend on which classes of other components. Consider organizing your components into layers.
Each layer should depend on classes of the same or lower layers only.
Note that only constructor-injection is considered for this analysis, so the picture might be incomplete.

I'm using version 1.1.7

Code scanning problems can lead to an error when writing component dependency info:

Fatal error: Uncaught exception 'ErrorException' with message 'Undefined offset: 1' in /.../ZendDiCompiler/ZendDiCompiler.php:433 Stack trace: #0

I took a closer look into ZendDiCompiler but I still got problems to get it working. As stated in the docs, the Container will be added as a fallback to the ServiceManager. However, here is an example config:

    'view_manager'          => array(
        'strategies'               => array(
            'Ui\Strategy\PhpRendererStrategy'
        )
    ),
    'service_manager'       => array(
        'factories'  => array(
            'Ui\Renderer\PhpDebugRenderer' => function (ServiceLocatorInterface $sm) {
                    $service = new Renderer\PhpDebugRenderer();
                    $service->setResolver($sm->get('Zend\View\Resolver\AggregateResolver'));
                    $service->setHelperPluginManager($sm->get('ViewHelperManager'));

                    return $service;
                },
        )
    ),

So the PhpRendererStrategy should be known to the default ServiceManager. However, when I activate the ZDC in my application.config with the following settings:

    'zendDiCompiler'     => array(
        // nothing to scan yet
    ),

I get the following exceptions:

Fatal error: Uncaught exception 'Zend\ServiceManager\Exception\ServiceNotCreatedException' with message 'The factory was called but did not return an instance.' in /var/www/src/vendor/zendframework/zendframework/library/Zend/ServiceManager/ServiceManager.php on line 904

Zend\ServiceManager\Exception\ServiceNotCreatedException: An abstract factory could not create an instance of uistrategyphprendererstrategy(alias: Ui\Strategy\PhpRendererStrategy). in /var/www/src/vendor/zendframework/zendframework/library/Zend/ServiceManager/ServiceManager.php on line 1075

I thought that this might be related to the ViewManager, however, if I deactivate that view strategy, other services can't be instantiated as well (same error). Also it doesn't matter where I place ZDC in the module section.

One more thing:

Allows for custom code introspection strategies (by default, only constructors are scanned)

This has to do directly with DI and not ZDC right? So if I do this:

    'di'             => [
        'definition'          => [
            'class' => [
                'Discussion\DiscussionManager'                => [
                    'setObjectManager'        => [
                        'required' => true
                    ],
                ],
                // ...

The method setObjectManager will be scanned as well, won't it?