Classe: Controller  - X-Ref

\ingroup Controller

This is how MVC works, using the pattern of the 'Front Controller'. With this pattern, we have
a single controller class that receives all the requests from the client, identifies the
action to be taken and the relays the execution of the action to the most suitable Action class.
The 'Action' class then will use the application business logic (the Model) to carry out the
operations necessary.

(according to http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html)

# The controller receives a POST from the client.
# The controller creates an Action corresponding to the requested operation (as described in the previous section).
# The controller calls the Action's perform method.
perform calls a model business method.
# The controller calls the screen flow manager to select the next view to display.
# The screen flow manager determines the next view and returns its name to the controller.
# The controller forwards the request to the templating service, which assembles and delivers the selected view to the client.

The Controller uses an action map file that maps action parameters to action classes. This is file is
nothing more than an associative PHP array where the key of the array is the value of the action
parameter and the key is the name of an action class. The default action parameter is "op" and the default
action is "Default" unless otherwise specified.

This is an example of a map file:

<pre>
$actions["Default"] = "AdminDefaultAction";
$actions["Login"] = "AdminLoginAction";
$actions["blogSelect"] = "AdminMainAction";
$actions["Dashboard"] = "AdminMainAction";
$actions["Manage"] = "AdminManageAction";
</pre>

It is not necesary to specify the full extension of the file, and by default it is considered to be
".class.php". In case this is not the case, please the ResourceClassLoader::setClassFileSuffix()
method.

Classes can be dynamically loaded (meaning that we
do not need to load all of them via include() or lt_include() at the top of our code), via the
ResourceClassLoader class. This class will scan a set of pre-defined folders looking for the action
class and load it if it's the one we were looking for.

In order to create a Controller object and process a request, we would use something like:

<pre>
$controller = new Controller( "myactionmap.properties.php" );
$controller->process( $_REQUEST );
</pre>

It is also possible to register new actions dynamically at run time via the static method
Controller::registerAction() which takes an action class name and an action id as parameters. This is the
method used by plugins to register new actions (although via the wrapper PluginBase::registerAction())

In our particular implementation, each action class should extend the Action class or a child of it
such as BlogAction, AdminAction, etc. Each one of this action classes should at least implement
the Action::perform() method and include there its business logic (which can be whatever) Action classes
are expected to generate a valid View class that the Controller will use to render the contents that
will be sent back to the client. The Controller will get the right view via the Action::getView() method, and
views can be set via the Action::_view attribute or the Action::setView() method.

Another method that the controller will call is the validate() method that can be used for basic
data validation logic. The base Action class already provides some code in this method, which is tied to
the FormValidator and Validator classes so in case of data validation, it is advisable to use those
methods. However if required, feel free to reimplement Action::validate(), keeping in mind that if the controller
receives a positive value, it will continue processing the Action::perform() and if not, it will stop
processing and call Action::getView() right away.

Actions can also forward the process flow to another action without generating a view by calling
the static method Controller::setForwardAction(), which takes an action class identifier as a parameter. If
after processing action the controller detects that there is a forwarding in place, it will <b>not</b>
call Action::getView() but instead, start the process again and call validate() and process() in the next
action in line.