400440307. PHP: El poder detrás de la Web 2.0

Para entender por qué los sitios web y las aplicaciones podrían ser consideradas Web 2.0, necesitamos primero acordar una definición del término. Aunque no hay una definición formal, creemos que hay tres componentes esenciales para ser Web 2.0:
– Que ofrezca una experiencia de usuario tipo sobremesa más rica (Ajax).
– Que exponga la funcionalidad como servicios fácilmente consumibles (servicios web).
– Que incentive la base de usuarios para crear, potenciar y categorizar información.

El concepto de Rich Internet Applications consiste en hacer llegar al navegador experiencias tipo sobremesa. JavaScript y Ajax se utilizan normalmente en el lado del cliente para hacer llegar esta experiencia. La principal ventaja de estas tecnologías es su presencia en los navegadores web populares, y que pueden ser aplicadas cada vez más sin tener que re-escribir las aplicaciones web existentes.

En este modelo, el cliente depende del servidor para orquestar y hacer llegar sus datos. PHP es popular con las aplicaciones Ajax porque está excepcionalmente bien equipado para esta tarea. No sólo es PHP una plataforma de integración enriquecida que incluye conectividad a todas las bases de datos, lenguajes, formatos de fichero y servicios más populares, sino que también tiene un soporte sólido y fácil de usar tanto para los formatos XML como para los JSON, que normalmente se utilizan en las comunicaciones cliente/servidor.

El segundo componente de Web 2.0 es la exposición de la funcionalidad a través de servicios web. Aunque las Arquitecturas Orientadas a Servicios (SOA, por sus siglas en inglés) llevan ya unos cuantos años en existencia, nadie está totalmente seguro de cómo traerlas a la vida. Los servicios Web, con su ubicuidad y facilidad de implementación, realizan la promesa de las SOA.

De igual forma, una de las más populares jergas modernas para Web 2.0 es “mezcla”. Estrictamente hablando, las mezclas son cualquier servicio web que combina dos o más servicios para crear un nuevo servicio. Las mezclas son la muestra emblemática de lo que puede ser la Web. Una vez más, PHP tiene un soporte excelente para los servicios web, con su soporte incorporado para SOAP, XML y HTTP.

Por último, el contenido generado por el usuario es donde estas aplicaciones dan más capacidad al usuario, no sólo para crear contenido, sino también para potenciarlo mediante la categorización.

En el presente artículo, vamos a mostrar la capacidad de estas comunidades, incentivando la colección de fotos de Flickr y la categorización a la que han contribuido sus usuarios. Para este proyecto, utilizamos piezas de la Plataforma Zend (framework.zend.com) en el back end y bibliotecas Prototype.js (www.prototypejs.org) y Script.aculo.us en el front end. Los servicios que mezclamos son:
– Un news feed.
– El servicio Yahoo Content Analyzer (developer.yahoo.com/search/content/V1/termExtraction.html ).
– La API de Flickr (www.flickr.com/services/api).
Hemos llamado a esta mezcla «Flickr News Network» (FNN) (el código fuente completo para FNN está disponible online en: www.ddj.com/code/). Tal y como ilustra la figura 1, el concepto detrás de FNN es sencillo: Queremos mostrar fotos desde Flickr para aumentar un artículo de un news feed dado. La implementación es sencilla: se toman los artículos de un news feed y se seleccionan fotos para ellos.

Figura 1

La arquitectura Flicker News Network.

Como Flickr permite que la gente etiquete las fotos, todo lo que necesitamos hacer es identificar las palabras claves del artículo y pedirle a Flickr que busque etiquetas para esas palabras clave. Por suerte, Yahoo tiene una API, Yahoo Content Analyzer, que hace justo eso. Toma como parámetro el contenido que queremos analizar, y a continuación retorna una lista con lo que considera son las palabras clave.

Cuando se busca en Flickr las palabras clave, normalmente obtenemos múltiples respuestas. En aras de la simplicidad, tomamos la que tiene un nivel más alto de “interés” y la mostramos con el artículo.

