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.

Usualmente al construir mis clases no pongo mucha documentación por función, por tanto Zend Studio no puede “determinar” qué tipo de variable regresa esa función. 

Para facilitar esto, lo que hago es simplemente agregar este pedazo de código:

    /**
     * @return Zend_Db_Adapter_Abstract
     */
	public static function getDB() {
             /* ... aqui va el código */
         }
 

Básicamente es el snippet de código para documentación pero usando solamente el tipo de objeto que regresa la función.
Con esto cuando utilices la función, Zend Studio podrá fácilmente mostrarte las propiedades y métodos del objeto.

http://tinyurl.com/api-create.php?url= 

y agregar al final la URL que queremos “achicar” con TinyURL, la página regresará como único contenido la URL nueva, por ejemplo:
http://tinyurl.com/api-create.php?url=http://vida.danguer.com

Da como resultado:
http://tinyurl.com/dfz9c3

El snippet para PHP es el siguiente: 

function get_tinyurl($url) {
     $url = "http://tinyurl.com/api-create.php?url=".urlencode($url);
     return trim(file_get_contents($url));
}

Demasiado facil, no? solamente hay que invocarlo como:

get_tinyurl('http://vida.danguer.com')

y obtendremos la nueva URL.

El método es muy fácil, los pasos son:

1. Llamar a: 
   http://www.youtube.com/get_video_info.php?video_id=VIDEOID
   Donde VIDEOID es el id del video que vamos a obtener el archivo FLV (las ligas de YouTube para ver el video son como: http://www.youtube.com/v/VIDEOID)
   Tomaremos por ejemplo este:
   http://www.youtube.com/get_video_info.php?video_id=HDi9OeJqwG4 
2. El resultado será en texto y tendrá muchas variables como:

   status=ok&title=Rob+Dougan+-+Furious+Angels&muted=0&avg_rating=4.8496592845&creator=eitch&length_seconds=237&vq=None&fmt_map=&token=OEgsToPDskKxBcum6P4BEStM-z3qkYZW&thumbnail_url=http%3A%2F%2Fi1.ytimg.com%2Fvi%2FHDi9OeJqwG4%2Fdefault.jpg&allow_ratings=True&plid=AARgErHUJPLX2RPWAAAAoABoIAE&track_embed=1

3. De aqui solamente necesitamos obtener el parámetro token y pasarlo al ya conocido get_video.php:
   http://www.youtube.com/get_video.php?video_id=HDi9OeJqwG4&t=OEgsToPDskKxBcum6P4BEStM-z3qkYZW

Con esto ya obtendremos el FLV deseado, en PHP la rutina sería la siguiente:

<?php
//video id por defecto
$video_id = 'HDi9OeJqwG4';

if (isset($_REQUEST['video_id']))
        $video_id = trim($_REQUEST['video_id']);

//obtener informacion
$url_info = 'http://www.youtube.com/get_video_info.php?video_id='.$video_id;
$info = file_get_contents($url_info);

$vars = array();
parse_str($info, $vars);

$url_flv = 'http://www.youtube.com/get_video.php?video_id='.$video_id.'&t='.$var
s['token'];

print 'Archivo FLV: '.$url_flv;
?>

Con esto obtenemos la URL del archivo FLV.

Es importante notar que en Flex/Flash no se podrá cargar diréctamente get_video_info.php por la política del crossdomain de YouTube así que hay que utilizar un proxy.

El demo lo pueden probar desde:
http://demo.livesourcing.com/blog_vida/articulos/DanguerArticle_Youtube/?video_id=VIDEOID
Donde VIDEOID es el id del video de YouTube de su preferencia =)

El código fuente lo pueden descargar de:
http://demo.livesourcing.com/blog_vida/articulos/DanguerArticle_Youtube.tar.gz
 

basename($cadena[, $sufijo])
Regresa el nombre del archivo o directorio, por ejemplo:

<?php
basename('/var/www/index.html'); //regresa 'index.html'
basename('/var/www'); //regresa 'www'
?>

Adicionalmente si se le pasa un segundo parámetro se removerá el sufijo si es que existe por ejemplo:

<?php
basename('/var/www/index.html', '.html'); //regresa 'index'
?>

dirname($cadena)
Regresa el nombre del directorio padre del archivo o directorio, es decir regresa lo opuesto a basename

<?php
dirname('/var/www/index.html'); //regresa '/var/www'
dirname('/var/www'); //regresa '/var'
?>

Debe notarse que no regresará el último separador (/)

pathinfo($cadena[, $opciones])
Regresa información del archivo, si no se le pasan opciones regresa un arreglo con las siguientes llaves:
dirname: nombre del directorio, es la misma salida de dirname($cadena)
basename: nombre del archivo, es la misma salida de basename($cadena)
extension: Si la extensión existe estará presente y será la extensión del archivo (cadena a partir del último .)
filename: nombre del archivo sin extension

Por ejemplo:

<?php

pathinfo('/var/www/index.html');
/*
regresa:
Array
(
    [dirname] => /var/www
    [basename] => index.html
    [extension] => html
    [filename] => index
)
*/

pathinfo('/var/www/index');
/*
regresa:
Array
(
    [dirname] => /var/www
    [basename] => index
    [filename] => index
)
*/

pathinfo('/var/www/index.inc.php');
/*
regresa:
Array
(
    [dirname] => /var/www
    [basename] => index.inc.php
    [extension] => php
    [filename] => index.inc
)
*/

pathinfo('/var/www');
/*
regresa:
Array
(
    [dirname] => /var
    [basename] => www
    [filename] => www
)
*/

?>

Adicionalmente se puede pasar una constante como parámetro para especificar unicamente un valor, en este caso la función regresa una cadena solamente; las constantes posibles son:

• PATHINFO_DIRNAME
• PATHINFO_BASENAME
• PATHINFO_EXTENSION
• PATHINFO_FILENAME

De los cuales, solamente son útiles: PATHINFO_EXTENSION y PATHINFO_FILENAME ya que PATHINFO_DIRNAME es equivalente a dirname y PATHINFO_BASENAME es equivalente a basename

PATHINFO_FILENAME evitar hacer dos llamadas (una a filepath para saber la extensión y la siguiente a basename con la extensión como sufijo para saber el nombre del archivo)

Ejemplo:

<?php

pathinfo('/var/www/index.html', PATHINFO_EXTENSION); //regresa 'html'
pathinfo('/var/www/index.html', PATHINFO_FILENAME); //regresa 'index'
?>

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

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 )

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:

• Sitio oficial de la API de Yahoo Weather:
  http://developer.yahoo.com/weather/
• API “vieja” de Weather.com (son en si iguales pero tienen diferente forma de ser llamadas y obtener resultados):
  http://www.weather.com/services/xmloap.html 

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

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