Tag Archives: PHP - Page 2

Certificación en Zend Framework

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
Tampoco hay guia oficial, solamente está la opción de curso.
Creo que el Zend Framework debe crecer un poco más para estabilizarse en cuestión de características generales y de ahi ya es una opción muy válida de certificación; ya que en el momento hay mucho movimiento en cuestión de nuevas características, por ejemplo la versión 1.6 la principal mejora fue la introducción de Dojo.

 

Como programar (decente) en PHP

El viernes un cliente me pidió un favor de ayudarle a terminar de instalar un script de un amigo en su servidor. 

Todo parecía ser un simple problema con la importación de MySQL por los acentos, aunque eso solucionó parcialmente aún tenía un error en la parte medular del sistema, en cuanto abri el archivo que estaba dando el error me arrepentí de hacerlo y mi mente se volcó a recordar hace cinco años o tal vez seis cuando se programaba de esa manera =)

Con ese ejemplo me vino a la mente una frase célebre de mi buen amigo Nexus en esas épocas cuando estaba aprendiendo a programar en PHP, mi geek interno terco siguió programando con las antiquísimas $HTTP_POST_VARS a pesar de que se habían desalentado utilizar esas variables y se reemplazó por las variables tipo: $_POST ó $_GET

Recuerdo que cuando Nexus vio un código mio que tenía el $HTTP_POST_VARS me dijo en un chat con (me parece Carlos Cortez): “Programas a la manera viejita jajajaja”. Claro por orgullo después de eso nunca volví a tocar $HTTP_POST_VARS

Aqui tengo unos consejos para que no solamente sea fácil programar, depurar y para otros leer tu código. También para evitar que PHP siga siendo visto como un lenguaje de “bajo presupuesto” (por aquello que muchos prefieren Java por lo ‘empresarial’)

 

Tip: PHP dejó de ser un lenguaje de Script hace años

Lo digo en completo tono sarcástico, si bien PHP no se puede compilar no hay razón para meter todo dentro de un solo archivo como print’s con funciones, prácticamente se debe separar de preferencia en un modelo MVC si no puedes hacerlo, entonces al menos hazlo en VE (Vista-Espaguetti donde vas a meter tanto modelo como controlador)

 

Tip: register_globals está muerto

Por eso me dio miedo abrir el archivo, necesitaba register_globals. Para el que no sepa que es register_globals es simplemente que cuando mandamos parámetros a un script como por ejemplo: prueba.php?variable1=hola&variable2=mundo PHP convierte automáticamente esas dos variables en $variable1 y $variable2 con su respectivo contenido.

Qué fácil, ¿No?. Pues en realidad no, cuando el mundo no se percataba del error fatal de hacer esto, parecía que PHP era tan fácil de programar, vaya no necesitabas ni siquiera  vincular los parámetros.

Poco después un balde de agua fria cayó sobre todos nosotros… el problema es que cualquier tipo con algo de sesos puede simplemente pasar variables y asignar valores de la aplicación. En el caso de una aplicación que no inicializara las variables (el 99% para ser sinceros) podía sufrir porque era fácilmente “hackeada” sin necesidad de hacer mucho.

Por eso rápidamente se eliminó register_globals y se dejó como un parámetro opcional, pero muy opcional. Tanto que en PHP 6 va a desaparecer definitivamente. 

register_globals no ayuda, no hace más rápido el desarrollo; simplemente destruye todo lo bueno que podría tener una aplicación, porque en primer lugar es difícil saber cuales variables son parámetros del usuario y cuales son variables internas. También hace fácil explotar un sistema (creo que ya lo había dicho ;) ).

La solución para esto… reescribe tu aplicación.

 

Tip: die() está muerto

¿Alguien se ha preguntado porqué existe esta construcción del lenguaje de PHP?, supongo que es un legado de los viejos días cuando PHP era un lenguaje de script.

