En un proyecto, estaba utilizando Zend_Date para manejo de horas en diferentes zonas horarias, cuando lo estaba desarrollando empecé a tener un error porque olvidé que la fecha se actualiza cuando cambias un parámetro y el problema surge cuando cambias el mes o día y se encuentra con una fecha inexistente aunque en el código parezca correcta, por ejemplo, supongamos que estamos en el mes de febrero y queremos crear una fecha de marzo (asignaré la fecha para reproducir el error, aunque el error es cuando se utiliza la fecha actual)

include_once("Zend/Date.php");
$fecha_febrero = mktime(0, 0, 0, 2, 1, 2010);
$fecha = new Zend_Date($fecha_febrero);
$fecha->setDay(31);
$fecha->setMonth(3);
print "Fecha Marzo: ".date("d/m/Y", $fecha->getTimestamp());

Uno esperaría que el resultado fuera: 31/03/2010

Pero en su lugar mostrará 03/03/2010

Esto es porque al hacer $fecha->setDay(31) el sistema intenta crear la fecha: 31/02/2010 que no existe, por lo que “recorre” los días restantes para quedar en 03/03/2010, al asignar el mes, no tiene efecto.

La solución es simplemente hacerlo en orden inverso:

include_once("Zend/Date.php");
$fecha_febrero = mktime(0, 0, 0, 2, 1, 2010);
$fecha = new Zend_Date($fecha_febrero);
$fecha->setMonth(3);
$fecha->setDay(31);
print "Fecha Marzo: ".date("d/m/Y", $fecha->getTimestamp());

Eso parecería la solución ideal (y es la recomendada por la documentación), pero no es totalmente cierta, si por ejemplo estamos en enero 31 del 2010 e intentamos asignar una fecha de febrero, siempre obtendremos una fecha de marzo:

include_once 'Zend/Date.php';
$fecha_enero = mktime(0, 0, 0, 1, 31, 2010);
$fecha = new Zend_Date($fecha_enero);
$fecha->setMonth(2);
$fecha->setDay(10);
print "Fecha Febrero: ".date("d/m/Y", $fecha->getTimestamp());

Uno esperaría que mostrara la fecha:
10/02/2010

Pero en realidad muestra
10/03/2010

Esto porque cuando asignamos el mes, el sistema intenta crear la fecha 31/03/2010 que una vez más es incorrecta, por lo que crea la fecha 03/03/2010, pero al asignar la fecha, el resultado es un error en el mes.

Aunque esto no es un error, es muy peligroso porque uno puede suponer que la fecha es correcta porque en el código lo parece, la solución sin embargo es trivial, asignar el primer día de un mes que tenga 31 días y asignar los valores en orden inverso (primero año, luego mes y por último día), así el código sin error sería:

include_once 'Zend/Date.php';
$fecha = new Zend_Date(0, 0, 0, 1, 1, date('Y'));
$fecha->setMonth(2);
$fecha->setDay(10);
print "Fecha Febrero: ".date("d/m/Y", $fecha->getTimestamp());

Resultado (el esperado)
10/02/2010

Esto funciona en la mayoría de los casos; aunque si van a manejar diferentes zonas horarias mediante setTimezone() el código anterior tendrá el mismo error en los casos que la zona horaria sea menor a la zona horaria del servidor, por lo que hay que hacer algo más elaborado:

include_once 'Zend/Date.php';
$fecha = new Zend_Date();
//eliminar "errores"
$fecha->setTimezone('mi_codigo_zona_horaria');
$fecha->setDay(1);
$fecha->setMonth(1);

//nuestro código
$fecha->setMonth(2);
$fecha->setDay(10);
print "Fecha Febrero: ".date("d/m/Y", $fecha->getTimestamp());

Lo peligroso del comportamiento de Zend_Date es que funcionará con errores durante algunos días/meses dependiendo de la manera en como se programe y es un poco difícil de diagnosticar por su misma naturaleza, con esto se elimina cualquier tipo de errores.

Hace poco Zend publicó la certificación de Zend Framework:
http://www.zend.com/en/services/certification/framework/

Estoy algo divergente entre si es una buena opción o no

Buena opción:

• El Framework está muy bien hecho como para que valga una certificación
• Tiene tantos componentes que es una buena medida para destacar entre los que han utilizado solamente brevemente el Framework

Mala opción

• Cuesta más que la certificación en PHP ($160 dolares en contra de $125 para la certificación de PHP)
• Lamentablemente la certificación es en la versión 1.5 y la versión estable es la versión 1.6, si bien la versión 1.5 ya tenía muy estandarizado el modelo del Framework, a menos que tengan un periodo largo de liberar versiones (lo cual puede ser malo ya que ahora hay mucho movimiento) en menos de un año seguramente saldran al menos un par de versiones por lo que ¿se va a certificar en cada version? =P

