views:

42

answers:

1

The ZF Docs reference 'Subclassing the Action Controller' (bottom of the page), but don't reference a standard place to put the new Action_Controller class.

Application_Module_Autoloader sets up pats for a bunch of things, but never controllers. I guess putting it on library/APPNAMESAPCE/Action/Contoller would work. But that seems a bit odd since every other application specific file is stored under application/.

+1  A: 

The class gets autoloaded like any other class, there isn't a 'standard' place for it as such. So the question becomes, where do you want it to live?

The convention I usually follow in modular applications is to have most stuff in the modules, but register an app namespace and use application/models for 'core' type classes. So in your case, say your app namespace was Wordpress, you'd have:

class Wordpress_Controller_Action extends Zend_Controller_Action
{

}

and the file would live in application/models/Wordpress/Controller/Action.php.

To make this work you'll need application/models on your include path, and you'll want to init the standard autoloader with something like this (in your bootstrap class):

protected function _initAutoloader()
{
    $autoloader = Zend_Loader_Autoloader::getInstance();
    $autoloader->registerNamespace('Wordpress_');

    return $autoloader;
}

alternatively you could setup the above in application.ini.

Tim Fountain
There are indeed 'standard' places. As mentioned in the question, newer versions of ZF take care of autoloading automatically, mapping not only 'Namespace\_Models\_' to `application/models`, but 'Namespace\_Forms\_' to `application/forms`, and the same for 'dbtable', 'mappers', 'plugin', 'service', 'viewhelper', 'viewfilter'. Sure, I know I can put it in `application/models`, but that's where I put my *models*, not my controllers.
Tim Lytle
I am aware of how the resource autoloaders work. My point was that there isn't a standard place for controller base classes, so personally I put it in the model directory (since IMO it isn't a controller, it's just a component used by them). Alternatively you could register a new resource type just for controllers, and have Namespace_Controller_Controller_Action, but that would seem like overkill for what I imagine will be only one class.
Tim Fountain
I misread your first line to mean there's not a standard place for the classes you need autoloaded (not just no place for controller classes), my mistake. Seems like `application/controllers` could be used without the extra level (after all 'real' controllers end with 'Controller', so that helps with naming issues). Guess it's something to play with.
Tim Lytle