die() permite simplemente eso: hace que el script muera. Muchos lo hacían para verificar una situación intolerable como al abrir una conexión a una base de datos y que no se pudiera conectar; como no se pueden mostrar datos entonces simplemente le decimos al usuario: “perdon pero aqui nos detenemos” un ejemplo es el siguiente:

<?php
    mysql_connect($host, $usuario, $password) or die('No pude conectarme a la base de datos');
?>

¿Cuál es el problema?, muy simple la función die funciona tan perfectamente que el script se muere ahi. Por lo que el usuario simplemente verá una pantalla blanca con un texto críptico. En el peor de los casos mostrará una parte de la página y la “cortará” donde se haya ejecutado esta instrucción.

No seas perezoso, utiliza construcciones de if() para separar bloques de instrucciones en vez de suicidarte.
Si aún así quieres hacer un die() o un exit() al menos manda a llamar a una plantilla especial que muestre el error con la mayor parte del mismo estilo de la página que vas a mostrar, te lo agradecerá el usuario.

 

 

Tip: include y require es un arma de dos filos

También un legado de aquellos días es que un script luzca como:

<?php include 'cabecera.php'; ?>
<?php print "Hola mundo 'plantilla'; ?>
<?php include 'pie_pagina.php'; ?>

En aquellos días estas eran nuestras plantillas, cabecera.php mostraba el código inicial de HTML y pie_pagina.php cerraba ese código HTML, qué facil, ¿verdad?

Pues no, el problema de este método es que en primer lugar las variables son globales y compartidas, por lo que si haces el código espaguetti anterior es un total NO.

Por ejemplo es fácil sobreescribir variables dentro de un archivo “plantilla” y el error se propaga a las otras “plantillas”.

Otro problema es que hacen difícil seguir un flujo real de plantillas (si no quieres una parte tienes que reescribir todo en lugar de simplemente cambiar por ejemplo la distribución de los objetos en una plantilla general. También es fácil de romper todo el HTML por una etiqueta fuera de lugar

Una vez más, no seas perezoso y utiliza un manejador de plantillas como Smarty

Ahora bien del lado de programación un include() por lo regular es utilizado para incluir pedazos de código tales como funciones, clases, etc. Pero lamentablemente también es utilizado para incluir pedazos de código que tienen el mismo uso que funciones!!

Eso es algo totalmente prohibido, no se porque no utilizas funciones o mejor aún una clase.

 

Tip: mysql_connect y sus vicios

Un legado también de aquellos días es que se programaba de la siguiente manera:

<?php
include 'configuracion_db.php';
mysql_connect($host, $usuario, $password) or die('No pude conectarme a la base de datos');
?>

donde configuracion_db.php era simplemente:

<?php 
$host = 'localhost';
$usuario = 'mi_usuario';
$password = 'mi_password';
?> 

El primero se incluia prácticamente como cabecera para todas las páginas porque necesitaban acceso a la base de datos, y también se incluia dentro de otros bloques dentro de la misma página.

O peor aún, incluir en cada archivo los parámetros de configuración. Esto último es simplemente un caos y es no saber programar, así que toma un curso de programacion básica en otro lenguaje antes de programar en PHP ;)

Para el primer caso si bien es válido, es simplemente malo debido a que otro script puede fácilmente sobreescribir esas variables (o el mismo script por error). Aunque es utilizado, es muchísimo mejor utilizar un patron de diseño llamado: Singleton

El Singleton es un patron de diseño muy simple, en términos de orientación a objetos es un método estático de una clase que regresa siempre la misma instancia de la clase. Es decir solamente existirá un objeto en todo el sistema y que lo creará ese método estático normalmente llamado: obtenerInstancia()

En lenguaje de funciones es simplemente una función que regresará la misma variable (tendrá la misma dirección de memoria) cada vez que se llame, así que en lugar de hacer el primer ejemplo utiliza este:

