Foto del dia

Front Controller pattern

Intentando una definicion desde java
El diseño de aplicaciones Web basadas en los Patrones J2EE se organiza alrededor de la utilización de varios elementos: un controlador frontal, dispatchers (despachadores), vistas compuestas (composite views), vistas (JSPs) y los helpers (ayudantes) de las vistas (JavaBeans).

Todos estos elementos se pueden organizar en el siguiente diseño, que ejemplifica un diseño basado en los patrones:



Describamos la función basica de cada uno de estos elementos:

Front Controller (controlador frontal).

Este elemento provee un controlador centralizado para gestionar las peticiones webs a la aplicación. Un controlador frontal recibe todas las peticiones entrantes de los clientes, remitiendo a su vez cada petición al gestor de peticiones (Dispatcher) adecuado, que se encargará de gestionar la construcción de una respuesta adecuada al cliente. Son los puntos ideales para implementar servicios de seguridad, tratamiento de errores, y la gestión del control para la generación de contenidos.

Dispatcher.

Tendremos toda una colección de estos elementos. En cada uno codificaremos la construcción de la respuesta al usuario. Básicamente lo que hacen es componer vistas y configurar estas para que muestren la información adecuada como respuesta a la petición del usuario.

Composite View (Vista Compuesta).

Este patrón hace que la representación de vistas sea más manejable ya que gestiona los diferentes elementos de una página por medio de una plantilla. Frecuentemente, las páginas webs contienen una combinación de contenido dinámico y elementos estáticos, tales como cabeceras, pies, logos, imágenes de fondo, etc. La parte dinámica es particular para cada página, pero los elementos estáticos suelen ser los mismos para todas las páginas. La plantilla de la vista compuesta captura estas características comunes. La integración debe ser dinámica, siendo el Composite View básicamente un layout (diseño, esquema) que componga dicha página.

Vistas (Views).

Se encargan de generar contenido visual específico que responda a las necesidades del usuario. Dichas paginas por lo general estarán parametrizadas de tal forma que muestren diferente información según los parámetros que le mandemos. Por lo general una vista produce un trozo de la página web que recibe el usuario.

View Helper (Ayudante o Auxiliar de Vista).

Un ‘View Helper’ encapsula los trozos de lógica (código de programa) correspondientes a la presentación y al acceso a datos y componentes que necesita una vista, haciendo que la vista permanezca de esta forma mucho más simple, reutilizable y mantenible. La lógica de presentación se encarga de formatear datos para que sean visualizados en una página, mientras que el acceso a datos o componentes implica la obtención de datos.

Diagrama de Participantes y Responsabilidades

Zend_Controller quick start (del manual de zend framework)

Introduccion
Zend_Controller es el corazon del sistema Zend Framework's MVC.
MVC es el soporte para el modelo Model-View-Controller , el cual es un patron de diseño que apunta a separar la logica de la aplicacion de la logica de la presentacion.
Zend_Controller_front implementa a Front Controller pattern, en el cual todas las paticiones son interceptadas por el front controller y despachadas a un Action Controllers individual basados en la URL solicitada.

Descripcion Front Controller Patterns.
El Front Controller maneja todos los requerimientos de una aplicacion basada en Web decidiendo que es lo siguiente que sucederá.
Es un patterns bien conocido en la especificacion de J2EE y comun su uso en frameworks como Jakarta Struts.

Martin Fowler, en "Patterns of Enterprise Application Architecture" realiza un buen trabajo discutiendo en general las entradas y salidas de un Front Controller, las que resume de la siguiente manera:

“Un Front Controller maneja todas las llamadas a un sitio Web, y es generalmente estrucurado en dos partes: un manejador Web( Web handler) y una jerarquia de comandos(a command hierarchy).”

El termino “Web handler” se refiere a la logica que examina las solicitudes entrantes HTTP para recoletar la suficiente informacion para saber que hacer con ella, mientras el “command hierarchy” es una especie de estructura organizacional, donde el Front Controller hace referencia a él, para decidir que es lo proximo a hacer, basado en la informacion brindada por el “Web handler”.

