In Zend Framework 1, controller's had an init() method, which was called after the controller was instantiated. The reason for it was to encourage developers not to override the constructor, and thus potentially break some of the functionality (as a number of objects were injected via the constructor). init() was useful for doing additional object initialization. [...] But this feature is missing from ZF2; how can we accomplish this sort of pattern?

In Zend Framework 2, there's no Controller constructor by default anymore, so you have to do things slightly differently. He shows you how to use the event manager to simulate the same thing, attaching an event to the "dispatch" of the controller to do the work. He came back and updated the post with a second method that could do the same thing - using the ServiceManager from inside a module and attaching the event that way.

I've been teaching a Zend Framework class this week and my students have been throwing all kinds of questions at me. Most recently, while we were discussing creating a Bootstrap class for an application a question came up about the _init* functions.

The documentation talks about the bootstrap loading those init functions, but it leaves out the order they're executed in. Cal did a bit of research and found that they're executed in the order they're created with one exception - if you specify one to run first in the bootstrap constructor.

Recently at work I had the need to run a script before every single controller (namely to add a plugin folder to Dwoo) for a specific module that I did not desire for any other modules. I could have subclassed all my controllers to extend a custom action controller that handled this in the init() method, however I'm lazy so I wrote a quick Zend Controller Plugin to handle this for me.

The plugin actually runs when the routeShutdown method is used (after the routing is done, but before the controller is called) and pulls in the contents of the specified file and executes it like the code was already embedded. Complete code is included.

Most notably, I've started using the "new way" of using views, which is still undocumented in the manual. Rather than create a new Zend_View object, tell it where my views are, and echo a call to its render() method, I'm letting the controller's render() method do it all for me.

He illustrates with a simple example using the default framework directory setup, save for the special "scripts" directory he creates. This makes it possible for the controller to handle the rendering rather than the typical view functionality. Then, using the views is a simple init() call away, automagically.