php-di / zf1-bridge Goto Github PK
View Code? Open in Web Editor NEWPHP-DI integration with Zend Framework 1
Home Page: http://php-di.org/doc/frameworks/zf1.html
PHP-DI integration with Zend Framework 1
Home Page: http://php-di.org/doc/frameworks/zf1.html
Line 13 in a0357dc
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?
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
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.
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
?
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.
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.
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);
}
}
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();
}
}
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
any ideas why it's trying to load this non-existent class?
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
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
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() . ')');
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.