El sistema de Zend_Controller fue construido pensando en su extensibilidad, donde podemos realizar sub clases de las clases existentes, escribiendo las nuevas clases que ponen en ejecucion las diversas interfaces y las clases abstractas que forman el conjunto de clases de la familia controller, o escribiendo plugins o action helpers para aumentar o para manipular la funcionalidad del sistema.

Ejemplo.
Crear la siguiente estructura de directorios.

application/
    controllers/
        IndexController.php
    models/
    views/
        scripts/
            index/
                index.phtml
        helpers/
        filters/
html/
    .htaccess
    index.php

Ahora en tu web server, señala tu documento raiz al directorio HTML de la disposición antedicha del sistema de ficheros.

Crea tus reglas rewrite
editar el html/.htaccess para que quede de la siguiente manera.

RewriteEngine on
RewriteRule !\.(js|ico|gif|jpg|png|css)$ index.php

Las reglas antedichas encaminarán cualquier petición del "no-recurso" (imágenes, stylesheets) al front controller. Si existen otras extensiones que desea excluir del front controller (PDF's,text files,etc), agregue esas extenciones al switch, o cree sus propias reglas rewrite.

Cree su propio archivo bootstrap
El archivo bootstrap es la pagina donde todos los requerimientos son ruteados --html/index.php en nuestro ejemplo.
<?php
require_once 'Zend/Controller/Front.php';
Zend_Controller_Front::run('/path/to/app/controllers')

Antes de discutir las acciones del controlador, deberiamos primero entender como las solicitudes son ruteadas en Zend Framework. Por defecto, el primer segmento del la URL mapea el controlador, y el segundo la accion. Por ejemplo dada la siguiente URL http://framework.zend.com/roadmap/components, el camino es /roadmap/components, la cual mapeara el controlador roadmap y la accion components.
En el caso de no proporcionar una accion, la accion index is asumida, y si no se ha proporcionado un controlador, el controlador index es asumido, (después de la convención de Apache que mapea un DirectoryIndex automáticamente).

El despachador de Zend_Controller despues toma el valor controlador y lo mapea a su clase. Por defecto, toma el nombre del controlador y le agrega la palabra controller. En el caso anterior el controlador roadmap es mapeado a la clase RoadmapController

De manera similar la "accion" es mapeada al metodo de la clase controladora. Por defecto, el valor es en minusculas, y luego la palabra "Action" es agregada. En nuestro ejemplo la accion components se transforma en componentsAction, y el metodo final es llamado de la sigiente manera:
RoadmapControler::componentsAction();

Vamos a crear una accion controladora por defecto y un metodo accion. Como lo mencionamos con anterioridad, el controlador por defecto y la accion son llamados ambos "index". Abrimos el archivo application/contollers/IndexController.php, y digitamos lo siguiente

<?php 


/** Zend_Controller_Action */
require_once 'Zend/Controller/Action.php';

class IndexController extends Zend_Controller_Action
{
    public function indexAction()
    {
    }
}

Por defecto la accion del ayudante ViewRenderer esta habilitada. Lo qie esto significa es que simplemete definiendo un metodo action y su correspondiente script view, se obtendra inmediatamente el contenido volcado. Por defecto , Zend_View es usado como la capa de vista(view layer) del MVC. El VewRenderer hace algo magico, y usa el nombre del controlador (ej. index) y su actual nombre de accion (ej. index) que template usar. Por defecto los template tienen la extension .phtml, esto significa que , en el ejemplo anteriror, el template index/index.phtml sera ejecutado, adicionalmente el ViewRenderer automaticamente asume que el directorio de las vistas , y que el el actual view script estaran en el subdirectorio /views/scripts/, ademas, el templete mostrado lo podremos encontrar en application/views/scripts/index/index.phtml.

Creando nuestro View Script

Como mencionamos anteriormente , los view scripts son encontrados en application/views/scripts/; el ciew script por defecto para el controlador y la accion estan en application/views/scripts/index/index.phtml, por lo tanto vamos a crear este archivo y escribirle agun codigo html:

<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <title>My first Zend Framework App</title>
</head>
<body>
    <h1>Hello, World!</h1>
</body>
</html>   

Crear nuestro controlador de errores (error controller)
por defecto esta registrado el plugin manejador de errores. Este plugin espera que exista un controlador para el manejo de errores. Por defecto. este asume un ErrorController en el modilo por defecto con un metodo errorAction:

<?php
/** Zend_Controller_Action */
require_once 'Zend/Controller/Action.php';

class ErrorController extends Zend_Controller_Action
{
    public function errorAction()
    {
    }
}

Si se asume que la disposición de directorios es la ya discutida, este archivo entrará en application/controllers/ErrorController.php. Tambien se necesitara crear un view script en application/views/scripts/error/error.phtml, donde el contenido de ejemplo puede lucir de la siguiente forma.

<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>

  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <title>Error</title>
</head>
<body>
    <h1>An error occurred</h1>

    <p>An error occurred; please try again later.</p>
</body>
</html>

Vista del sitio
Con tu primer controlador y vista (view) bajo nuestro dominio, puedemos ahora acceder desde nuestro browser y hojear al sitio. Si se asume que example.com es tu dominio,accediento a cualquiera de las siguientes URL's obtendremos la pagina que acabamos de crear.
*http://example.com/
*http://example.com/index
*http://example.com/index/index

Clase Zend_Loader (extraido del manual oficial de Zend_Framework)

La clase Zend_Loader incluye metodos para ayudarte a cargar archivos dinamicamente.

Zend_Loader vs. require_once()
El metodo Zend_Loader es usado si el nombre de archivo que necesitas cargar es variable.
Por Ejemplo si éste se basa en un parametro en una entrada de usuario , o pasado como argumento de un metodo.
Si estas cargando un archivo o una clase cuyo nombre es "constante", no existen beneficios de Zend _loader sobre el uso tradicional de funciones PHP como lo puede ser "requiere_once()"

Cargando archivos
El metodo estatico Zend_Loader::loadFile() lee un archivo PHP que pude contener cualquier tipo de codigo PHP.
El metodo es un wrapper (lo que se define como un pequeño programa o script, escrito para encapsular grandes programas),para la funcion de PHP include(). Este metodo lanza Zend_Exception en una falla, por ejemplo:si el archivo especificado no existe.


Ejemplo del metodo loadFile()


<?php
Zend_Loader::loadFile($filename, $dirs=null, $once=false);


el parametro o argumento $filename especifica el archivo a ser leido, el cual no debe contener ninguna informacion de su ubicacion. Un chequeo de seguridad es ejecutado sobre $filename en donde éste solo debe contener caracteres alfanumericos,o tambien dashes ("-"), underscores ("_"), o puntos ("."). No se pone ninguna otra restriccion en la discusion de $dirs.

El argumento $dirs especifica el directorio donde sera buscado el archivo, si este es NULL, solamente el es buscado en include_path. Si existe un string o un array, con directorio o directorios el archivo será buscado en los mismos y por ultimo en el include_path.

El argumento $once es booleano. Si éste es TRUE Zend_Loader::loadFile() usa la funcion de PHP include_once() para leer el archivo,de lo contrario la funcion include() sera usada.

Cargando Classes
El metodo estatico Zend_Loader::loadClass($class, $dirs) lee una archivo de clase PHP y despues chequea la existencia de la clase.

Ejemplo del metodo loadClass()


<?php

Zend_Loader::loadClass('Container_Tree',
array(
'/home/production/mylib',
'/home/production/myapp'
));

?>


El String que especifica la clase es convertido a un path relativo mediante la sustitucion de los directorios separados por 'underscores' y agregandole '.php'. En el ejemplo anterior, 'Container_Tree' se transforma en 'Container/Tree.php'.

El argumento $dirs puede ser un string o un array, Zend_Loader::loadClass()
busca los directorios en el orden suministrado. El primer archivo encontrado es leido. Si el archivo no existe en $dirs, entonces es buscado en el include_path del entorno PHP

Si el archivo no es encontrado o la clase no existe ,entonces Zend_Loader::loadClass() lanza Zend_Exception.

Zend_Loader::loadFile() es usado para la carga , pero el nombre de la clase solo puede contener caracteres alfanumericos y el hyphen ('-'), underscores ('_'), y el punto('.').

Testeando si un archivo es leible.

El metodo estatico Zend_Loader::isReadable($pathname) retorna TRUE si el archivo especificado en $pathname existe y es leible, de lo contrario FALSE .

Ejemplo del metodo isReadable()

<?php

if (Zend_Loader::isReadable($filename)) {
// do something with $filename
}


El argumento $filename especifica el archivo a ser chequeado. Este puede contener informacion del camino.
Este metodo es un wrapper para la funcion PHP is_readable(). La funcion PHP

no busca

en include_path, mientras Zend_Loader::isReadable() si lo hace.

Usando el Autoloader
La clase de Zend_Loader contiene un método que puede colocarse con el autoloader del SPL de PHP. Zend_Loader::autoload() es un método de servicio repetido. Como conveniencia, Zend_Loader proporciona el registro de la función del registerAutoload() su método autoload(). Si la extensión del spl_autoload no está presente en tu ambiente de PHP, entonces el método del registerAutoload() lanza un Zend_Exception.

Ejemplo de registracion del metodo autoloader

Ejemplo del metodo isReadable()

<?php

Zend_Loader::registerAutoload();



despues de registrar el Zend Framework autoload callback,puedes referenciar las clases desde Zend Framework sin tenerla que cargarlas explicitamente. El metodo autoload() usa Zend_Loader::loadClass() automaticamente cuando la clase es referenciada.

Si has extendido la clase Zend_Loader, tu puedes darle un argumento opcional al registerAutoload(), para especificar la clase de la cual colocar un método del autoload().

Ejemplo de registrando el metodo autoload callback desde una clase extendida

Debido a la semantica de las referencias estaticas en PHP, debes implementar codigo para ambas loadClass() y autoload(); y el autoload() debe llamar self::loadClass(). Si el metodo autoload() delega a su padre el llamar a self::loadClass(), entoces llama al metodo con ese nombre en la clase del padre, no en la subclase.


Ejemplo del metodo isReadable()

<?php

class My_Loader extends Zend_Loader
{
public static function loadClass($class, $dirs = null)
{
parent::loadClass($class, $dirs);
}

public static function autoload($class)
{
try {
self::loadClass($class);
return $class;
} catch (Exception $e) {
return false;
}
}
}
Zend_Loader::registerAutoload('My_Loader');


Empezando con Zend - Framework

Bootstrapping (Configuración de Arranque)
El controlador (controller) de Zend FrameWork, Zend_Controller se diseño para ofrecer sitios Web con direcciones url claras. Para lograr esto, todas las peticiones deberán ser procesadas únicamente por un archivo index.php. Asi se ofrece un punto central para todas las páginas de la aplicación y asegura la instalación de un ambiente correcto para ejecutar la aplicación. Esto se logra mediante el uso de un archivo .htaccess (que es utilizado por el modulo mod_rewrite del servidor web apache)dentro del directorio raíz de zf-tutorial:
zf-tutorial/.htaccess
RewriteEngine on
RewriteRule .* index.php
php_flag magic_quotes_gpc off
php_flag register_globals off

Funcionamiento
Apache usa archivos con el nombre de .htaccess para que el administrador de las páginas web pueda definir una serie de parámetros de configuración para su espacio. Deben estar ubicados en el directorio sobre el que quieras aplicar esa configuración.

Crear este tipo de archivos en plataformas Microsoft Windows puede ser un problema, ya que este no permite poner archivos sin nombre pero ello no significa que no se pueda hacer.

El archivo se puede crear de varias maneras, utilizando PHP bastaria con poner algo como lo siguiente para crear el archivo:
<?php
touch('.htaccess');
?>

Comprobar que tenemos activado mod_rewrite
Podemos hacer lo siguiente

<?php
echo phpinfo();
?>

Si Apache está como módulo de PHP entonces podemos revisar en los módulos que tiene cargados, en el cual mod_rewrite está entre ellos.

Configuracion .htaccess
Como primer paso deberemos poner al principio del archivo .htaccess la cadena RewriteEngine On, que se encarga de activar el módulo de reescritura, tras poner esto ya debemos poder empezar a escribir nuestras reglas para formatear las direcciones como nos plazca. A veces puede ser necesario poner un Options FollowSymLinks antes para que funcione, de modo que quedaría así:

Options FollowSymLinks
RewriteEngine On


Funciones o comandos del mod_rewrite

La sintaxis de los comandos del mod_rewrite es bastante sencilla y rápida de entender. Los comandos empiezan con Rewrite y normalmente el patrón de sintaxis es el siguiente:

Comando Parámetro1 Parámetro2

Aunque en algunos casos varía ligeramente, como se verá a continuación:

RewriteEngine
Solo acepta dos valores para su único parámetro: On y Off. Le dice a Apache una vez puesto en el .htaccess si debe o no iniciar el motor de reescritura. Está desactivado por defecto.

#Para activar la reescritura
RewriteEngine On

RewriteBase
Nos permite ajustar una "base" para las rutas que escribamos. Lo que hace es añadir a las rutas siguientes el prefijo que indiquemos, esto puede ahorrar mucho espacio y es necesario muchas veces al no encontrarse el archivo .htaccess en el mismo directorio sobre el que se quiere aplicar (por eso es recomendable ponerlo ahí).
ejemplo
RewriteRule ^/pagina/index.xml$ /pagina/xml.php?generar=xml
#Con RewriteBase nos podemos ahorrar el /pagina/ de la siguiente forma:
RewriteBase /pagina/
RewriteRule ^index.xml$ xml.php?generar=xml


RewriteCond
Permite definir sentencias condicionales, la sintaxis es muy simple y fácil de entender. Se pueden unir varias condiciones con el modificador OR.

A continuación de este comando se debe poner o bien otro RewriteCond (usando el modificador para unirlos) o bien un RewriteRule, que es el que se debe ejecutar en última instancia en caso de cumplirse la(s) condicion(es). En caso de no cumplirse la condición el RewriteRule sería ignorado.

#RewriteCond Cadena Patrón
#Si la dirección contiene "pepe" se ejecuta el RewriteRule que habría debajo
RewriteCond %{REQUEST_URI} pepe

RewriteRule
Posiblemente este sea el comando que más usaremos. Es el pilar para lo que queremos hacer, ya que de el depende que se lleve a cabo la reescritura.
Lo que hace es simple: le das un patrón y una URI de destino, si el patrón coincide se llama a la URI especificada con los parámetros que se haya indicado. Las referencias hacia los valores agrupados con paréntesis en las expresiones regulares del patrón pueden ser referidas como $1, $2… hasta $9.

Aquí es donde las expresiones regulares juegan un papel importante, al ser con lo que haremos los patrones de comparación. Es importante conocer su sintaxis básica y poder manejarse con soltura para crear reglas efectivas.


Modificadores de RewriteRule
Esto son las flags de las que se habla en el manual oficial,a los cuales los llamaremos modificadores. Los modificadores sirven para añadir características extra a ciertos comandos del mod_rewrite, como RewriteRule o RewriteCond.

Cada comando tiene sus propios modificadores. Se ponen entre corchetes, tras un espacio al final del comando y se separan (en caso de especificar más de uno) con comas y sin espacios.

Solo mencionaremos los pertenecientes a RewriteRule que me parecen más útiles para lo que estamos haciendo.

Por encima, los modificadores que más nos interesan son los siguientes:
nocase (NC)
Este útil modificador hará que las expresiones regulares (o simplemente cadenas literales) que pongamos como patrón sean case-insensitive, es decir, que no se distinga entre mayúsculas y minúsculas. Esto nos puede venir bien muchas veces.
redirect (R[=codigo])
Permite redireccionar a una dirección con un código concreto de respuesta del protocolo HTTP. El rango, según el manual oficial, debe estar entre el código 300 (HTTP_MULTIPLE_CHOICES) y 400 (HTTP_BAD_REQUEST). Para conocer el significado de esas constantes y los códigos que puedes usar debes consultar este protocolo.

Suele interesar que, al redireccionar por este metodo, el archivo .htaccess no siga siendo interpretado, para lo que usaremos el modificador L.

Por defecto, si no se especifica un codigo, se pone automáticamente el 302 (MOVED TEMPORARILY).

last (L)
Este modificador hace que la condición, en caso de que se cumpla, sea la última en interpretarse del archivo. En caso de no cumplirse seguirá su curso normal. Es bueno especificarlo casi siempre, ya que le va a ahorrar a Apache la interpretación del resto de reglas.

Construcción de reglas o patrones
Puedes construir tantas reglas como quieras, pero ten en cuenta que, cuanto más pesado el archivo, más le costará de interpretar a Apache. No se recomienda que pases de los 2KB (que ya es mucho).

Se usan patrones basados en expresiones regulares (de tipo POSIX a partir de Apache 1.2.x) de manera que, si coinciden, se redirija al archivo que especifiquemos. Es realmente simple crear expresiones regulares para hacer las URIs como las de esta página. Dos buenos manuales para aprender a hacer expresiones regulares efectivas son los siguientes:

* Expresiones regulares, por Iván Arias
* Expresiones regulares en Ignside

Es muy importante que delimitemos el rango de caracteres correcto acorde a nuestra necesidad. Si necesitamos obtener un número… ¿para que permitir letras u otros símbolos en el patrón? Esto nos ahorrará quebraderos de cabeza posteriores en lo referente a la seguridad de la aplicación final.

También suele ser necesario que, en las direcciones que puedan terminar con o sin barra, indiquemos esta eventualidad (es decir, que pongamos la barra del final como caracter opcional), algo como lo siguiente:
RewriteRule ^seccion/([0-9]+)/?$ index.php?seccion=$1

En el caso de que la barra opcional no está contemplada y es escrita en la dirección se lanzaría un error de tipo 404 (Página no encontrada).

Ejemplos de la vida real
Lo que vamos a hacer en el siguiente ejemplo es obtener y enviar un identificador numérico a partir de una URL de tipo example.com/articulo/identificador_numérico, o sea, tomar el número y pasárselo a una aplicación:

RewriteEngine On
RewriteRule ^articulo/([0-9]+)/?$ articulos.php?id=$1 [L]

Si quisieramos obtener el nombre de la sección de ese artículo (a partir de una dirección tipo example.com/articulo/sección/identificador_numérico) sería muy sencillo también:
#La sección puede contener letras, guiones y guiones bajos
RewriteRule ^articulo/([a-z_-]+)/([0-9]+)/?$ articulos.php?seccion=$1&id=$2 [NC,L]

Ojo porque el identificador ya no está en $1, sino en $2, ya que es el segundo grupo de captura que hemos indicado. Al interesarnos tanto letras minúsculas como mayúsculas debemos poner el modificador NC.

Problema común y final del escrito
Suele pasar que al usar el mod_rewrite por primera vez, después de haber hecho funcionar sus primeros patrones, etc. diga… ¡No me funcionan los enlaces! ¡No me carga la hoja de estilos! Bien, esto es muy fácilmente solucionable y totalmente previsible. Solo debemos poner la dirección "base" de la página hacia el dominio principal y hacer las demás rutas relativas. Para esto tenemos el elemento <base />de XHTML:
<head>
<base href= "http://www.example.com/" />
…
</head>

Para obtener infomracion mas detallado sobre el comando modrewrite.com y sus foros de ayuda
Tambien podemos utilizar la siguiente pagina como wizard de ayuda para crear sentencias http://www.mod-rewrite-wizard.com/

Como activar el modulo mod_rewrite en XAMPP
editar el archivo xampp\apache\conf\httpd.conf
busca la linea #LoadModule rewrite_module modules/mod_rewrite.so y quitarle el simbolo # , como paso siguiente se debe reiniciar el servidor apache