Zend Framework 2 has built-in :doc:`MVC integration with the console<zend.console.introduction>`. When the user runs an application in a console window, the request will be routed. By matching command line arguments against :doc:`console routes we have defined in our application <zend.console.routes>`, the MVC will invoke a controller and an action.
In this chapter we will learn how ZF2 Controllers can interact with and return output to console window.
Console requests are very similar to HTTP requests. In fact, they implement a common interface and are created at the same time in the MVC workflow. :doc:`Console routes <zend.console.routes>` match against command line arguments and provide a defaults array, which holds the controller and action keys. These correspond with controller aliases in the ServiceManager, and method names in the controller class. This is analogous to the way HTTP requests are handled in ZF2.
In this example we'll use the following simple route:
This route will match commands such as:
> php public/index.php show users > php public/index.php show all users > php public/index.php show disabled users
This route points to the method Application\Controller\IndexController::showUsersAction().
Let's add it to our controller.
We fetch the console request, read parameters, and load users from our (theoretical) users service. In order to make this method functional, we'll have to display the result in the console window.
The simplest way for our controller to display data in the console window is to return a string. Let's modify our example to output a list of users:
On line 27, we are checking if the users service found any users - otherwise we are returning an error message that will be immediately displayed and the application will end.
If there are 1 or more users, we will loop through them with and prepare a listing. It is then returned from the action and displayed in the console window.
Sometimes we might need to check if our method is being called from a console or from a web request. This is useful to block certain methods from running in the console or to change their behavior based on that context.
Here is an example of how to check if we are dealing with a console request:
You do not need to secure all your controllers and methods from console requests. Controller actions will only be invoked when at least one :doc:`console route <zend.console.routes>` matches it. HTTP and Console routes are separated and defined in different places in module (and application) configuration.
There is no way to invoke a console action unless there is at least one route pointing to it. Similarly, there is no way for an HTTP action to be invoked unless there is at least one HTTP route that points to it.
The example below shows how a single controller method can handle both Console and HTTP requests:
There are several types of parameters recognized by the Console component - all of them are described in :doc:`the console routing chapter <zend.console.routes>`. Here, we'll focus on how to retrieve values from distinct parameters and flags.
After a route matches, we can access both literal parameters and value parameters from within the $request container.
Assuming we have the following route:
If this route matches, our action can now query parameters in the following way:
In case of parameter alternatives, it is a good idea to assign a name to the group, which simplifies the branching in our action controllers. We can do this with the following syntax:
Now we can use a the group name userTypeFilter to check which option has been selected by the user:
Flags are directly accessible by name. Value-capturing flags will contain string values, as provided by the user. Non-value flags will be equal to true.
Given the following route:
We can easily retrieve values in the following fashion:
In case of flag alternatives, we have to check each alternative separately: