Controllers

In an MVC application, the controller’s job is to handle user input, and handle that request with a specified action. Though the controller action is where action logic is determined, models are often the real workhorses in the request cycle. Keep in mind as you read this guide to keep your controller action trim, with most of the actual functionality spread across models and other classes.

This guide is meant to introduce you to li3 controllers: their features, behaviors, and the best practices revolving around their usage.

Controller Actions

li3 controllers reside inside the /app/controllers directory and extend the lithium\action\Controller core class. Let’s start by creating a simple controller inside of an application. Controllers are often named after the objects they manage. This way the URL and model line up as well, and it’s easy to know where certain bits of logic should live.

For example, let’s create a new controller UsersController. Let’s create a new file in /app/controllers/UsersController.php that looks like this:

  1. namespace app\controllers;
  3. class UsersController extends \lithium\action\Controller {
  5.     public function index() {}
  6. }

Each public function in a controller is considered by the li3 core to be a routable action. In fact, li3’s default routing rules make these actions accessible via a browser immediately (in this case /users/index).

The index() action is a special action: if no action name is specified in the URL, li3 will try to pull up the index action instead. For example, a visitor accessing http://example.com/users/ on your application will see the results of the index() action. All other controller actions (unless routed otherwise) are at least accessed by the default route.

For example, we can create a new controller action that would be accessible at /users/view/:

  1. namespace app\controllers;
  3. class UsersController extends \lithium\action\Controller {
  5.     public function index() {}
  7.     public function view() {}
  8. }

Accessing Request Parameters

An important part of a controller’s role in an application is processing incoming request data to show the correct response. In this section, we’ll show a few examples that should help you to get data into your controller actions.

GET Parameters

One of the most user-friendly ways to handle incoming data is through the URL. Information passed along with a GET request is handled a number of different ways, based on your preferences.

The easiest way to handle incoming GET data is by realizing that URL segments that follow the action name are mapped to controller action parameters. Here’s a few examples:

  1. http://example.com/users/view/1  --> UsersController::view($userId);
  2. http://example.com/posts/show/using+controllers/8384/  -->  PostsController::show($title, $postId);

GET information passed this way is also accessible via the incoming request object:

  1. http://example.com/users/view/1  --> $this->request->args[0]

While we’ll always recommend using clear URL-based variables, it’s important to mention that GET parameters passed as raw query string variables are also available as an attribute of the incoming request:

  1. http://example.com/users/view?userId=1  --> $this->request->query['userId']

POSTed Data

POSTed data is also gathered from the request object. Form field data is found on the request object inside an array with keys named after the input elements generated on the referring page. For example, consider an HTML form that included these elements:

  1. <input type="text" name="title" value="How to Win Friends and Influence People" />
  2. <input type="text" name="category" value="Self-Help" />

Accessing these values when submitted to a controller action is as easy as:

  1. $this->request->data['title'];
  2. $this->request->data['category'];

Request Flow Control

Occasionally a controller action will want to divert, re-route, or automatically configure the view layer based on an incoming request. There are a number of controller methods to help facilitate request flow handling.

Redirection

The most basic type of flow control at the controller level is redirection. It’s common to redirect a user to a new URL once an action has been performed. This type of control is done through the controller’s redirect() method. Here’s an example of a controller action that redirects the request:

  1. public function register() {
  2.     // Validate and save user data POSTed to the 
  3.     // controller action found in $this->request->data...
  5.     $this->redirect('Users::welcome');
  6. }

The URL specified can be relative to the application or point to an outside resource. The redirect() function also features a second $options parameter that also allows you to set HTTP status headers, and make decisions about whether or not to exit() after a redirect. Be sure to check the API for lithium\action\Controller::redirect() for more details.

Exceptions and Error Handling

Error handling in li3 is done using the core ErrorHandler class. ErrorHandler allows PHP errors and exceptions to be handled in a uniform way. Using ErrorHandlers configuration makes it possible to have broad but tightly controlled error handling across your application.