En el proceso, sacamos partido a los tres temas de Web 2.0: Hacemos gran uso de Ajax y JavaScript en el cliente, potenciamos los servicios web (incluidos los feeds RSS y los servicios desde Yahoo), y nos aprovechamos del etiquetado al que ha contribuido la base de usuarios de Flickr.

Como podemos observar en el Listado número 1, no hay mucho HTML. Típico de muchas mezclas, el “trabajo pesado” lo realiza JavaScript, y no HTML. Como nota importante, el código de muestra que presentamos aquí ilustra una forma en el se podría escribir el código, pero no es la única. En muchos casos omitimos pasos importantes (filtrar input, evitar output, comprobar errores, y otras medidas de seguridad importantes) que las aplicaciones de producción incluirían.

Listado número 1

('sak') = md5(mktime());

?>

Aparte de la lista de bibliotecas JavaScript incluidas en la, el único JavaScript que realmente mostramos en el HTML es la función invocada en la carga de página. pageLoad() gestiona las cosas que no podemos hacer dentro de los ficheros JavaScript o las que tienen que estar hechas para el tiempo de ejecución.

Concretamente, puesto que el intérprete PHP del servidor web no interpreta los ficheros JavaScript y nosotros necesitamos establecer un valor de PHP, establecemos ese valor en la pageLoad(). Lo otro que hacemos es crear un RequestWatcher para que cuando cambie cualquier cosa, podamos actualizar nuestra presentación visual de solicitudes pendientes.

PHP

Toda la comunicación con los socios necesarios para el servicio se hace a través de Ajax. Por restricciones de seguridad, las invocaciones a Ajax sólo pueden hacerse al mismo servidor que sirvió la página original.

El centro de service.php (disponible online en www.ddj.com/code/) son las dos líneas que obtienen un proxy de la fábrica e invocan su función main(). Proxy:;factory() realiza la acción que se ha pasado. A continuación mira a ver si una clase Proxy/ACTION.php está en alguna parte de la ruta include.

Una vez que tenemos la clase proxy, invocamos a su función main(). factory entregó nuestra lista de opciones sin filtrar al constructor. Las opciones genéricas que se aplican a todas las clases Proxy se filtraron en la clase de base, Proxy_Abstract. Cada clase de proxy puede filtrar opciones adicionales mediante overriding _filterOptions(). Hay que asegurarse de que si realizamos override _filterOptions(), invocamos el método padre.

Caching

Por lo que respecta a caching, lo primero que hacemos es ver si tenemos un caché reciente de esta alimentación (véase feed.php, que se encuentra disponible online). Para que no sobrecargar innecesariamente a los proveedores de servicio, guardamos en caché todo lo que nos dan. Gracias a Zend_Cache, caching es sencillo.

Pero no todos los cachés se crean igual. Como nuestro feed puede cambiar con frecuencia, lo guardamos en caché durante 15 minutos. Una vez hemos reunido las palabras claves para un artículo dado, hay bastantes posibilidades de que Yahoo no va a cambiar de opinión sobre dichas palabras, así que podemos guardarlas en caché durante 24 horas. Flickr, no obstante, puede tener subidas fotos nuevas que sean más apropiadas que las que tenemos actualmente, así que guardamos en caché las respuestas de Flickr durante dos horas.

Caching hace dos cosas importantes por nuestro servicio:
– Acelera la aplicación ya que las invocaciones a otros servicios son caras desde el punto de vista del tiempo.
– Al guardar en caché las respuestas durante un tiempo razonable, nos protegemos frente a posibles fallos de nuestros socios. Como la mayor parte del tiempo estamos leyendo del caché, si el sitio de un socio no responde o no está disponible, nuestra aplicación sigue funcionando normalmente. Si fuera un problema serio, podríamos desconectar el limpiado automático del Zend_Cache y sólo eliminar las antiguas entradas de caché una vez hayan expirado y sepamos que tenemos una entrada nueva para sustituirlo. Esto añade unas cuantas líneas más de código a nuestras clases Proxy, pero nada que sea tremendamente difícil y podría ser la diferencia entre mostrar resultados a los usuarios y una página en blanco.