<?php
function obtenerConectorMysql() {
     static $conector_mysql = null; 
     if ($conector_mysql == null) {
         //aqui insertar las instrucciones para obtener el host, usuario y password, 
         // por ejemplo de un archivo o simplemente escribirlas aqui
         $conector _mysql = mysql_connect($host, $usuario, $password);
     } 

     return $conector_mysql;
}

 

Esto simplemente crea la primera vez que se llame el conector_mysql, después simplemente lo regresa por lo que no se crean diferentes instancias, es la misma conexión a MySQL

Si lo quieres hacer mediante clases, puedes utilizarlo algo similar como una llamada a una función estática o “envolverlo” en la clase que tengas para manejar la base de datos.

Tip: La seguridad no es para sitios de comercio o bancos solamente

Mucha gente piensa que debe hacer “seguro” un sitio solamente si va a tener operaciones monetarias. Nada más fuera de la realidad. 

Todos los sitios necesitan seguridad para evitar que los ataques logren su resultado: hacer “explotar” la aplicación.

Evitando los errores más comunes tendrás una aplicación que si bien no es tan segura como la de la CIA (lease con sarcasmo) evitará el 90% de los ataques comunes.

  1. Al desarrollar una aplicación, recuerda que el usuario no es de fiar, por lo que todo lo que provenga del usuario puede ser alterado
  2. Siempre verifica la información que el usuario envió mediante parámetros. Si es posible restringe mediante un arreglo de valores válidos, si no es posible entonces haz muchas verificaciones, por ejemplo en el caso de un archivo, elimina caracteres peligrosos como: ‘..’ o ‘/’ que pueden hacer que el sistema lea (o incluso escriba) un archivo muy diferente al planeado.
    Esto se hace indispensable si vas a utilizar una función poderosa como include() o acceso al archivo (como fopen() )
  3. Nunca pongas datos importantes en una cookie, utiliza sesiones. Si lees datos de una cookie nunca asumas que por ser cookie es dificil de alterar
    Si los datos van a “perdurar” más alla de una sesión, entonces deja en la cookie un identificador único y guárdalo en la base de datos, de esta manera el usuario solo debe proveer su identificador y no otra información que pudiera ser alterada. 
  4. Siempre “escapa” las variables que vas a utilizar en una consulta a la base de datos, utiliza funciones como: mysql_escape_string(), si utilizas un framework la mayoría de ellos tienen una función para hacer esto (que terminan llamando a algo similar a la primera función)

 

Tip: PHP5 no es una opción, es obligatorio >=)

No veas a PHP5 como una “extensión” o una versión más. El propósito de PHP5 es hacer una transición entre el mundo de scripts de código espaguetti a un sistema de clases muy bien separadas.

Aunque PHP5 aún permite programar sin clases y con solo funciones; si tienes la oportunidad no dudes en utilizar PHP5 con clases con todo lo nuevo que trae. La guia de estudio de Certificación Zend es un buen inicio. 

PHP5 tiene un gran potencial y está esperando para ser plenamente utilizado, algunos frameworks ya están utilizando plenamente su potencial, entre ellos Zend Framework que es altamente recomendable.

 

Último tip: MVC es lo único para web ;)

Si vas a desarrollar una aplicación en PHP que contenga todo lo que una aplicación web contiene (contenido en HTML, bases de datos, procesamiento, etc) simplemente utiliza un framework que tenga un diseño de MVC; los más conocidos son Zend Framework (mi recomendación nuevamente) y CakePHP, también están otros en rápido ascenso como Simfony y Code Igniter

También son de uso popular los CMS como drupal y joomla/mambo, aunque ellos no proveen directamente el modelo MVC si proveen el modelo Vista-Espaguetti por lo que con un poco de trabajo extra puedes lograr algo similar a MVC

 

En resumen PHP es un lenguaje muy poderoso y con historia; por lo que es fácilmente quedarse con las primeras formas de programar, pero con todos los nuevos desarrollos ahora si se puede empezar a hablar de un PHP a nivel empresarial (ya formalmente ;) )

 

Ejemplo de API de Yahoo/Weather.com