Me acabo de dar cuenta que ya hay una nueva versión estable de Zend Framework, la 1.6.

Al parecer lo más novedoso es la incorporación de Dojo y la incorporación de SOAP. En lo particular no uso Dojo, pero vale la pena probar estos cambios.

No planeaba “actualizar” tan rápidamente, pero me acabo de dar cuenta que hay un bug en las versiones de 1.5.* que cuando Zend_Db lee un campo tipo LONGBLOB trata de reservar en una variable todo el tamaño máximo del longblob (aproximadamente 4GB) algo que hará tronar a PHP y marcará un fatal error.

Como estoy trabajando en un proyecto con LONGBLOB decidí actualizar, más adelante escribiré mis experiencias con los nuevos componentes, que SOAP es algo que tengo que probar =).

Bug de Zend Framework:http://framework.zend.com/issues/browse/ZF-1498

Descargar Zend Framework 1.6

MVC es un acrónimo para Model-View-Controller (Modelo-Vista-Controlador); esta es un patrón de arquitectura de software.

Básicamente este patrón divide una aplicación (en nuestro caso una aplicación web) en tres partes:

• Modelo
  Es la parte que se entenderá con la base de datos, una manera elegante y clara de separar esto, es que para cada tabla generar una clase que será su Modelo, aunque en realidad podría ser que un Modelo controle varias tablas que tengan mucho en común, por ejemplo para las relaciones muchos-a-muchos.
• Controlador
  Se encarga de procesar la entrada del usuario, en nuestro caso de recoger los datos de formularios, la URL, etc. Procesarlos (utilizando los otros componentes ya que esta parte debería ser la única que se comunica con los demás y las otras partes deben estar aisladas) y producir un resultado.
• Vista
  Es la parte que maneja la parte que el usuario verá, el caso más común es tener una página en HTML, pero las posibilidades son que podemos tener incluso páginas en WAP (contenido móbil) o representaciones de texto. El controlador procesará todo lo necesario y enviará sus resultados a la vista (en el caso de Zend Framework mediante asignación de variables). La vista procesará todos los datos de una manera que sean claros para el usuario (aunque una vez más, esto podría ser incluso tener como salida por ejemplo XML para una API para comunicación entre librerías)

En este tutorial veremos de manera introductoria como funciona el patrón de MVC con Zend Framework. Antes de ver el código, mostraremos como funciona básicamente Zend Framework con MVC mediante el siguiente esquema:

En el esquema el primer paso es cuando accedemos a una dirección, por ejemplo http://www.danguer.com/ajax/resultado

La configuración de Zend Framework mediante Apache utilizando Mod_Rewrite hace que la mayoría de ligas (con algunas excepciones por ejemplo extensiones de hojas de estilo, javascript, etc) las procese el archivo index.php que contiene el código básico para inicializar el MVC que veremos más adelante.

Este archivo index.php tiene un código básico para inicializar toda la aplicación web, lo cual es ya de entrada interesante. Para la estructura de directorios será de la siguiente manera:

Tendremos la carpeta principal app/ que será donde irá todo el código de PHP, dentro de esta carpeta tenemos varias carpetas pero las principales son:

• controllers, donde estará el código de los controladores
• models, donde estará el código de los modelos (no lo utilizaremos)
• layout, las plantillas para el sitio (parte de las vistas)
• views, las vistas junto con “ayudantes” (helpers)

La carpeta adicional langs, es una carpeta opcional y personal que he dejado del ejemplo de tutorial con Zend_Form, solo para ilustrar que se pueden crear carpetas adicionales sin problemas.

Como nota personal a mi me gusta dejar código que es necesario dentro de la carpeta /app, en el ejemplo se puede ver el archivo: Danguer_Controller_Action.php que después veremos a detalle. Esto es totalmente preferencia personal de como estructurar el archivo.

Después de la carpeta /app, hay una carpeta styles/ que contiene archivos CSS, en realidad la carpeta no será visible para el usuario ya que http://sitio/styles intentará interpretarlo como código PHP mediante controladores como veremos más adelante.

Hay sugerencias de seguridad de como estructurar estas carpetas, pero en lo personal para mis desarrollos utilizo la estructura mostrada para no separar por completo el código y tenerlo todo en un solo lugar.

El archivo realmente importante es index.php y por supuesto .htaccess, el primero tiene el código de manejo para el MVC de Zend Framework y el segundo es un archivo para que Apache redireccione todas las peticiones al archivo index.php

Contenido del archivo index.php y .htaccess