Si no tenemos un caché válido, el código dentro de la sentencia IF se desencadena y obtenemos la fuente actual. Al usar la clase Zend_Feed_RSS, la instanciamos con la URI del feed. Como no necesitamos todo lo que hay en el feed, creamos una matriz de los trozos que nos conciernen. Estamos recogiendo el feed porque no teníamos un caché válido, así que antes de terminar, guardamos esta matriz en el caché para la siguiente solicitud.

En todas las clases basadas en Proxy para este proyecto, hemos utilizado una función resumen md5() como identificador de caché. En el caso del caché Feed, hemos usado un md5() de la URL. Para las palabras clave, hacemos una función resumen del contenido utilizado para general las palabras clave; para las fotos usamos una función resumen de la palabra clave para la que estamos solicitando una foto. La clase Zend_Cache requiere que el identificador de caché sea sólo alfanumérico. El uso de md5() es una forma rápida de garantizar que se siga la norma y que tenemos un identificador exclusivo y extraíble.

Por último, cargamos la propiedad de la respuesta de nuestra clase Proxy con la matriz y la retornamos de manera que el servicio la pueda entregar de vuelta a nuestro JavaScript.

Las proxies son todas iguales

Las tres clases Proxy que hemos usado en este proyecto se comportan igual. Por ese motivo, no vamos a explicarlas con mucho detalle, pero sí queremos resaltar una diferencia significativa.

La proxy Keywords.php usa la clase Zend_Client_Rest para hablar con el Content Analyzer deYahoo. Content Analyzer de Yahoo es distinto en que aunque que continuamos utilizando una API Representational State Transfer (REST) para hablar con él, usamos un HTTP POST en lugar de un GET. El motivo es que la descripción del artículo podría ser potencialmente más larga que lo que puede enviar el navegador a través de un GET. Por eso es por lo que, cuando preparamos la invocación a la fábrica de Proxy, usamos la matriz $_REQUEST en vez de $_GET o de $_POST.

Con Keywords y Photos, necesitamos registrarnos con los servicios y obtener auténticas claves API para conseguir acceso. La mayoría de los news feeds no requieren que nos registremos primero.

El uso de piezas de la Plataforma Zend simplificó la programación. Además, al estructurar service.php como una fábrica, se puede volver a usar esta solución y se puede añadir con facilidad proxies de servicios adicionales.

JavaScript

Casi todo el JavaScript de FNN está basado en Prototype.js. Hay otras buenas bibliotecas JavaScript como Dojo y YUI!. Pero Prototype.js es sencilla de entender y de implementar, y aún así lo suficientemente avanzada como para encargarse de las necesidades de FNN. (Véase «Ajax: Selecting the Framework that Fits,» de Andrew Turner y Chao Wang, DDJ, junio 2007.)

La mayor parte del código de JavaScript está contenido en dos clases (ambas disponibles online). La primera de ellas es una clase que tratamos como clase Static, aunque JavaScript no tiene el servicio para declararla así. La clase Articles contiene todo lo que necesitamos para ponerlo a funcionar. Debido a su naturaleza estática, Articles es la única clase que no es una sub-clase del objeto Class del Prototipo. Como es un estático, nunca lo instanciamos, sino que sencillamente hacemos invocaciones a sus métodos de miembros. La primera invocación que vemos está en el método pageLoad() al que añadimos un observador al Event Bus.

El método de entrada principal es Articles.fetchArticleList() (disponible online), que dispara la solicitud a services.php para que recoja la fuente. Pasa los necesarios parámetros a service.php, incluido el nombre de acción, para crear adecuadamente y ejecutar el objeto proxy. Prototype.js tiene una característica exclusiva. Si estamos retornando a JSON de nuestro servicio, podemos establecer un encabezamiento HTTP de X-JSON. Los contenidos del encabezamiento se evalúan de forma automática creando un objeto JavaScript para que lo podamos utilizar. Este objeto es pasado como segundo parámetro al método onComplete.