ErrorHandler configuration is done by creating a new error-specific bootstrap file that contains your ErrorHandler configuration and initialization. To illustrate how this is done, let’s consider an imaginary (but common) scenario. Rather than tossing up error messages and stack traces to your users, it’s better to create some sort of way to handle exceptions and render user-friendly error pages.

Let’s start by creating a way to handle page not found-like errors. If a request can’t be routed properly, the li3 dispatcher will throw an exception to let you know that a controller or view can’t be found. Though the example here will be specific to this case, it should provide a mental framework that will allow you to understand how to catch errors and exceptions, and handle them accordingly.

Start by creating a new bootstrap file in /app/config/bootstrap/error.php:

  1. use lithium\core\ErrorHandler;
  3. $conditions = ['type' => 'lithium\action\DispatchException'];
  5. ErrorHandler::apply('lithium\action\Dispatcher::run', $conditions, function($exception, $params) {
  6.     var_dump(compact('exception', 'params'));
  7.     die();
  8. });

This simple example shows how you can create a lambda that handles any DispatchExceptions being thrown in your entire application. The function you pass to apply() can be more involved, depending on what you want to do, however.

Here’s a more complete example, showing how you’d actually render a template, and include logging:

  1. use lithium\core\ErrorHandler;
  2. use lithium\analysis\Logger;
  3. use lithium\template\View;
  5. Logger::config(['error' => ['adapter' => 'File']]);
  7. $render = function($template, $content) {
  8.     $view = new View([
  9.         'paths' => [
  10.             'template' => '{:library}/views/{:controller}/{:template}.{:type}.php',
  11.             'layout'   => '{:library}/views/layouts/{:layout}.{:type}.php',
  12.         ]
  13.     ]);
  14.     echo $view->render('all', compact('content'), compact('template') + [
  15.         'controller' => 'errors',
  16.         'layout' => 'default',
  17.         'type' => 'html'
  18.     ]);
  19. };
  21. ErrorHandler::apply('lithium\action\Dispatcher::run', [], function($exception, $params) use ($render) {
  22.     Logger::write('error', "Page Not Found...");
  23.     $render('404', compact('exception', 'params'));
  24. });

If you’ve got more than one type of exception you want to handle, just add more calls to apply() in your error bootstrap file.

Render Types and Detection

Although a typical request to a li3 application receives an HTML response, the framework is built to be extremely flexible in handling and serving different types of content. This functionality is especially important in applications that have many different components or endpoints. If your app also feeds data to a Flash object (AMF/XML) and a mobile phone (XML/JSON), responding to requests in different ways with the same underlying logic can be a huge time saver.

The flow for handling a given type of a response works something like the following:

  1. A request is sent to the application, containing some sort of indicator of the request type. li3’s default routing allows for simple extension detection, for example.
  2. As li3 bootstraps, a media type and handler is registered with the \net\http\Media class.
  3. The application detects the request type and sets the response type.
  4. Once a controller is ready to render the data, the registered handler receives the data and renders the output.

Detecting and Setting Types

The easiest way to set a type is by declaring it as part of the route. One of li3’s default routes already does this for you:

  1. Router::connect('/{:controller}/{:action}/{:id:[0-9]+}.{:type}', ['id' => null]);

In effect, this forces a request to /controller/action/7345.json to be rendered by the JSON media handler currently registered. You can use this pattern to expand your routes to apply type-matching to a wider array of requests:

  1. // http://example.com/controller/action.xml
  2. Router::connect('/{:controller}/{:action}.{:type}');

You can also statically define the type for a route by adding the ‘type’ key to the route definition:

  1. Router::connect('/latest/feed', [
  2.     'Posts::index',
  3.     'type' => 'xml'
  4. ]);