El archivo .htaccess es muy simple, debido a que solamente habilita Mod_Rewrite y redirecciona todas las peticiones al archivo index.php:

RewriteEngine on

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

La primera linea habilita Mod_Rewrite, la otra linea indica que salvo las ligas que contengan las extensiones js, ico, gif, jpg, png, css y swf deben procesarse con el archivo index.php, aqui se puede hacer que por ejemplo se habiliten algunos directorios para no ser procesador por el archivo index.php (por ejemplo un directorio de imagenes), pero esto debe ser tratado con cada caso en particular.

El archivo index.php contiene más lineas, pero son muy sencillas:

require_once 'Zend/Controller/Front.php';
require_once 'Zend/Layout.php';

require_once './app/Danguer_Controller_Action.php';

// Configurar controlador
$controller = Zend_Controller_Front::getInstance();
$controller->setControllerDirectory('./app/controllers');
$controller->throwExceptions(true); 

// asignar MVC
Zend_Layout::startMvc(array(
    'layoutPath' => './app/layouts',
    'layout' => 'principal'
	));

// ejecutar!
$controller->dispatch();

Las primeras lineas llaman las librerías necesarias que son el “despachador” de los controladores (Zend/Controller/Front.php) y la plantilla (Zend/Layout.php) la otra línea requiriendo un archivo en php (./app/Danguer_Controller_Action.php) será discutido más adelante, pero en esta parte podemos incluir todas los archivos/librerías que necesitemos, tanto de Zend como propios.

La siguiente línea de código genera el despachador, básicamente genera una instancia de este despachador (es única para toda la aplicación, por eso utilizamos de manera estática sin construirlo), asignamos el directorio de los controladores (./app/controllers) y por último permitimos que muestre excepciones por ser código en desarrollo (en producción se sugiere no utilizarlo para no dejar ver código importante a los usuarios).

La siguiente parte tiene como misión inicializar el sistema MVC de la parte de la plantilla. Anteriormente Zend Framework no manejaba plantillas en sus vistas, algo odioso porque se necesitaba crear un código propio (aunque había buenos ejemplos en la red). Actualmente con esa línea podemos definir la plantilla que utilizarán las vistas. Más adelante veremos como está hecha la plantilla.
Con ese código hemos definido que el sistema debe buscar en el directorio ./app/layouts las plantillas, y que la plantilla por defecto es ‘principal’ que el archivo debe llamarse: ./app/layouts/principal.phtml

Con esto el sistema llamará a los controladores de la manera que veremos en la siguiente sección.

Proceso del MVC

Zend Framework una vez que tenga la liga (en este caso /ajax/resultado) procederá a “enrutarla”, es decir a convertir la liga en el controlador y acción deseada. Si no modificamos nada, por defecto el enrutamiento funciona de la siguiente manera:

http://sitio/controlador/accion

Así en nuestro ejemplo, el controlador es “ajax” y la acción es “resultado“. Por supuesto se pueden definir rutas alternativas, por ejemplo se puede decir que http://sitio/blog/2008 sea el controlador “blog“, la acción “archivos” y pasarle a la acción un parámetro de nombre “annio” con el valor 2008. Esto podría ser un alias de: http://sitio/blog/archivos?annio=2008 que funciona bajo la configuración estándar

El ruteador puede ser tan personalizado que podemos pasar nuestro propio ruteador siempre y cuando se extienda de la interfaz: Zend_Controller_Router_Interface, o en su defecto que extienda la clase Zend_Controller_Router_Abstract, pero esto son temas avanzados que podemos discutir en otro tutorial =).

Una vez que el sistema sabe que controlador y acción es, procederá a llamar al controlador y a la acción. El controlador debe ser especificado de la siguiente forma:

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

class ControladorController extends Zend_Controller_Action {
    public function accionAction() {
         //codigo del controlador
    }
}

En donde el nombre de la clase debe ser el nombre del controlador iniciando con mayúscula y seguido por ‘Controller‘ (sin espacios) y cada nombre de función debe ser el nombre de la acción seguido por ‘Action‘ (sin espacios). El nombre del archivo debe ser igual que el nombre de la clase y se almacena dentro de la carpeta /app/controllers.

En el caso anterior para la liga /ajax/resultado nuestro archivo sería el siguiente:

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

class AjaxController extends Zend_Controller_Action {
    public function resultadoAction() {
         //codigo del controlador
    }
}

Cuando entremos a la liga mencionada, el sistema procesará todo el código en la función de la acción. Como vemos nuestra clase extiende de Zend_Controller_Action, esta clase contendrá básicamente:

• una petición (que contiene información de variables de entrada o del sistema)
• una respuesta (que puede ser para redireccionar la página a otra por ejemplo)
• la vista