El proceso que hay detrás de la recogida de los artículos, claves y fotos es sencillo y también lo es la implementación de JavaScript – obtener artículos, obtener las palabras clave para cada artículo, obtener una foto para cada palabra clave.

La segunda clase JavaScript importante en este proyecto es NewsArticle. Una vez que Articles ha recogido el feed, instancia una copia de NewsArticle por cada artículo en el feed. Cada NewsArticle va entonces por su cuenta, recoge las palabras clave para su historia y a continuación la mejor foto para cada palabra clave según Flickr. Por último, muestra cada uno de esos artículos.

Si bien la clase NewsArticle contiene la mayor parte del código que se ejecutará, los conceptos que hay tras ella son bastante corrientes.

Autobuses y observadores

El otro código de interés son las clases Event Bus y Observer mencionadas anteriormente. La clase Event Bus nos permite organizar a los observadores para un evento dado. Estos eventos no están basados en el navegador, sino en el código. Podemos crear tantos como deseemos y nuestros observadores contendrán el código necesario para procesar estos eventos cuando ocurran.

En el caso de esta aplicación muestra, hay sólo dos eventos de interés. Cuando iniciamos una nueva solicitud de Ajax, queremos incrementar el número de solicitudes actualmente pendientes. El corolario para esa acción es que cuando se completa una acción Ajax, queremos reducir el número de eventos pendientes. Para registrar el observador, incluimos esta línea en el método pageLoad():

Articles.getEventBus().addObserver

(newRequestWatcher('requestCount'),'requests');

Vamos a echarle una ojeada ahora al código EventBus.js (disponible online). Cuando queremos disparar un evento, invocamos a EventBus.notify() con un mensaje (o nombre de evento) y una carga útil. Se utiliza el mensaje para establecer los observadores a notificar.

Cuando se registra un observador, especificamos dos parámetros – una instancia del observador mismo y el mensaje al que suscribirse. Fuera de su constructor, RequestWatcher.js (disponible online) implementa el método único, notify(). Notify toma la carga útil, en este caso el número de solicitudes pendientes, y actualiza el contenedor de output en la misma.

Cuando lo instanciamos en pageLoad(), el parámetro que manejábamos era requestCount. Eso corresponde con la identidad de una etiqueta span en el HTML a actualizar.

Síntesis

Seleccionando las herramientas adecuadas para el trabajo, incluso una mezcla de tres formas como esta puede realizarse con rapidez. En el caso de FNN, elegimos la Plataforma Zend como la base porque contiene todas las piezas que necesitábamos para que nuestro servicio se escribiera con rapidez. De forma adicional, debido a la forma en que la Plataforma Zend está estructurada, pudimos sacar con facilidad las piezas que necesitábamos y usarlas de forma independiente.

La otra pieza que seleccionamos fue Prototype.js. La marca ligera de Prototype y su sencilla interfaz nos permite montar JavaScript con rapidez.

En segundo lugar, al usar buenas técnicas y prácticas orientadas a objetos, la pieza del lado del servidor es ahora una plataforma que puede ser ampliada para consumir recursos de otros servicios mediante la construcción de nuevas clases Proxy.

En el lado del cliente, el OO es algo más difícil debido a limitaciones de lenguaje, pero nos atenemos a la teoría del diseño OO siempre que es posible. Ello se presta a un código bien segregado.

Por último, el concepto no mencionado que hemos cubierto – la construcción de servicios web, incluso servicios que consumen servicios de otros, es indoloro. FNN habla con una simple página PHP denominada «service.php,» que consume los servicios de otro, pero también publica su propio servicio. Convierte los datos de nuestros news feeds, Yahoo y Flickr, en un formato fácilmente digerible.

Con las herramientas que hemos examinado, podemos ahora encontrar los datos o el servicio exclusivos que tenemos y compilar en torno a ello un servicio.
DDJ