La pagina de Yahoo developers tiene el API de Weather.com (que compro hace tiempo), Weather.com ya tenia un xml que ha simplificado Yahoo.com

Esta API nos permite obtener informacion del clima de practicamente cualquier lugar del mundo y sin duda es muy utilizada para varios widgets dentro de páginas o como widgets de escritorio.

Básicamente para usar esta API se hace una llamada a la siguiente dirección:
http://weather.yahooapis.com/forecastrss?p=CODIGO&u=c

Donde código puede ser un Código Postal de Estados Unidos, o un ID de una ciudad en el mundo, el API de yahoo developers, dice brevemente que para conseguir este ID se necesita ir a la página de Yahoo Weather y copiar de la URL el código de la ciudad.

Esto es realmente muy malo ya que lo que se busca es optimizar, pero ahi entra el API viejo de Weather.com, donde podemos enviarle una cadena con la ciudad a buscar y nos regresará diversos resultados que pueden concordar con el código de la ciudad y su nombre “legible”, la url es: 
http://xoap.weather.com/weather/search/search?where=NOMBRE_CIUDAD

Por ejemplo para buscar la ciudad de Puebla, Mexico haremos:
http://xoap.weather.com/weather/search/search?where=Puebla

El resultado nos dará como resultado:

<!-- This document is intended only for use by authorized licensees of The  -->
<!-- Weather Channel. Unauthorized use is prohibited.  Copyright 1995-2008, -->
<!-- The Weather Channel Interactive, Inc.  All Rights Reserved.            -->
<search ver="2.0">
  <loc id="MXPA0070" type="1">Puebla, Mexico</loc>
</search>

 

Que vemos que el elemento loc provee el ID de la ciudad y el nombre legible; ahora si podemos contruir la nueva URL que será:

http://weather.yahooapis.com/forecastrss?p=MXPA0070&u=c

El resultado es un documento RSS con un nombre de espacio (namespace) de yweather, la página contiene mucha información, mucha de ella redundante, pero lo que más nos importa es lo que tiene ese nombre de espacios como:

<yweather:condition  text="Partly Cloudy"  code="30"  temp="19"  date="Sat, 27 Sep 2008 5:49 pm CDT" />
<yweather:location city="Puebla" region=""   country="MX"/>
<yweather:units temperature="C" distance="km" pressure="mb" speed="kph"/>
<yweather:wind chill="19"   direction="150"   speed="11.27" />
<yweather:atmosphere humidity="60"  visibility="1607.69"  pressure="0"  rising="0" />
<yweather:astronomy sunrise="7:23 am"   sunset="7:24 pm"/>

El primero es lo más importante (condition), nos mostrará la información del clima, el código de estado (code), la temperatura (temp) y la fecha de cuando se obtuvo la información.
El segundo (location) nos dice información del lugar.
El tercero (units) nos dice en qué unidades está expresada la información, como hemos solicitado en formato de grados Centigrados el sistema muestra la información en sistema métrico.
El cuarto (wind) nos da información del viento.
El quinto (atmosphere) nos da información del medio ambiente en cuanto a humedad, visibilidad, etc
El último (astronomy) nos da una breve información de cuando el sol aparece y se oculta en el horizonte.

La página también incluye una liga a la imagen del estado, yo he decidido utilizar las que provee Weather.com

El nombre del estado no lo usaremos ya que está en inglés, por lo que hice una traducción del estado al nombre correspondiente, los códigos se pueden ver aqui:
http://developer.yahoo.com/weather/#codes

 

Aqui tenemos un ejemplo ensamblado en PHP y Javascript:
http://demo.livesourcing.com/blog_vida/articulos/DanguerArticle_Clima/

 

Básicamente tiene tres partes, la primera nos permite introducir un nombre y obtener el ID de los lugares, obviamente está en ingles por lo que se tienen que hacer busquedas como “Mexico City” para encontrar la información del clima del D.F.