Por defecto el sistema crea una vista, crea las variables de la petición y la respuesta, llama a la función de la acción; y por último llama a un “ayudante” para que la vista sea generada y la salida se envia al navegador. Es por esto que dentro del controlador no llamaremos a la función render ya que la clase principal lo hace automáticamente.

Para obtener información de entrada, como un parámetro que se especificó mediante /controlador/accion?variable=valor utilizamos la variable de la petición de la siguiente manera:

$peticion = $this->getRequest();
$valor = $peticion->getParam('variable');

También existe una función $peticion->getParams(); que regresa un arreglo asociativo con todas las variables y sus valores.

Para pasar una variable a la vista existe una variable $this->view dentro del controlador a la que podemos pasar valores de la siguiente forma:

$variable = 'Hola mundo';
$this->view->assign('variable', $variable);
//la vista ahora tendrá una variable que puede ser accesada como $this->variable

Más adelante veremos algunas opciones útiles para inicializar valores en la vista o cambiar el ciclo de renderizado de la vista.

Vistas

Las vistas deben ser guardadas en el directorio apps/views/scripts/controlador/ con el nombre de archivo: accion.phtml, así por ejemplo para nuestro ejemplo de /ajax/resultado debemos crear el siguiente archivo: apps/views/scripts/ajax/resultado.phtml

La vista contendrá archivo principalmente HTML, pero podemos procesar código PHP de forma normal entre <?php y ?>, Zend también permite que las vistas utilicen cualquier otro sistema de plantillas que esté escrito en PHP, por ejemplo Smarty.

Dentro llamamos a las variables que hemos asignado de la siguiente manera:

<?=$this->variable?>

Dentro de las vistas podemos alterar un poco la plantilla, para iniciar podemos cambiar el título de la siguiente manera:

<?php
$this->headTitle('Ventana emergente');
?>

Eso hará que el título de la página sea “Ventana Emergente”, pero también podemos agregar un archivo de hoja de estilo de la siguiente manera:

<?php
$this->headLink()->appendStylesheet($this->baseUrl.'/styles/archivo.css', 'screen');
?>

O incluir un archivo de javascript:

<?php
$this->headScript()->appendFile($this->baseUrl.'/scripts/archivo.js');
?>

El sistema de plantillas tiene algunas opciones extra que por brevedad no revisaremos, pero incluyen la posibilidad de incluir código en javascript/css que manejará de manera adecuada mediante una cadena.

La variable de $this->baseUrl, no es estándar de las vistas y es algo que yo he agregado y que veremos más adelante como se logra.

Plantillas

Las plantillas son muy simples, tienen el siguiente modelo:

<?php
/* con esto establecemos un documento XHTML */
echo '<?xml version="1.0" encoding="UTF-8" ?>';
/* esto generará las cabeceras de XHTML,
   también podemos definir otras como HTML 4 */
echo $this->doctype()
?>

<html>

	<head>
		<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
		<!-- es bueno definir algunas etiquetas "globales" aunque pueden hacerse sobreescribiendo el Danguer_Action_Controller  -->
		<link type="text/css" href="<?=$this->baseUrl?>/styles/main.css" rel="stylesheet" />		

		<?php
			/* Con esto nos aseguramos que el título siempre tenga un nombre al inicio */
			$this->headTitle('Ejemplo de MVC, danguer.com | ',Zend_View_Helper_Placeholder_Container_Abstract::PREPEND);

			echo $this->headTitle();
		    echo $this->headScript();
		    echo $this->headStyle();
	    ?>
	</head>

	<body>
		<!--  solo contenido, esto puede ser usado para un popup -->
		<?php echo $this->layout()->content ?>
	</body>

</html>

Como vemos definimos básicamente la plantilla del documento y definimos una parte que será donde irá el contenido con: <?php echo $this->layout()->content ?>, esta parte es reemplazada por la vista en cuestión.
La otra parte dinámica es:

<?php
			/* Con esto nos aseguramos que el título siempre tenga un nombre al inicio */
			$this->headTitle('Ejemplo de MVC, danguer.com | ',Zend_View_Helper_Placeholder_Container_Abstract::PREPEND);

			echo $this->headTitle();
		    echo $this->headScript();
		    echo $this->headStyle();
	    ?>

Que se reemplazará como vimos anteriormente por el título de la página, los archivos de scripts y las hojas de estilo.

Una plantilla también puede tener zonas de contenido, donde desde la vista podemos llenarlas, por ejemplo podemos tener una zona que indique un mensaje y no tendremos que alterar la plantilla segmentándola en diferentes archivos como se suele hacer. Eso se verá en otro tutorial =)

