Introducción.
Estos se ubican entre el usuario y la aplicación. Su función es la de controlar la comunicación entre los modelos y la vistas según la solicitud (requerimiento) que ha hecho usuario.
Su clase base es CController y en ellos se implementan Acciones (definen la lógica de la aplicación) y Filtros (establecen validaciones o controles antes y después de la ejecución de las acciones).
El usuario invoca indirectamente a los controladores especificando un ruta a través del controlador frontal o Application.
La ruta del requerimiento.
El URL solicitado determina que controlador y que acción se van a ejecutar para resolver el requerimiento del usuario.
Los URL tienen el siguiente formato.
Sin URL limpias (por defecto).
http://servidor/index.php?r=ControladorId/AcciónId
Con URL limpias.
http://servidor/ControladorId/AcciónId
Si se utilizan módulos (y URL limpias para este ejemplo).
http://servidor/MóduloId/ControladorId/AcciónId
- El archivo fuente del controlador se ubica en protected/controllers/ControladorIdController.php.
- El nombre de la clase allí contenida deberá ser ControladorIdController.
- Se invoca a la acción (ver mas adelante) AcciónId. En caso de no haberse especificado una se considera la acción por defecto del controlador, comúnmente index.
Las acciones.
Pueden implementarse de dos maneras.
- Como métodos del mismo controlador.
- Como clases que heredan de CAction.
Acciones implementadas como métodos del controlador.
- El nombre del método deberá ser actionAcciónId.
En el siguiente ejemplo se muestra al controlador User que implementa la acción add como un método suyo.
class UserController extends CController
{
public function actionAdd()
{
// Implementación ...
}
}
Acciones implementadas como clases independientes.
- Los objetos acción heredan de CAction.
- El nombre de la clase es AcciónIdAction (por convención, no es obligatorio).
- Se almacena en un archivo bajo la ruta protected/controllers/controladorId/AcciónIdAction.php.
- Su ubicación puede referenciarse mediante alias de esta manera: application.controllers.controladorId.AcciónIdAction.
- Es obligatorio sobreescribir el método run() de la acción para definir allí su implementación.
En el siguiente código se muestra la acción remove del controlador User implementada como una clase independiente.
class RemoveAction extends CAction
{
public function run()
{
// Implementación ...
}
}
Esta clase se almacena entonces en el archivo protected/controllers/user/RemoveAction.php.
Como paso final de su implementación, es necesario indicarle al controlador de la existencia de la acción. Para hacer esto es necesario sobreescribir el método actions del controlador de la siguiente manera.
class UserController extends CController
{
public function actions()
{
return array(
'remove' => 'application.controllers.user.RemoveAction'
);
}
}
Los filtros.
- Permiten realizar verificaciones y validaciones antes y después de la ejecución de las acciones.
- Una acción puede tener asociados múltiples filtros.
- Los filtros se ejecutan en el orden en que fueron especificados.
- Un filtro puede abortar la ejecución de los demás filtros y de la acción misma.
- De manera análoga a las acciones, los filtros pueden implementarse de dos maneras también.
- Como métodos del mismo controlador.
- Como clases que heredan de CFilter.
Filtros implementados como métodos del controlador.
- El nombre del método debe empezar por la palabra filter.
- Deberá recibir como parámetro a $filterChain.
En el siguiente ejemplo se muestra al controlador User que implementa al filtro checkUser como un método suyo.
class UserController extends CController
{
public function filterCheckUser($filterChain)
{
// Implementación ... invocar $filterChain -> run()
// para continuar con el próximo filtro
}
}
Filtros implementados como clases independientes.
- Los objetos acción heredan de CFilter.
- El nombre de la clase es FiltroIdFilter (por convención, no es obligatorio).
- Se almacena en un archivo bajo la ruta protected/filters/FiltroIdFilter.php.
- Su ubicación puede referenciarse mediante alias de esta manera: application.filters.FiltroIdFilter.
- Es obligatorio sobreescribir los métodos preFilter($filterChain) y postFilter($filterChain) del filtro para definir que hacer antes y después de ejecutar la acción.
En el siguiente código se muestra al filtro isValid del controlador User implementado como una clase independiente.
class IsValidFilter extends CFilter
{
public $admin;
public function preFilter($filterChain)
{
// Se aplica antes de ejecutarse la acción.
// Si retorna true continúa el proceso, false lo
// aborta y no se ejecuta la acción solicitada.
return $exito;
}
public function postFilter($filterChain)
{
// Se aplica después de ejecutarse la acción.
}
}
Esta clase se almacena entonces en el archivo protected/filters/IsValidFilter.php.
Como paso final de su implementación, es necesario indicarle al controlador de la existencia del filtro y determinar su alcance sobre las acciones del mismo. Para hacer esto es necesario sobreescribir el método filters del controlador de la siguiente manera.
class UserController extends CController
{
public function filters()
{
return array(
'checkUser + add, remove',
array(
'application.filters.IsValidFilter - add, remove',
'admin' => false
)
);
}
}
- checkUser es un filtro basado en un método del controlador.
- isValid es un filtro basado en una clase externa.
- Es posible especificar los filtros con una notación de arreglo para determinar valores específicos para los atributos del filtro.
Los operadores + y - actúan como determinadores del alcance de los filtros sobre las acciones especificadas de la siguiente manera.
- + determina exactamente a cuales acciones se les debe aplicar el filtro. De esta manera, el filtro checkUser se aplicará a las acciones add y remove únicamente.
- - determina a cuales acciones NO se les debe aplicar el filtro. Así, el filtro isValid se aplicará a todas las acciones EXCEPTO a add y remove.
- Si no se especifica ninguno de los dos modificadores, el filtro aplicará a todas las acciones del controlador.
Enlaces.