La segunda parte nos permite seleccionar de las distintas opciones de los lugares el que queramos ver su clima, después de seleccionarlo le damos click a “Obtener clima” y obtendremos el clima ;)

El sistema muestra solamente el Estado (en español), la temperatura y la fecha con la imagen correspondiente del estado; en el ejemplo no obtuve información extra como información del viento o del medio ambiente, pero en base al ejemplo se puede extender fácilmente.

 

Descargar el código fuente del ejemplo: 
http://demo.livesourcing.com/blog_vida/articulos/DanguerArticle_Clima.tar.gz

 

Más información:

 

MVC en Zend Framework

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:

Proceso de MVC en Zend Framework

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:

Estructura de Directorios de Zend Framework MVC

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

Zend Form: Decoradores

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:

Ejemplo de Zend_Form_Decorator

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):
Ejemplo de Zend_Form_Decorator

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:

Ejemplo de Zend_Form_Decorator

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

PHP y msmtp

La mayoría de ISP bloquean el puerto 25 para “evitar” que computadoras infectadas envien SPAM. Este era mi caso por lo que me era imposible probar los correos que enviaba mediante PHP hasta subirlos a mi servidor de pruebas.

Recientemente me encontré con msmtp que es básicamente un cliente SMTP que funciona como proxy para enviar correo mediante otro servidor.
Para instalar msmtp en mi caso debian solo se necesita:

apt-get install msmtp msmtp-mta

Para configurarlo basta crear el archivo /etc/msmtprc con la configuración correspondiente, por ejemplo en mi caso fue:

defaults
tls on
tls_certcheck off

account danguer.com
host mail.danguer.com
port 999
from monitor@danguer.com
auth on
user monitor@danguer.com
password password_cuenta

account default: danguer.com

Lo que dice la configuración es que básicamente utilizará TLS (para mayor seguridad, además de que mi servidor lo requiere).
Creamos una cuenta llamada danguer.com y le decimos el usuario y la contraseña a utilizar, ya por último asignamos la cuenta por defecto que vamos a utilizar.

Con esto deberiamos de poder enviar correos como con sendmail pero utilizando el programa /usr/bin/msmtp por lo que lo único que basta es configurar php para que envie utilizando el programa en vez de sendmail.

En el archivo php.ini pondremos lo siguiente:

sendmail_path=/usr/bin/msmtp -t -i

Reiniciamos apache y ahora cuando utilicemos la funcion mail el sistema lo enviará mediante el servidor que hayamos especificado.

De hecho podemos utilizar una cuenta de gmail para hacerlo pero hay que tener en cuenta que debido a sus filtros anti-spam nuestros mensajes podrían ser rechazados o incluso la cuenta podría ser bloqueada para enviar correos (por defecto acepta un límite de 100 correos por día)

CentOS y PHP DOM

Hace mucho tiempo que no utilizaba una versión de Redhat; ya que sólo utilizaba Redhat cuando comence a aprender Linux, luego conocí Debian y no he necesitado otra distribución.

Pero ahora en el trabajo me han pedido configurar algunos servicios en un servidor CentOS y la verdad es que prácticamente a mi gusto Yum está muy atrasado respecto a apt-get pero lo peor que me encontré en CentOS es que la parte de DOM (lo que antes era DomXML) de PHP5 no está compilado!!, y eso que a diferencia de PHP4 la parte de DOM no necesita librerías externas por lo que no se sinceramente porqué esta parte fue omitida.

Para sanar hay dos opciones: instalar una versión recompilada de PHP incluyendo DOM, o compilar el módulo por separado de DOM e instalarlo a la versión actual; yo preferí utilizar esta última.

Para compilar solo el módulo, necesitas descargar la misma versión de PHP que tengas instalada, puedes buscar en internet por: php-VERSION.tar.bz2; por ejemplo: php-5.1.6.tar.bz2

Esta liga tiene varias versiones de PHP: http://museum.php.net/php5/

Después de descargar, simplemente debes hacer:
./configure --enable-dom=shared --enable-xmlreader=shared