Controlador Base

En lo particular me gusta crear un controlador base que contiene código de utilidad para mis aplicaciones, casi siempre utilizo uno. En el código de ejemplo tiene nombre: app/Danguer_Controller_Action.php

Lo que hace este controlador base es lo siguiente:

• Asigna variables a la vista (por ejemplo baseUrl que es el directorio base de ligas relativas, muy útil para subdirectorios)
• Permite deshabilitar el renderizado automático (ya que al finalizar la función intentará buscar el archivo de vista que puede no existir por ejemplo para resultados de AJAX)
• Tiene funciones de utilidad, en el ejemplo tiene una función para enviar datos en formato JSON con el simple llamado de una función, pero puede incluir código que se compartan entre todos (o la mayoría) de controladores

El código del controlador base es el siguiente:

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

class Danguer_Controller_Action extends Zend_Controller_Action {
	protected $autoRender = true;

    public function initView()
    {
    	parent::initView();

	    $this->view->assign('baseUrl', $this->getRequest()->getBaseUrl());
		$this->view->assign('fullUrl', $this->getFullURL());
    	return $this->view;
    }

    public function init() {
    	$this->initView();
    }

    public function disableAutoRender() {
    	$this->autoRender = false;
    	$args = $this->getInvokeArgs();   	

    	$args['noViewRenderer'] = true;
    	$this->_setInvokeArgs($args);

    	$this->_helper->resetHelpers();
    }

    protected function getFullURL() {
    	$protocol = 'http://';
    	$host = $_SERVER['HTTP_HOST'];
    	$port = $_SERVER['SERVER_PORT'];

    	if ($port != '80')
    		$port = ":{$port}";
    	else
   			$port = '';

    	return "{$protocol}{$host}{$port}".$this->getRequest()->getBaseUrl();
    }

	protected function writeJSON($data) {
		require_once 'Zend/Json.php';

		$this->disableAutoRender();
		header('Content-Type: text/javascript');

		print Zend_Json::encode($data);
	}
}

La función init (similar al constructor de clases) forza a iniciar la vista, en esa función (initView) se llama al padre para que genere el objeto de vista y le asignemos variables predefinidas. Aqui podemos incluir todas las variables que necesitemos.

Las otras dos funciones extras son:

• disableAutoRender
  Permite deshabilitar el auto-renderizado para que la aplicación no busque el archivo de la acción.
• writeJSON
  Codifica una variable en formato JSON (apropiado para AJAX), también automáticamente deshabilita el auto-renderizado

Estas funciones son ejemplo de lo que se puede lograr personalizando el sistema MVC.

Por último si se necesita modificar la plantilla, es muy sencillo; en el código del controlador simplemente necesitamos hacer los siguientes pasos:

$mvc = Zend_Layout::getMvcInstance();
$mvc->setLayout('simple'); //utilizar la plantilla app/layouts/simple.phtml

Esto es la base para entender el modelo MVC de Zend Framework, más adelante explicaré más a detalle cosas como los ayudantes, modelos y Ruteadores.

Código fuente: DanguerArticle_Zend_MVC.tar.gz

Ver sitio demo

Extendiendo un poco el tutorial de Formularios Zend ahora explicaré como funcionan los decoradores. Los decoradores son la manera de visualizar los diferentes elementos de la forma, básicamente se encargan de ‘renderizar’ los elementos de una forma (es decir es la parte de la Vista).

En el tutorial anterior no definí ningún decorador, esto es porque el Zend Framework inicializa los decoradores con algunos por defecto. Veremos un poco del código interno del Zend Framework para entenderlo a detalle.

en Zend/Form/Element.php nos daremos cuenta que en el __construct (inicialización del elemento) hasta al final hay una llamada a la función loadDefaultDecorators que es la siguiente:

public function loadDefaultDecorators()
{
    if ($this->loadDefaultDecoratorsIsDisabled()) {
        return;
    }

    $decorators = $this->getDecorators();
    if (empty($decorators)) {
        $this->addDecorator('ViewHelper')
            ->addDecorator('Errors')
            ->addDecorator('HtmlTag', array('tag' => 'dd'))
            ->addDecorator('Label', array('tag' => 'dt'));
    }
}

Estos cuatro decoradores son la base de como los elementos son renderizados. El sistema procesa en orden lineal de como definimos los decoradores, si no modificamos entonces el orden es de procesar primero ViewHelper, luego Errors, HtmlTag y por último Label.

Cada decorador al momento de procesar en la función render, el sistema le pasa una cadena con el contenido actual y regresa una cadena de texto que procesó. Idealmente debe de utilizarse la cadena del contenido actual, pero con esto también podemos incluso procesar los elementos procesados y sobreescribir todo el resultado o hacer otras cosas interesantes (aunque podría ser no recomendable en un elemento que tenga como propósito ser parte de una librería).

