Greeting! If you use the Zend Framework MVC components, please read this message as it details a backwards compatibility change in the controller components.
In the 0.9.x series of ZF, we introduced some rudimentary View integration into Zend_Controller_Action with the methods initView(), getViewScript(), and render(). With these methods, you could quickly and easily instantiate view objects as well as render view scripts to the response object. In 0.9.3, we introduced Action Helpers. Similar to view helpers, these can be loaded on-demand by action controllers to provide extra functionality. They also have pre- and postDispatch() hooks such that globally registered helpers can hook into dispatched actoin controllers. Ralph Schindler felt it didn't go far enough, and created http://framework.zend.com/issues/browse/ZF-1354, detailing an idea he had for adding more integrated View dependency injection to Zend_Controller_Action. After some thought and discussion with him, I countered with a new action helper, the ViewRenderer. The ViewRenderer's goals were: * Eliminate the need to instantiate view objects within controllers * Have a view object globally available to all controllers * Automatically determine view script, helper, and filter paths based on the current module's filesystem location * Automatically associate the current module name as a class prefix for view helper and filter classes * Allow the developer to set default view rendering options for all controllers or a single action * Add the ability for developers to create their own path specifications for determining the view base path and individual view script paths * Add the ability to autorender view scripts based on the current action What does this mean? Basically, it means less coding for you, the developer, in your controller classes. It means that instead of this: class FooController extends Zend_Controller_Action { public function barAction() { $this->initView(); // initialize view $this->view->baz = 'bat'; // set view variable $this->render(); // render view } } You would then do this: class FooController extends Zend_Controller_Action { public function barAction() { $this->view->baz = 'bat'; // set view variable } } In other words, you're just setting view variables; you don't need to worry about initializing the view object, or rendering it. The ViewRenderer automatically determines the view script path (by assuming a conventional modular layout), and renders 'foo/bar.phtml' (the default view script path is :controller/:action.phtml'). So, how will this affect your existing controllers? * If you call $this->render(), $this->_forward(), or $this->_redirect() (or use the Redirector helper) in your methods, no changes are required. * If you have methods that call none of the above -- i.e., you're not redirecting, not forwarding to a new method, and/or not rendering via the built-in render() method -- you will need to make changes. You can disable autorendering by calling: $this->_helper->viewRenderer->setNoRender() If you call this in preDispatch() or init(), it will turn it off for all actions in the controller; alternately, you can disable it for a single action by calling it only in that action method. If you want to turn off the ViewRenderer globally, i.e., for your entire suite of controllers, add the following to your bootstrap, prior to calling dispatch() on the front controller: // Assuming $front is your front controller instance $front->setParam('noViewRenderer', true); If you're using a view object from the registry, or customizing your view object, or using a different view implementation, you'll want to inject the ViewRenderer with this object. This can be done easily at any time. * Prior to first instantiating a front controller instance: // Assuming $view has already been defined $viewRenderer = new Zend_Controller_Action_Helper_ViewRenderer($view); Zend_Controller_Action_HelperBroker::addHelper($viewRenderer); * After retrieving a front controller instance: $viewRenderer = Zend_Controller_Action_HelperBroker::getExistingHelper('viewRenderer'); $viewRenderer->setView($view); There are many ways to modify the ViewRenderer, including setting a different view script to render, specifying replacements for all replaceable elements of a view script path (including the suffix), choosing a response named segment to utilize, and more. If you aren't using the conventional modular directory structure, you can even associate different path specifications with the ViewRenderer. Documentation is now in the repository if you want to get a jump on this new feature. I strongly encourage you to start modifying your controllers to make use of this helper; I did so in a site of mine while developing this, and reduced my controller code by > 20%, and eliminated several subclasses and plugins I'd created. -- Matthew Weier O'Phinney PHP Developer | [EMAIL PROTECTED] Zend - The PHP Company | http://www.zend.com/
