php-di / zf1-bridge

PHP-DI integration with Zend Framework 1

layout
home

PHP-DI is a dependency injection container meant to be practical, powerful, and framework-agnostic.

Read more on the website: php-di.org

For Enterprise

Available as part of the Tidelift Subscription

The maintainers of php-di/php-di and thousands of other packages are working with Tidelift to deliver commercial support and maintenance for the open source dependencies you use to build your applications. Save time, reduce risk, and improve code health, while paying the maintainers of the exact dependencies you use. Learn more.

zf1-bridge's Issues

Let ZF1 load the controller and inject dependencies afterwards

When PHP-DI/PHP-DI#84 is implemented, refactor the PHP-DI - ZF1 integration to simplify it:

Let ZF1 load the controller, and inject the dependencies afterwards.

waiting for PHP-DI/PHP-DI#84

Hard dependency on ZF1

Currently composer.json contains:

"zendframework/zendframework1": "1.12.*"

This seems obvious for this bridge, but we are using the component based / optimized packages from https://github.com/zf1. This way we do not need to download the complete ZF1 and can gradually phase out the use of ZF1 packages and migrate to ZF2.

Would it be an option to 'suggest' the complete Zend Framework and only 'require' the https://github.com/zf1/zend-controller ?

Tried wiring this up, autoloader is choking on "Class DI_ZF1_CONTROLLER_PARAMS could not be loaded"

any ideas why it's trying to load this non-existent class?

Quickstart should include example of mocking dependency in test

Hi,

I really like the look of PHP-DI, but from just reading around I'm not sure what the recommended approach for injecting mock dependencies into ZF1 controllers in unit tests is. I've phrased this issue as a suggested improvement, but I'm really just after more information.

I see PHP-DI-ZF1 uses injectOn and an already constructed controller in its dispatcher (so constructor injection, my preferred DI approach, can't be used), and that the quickstart GuestController has a private property that PHP-DI injects into (so the test can't easily set it).

Is the recommended approach to use reflection to set the property? Or maybe to obtain the controller through the container, having set the dependencies as mocks in the container? Both approaches seem a bit fiddly, although presumably the latter is what should be done when writing tests at a slightly higher level, using Zend's $this->dispatch().

Perhaps the expectation is for the property (or setter) to be public? But if so, I think the quickstart example should be written as such, ideally with corresponding examples in the tests.

Thanks,
Rowan

Problem initializing

Hi after installing with composer and adding init method to my Bootstrap.php iam getting following error in my webapp :

Fatal error: Uncaught exception 'Zend_Application_Bootstrap_Exception' with message 'No default controller directory registered with front controller'

Any tips? Thanks

The ZF1 bridge requires doctrine annotations?

PHP DI does not require doctrine/annotations - when installed it just recommends installing it. But ZF1 seems to require it, therefore it should be added to composer.json.

Sample code not working

I am sure I am just missing something, I am trying to duplicate the sample code at http://php-di.org/doc/frameworks/zf1.html with a "Hello World" controller.

Bootstrap.php

class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
    protected function _initContainer()
    {
        $builder = new \DI\ContainerBuilder();
        $container = $builder->build();


        $dispatcher = new \DI\Bridge\ZendFramework1\Dispatcher();
        $dispatcher->setContainer($container);

        Zend_Controller_Front::getInstance()->setDispatcher($dispatcher);
    }

}

IndexController.php

class IndexController extends Zend_Controller_Action
{

    /**
     * This dependency will be injected by PHP-DI
     * @Inject
     * @var Application_Model_HelloWorld
     */
    private $hw;

    public function init()
    {
        /* Initialize action controller here */
    }

    public function indexAction()
    {
        // action body

        //$this->hw = new Application_Model_HelloWorld();

        $this->view->helloworld = $this->hw->Msg();
    }


}

HelloWorld.php

class Application_Model_HelloWorld
{
    function __construct() {
        fb("Hello");
    }

    public function Msg() {
        return "Hello World";
    }
}

The code works fine when I uncomment $this->hw = new Application_Model_HelloWorld(); but my understanding is that auto-wiring would instantiate the object. Not sure if my understanding is wrong or my code is wrong.

Any help would be appreciated.

Thanks

Handling not existent controllers/actions

I keep getting 500 errors in an error tracking software because apple devices try to request apple-touch-icon-precomposed.png, which we do not have set up and bots constantly trying to access common paths (eg. /wp-admin/, /news, /cms)

This comes down to the controller not existing and therefore the bridge plugin is throwing Zend_Controller_Dispatcher_Exception

Is there a way to handle the following exceptions (in /src/DI/Bridge/ZendFramework1/Dispatcher.php:50) properly and display a 404 instead of 500:

throw new Zend_Controller_Dispatcher_Exception('Invalid controller specified (' . $request->getControllerName() . ')');

Should update to allow version 6

ZF1-Bridge/composer.json

Line 13 in a0357dc

"php-di/php-di": "~5.0"

Can the dependency on ~5.0 be amended allow installing version 6? I think ~5.0 || ~6.0 should do it?

At first glance it seems that v6 should be compatible with the dispatcher in this repo? The example app looks to have been kept simple (no caching or complex config) and ought to work with v6 too?

Fails if your controllers init method depends on an injection with 3.3

Not so much a bug, but a warning about a problem that is pretty common (at least in our code base). If your controller's init references a dependency (not in a constructor) then it won't be there during init.

3.3 switched from using a constructor-less instantiation of the dependency to using the constructor. IE the controller. In previous version controller init was not called on the controller till after the property injections occurred as the constructor injection was called after properties injection occurred.

The immediate solution is to override the constructor with the required dependencies of the constructor but Zend docs recommend you not override the constructor and instead override init.

Another option is to override the init and include an InjectOn call against itself so that the dependencies are there. This would get you away from a custom dispatcher being required. The drawback is you have to get a handle to the DI container in your init call. If you instantiate the DIcontainer in a bootstrap file it's ugly to pass it down, so it may be better to instantiate it in the init itself.

Another option is to degrade into the service locator pattern within the init method for anything init requires.

Another option is to move all your init code (if possible) into the preDispatch instead of init. This isn't a straight forward migration.

It's a shame the constructor calls init, and not the dispatcher.