Los elementos por defecto funciona de la siguiente manera:

• ViewHelper: renderea en sí el elemento mediante un helper. Por ejemplo un elemento Zend_Form_Element_Select que tiene un helper formSelect utilizará este último helper para mostrar el elemento como <select>...</select>
• Errors: renderea las partes de los errores, utiliza una plantilla de la siguiente forma:

  <ul class="errores"[opciones html]>
  <li>[error1]</li>
  ....
  <li>[errorN]</li>
  </ul>

• HtmlTag: Le da un poco de formato al elemento ya que lo agrega en una plantilla de la siguiente forma:

  <dd>
  ...
  </dd>

• Label: Asigna una etiqueta de la siguiente forma:

  <dt><label>Etiqueta</label></dt>

Los decoradores por defecto tienen opciones para ser puestos al inicio (PREPEND) o al final (APPEND) del contenido, por defecto Errors se pone al final, HtmlTag pone el contenido en medio de las etiquetas y Label se pone al inicio del contenido.

Por lo que con las opciones por defecto la plantilla de como se verá nuestro elemento es:

<dt><label>[Etiqueta del elemento]</label></dt>
<dd>
    [Elemento]
    <ul class="errors">
        <li>[Errores]</li>
    </ul>
</dd>

Si queremos cambiar el orden, o forma de presentación tenemos que cambiar un poco el formato de salida; por ejemplo con el siguiente código (modificándolo de IndexController.php del tutorial de Zend Form):

$decoradores = array(
     'ViewHelper',
     'Errors',
     array('HtmlTag', array('tag' => 'div', 'class' => 'formElement')),
     array('Label', array('tag' => 'div'))
);

$nombre = $formulario->createElement('text', 'nombre_completo')
               ->setLabel('Nombre Completo')
               ->setDecorators($decoradores)
               ->setRequired(true);

Esto nos mostrará un resultado como el siguiente:

