Conceptos Básicos de Zend_Controller
El sistema Zend_Controller está diseñado para
ser liviano, modular y extensible. Se trata de un diseño minimalista
para permitir flexibilidad y cierta libertad para los usuarios
proporcionando al mismo tiempo suficiente estructura para que sistemas
construidos alrededor de Zend_Controller
compartan algunas convenciones y layouts de código similares.
El siguiente diagrama muestra el flujo de trabajo, y la narrativa
que le sigue describe en detalle las interacciones:
El workflow de Zend_Controller está implementado
por varios componentes. Si bien no es necesario entender los cimientos
de todos estos componentes para utilizar el sistema, tener un
conocimiento práctico del proceso es de mucha utilidad.
Zend_Controller_Front orquesta todo
el workflow del sistema Zend_Controller.
Es una interpretación del patrón FrontController.
Zend_Controller_Front procesa todas
las solicitudes recibidas por el servidor y es responsable
en última instancia para delegar requerimientos a los
ActionControllers
(Zend_Controller_Action).
Zend_Controller_Request_Abstract (a
menudo denominado Request Object) representa
el medio ambiente de la solicitud y ofrece métodos para
establecer y recuperar el controlador, los nombres de
acción y cualquier parámetro de solicitd. Además mantiene
la pista de si la acción que contiene ha sido enviada o no
por Zend_Controller_Dispatcher.
Se pueden uar extensiones del objeto abstracto para
encapsular toda el medio ambiente de la solicitud,
permitiendo a los routers traer información del medio
ambiente de la solicitud a fin de establecer el controlador
y los nombres de acción.
Por defecto, se usa
Zend_Controller_Request_Http, que
proporciona acceso a todo el medio ambiente de la petición
HTTP.
Zend_Controller_Router_Interface
se usa para definir routers. El ruteo es el proceso de
examinar el medio ambiente de la solicitud para determinar
qué controlador, y qué acción del contralor debe recibir
la solicitud. Este controlador, la acción, y los parámetros
opcionales son luego establecidos en el objeto solicitud
para ser procesados por
Zend_Controller_Dispatcher_Standard.
El ruteo (routing) ocurre sólo una vez: cuando la solicitud
se recibie inicialmente y antes de despachar el primer
controlador.
El router por defecto,
Zend_Controller_Router_Rewrite,
toma el punto final de una URI como se especidicó en
Zend_Controller_Request_Http
y la descompone en un controlador, acción y parámetros
basados en la información del path en la url.
Como ejemplo, la URL
http://localhost/foo/bar/key/value se
decodificará para usar el controlador foo,
la acción bar y especificar un parámetro
key con el valor de value.
Zend_Controller_Router_Rewrite
también puede ser utilizado para igualar paths arbitrarios;
para más información, ver documentación
del router.
Zend_Controller_Dispatcher_Interface
se usa para definir despachadores. Despachar es el proceso
de sacar el controlador y la acción del objeto solicitud y
mapearlo a un controlador archivo/clase y al método acción
en la clase del controlador. Si el controlador o acción no
existen, hará un manejo para determinar los controladores
por defecto y las acciones a despachar.
El proceso actual de despacho consta de instanciar la
clase del controlador y llamar al método acción en esa
clase. A diferencia del routing, que ocurre sólo una vez,
el despacho ocurre en un bucle. Si el status del objeto
solicitud despachado es reseteado en cualquier punto,
el bucle se repetirá, llamando a cualquier acción que esté
actualmente establecida en el objeto solicitud.
La primera vez el bucle termina con el objeto solicitud,
el status de lo despachado se establece a (booleano true),
que terminará el procesamiento.
El despachador por defecto es
Zend_Controller_Dispatcher_Standard.
Se definen como controladores MixedCasedClasses cuando
terminan en la palabra Controller, y los métodos de acción
como camelCasedMethods cuando terminan en la palabra Action:
FooController::barAction(). En este caso,
el controlador será referido como foo y a la
acción como bar.
Convenciones para Case Naming
Dado que los humanos somos notablemente inconsistentes
en mantener cierta sensibilidad respecto a las
minúsculas y mayúusculas al escribir enlaces,
Zend Framework realmente normaliza ls información del
path a minúsculas. Esto, por supuesto, afectará cómo
nombre usted a su controlador y acciones... o referirse
a ellos en los enlaces.
Si desea que su clase controlador o el nombre del
método de la acción tenga múltiples MixedCasedWords o
camelCasedWords, para separar las palabras en la RUL
necesitará hacerlo con un '-' o '.' (aunque puede
configurar el carácter utilizado).
Como ejemplo, si se va a la acción en
FooBarController::bazBatAction(),
se referirá a ella en la URL como
/foo-bar/baz-bat
o /foo.bar/baz.bat.
Zend_Controller_Action
es el componente base del controlador de acción.
Cada controlador es una sola clase que extiende la
Zend_Controller_Action class
y debe contener uno o más métodos de acción.
Zend_Controller_Response_Abstract
define una clase base de respuesta utilizada para recoger y
retornar respuestas de los controladores de acción.
Recoge tanto a las cabeceras como al contenido del cuerpo.
La clase respuesta por defecto es
Zend_Controller_Response_Http,
la cual es adecuada para usarla en un entorno HTTP.
El workflow de Zend_Controller es relativamente
sencillo. Una solicitud es recibida por
Zend_Controller_Front, la que a su vez llama a
Zend_Controller_Router_Rewrite
para determinar qué controlador (y la acción en ese contralor)
despachar.
Zend_Controller_Router_Rewrite
descompone la URI a fin de establecer el controlador y el nombre de
acción en la solicitud.
Zend_Controller_Front
entonces entra al loop de despacho. Llama a
Zend_Controller_Dispatcher_Standard,
le pasa la solicitud para despachar al contralor y a la acción
especificada en la solicitud (o el usado por defecto).
Después de que el contralor ha terminado, el control vuelve a
Zend_Controller_Front.
Si el contralor ha indicado que debe despacharse otro controlador
mediante el reinicio de la condición (status) de la solicitud,
el bucle continúa y se ejecuta otro despacho.
En caso contrario el proceso termina.