Controllers

  • BUILD SCRIPT
    A convenience build script exists to create a controller class with a default "index" action method:
    >php buildcontroller Test would produce a TestController class located in app/controller/Test.controller.php.
  • Controller classes are located in the app/controller directory. They follow the naming convention of My.controller.php for the file name, and the class name would by MyController.
  • They contain Action methods, which follow a naming convention of sampleAction for the sample action. Default actions for controllers are named indexAction.
  • Controller and Action names map directly to url requests. If I wanted to write a controller and action to handle a request of www.mytestsite.com/test/, I would create a method in IndexController named testAction. IndexController is the default controller that root level requests are mapped through. This allows you to have IndexController contain multiple methods to handle any actions that are directly off of the root url path. For example:
    • www.mytestsite.com/about/ could be handled in IndexController.aboutAction
    • www.mytestsite.com/register/ could be handled in IndexController.registerAction
    • www.mytestsite.com/ would be handled in IndexController.indexAction
  • Along with IndexController handling any root level url requests, you can also override that by creating a new controller class named according to your request path to have subsequent requests filtered through it. For example, we saw how www.mytestsite.com/test/ can map to IndexController.testAction. This same url would map to TestController.indexAction by default if that class existed, and it would take precedence over the IndexController.testAction method. Depending on your site, you may or may not need specific controllers for different url paths. A good way to judge if you do is if you need to group a set of action methods under a common path. This is often common for CRUD behavior, where you would map edit, save, delete actions for an object under one path, such as:
    • www.mytestsite.com/myobject/edit/
    • www.mytestsite.com/myobject/save/
    • www.mytestsite.com/myobject/delete/
    Just as a controller is a way to group similar actions into one class, you can also group similar controllers into a sub-directory in the app/controller/ location. The name of the directory becomes part of the url path, preceding the controller. For example, if I wanted to group a set of controllers I had that all dealt with the administration of a site, I could create a directory, app/controller/admin and put the controllers inside of this. My url path would then be www.mytestsite.com/admin/controllername/actionname/. When creating a sub-directory for your controllers, it should be noted that you must also mirror the same directory structure when creating the view templates for those controllers as well, packaging them into a sub-directory just like the controllers.
  • Every controller class will have a directory for its view templates that correspond to the action methods within the controller. More about this in the views section.