If you’d rather use other information to convey the request type to li3 (headers, GET variables, etc.) you can gather that information then set $this->_render['type'] in the controller action.

Manual type rendering can also be done by handing the type’s name to the render function:

  1. $this->render(['csv' => Post::find('all')]);

Handler Registration

As mentioned earlier, type handlers are registered by the \net\http\Media class. This is usually done in the /config/bootstrap/media.php bootstrap file. Be sure to uncomment the corresponding line in the main bootstrap file to enable this functionality.

Register your type by passing the relevant information to Media::type() inside the bootstrap. Here’s what the general pattern looks like:

  1. Media::type('typeName', 'contentType', [$options]);

To give you an idea of how this process is completed, let’s register a new handler for the BSON data type. If you’re curious, BSON is a binary, serialized form of JSON used by MongoDB. Start by declaring a new media type in /config/boostrap/media.php and uncommenting the media.php line in your main bootstrap file:

  1. Media::type('bson', 'application/bson', []);

This gets us pretty far. If you make a request with a .bson extension that matches a configured route (one with {:type} in it), li3 will already hunt for a .bson.php template in the controller’s template directory. You can continue to customize li3’s behavior by utilizing the $options array you supply to Media::type(). After checking the API docs for Media::type(), we realize we can utilize a few options to make sure our response isn’t housed in an HTML layout and use some functions we’ve defined for encoding and decoding the data:

  1. Media::type('bson', 'application/bson', [
  2.     'layout' => false,
  3.     'encode' => 'bson_encode',
  4.     'decode' => 'bson_decode'
  5. ]);

Try the request again, and you’ll get your BSON-encoded data, minus the HTML layout. Note that the bson_* functions used in this particular example are part of the PECL MongoDB extension. Don’t worry if you don’t have it installed: the main point is to realize that you can tell Media exactly what function to use to render the data (including using closures).

For more ideas on configuring media types, see the documentation for Media::type().

Using Models and Core Libraries

While an entire guide is devoted to covering model usage, it’s important to see how they’re used inside the controller layer. Using models inside li3 controllers is simple. Let’s start with a bare controller as an example:

  1. namespace app\controllers;
  3. class ClientsController extends \lithium\action\Controller {
  5.     public function index() {}
  6. }

While not required, it’s helpful to name controllers after the models they primarily use, at least for organizational purposes. To start using your model inside this controller, you’ll need to let PHP know you intend to use the model class inside this controller:

  1. namespace app\controllers;
  3. use app\models\Client;
  5. class ClientsController extends \lithium\action\Controller {
  7.     public function index() {}
  8. }

Since most model access is done statically, just access the methods you need in your controller actions directly:

  1. namespace app\controllers;
  3. use app\models\Client;
  5. class ClientsController extends \lithium\action\Controller {
  7.     public function index() {
  8.         $clients = Client::find('all');
  9.         return compact('clients');
  10.     }
  12.     public function details($clientId) {
  13.         $client = Client::find('first', [
  14.             'conditions' => [
  15.                 'id' => $clientId,
  16.             ]
  17.         ]);
  19.         return compact('client');
  20.     }
  21. }

Using li3’s core libraries inside the controller layer is similar, although instantiating a class is sometimes necessary. Consider the following example that uses the Service class:

  1. namespace app\controllers;
  3. use SimpleXmlElement;
  4. use lithium\net\http\Service;
  6. class ClientsController extends \lithium\action\Controller {
  8.     public function index() {
  9.         $service = new Service(['host' => 'api.flickr.com']);
  10.         $response = new SimpleXmlElement($service->get('/services/feeds/photos_public.gne'));
  11.         return compact('response');
  12.     }
  13. }

This is done by declaring the usage of the class by specifying it’s fully namespaced path, and later instantiating it inside the action logic.

Also note that core PHP classes (SimpleXmlElement, in this case) are imported with the use statement as well, since they exist in the root namespace.

Moving Data to the View

