As many of the answers here state, there is a good chance that your design could use some review and some of the logic should be refactored to the model classes or action helpers. The two biggest warning signs of this are:
- You are trying to manipulate the response from that other "inner" action at the point in which your "outer" action is happening
- You are trying to manipulate a shared object/model
Both of these cases will create a bad interdependence in one or both directions and will result in code reuse that is very difficult to maintain in the long run.
However, there are some common scenarios where I've found "inner" actions very useful for reusing controller actions cleanly. The most common of these is when you really only need the inner action's response within the outer action's view. From within your view, you can easily use the Zend_View_Helper_Action:
print $this->action('foo', 'controller2');
For example, this can be useful when including some javascript created by another view. For example, MenuController::viewAction might have a response like this:
(function() {
var menuComponent = new MenuObject({dynamicOptions: ...});
return menuComponent;
})()
Now in DefaultController::indexAction's view script you can do something like this:
var mainmenu = <?php print $this->action('view', 'menu'); ?>;
navigationBar.add(mainmenu);
Additionally, in SpecificModule_DefaultController::indexAction's view script you can do something like this:
var modulemenu = <?php
print $this->action('view', 'menu', 'default', array(
'Module' => 'SpecificModule'
));
?>;
moduleWidgetMenu.add(modulemenu);
This can be a powerful technique for reusing actions and essentially creates a nested MVC request (see the other answer here about HMVC). In the above example, we have the rendering of a menu centralized to one action and we are able to use that in a variety of ways. More over, we have more flexibility in the execution of that action since we get the full action lifecycle (dispatch/plugins/etc.) in a separate execution context rather than overloading logic in to large view and/or action helpers.
Two very very crucial things to make sure of that will help your design stay safe and sane while using this approach:
- The "inner" request (both the action and its associated view) should have no concept of the "outer" request, or even know about its existence at all.
- The "outer" request (both the action and its associated view) should have no control of the inner request except as passed through as parameters to the $this->action($actionName, $controllerName, $moduleName, $paramsArray) call.
This approach generally has worked best with the least maintenance necessary when not modifying the standard MVC lifecycle that ZF implements, including using the two-step view approach with the ViewRenderer action helper.