Hacer el clásico make y esperar a que compile, una vez terminado verás en la carpeta modules/ dos archivos: dom.so y xmlreader.so, estos se deben copiar al directorio de modulos de php; en CentOS: /usr/lib/php/modules/

Después editar tu /etc/php.ini e incluir lo siguiente:

extension=xmlreader.so
extension=dom.so

Reiniciar apache:
/etc/init.d/httpd restart

Ahora deberás tener PHP5 con DOM funcionando.

Presence API – Estado de MSN Messenger en Web (Live Dev)

Presence API - Estado de MSN Messenger en Web

Desde hace algo de tiempo MS ha intentado entrar al mercado de internet, si bien sus productos no han logrado ser populares me acabo de dar cuenta que tienen una API para obtener información de MSN Messenger.

Esto es realmente útil sobre todo por la gran cantidad de personas que usamos este servicio y que las páginas pueden beneficiarse de ello; en este caso probaremos el Presence API que es muy simple y nos permite obtener el estado de una persona mediante su ID.

Funcionamiento

Con esta herramienta podemos obtener su estado (En Línea, Ocupado, etc) el ícono de su estado (no el avatar que lamentablemente no se puede obtener) y el nombre que se ha asignado (también falta el mensaje que uno puede asignar en el messenger).

Inicialmente debemos de obtener el ID del usuario, para esto podemos ir a la siguiente liga:
http://settings.messenger.live.com/applications/websignup.aspx?returnurl=[URL]&privacyurl=[URL]

Donde returnurl es donde se pasarán los datos del usuario y privacyurl una liga donde se especifiquen los criterios de privacidad para que el usuario sepa que se hará con su cuenta.

En esta liga el usuario dará sus credenciales para acceder a su cuenta de messenger; después aceptará que nuestra aplicación pueda ver los detalles; aunque en realidad lo único es que le envia a la aplicación nuestro ID de usuario.

Del lado de nuestra aplicación recibiremos los siguientes parámetros:

  • result, nos indicará el estado de la petición que puede ser:
    Accepted – Cuando el usuario ha aceptado que podamos ver su estado
    Declined – Cuando el usuario ha declinado
    NoPrivacyUrl – Cuando nuestra página de privacidad no es encontrada
  • id, es el ID del usuario en una forma como USUARIO_ID@apps.messenger.live.com, esta cadena es con la que realizaremos la consulta

Cuando necesitemos saber el estado de una persona, debemos llamar a su servicio web en la siguiente dirección:
http://messenger.services.live.com/users/[ID]/presence?mkt=es-MX

Esto nos regresará un elemento en JSON (que puede ser utilizado por javascript si es utilizado mediante un proxy) de otra manera necesitamos convertirlo a PHP, en el ejemplo utilizo Zend_Json para obtener el resultado, el resultado es muy sencillo tiene los siguientes valores (ya convertido en php):

  • $estado['icon']['url']
    Icono de estado
  • $estado['icon']['width']
    Ancho del Icono
  • $estado['icon']['height']
    Alto del Icono
  • $estado['displayName']
    Texto que el usuario ha puesto en su messenger
  • $estado['status']
    Estado del usuario (ID)
  • $estado['statusText']
    Estado en formato ‘legible’ pero debe proporcionarse el ‘contexto’ para que provea en el lenguaje correcto, en la liga de arriba ya se proporcionó para Español de México (?mkt=es-MX)

De esta manera podemos ver el estado de una persona.

Descargar Código:
http://demo.livesourcing.com/blog_vida/articulos/DanguerArticle_LiveDevPresenceApi/.tar.gz

Ver Ejemplo:
http://demo.livesourcing.com/blog_vida/articulos/DanguerArticle_LiveDevPresenceApi/

Información (en inglés):
http://msdn.microsoft.com/en-us/library/bb936691.aspx

Formularios con Zend Framework (Zend_Form)

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.

Esquema de Zend_Form

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/