Once your controller action has fetched and processed the data it needs, it’s time to push the data to the view layer. There are two main ways to accomplish this: by using the set() method of the Controller class, or by simply returning an associative array as the result of a controller action method.

First, the set() method is used to send an associative array to the view. Consider this example controller action method:

  1. public function index() {
  2.     $data = SomeModel::find('all');
  3.     $this->processData($data);
  4.     $this->set(['importantData' => $data]);
  5. }

This populates the index view for this controller with a variable named $importantData with the same contents as $data. This same logic could be written a bit more elegantly:

  1. public function index() {
  2.     $data = SomeModel::find('all');
  3.     $this->processData($data);
  4.     $this->set(compact('data'));
  5. }

One difference to note here is that the view’s variable is now named $data, just as it was in the controller.

The set() method is especially useful when you’ve got bits of data you want to hand to the view in pieces, or conditionally, as it can be called at any point inside of a controller action method:

  1. public function index() {
  2.     $data = SomeModel::find('all');
  3.     $this->processData($data);
  4.     $this->set(['importantData' => $data]);
  6.     $moreData = SomeService::get();
  7.     $this->processData($moreData);
  9.     if ($someCondition) {
  10.         $this->set($moreData);
  11.     }
  13.     //...
  14. }

Conversely, sometimes all your data is ready by the end of the method’s logic, and you can just return the associative array to hand it to the view:

  1. public function index() {
  2.     $data = SomeModel::find('all');
  3.     $this->processData($data);
  5.     $moreData = SomeService::get();
  6.     $this->processData($moreData);
  8.     return compact('data', 'moreData');
  9. }

Filtering Controller Logic

Filtering controller logic can be a bit tricky to the new li3 user, due to the flexible and elegant way the dispatch cycle executes.

When a request is sent to an application, the Dispatcher first uses the Router to determine which controller to load. Once a target controller has been identified, a new controller object is created and invoked.

This last invokation step is performed inside of the dispatcher’s _callable() method. Because of this, filters that wish to inject logic before or after controller actions is often done against _callable(). Doing so allows you access to parameters that are normally available to the controller, as well as the right controller instance, allowing you to call its methods.

Note: You might have seen some filters run against the dispatcher’s run() method instead. In many cases, this should work just fine. The difference in using _callable() is that with the latter, you’ll end up with access to the active controller instance itself, along with its parameters.

The g11n filters that come with the standard distribution form an illustrative example. Consider this slightly modified (for simplicity) version of that same filter:

  1. use lithium\aop\Filters;
  2. use lithium\action\Dispatcher;
  4. Filters::apply(Dispatcher::class, '_callable', function($params, $next) {
  5.     $request = $params['request'];
  6.     $controller = $next($params);
  8.     if (!$request->locale) {
  9.         $request->params['locale'] = Locale::preferred($request);
  10.     }
  11.     Environment::set(Environment::get(), ['locale' => $request->locale]);
  12.     return $controller;
  13. });
This example uses new-style filters, available with 1.1.

Here you can see that you’ve got access to the request parameters and the controller instance itself in the first two lines of the Filters::apply() call. In this case, the g11n framework is inspecting the request and setting locale settings accordingly, but when creating your own filter, you’d have access to the same data.

An important case to consider that’s also covered in the g11n filters is remembering to also filter the frameworks other dispatcher: the console action dispatcher. In other words, if you truly want to effect every action in an application, you might consider also filtering the lithium\console\Dispatcher as well as the lithium\action\Dispatcher.

In this case, you’ll want to use the special use/as syntax:

  1. use lithium\aop\Filters;
  2. use lithium\action\Dispatcher as ActionDispatcher;
  3. use lithium\console\Dispatcher as ConsoleDispatcher;
  5. Filters::apply(ActionDispatcher::class /*, ... */);
  6. Filters::apply(ConsoleDispatcher::class /*, ... */);