Como hemos definido todos los decoradores que vamos a utilizar es fácil aplicarlo a los demás elementos (en el ejemplo anterior, sólo se aplicó al primer elemento.

Hay que hacer notar que sólo podemos utilizar una vez el decorador en un elemento, si agregamos otro HtmlTag por ejemplo, el último sobreescribirá al primero.

Si queremos construir algo más complejo existe un decorador que nos permite tener mucho mayor control: ViewScript, este decorador básicamente llamará a un archivo de la carpeta de vista (views/scripts) y le pasará tres parámetros:

• content: El contenido actual producto del renderizado de los otros decoradores
• element: El Zend_Form_Element que estamos renderizados
• decorator: Una referencia al decorador ViewScript

Por defecto el resultado se agrega al final, si pasamos como opcion que la posición sea false entonces el contenido que resulte de renderizar este decorador será el único contenido.

Por ejemplo lo siguiente crea un “contenedor” al elemento:

$decoradores = array(
           'ViewHelper',
           'Errors',
           array('HtmlTag', array('tag' => 'div', 'class' => 'formElement')),
           array('Label', array('tag' => 'div')),
           array('ViewScript', array('viewScript' => 'decorador-contenedor.phtml', 'placement' => false)),
    );

Y el decorador está especificado como (archivo nombreado como: views/scripts/decorador-contenedor.phtml:

<div class="formElementContent">
	<?=$this->content ?>
</div>

El resultado es el siguiente (con un poco de CSS):

Ahora bien, si queremos podemos prácticamente reconstruir todo los demás decoradores mediante un un decorador de ViewHelper y un decorador ViewScript de la siguiente manera:

$decoradores = array(
          'ViewHelper',
          array('ViewScript', array('viewScript' => 'decorador-avanzado.phtml', 'placement' => false)),
     );

Y el decorador seria de la siguiente manera:

<!-- Esta primera parte reemplazaria HtmlTag -->
<div class="formElementContent">
	<!--  parte que remplaza el decorador Label -->
	<div>
    <?php
    	$attribs = $this->element->getAttribs();
    	$label = $this->element->getLabel();

    	//nuevo, verificamos si el elemento es requerido,
    	//entonces agregamos un elemento en html al final de la etiqueta
    	if ($this->element->isRequired()) {
    		$attribs['escape'] = false;
    		$label = $this->escape($label). ' <span class="required">*</span>';
    	}

    	echo $this->formLabel($this->element->getName(), $label, $attribs);
    ?>
    </div>

    <!-- parte del elemento -->
    <?=$this->content ?>

    <!--
    	parte que reemplaza Errors
    	observen que estoy poniendo los errores
    	con simples saltos de linea en lugar de lista
     -->
	<?php if ($this->element->getMessages()) { ?>
	<div class="errors">
		<?=implode('<br />', $this->element->getMessages())?>
	</div>
	<?php } ?>

    <!-- esta parte es opcional si agregaron una descripción -->
    <div class="hint"><?= $this->element->getDescription() ?></div>
</div>

El resultado con un poco de CSS es el siguiente:

Como se puede observar el anterior ejemplo nos da completo control sobre como mostrar los elementos.

También en un caso más complejo y avanzado podemos incluso definir con algunos cambios sobre el formulario principal (Zend_Form) para definir un decorador que nos permita sobre la vista definir el orden de los elementos, mostrar un formulario totalmente estilizado que no sea regular o incluso no mostrar elementos o crear nuevos para cosas como AJAX/Javascript por ejemplo.

Pero de eso hablaría en otro pequeño tutorial =).

Código Fuente:

DanguerArticle_Zend_Form_Decorator.tar.gz

Visitar Sitio Demo

Una de las características que se había solicitado en Zend Framework era la de poder utilizar formularios. En la versión 1.5 ya existe esta característica; aunque algunas partes de la documentación de Zend es muy vaga el poder de los formularios es excelente; como siempre tiene una muy buena arquitectura que va desde lo medianamente simple para utilizar los formularios de manera rápida hasta lo complejo que permite extender sus capacidades sin ‘hacks’ en el código o rehaciendo partes de código vitales.

Un formulario (Zend_Form) es un contenedor de elementos (por ejemplo una entrada de texto, una casilla de verificación, etc), del lado del controlador debemos definir los elementos, una vez hecho esto entonces podemos visualizar (render) la forma del lado de la vista ya sea asignándole una vista o simplemente con <?=$formulario?> donde $formulario es por supuesto nuestro objeto de tipo Zend_Form

Los elementos que maneja Zend Framework son básicamente los objetos en HTML a los que estamos acostumbrados, pero no estamos limitados a ellos ya que podemos crear los elementos que necesitemos.
Un elemento puede tener validadores (subclases de Zend_Validate_Abstract) que nos permiten validar la entrada, aunque ya existen muchos validadores muy útiles y de uso frecuente.
El elemento puede ser asignado uno o varios “Decoradores“; un Decorador es un objeto que pasa información a un Helper de la vista, los decoradores que tiene Zend Framework integrado nos permiten fácilmente alterar la salida de un elemento y también añadir fácilmente un diseño.

Esquema

El siguiente es un esquema de cómo funciona Zend_Form, podemos ver que el controlador se encargará de crear el formato del formulario y la parte de vista se encargará de mostrar el formulario y de mostrar los errores que hayan surgido.

Crear un formulario

Para crear un formulario debemos hacer lo siguiente:

1. Crear un formulario (Zend_Form)
2. Crear elementos ya sea mediante
   $elemento = $formulario->createElement('tipo_elemento', 'nombre_elemento');
   o mediante un objeto de tipo Zend_Form_Element:
   $elemento = new Zend_Form_Element_Text('nombre_elemento');
3. Asignar propiedades al elemento:
   setLabel('nombre_etiqueta'); //asigna el nombre de la etiqueta del elemento
setValue('valor'); //asigna el valor del elemento (sobreescribe la entrada del usuario)
setDecorators($arreglo_decoradores); //asigna los decoradores a usarse
setRequired(true/false); //indica si el valor no debe estar vacio
addValidator($validador); //indica el validador a utilizar
4. Agregar el elemento al formulario:
   $formulario->addElement($elemento);
   los elementos se visualizarán en el orden en que han sido agregados, aunque esto puede cambiarse si se modifica el elemento mediante $elemento->setOrder($numero);
5. Pasar el formulario a la vista para que sea renderizado:
   $this->view->assign('formulario', $formulario);
6. Renderizarlo en la vista:
   <?=$this->formulario?>

Validar un formulario

Una vez que hemos renderizado el formulario y el usuario ha enviado datos, lo siguiente que debemos hacer es validar la entrada, para esto debemos de crear nuevamente el formulario y verificar si se han enviado datos (porque Zend Framework solo envia valores y no información sobre el formulario), si se han enviado datos entonces podemos utilizar la función isValid($_POST); que regresará un valor de verdadero en caso de que todos los validadores fueron satisfechos o falso en caso de que alguno no lo fuera.

La ventaja de Zend es que automáticamente agregará un mensaje de error al renderizar el elemento que tuvo un error; inicialmente el código de error estará en inglés, por lo que deberemos de traducir los mensajes (más adelante).

Opciones de Validación

Zend Framework tiene varias opciones para validar las entradas, todas ellas son subclases de Zend_Validate_Abstract, para agregar un validador debemos llamarlo de la siguiente manera:

$elemento->addValidator('nombre_validador', $romper_cadena_al_fallar, $arreglo_opciones);

Los validadores más importantes son (el nombre de validador es el que está entre paréntesis):

• Zend_Validate_Alnum (alnum)
  Nos permite verificar que la entrada solo contenda caracteres alfanuméricos (letras y dígitos), opcionalmente se le puede pasar como opción un booleano para definir si se deben aceptar espacios en blanco (predeterminado en falso)
• Zend_Validate_Alpha (alpha)
  Nos permite verificar que la entrada sea sólo letras, al igual que el anterior permite una opción para aceptar espacios en blanco
• Zend_Validate_Digits (digits)
  Permite verificar que la entrada sea sólo números
• Zend_Validate_StringLength (stringLength)
  Nos permite definir que la entrada sólo contenga un número mínimo o máximo de valores; que deben ser especificado en las opciones por ejemplo:
  $element->addValidator('stringLength', false, array(3, 20));
  Que especifica una cadena de al menos 3 caracteres y máximo 20 caracteres.
• Zend_Validate_EmailAddress (emailAddress)
  Es un validador muy poderoso que nos permite verificar que un correo sea válido (al menos en cuanto a formato y servidor válido incluso)
• Zend_Validate_NotEmpty (notEmpty)
  Este validador nos permite verificar que el usuario ha introducido un valor, lamentablemente no permite eliminar espacios en blanco con trim por ejemplo.

Traducción

Los mensajes de error que mostrará Zend Framework de manera predeterminada serán en inglés; para poderlos mostrar en español debemos utilizar la parte de traducción de Zend (Zend_Translate).

Zend_Translate permite muchas opciones pero aqui haremos una de las más básicas que es mediante un archivo PHP, esto nos permitirá usar las constantes de Zend, para esto simplemente hay que crear un archivo en PHP donde tendrá los mensajes en español, por ejemplo: app/langs/es.php

En este archivo deberemos regresar un arreglo con la llave la cadena a traducir y el valor con la cadena traducida, por ejemplo:

<?php
require_once 'Zend/Validate/NotEmpty.php';
require_once 'Zend/Validate/StringLength.php';
require_once 'Zend/Validate/EmailAddress.php';

return array(
Zend_Validate_NotEmpty::IS_EMPTY => 'El campo no puede estar vacío',
Zend_Validate_StringLength::TOO_LONG => 'El campo debe contener por lo menos %min% caracteres',
Zend_Validate_StringLength::TOO_SHORT => 'El campo debe contener un máximo de %max% caracteres',
Zend_Validate_EmailAddress::INVALID => 'La dirección de correo no es válida',
Zend_Validate_EmailAddress::QUOTED_STRING => "'%localPart%' no concuerda con el formato de comillas",
Zend_Validate_EmailAddress::DOT_ATOM => "'%localPart%' no concuerda con el formato de punto",
Zend_Validate_EmailAddress::INVALID_HOSTNAME => "'%hostname%' no es un nombre de dominio válido",
Zend_Validate_EmailAddress::INVALID_LOCAL_PART => "'%localPart%' no es una parte local válida",
Zend_Validate_EmailAddress::INVALID_MX_RECORD => "'%hostname%' no tiene un dominio de correo asignado",
);

?>

Debemos consultar la API para ver las cadenas que debemos traducir para cada validador. En el ejemplo sólo usaremos tres notEmpty, stringLength y emailAddress

Entonces debemos de asignar estas traducciones a todos los componentes de Zend_Form de la siguiente manera:

$traduccion = new Zend_Translate('array', 'app/langs/es.php', 'es');
Zend_Form::setDefaultTranslator($traduccion);

Obtención de Valores

Los valores del formulario estarán en $_POST['nombre_elemento'] o $_GET['nombre_elemento'] según sea el caso, pero podemos pedirle al formulario que nos regrese solamente los valores que le corresponden de la entrada (si es que pasamos más datos), por lo que debemos hacer:

$valores = $formulario->getValues();

Ejemplo

Para el ejemplo tendremos dos archivos, IndexController.php (Controlador) e index.phtml (vista), simplemente mostraremos un formulario y mostraremos los valores.

El código del ejemplo puede ser obtenido en esta liga:
http://vida.danguer.com/archivos/articulos/Zend_Form/DanguerArticle_Zend_Form.tar.gz

Mientras que el ejemplo puede visualizarse en la siguiente liga:
http://dev.fangit.com/DanguerArticle_Zend_Form/