La semana pasada me surgió la necesidad de hacer un sistema de gestión de eventos para el DotNetClub del que formo parte y, aprovechando que lo estábamos estudando en la carrera, decidí emplear el patrón Modelo-Vista-Controlador (MVC).

El problema era que no me decidía si desarrollarlo en ASP.net o en Ruby on Rails, así que se me ha ocurrido hacer una pequeña implementación de la misma interfaz en los dos modelos para ver las diferencias, y ya que estaba, compartirlo con vosotros.

Como en un solo artículo es imposible dar siquiera una primera aproximación a cada una de las herramientas, lo hemos dividido en una serie, titulada Monográfico MVC.

A lo largo de esta serie, veremos cómo partiendo de un diseño básico, podemos agregar la lógica MVC, y apreciar las diferencias entre dos tecnologías concretas, y muy diferentes:

• Ruby on Rails
• ASP.net MVC3

Comencemos pues la introducción al patrón MVC.

Introducción: ¿Qué es MVC?

De acuerdo con la definición de Wikipedia es:

Patrón de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos.

Esto significa que tendremos tres componentes principales en nuestra aplicación:

Modelo

El modelo lo podemos ver como la base de datos, o el sistema relacional que controla cómo se leen y se guardan los datos, así como cierta lógica de validación y relaciones entre ellos (Lo podemos llamar modelo relacional, si estamos trabajando con bases de datos)

Vista

La vista es lo que se muestra al usuario o a un servicio web, es decir, una vista puede ser una página HTML para que el usuario acceda a los datos, una interfaz en Silverlight, o incluso un fichero XML que se consuma desde un programa externo.

Controlador

El controlador es el enlace entre la vista y el modelo, se encarga de recibir los eventos desde la vista (por ejemplo un botón “Enviar” de un formulario o de un cuadro de login) y de exponer a la vista los datos desde el modelo.

Este modelo no es nuevo, sino que fue introducido en 1987 en el lenguaje de programación SmallTalk, si quereis echar un vistazo a la especificación original, la podeis encontrar aquí: http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html

Con el auge de las aplicaciones web, se ha demostrado ser un modo de programación que encaja bastante bien con internet, siendo tanto el modelo y el controlador ejecutados del lado del servidor, y la vista ejecutada del lado del cliente.

Diseño inicial

Para poder centrarnos en los diferentes sistemas y no centrarnos tanto en el diseño, partimos de un diseño HTML ya construido que contiene dos páginas:

• Lista de eventos
• Ventana de detalles

La lista de eventos contendrá la fecha, el título del evento, el ponente y una descripción.

La ventana de detalles contendrá, además, el edificio, el aula, y la hora, así como dos opciones para editar y/o borrar el evento.

Visto este diseño podemos extraer el conjunto de datos necesario, y su tipo:

• Id: Integer
• Titulo: String
• Fecha: Date
• Edificio: String
• Ponente: String
• Descripcion: String

A partir de este diseño, y usando técnicas de scaffolding, comprobaremos lo sencillo que puede ser empezar a trabajar.

En la próxima entrega veremos cómo agregamos lógica a esta web usando el primero de los jugadores: Ruby on Rails.

¡Nos vemos en la próxima publicación!

Related posts:

1. Introducción a Object-Relational Mapping (ORM)
2. Introducción a Zend Framework PHP
3. Grails: Introducción a desarrollo web Java para ‘dummies’

Imaginemos que tenemos un biblioteca de imágenes y que queremos añadirles una marca de agua a todas ellas. Podemos abrir un editor de imágenes (Gimp o Photoshop, por ejemplo) y crear nuestra marca de agua manualmente a todas ellas.

Es un trabajo sencillo pero si nuestra biblioteca de imágenes es muy grande el trabajo se convierte en algo más duro. Podemos automatizar esta tarea, pero si las marcas de agua que queremos poner son dinámicas, tenemos que buscar otra solución. Como ejemplo imaginemos que lo que queremos poner es la fecha/hora en la que el usuario solicita la imagen al servidor. Para hacer esto vamos a usar la librería GD y PHP. Empecemos:

Gracias a la librería GD podemos añadir de manera sencilla marcas de agua a nuestras imágenes. Esto Unido a mod_rewrite nos permite hacer el trabajo al vuelo.

¡Automaticemos el trabajo!

La idea es simple. En lugar de abrir directamente la imagen, lo que vamos a hacer es crear un script PHP que modifique la imagen original con la función imagecreatefromjpeg y le añada un footer con la fecha/hora . Después le entregaremos al navegador la imagen modificada con las cabeceras necesarias.

Esta solución nos implica modificar todas nuestras etiquetas img y pasar de algo así:

<img src='/ruta/de/la/imagen.jpg' alt='img' />

A algo así:

<img src='/ruta/del/script.php' alt='img' />

Para evitar esto vamos a usar un pequeño truco que consiste en usar el módulo mod_rewrite de apache (los demás servidores Web tienen módulos similares). Creando este simple archivo .htaccess en la carpeta donde tengamos nuestras imágenes jpg, podemos redirigir cada petición de la imagen original a nuestro script PHP que la modifica y le añade la marca de agua.

RewriteEngine on
RewriteRule !\.(php)$ watermark.php

Ahora creamos nuestro script watermark.php para hacer la modificación.

<?php
$uri = $_SERVER['REQUEST_URI'];
$documentRoot = $_SERVER['DOCUMENT_ROOT'];
$filename = $documentRoot . $uri;
if (realpath(__FILE__) == realpath($filename)) {
    exit();
}
$stringSize = 3;
$footerSize = ($stringSize==1) ? 12 : 15;
$footer = date('d/m/Y H:i:s');

list($width, $height, $image_type) = getimagesize($filename);
$im = imagecreatefromjpeg($filename);
imagefilledrectangle (
        $im,
        0,
        $height,
        $width,
        $height - $footerSize, imagecolorallocate($im, 49, 49, 156));

imagestring($im,
        $stringSize,
        $width-(imagefontwidth($stringSize)*strlen($footer)) - 2,
        $height-$footerSize,
        $footer,
        imagecolorallocate($im, 255, 255, 255));

header( 'Content-Type: image/jpeg' );
imagejpeg($im);

Como vemos el script es muy sencillo. Podemos modificarlo y cambiarlo por nuestro logotipo, o introducir nuevos valores. Para que esto funcione tenemos que tener nuestra instalación de PHP compilada con soporte GD.

Imagen Original:

Imagen transformada:

Una pequeña reflexión final

Y eso es todo. ¿Qué pega tiene esta técnica? Pues que estamos usando unos recursos del servidor elevados. Estamos transformando la imagen cada vez que la solicitamos. Si el volumen de peticiones es pequeño no hay problema, pero si crece podemos tirar el servidor.

Una solución sencilla es cachear la imagen resultante. De este modo liberamos al servidor, pero ¿que pasa si la marca de agua es dinámica?. En el siguiente artículo de esta mini serie veremos una posible solución al problema.

¡Nos vemos en el próximo capítulo!

Related posts:

1. Creando servicios de red TCP con PHP y xinetd
2. Acelerando los tiempos de carga uniendo archivos Javascript con PHP
3. Aprendiendo a utilizar la librería cURL en PHP
4. Introducción a Zend Framework PHP

No todo en PHP es Web y HTTP. Podemos usar PHP para muchas otras cosas. Por ejemplo podemos crear de una forma muy sencilla servicios de red. Cuando creamos servicios de red necesitamos obviamente un servidor de red (bien sea TCP o UDP).

Cuando trabajamos con Web y HTTP este servidor suele ser Apache (o similares), pero si queremos crear un servicio específico (no HTTP), además del servicio de red que queramos crear, necesitaríamos crear un servidor.

No todo en PHP es Web y HTTP. Podemos usar PHP para muchas otras cosas. Por ejemplo podemos crear de una forma muy sencilla servicios de red.

Esto lo podemos hacer con C, Java e incluso con PHP, pero cuando trabajamos en entornos Linux existe un daemon que nos permite desplegar servicios de red de una forma muy sencilla, encargándose de la parte del servidor y dejándonos a nosotros la parte del servicio de red. Este daemon es xinetd.

Vamos a ver cómo crear un sencillo servicio de red TCP con xinetd y PHP… ¡Empecemos!

Creando el servicio de red TCP con Xinetd y PHP

El ejemplo que vamos a realizar escuchará del puerto 69321, e inicialmente dirá “Hola” cuando alguien realice una petición TCP a dicho puerto. El script del ejemplo es sumamente complicado:

// /home/gonzalo/tests/test1.php
echo "HELLO\n";

Bien. Ahora lo que queremos es que nuestro servicio de red escuche el puerto tcp 60321. Para esto tenemos que definir en nuestro archivo /etc/services el puerto en cuestión:

// /etc/services
...
myService   60321/tcp # my hello service

Y finalmente creamos la configuración en el daemon xinetd. Para ello creamos el archivo /etc/xinetd.d/myService:

# default: on
# description: my test service

service myService
{
        socket_type = stream
        protocol = tcp
        wait = no
        user = gonzalo
        server = /usr/local/bin/php-cli
        server_args = /home/gonzalo/tests/test1.php
        log_on_success += DURATION
        nice = 10
        disable = no
}

Reiniciamos el daemon para que lea la nueva configuración del servicio que hemos creado:

sudo /etc/init.d/xinetd restart

Y listo. Ya tenemos nuestro servicio de red operativo y funcionando. Para probarlo podemos usar un simple telnet al puerto definido:

telnet localhost 60321
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Hola
Connection closed by foreign host.

¿Fácil, no? Sí pero útil, no mucho. Por esto vamos a cambiar un poco es script para que acepte variables de entrada. Esto no es HTTP por lo que no podemos usar las típicas variables $_POST y $_GET.

Lo que tenemos que hacer es leer del stdin. En PHP, al igual que con otros lenguajes, esto es muy sencillo:

$handle = fopen('php://stdin','r');
$input = fgets($handle);
fclose($handle);

echo "Hola {$input}";

Reiniciamos el xinetd y tenemos nuestro servicio listo

telnet localhost 60321
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

Vemos que el telnet se nos quedará a la espera que introduzcamos un texto. Escribimos: “gonzalo” y obtenemos:

gonzalo
Hola gonzalo
Connection closed by foreign host.

Conclusión

Y esto es todo. Con este sencillo script vemos que, si bien PHP es un lenguaje destinado principalmente para el desarrollo Web, podemos usarlo para otras cosas, manteniendo su punto fuerte: la sencillez.

¿Para qué nos puede servir esto? Bueno. Para empezar nos sirve para leer datos de dispositivos de red que tengamos por ahi, como báculas, lectores de tarjetas, sensores… Muchos de estos dispositivos suelen permitirnos en su configuración establecer una IP/puerto a la que van a enviar información en forma de trama TCP.

También podemos usarlo para comunicar procesos de una manera simple, sin necesidad de meternos con servidores XMLRPC/Soap y demás. En fin que es una herramienta más que tenemos a nuestra disposición para afrontar nuestros desarrollos.

¡Nos vemos en el próximo artículo!

Related posts:

1. Creando una capa de conexión abstracta a base de datos con PHP
2. Acelerando los tiempos de carga uniendo archivos Javascript con PHP
3. Marcas de agua en imágenes usando PHP (I)
4. Mini Aplicaciones Web con Python y Juno: Parte II

Antes de ponerme a comentar los distintos tipos de vulnerabilidades conocidos y explotados de las aplicaciones web, quiero compartir el siguiente informe: Informe de Investigación de Datos Violados 2010 (el informe se genera en 2010, por lo que analiza el año 2009) creado por Verizon en colaboración con el USSS (United States Secret Service).

Es un informe muy completo que analiza en profundidad los distintos tipos de ataques llevados a cabo con el objetivo final de robar información, bien sea a corporaciones o particulares. Os dejo un par de datos que me han parecido relevantes:

• 40% de los robos fueron por hacking.
• 98% de los datos robados, procedían de servidores.
• 85% de los ataques fueron considerados fáciles.
• 96% de los robos serían evitables con medidas simples o intermedias.

Solamente con ver estes datos, uno tiene razones más que suficientes para ponerse al día en el tema de seguridad web, y eso es lo que intentaré hacer en este artículo. A continuación le echamos un vistazo a los tipos de ataques más comunes para que por lo menos sepas que existen y los analices más profundamente si lo consideras necesario. Pero antes, os dejo unas cuantas gráficas extraídas del informe:

Categorías de ataques por porcentaje de robos y registros

Tipos de hacking por porcentaje de robos y registros

Vías de ataque por porcentaje de robos y porcentaje de filas

Cross-Site Scripting (XSS)

Es un tipo de vulnerabilidad web que permite a personas malintencionadas insertar código de lado de cliente (Javascript, VBScript, Flash…) en las páginas web accesibles por el resto de usuarios. Debido a esto, un atacante podría conseguir acceso a contenido sensible, cookies de sesión y demás información que el navegador almacene sobre el usuario atacado.

Un posible uso de esta vulnerabilidad, sería ejecutar un código Javascript que obtenga la cookie que almacena el identificador de sesión (SID) y lo envía al atacante, pudiendo así usar esa cookie para suplantar al usuario afectado.

Hay una pequeña categorización de este tipo de ataques, que los divide en dos:

A través de XSS una persona malintencionada puede insertar código en una web, de forma que cualquier usuario que entre, estará expuesto a sus peligros.

No persistente

Este es el tipo más común y se produce cuando un usuario envía datos al servidor, normalmente a través de la Query String (GET) o de un formulario (POST) e inmediatamente el código del servidor genera una respuesta usando esa misma información sin limpiar adecuadamente los datos.

Por ejemplo imagina que has programado un buscador para tu sitio web, que cuando no encuentra lo que acabas de buscar, genera una salida como “No se ha encontrado nada sobre gatos” en el caso que hayas buscado la palabra “gatos”. Bien, esto parece algo inofensivo pero…y si busco el siguiente texto?:

<script>alert(1)</script>

Pues que el servidor generará la siguiente salida:

No se ha encontrado nada sobre <script>alert(1)</script>

De forma que el navegador, al encontrarse con la etiqueta <script>, ejecuta inmediatamente el código, en este caso, saltaría un inofensivo cuadro de diálogo.

A lo mejor ahora te estás preguntando, “¿pero cómo afecta esto a un usuario particular?”, “nadie que no sepa del tema, va a buscar eso y en cualquier caso, se está fastidiando a sí mismo”. Bien, imagina que tu buscador maneja las peticiones a través de parámetros GET de forma que si buscas “gatos”, accedes a la siguiente dirección:

http://example.com/search?q=gatos

Pues alguien malintencionado, puede generar la url:

http://example.com/search?q=<script>alert(1)</script>

Simplemente tendría que enviar la URL a las personas que desea y listo.

Persistente

Este es un tipo más devastador ya que puede llegar a afectar a cualquier usuario que entre en tu web. Se trata de insertar y almacenar código malicioso en el servidor, de forma que se muestre a cualquier persona que acceda a dicha página. Esto es muy fácil de conseguir en las aplicaciones web que permiten a los usuarios generar contenido, como envíar comentarios, dar opinión en foros, etc…

Imagina que unos foros muy visitados no están limpiando bien los textos que los usuarios envían. Una persona que se haya dado cuenta, podría enviar un simple mensaje con:

<script>alert(1)</script>

Ahora, cada persona que visite la página en la que has escrito, verá un inofensivo cuando de texto. Pero repito, podría ejecutar cualquier código, tan malicioso como uno quiera y la seguridad del navegador lo permita.

La diferencia entre persistente y no persistente es que en los ataques persistentes, el código queda almacenada en el lado del servidor, mostrándose y ejecutándose en cada petición, mientras que los ataques no persistentes, inyectan el código de forma temporal como respuesta a una petición específica.

Cómo protegerse

• Asegúrate de que todas las salidas generadas con textos potencialmente inseguros (enviados por usuarios) son completamente escapados. Para eso PHP nos ofrece algunas funciones como htmlentities o htmlspecialchars, o como habíamos visto en un tutorial anterior, puedes Validar y sanear datos en PHP de forma bastante sencilla.
• Como ya he comentado, el principal objetivo de este tipo de ataques, es el robo de las cookies. Muchos sitios web, evitan que un atacante pueda suplantar cookies de otros usuarios vinculando la cookie a la dirección IP para la cual se había creado. De esta forma, alguien que intente usar una cookie desde otro ordenador, será considerado un usuario malicioso y se ignorará la cookie. Tambien existe la opción de especificar una cookie como HttpOnly, de forma que los navegadores no permiten acceder a dicha cookie al código ejecutado en el lado de cliente. Esta opción es soportada prácticamente por todos los navegadores modernos.

Cross-site request forgery (CSRF o XSRF)

Esta vulnerabilidad explota la confianza que un sitio tiene un usuario, a diferencia del XSS, que explota la confianza que un usuario tiene en un sitio web. A grandes rasgos, consiste en que una persona malintencionada envía un link a una persona que sabe (o supone) que está identificada en una web, de forma que la persona ejecuta ciertos comandos sin enterarse.

Por ejemplo, imagina una web de un banco que dispone de la siguiente url para realizar una transacción:

http://example.com/transaction?to=[ID USUARIO]&amount=[CANTIDAD]

Sería realmente sencillo generar una url para que cualquier usuario identificado, te enviase dinero. Sería tan fácil como enviarle este link:

http://example.com/transaction?to=ivan&amount=1000

Ahora, imagina que en ese banco existen unos foros para que los usuarios registrados puedan opinar sobre distintos temas. Si no tienen los textos perfectamente saneados y escapados, una persona malintencionada podría insertar la siguiente etiqueta HTML:

<img src=”http://example.com/transaction?to=ivan&amount=1000” />

De esta forma, el navegador de cualquier usuario que entra en el foro, intentará descargar dicha imagen, pero en realidad, esa url no va a generar ninguna imagen, lo que va hacer es enviar una orden de transacción en caso de que el usuario esté identificado. Como ya he dicho, es un exceso de confianza del sitio web en las acciones del usuario.

Cómo protegerse

• Requerir una clave secreta al usuario antes de llevar a cabo cualquier acción comprometida, como sería el caso del ejempl anterior.
• Limitar el tiempo de vida de la sesión: lo hacen en muchas webs de contenido sensible.
• Deshabilitar la opción de “Recordarme” ayuda a prevenir este tipo de ataques: si activas esa opción y luego te envían un exploit de CSRF, tienes muchas más posibilidades de que te afecte, pues el no estar logueado no te salva, ya que iniciarás la sesión automáticamente, ejecutando la acción que el exploit te envía.
• Comprobar la cabecera Referer: cualquier petición que no contenga esta cabecera debe ser denegada, debido a que existen formas sencillas de evitar el envío de esa cabecera. Además, esta validación podría tener problemas con navegadores o proxies que evitan el envío de esta cabecera por razones de privacidad. Sin embargo, si el sitio web requiere de máxima seguridad, es una opción más a tener en cuenta.
• Usar GET y POST debidamente: según los estandares, las peticiones GET nunca deben de tener efectos permanentes. Si bien los envíos POST tambien se pueden falsear, es una tarea más complicada en la que tienen que darse más vulnerabilidades.

SQL injection

Es un tipo de ataque que explota la vulnerabilidad de la capa de base de datos de una aplicación. Se presenta cuando los filtros pasados a una sentencia SQL no son escapados correctamente y por lo tanto, un usuario malitencionado puede envíar caracteres con significado especial en SQL para modificar la consulta.

En 2009, el 25% de los robos a través de hacking, fueron hechos usando SQL injection.

Imagina la siguiente consulta SQL para comprobar que los datos de inicio de sesión que acaba de enviar un usuario son correctos:

$query = “SELECT * FROM users WHERE login='{$username}' AND password='{$password}'”;

Si las variables son recibidas directamente del formulario enviado y no son escapadas, un usuario malintencionado podría hacer envíar lo siguiente:

• Usuario: ivan
• Contraseña: ‘ or ’1′=’1

Así, la query resultante sería:

SELECT * FROM users WHERE login='ivan' AND password=' ' or '1'='1' ;

Lo cual, hace que la condición siempre sea cierta y te puedas identificar como cualquier usuario.

La inyección SQL tiene muchas posibilidades, ya que una persona con experiencia podría poco a poco investigar la base de datos y llevar a cabo tareas como robar información valiosa, eliminar tablas importantes con el objetivo de hacer daño a tu sitio web, insertar contenido malicioso, dar permisos de administrador a su usuario…entre otras muchas, hay tantas posibilidades como ideas maliciosas

A continuación dejo un ejemplo para mostrar lo sencillo que es eliminar una tabla de un sitio web vulnerable a inyección SQl, para que te tomes siempre muy en serio este tipo de vulnerabilidad.

Siguiendo con el caso anterior, un usuario podría rellenar el formulario con lo siguiente:

• Usuario: ivan
• Contraseña: ‘;DROP TABLE users; –

Por lo que la consulta resultante sería:

SELECT * FROM users WHERE login='ivan' AND password=' ' ;DROP TABLE users; –';

Más vale que tuvieses bien configuradas las copias de seguridad

Como protegerse

Una vez más, la solución es escapar los datos antes de incrustarlos en la consulta. En PHP disponemos de una función llamada mysql_real_escape_string limpiará todos los caracteres que tienen significado especial para MySql y pueden modificar la consulta. Por lo tanto, la consulta de inicio de sesión que hemos visto, se corregiría ejecutándola de este modo:

$userName = mysql_real_escape_string($userName);
$password = mysql_real_escape_string($password);
$query = sprintf(“SELECT * FROM users WHERE login='%s' AND password='%s'”, $userName, $password);

También os podéis currar vuestro propio código para gestionar las consultas y que sea más cómodo. En un tutorial ya habíamos visto Cómo crear una capa de conexión abstracta a la base de datos

Session Fixation

Este ataque se aprovecha de la vulnerabilidad de algunos sitios que permiten a un usuario fijar el identificador de sesión (SID) de otro usuario. La mejor forma entender esta vulnerabilidad es mediante un ejemplo (usados los nombres por convención)

• Un usuario malintencionado llamado Mallory se percata de que en el sitio http://vulnerable.com existe la posibilidad de cambiar el SID de los usuarios.
• Mallory, envía el siguiente link a Alice: http://vulnerable.com?SID=este_sera_tu_sid (con esto lo que hace es que cuando Alice entre en el sitio web, el servidor establecerá su SID con el valor “este_sera_tu_sid”, de forma, que Mallory sabe el SID de Alice).
• Alice entra confiada en la web e inicia sesión.
• Mallory, al conocer el SID de un usuario identificado en la web, puede suplantarlo simplemente accediendo a http://vulnerable.com?SID=este_sera_tu_sid

Como puedes comprobar, es muy sencillo el proceso.

Cómo protegerse

La primera norma para evitar esto es no aceptar nunca identificadores de sesión a través de variables GET / POST. La mejor forma de manejar los SID de los usuarios es a través de cookies. Si usas PHP puedes configurarlo para que automáticamente maneje las sesiones a través de cookies e ignore cualquier forma de establecer el SID a través de otros medios. Esto se puede hacer configurando lo siguiente en el fichero php.ini:

session.use_cookies = 1
session.use_only_cookies = 1

Otra medida para evitar la fijación de sesión, es regenerar el SID del usuario en cada petición. Haciendo esto, incluso aunque un atacante obtenga tu SID, el SID será inválido cuando el atacante intente suplantar al usuario. Esto es muy fácil hacerlo en PHP, simplemente hay que llamar a la función session_regenerate_id

Conclusión

Como habrás podido comprobar, las aplicaciones web están expuestas a múltiples vulnerabilidades que podrían tener efectos catastróficos. El simple envío de un comentario “infectado” podría tener como resultado el robo de información de cientos o miles de usuarios.

De todas formas, el objetivo de este tutorial no es el de sembrar el miedo entre los desarrolladores, sino el de informar sobre algo que (creo) muchas veces se obvia o se deja en segundo plano. Lo único que hay que hacer es investigar y aprender, si quieres derrotar a tu enemigo, ¡conócelo!

Related posts:

1. Sesiones en PHP

Los custom fields son campos personalizados que nos permiten añadir información extra en nuestros artículos y páginas de WordPress. A través de un nombre y un valor podemos mostrar cualquier cosa que deseemos, imágenes, texto, código… ofreciendonos un mundo de infinitas posibilidades.

Cómo definir un custom field

Lo primero que debemos hacer es identificarnos en nuestro panel de administración y crear una nueva entrada -o página-. Veremos una caja llamada “Campos personalizados” (Custom fields si nuestro WordPress está en inglés) en la parte inferior de nuestra pantalla. Rápidamente podemos diferenciar dos campos esenciales, que deberemos rellenar debidamente, Nombre y Valor:

A través de estos dos únicos campos podremos mostrar información o compararla con otra existente. Como ya os hemos comentado, las posibilidades que nos ofrece esta funcionalidad son casi infinitas. Vamos a ver un par de ejemplos para comprender rápidamente el funcionamiento de este tipo de campos.

Mostrando imágenes en nuestros artículos

Antes de que WordPress incluyera la posibilidad de añadir thumbnails a las entradas los custom fields eran casi la única forma de mostrar miniaturas que encabezasen las entradas, sin recurrir a plugins. Ahora os explicaré cómo.

Para este primer ejemplo necesitaremos una imagen de 200x200px, que previamente habremos subido a nuestro servidor, y modificar el archivo index.php para añadir la funcionalidad deseada. Para ello definiremos la etiqueta Nombre como “thumb” y la de Valor con la URL de nuestra imagen.

Le damos a “Añadir un campo personalizado”, el formulario se enviará y nos automáticamente creara nuestro primer custom field. Ahora le toca el turno a nuestro index.php, en el que tendremos que añadir un par de líneas de código PHP para que cargue la imagen que hemos guardado previamente.

Una vez que hayamos creado nuestro primer custom field quedará almacenado y podremos acceder a el a través de un nuevo menú desplegable que aparecerá en la caja de “Campos personalizados”.

Tendremos que identificar el comienzo del loop de WordPress ya que inmediatamente después tendremos que pegar el código que os muestro a continuación. Para aquellos que no lo sepan, el loop comienza justo después del primer condicional while.

<?php
while (have_posts()) : the_post();
$thumb = get_post_meta($post->ID, "thumb", $single = true);
?>

Lo primero que hemos hecho es asignarle el valor del custom field “thumb” a la variable que lleva el mismo nombre, $thumb, para después poder interactuar con ella. En el siguiente paso comprobaremos que esta variable no está vacía con el fin de mostrar la imagen deseada, en caso contrario mostraremos una imagen por defecto.

<?php if($thumb !== '') { ?>
    <img class="left" src="" width="200" height="200" alt="" />
<?php } else { ?>
    <img class="left" src="/images/default_thumb" width="200" height="200" alt="" />
<?php } ?>

Podéis comprobar que le hemos asignado la clase “left” a nuestra imagen, con el único propósito de que le haga un float: left; y se muestre inscrustada a la izquierda del contenido de nuestro artículo. El código CSS sería algo así:

.left {
    float: left;
}

Mostrando la música que estamos escuchando

Ahora vamos a crear un custom field que nos permita mostrar la canción que estamos escuchando mientras escribíamos el artículo. Este pequeño campo podremos utilizarlo tanto en el index.php como en el single.php, a gusto del consumidor.

Primero localizaremos el formulario de “Campos personalizados” en la opción de “Editar entrada” dentro de nuestro panel de Administración. Definiremos el campo Nombre como “song” y el Valor con el nombre de la canción. Enviamos los datos a través del botón de “Añadir un campo personalizado” y guardamos la entrada.

Ahora que nuestro nuevo custom field está creado es hora de mostrarlo en nuestra plantilla. Para ello tendremos que editar nuestro single.php y colocar el siguiente código donde deseemos mostrar la información.

$customField = get_post_custom_values("song");
if (isset($customField[0])) {
echo "Escuchaba: ".$customField[0];

Este mismo procedimiento podéis utilizarlo, por ejemplo, para mostrar publicidad de AdSense. Tan solo tendréis que definir los valores del campo personalizado atendiendo al código que nos otorga Google para mostrar su publicidad.

Conclusión

Hemos visto cómo gracias a los custom fields podemos vitaminar nuestras plantillas con el fin de mostrar otro tipo de contenido. Queda en la imaginación de cada uno el buscar otras formas de sacarle provecho a esta funcionalidad, ya que la capacidad de la misma es enorme.

¡Nos vemos en el próximo tutorial WordPress!

Related posts:

1. Aprendiendo a utilizar la librería cURL en PHP
2. Marcas de agua en imágenes usando PHP (I)
3. Entendiendo los Layouts en Zend Framework PHP
4. Acelerando los tiempos de carga uniendo archivos Javascript con PHP

Una de las reglas de oro cuando tratamos de mejorar el rendimiento en aplicaciones Web es reducir el uso de peticiones HTTP. Normalmente solemos tener varios archivos Javascript dentro de nuestros proyectos, lo que significa varias peticiones HTTP para descargarlos.

Es una práctica recomendable unir todos estos archivos Javascript en uno solo para reducir el número de peticiones. Podemos hacerlo de forma manual. No es difícil. Solo tenemos que cortar y pegar las fuentes Javascript en un único archivo. Incluso tenemos herramientas que nos ayudan a hacerlo, como Yslow.

Esto es una buena solución si nuestro proyecto está terminado. Pero si nuestro proyecto está vivo y lo estamos modificando, suele ser útil (al menos para mí) separar los archivos Javascript para tener el código más organizado y mantenerlo.

En definitiva, que tenemos que decidir entre el rendimiento de nuestra aplicación en producción o ayudar al desarrollador. Es por esto que me gusta usar el script que os voy a mostrar. Un script PHP que junta todos los archivos .js dentro de un único archivo de forma dinámica.

¿Cómo aceleramos los tiempos de carga de Javascript?

La idea es la siguiente. Normalmente suelo tener los archivos .js guardados jerárquicamente dentro de una carpeta que se llama js (¿original, no?). También suelo tener un servidor de desarrollo y uno de producción (¿realmente original, no?). Cuando estoy desarrollando mi aplicación me gusta separar los archivos y en un formato legible, pero cuando están en producción combinarlos en uno solo e incluso minimizarlos para mejorar el tiempo de descarga.

El script que tengo para combinar todos los archivos .js en uno solo es el siguiente:

//js.php
require 'jsmin.php';

function checkCanGzip(){
    if (array_key_exists('HTTP_ACCEPT_ENCODING', $_SERVER)) {
        if (strpos($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip') !== false) return "gzip";
        if (strpos($_SERVER['HTTP_ACCEPT_ENCODING'], 'x-gzip') !== false) return "x-gzip";
    }
    return false;
}

function gzDocOut($contents, $level=6){
    $return = array();
    $return[] = "\x1f\x8b\x08\x00\x00\x00\x00\x00";
    $size = strlen($contents);
    $crc = crc32($contents);
    $contents = gzcompress($contents,$level);
    $contents = substr($contents, 0, strlen($contents) - 4);
    $return[] = $contents;
    $return[] = pack('V',$crc);
    $return[] = pack('V',$size);
    return implode(null, $return);
}

$ite = new RecursiveDirectoryIterator(dirname(__FILE__));
foreach(new RecursiveIteratorIterator($ite) as $file => $fileInfo) {
    $extension = strtolower(pathinfo($file, PATHINFO_EXTENSION));
    if ($extension == 'js') {
        $f = $fileInfo->openFile('r');
        $fdata = "";
        while ( ! $f->eof()) {
            $fdata .= $f->fgets();
        }
        $buffer[] = $fdata;
    }
}

$output = JSMin::minify(implode(";\n", $buffer));

header("Content-type: application/x-javascript; charset: UTF-8");
$forceGz    = filter_input(INPUT_GET, 'gz', FILTER_SANITIZE_STRING);
$forcePlain = filter_input(INPUT_GET, 'plain', FILTER_SANITIZE_STRING);

$encoding = checkCanGzip();
if ($forceGz) {
    header("Content-Encoding: {$encoding}");
    echo gzDocOut($output);
} elseif ($forcePlain) {
    echo $output;
} else {
    if ($encoding){
        header("Content-Encoding: {$encoding}");
        echo GzDocOut($output);
    } else {
        echo $output;
    }
}

Como podemos ver el script se recorre recursivamente los archivos Javascript dentro de una carpeta, los une e incluso le pasa la librería jsmin para PHP para reducir el tamaño del archivo Javascript resultante, y mejorar así el tiempo total de descarga en el navegador.

Con este script en marcha, es muy sencillo crear un archivo HTML que dependiendo del entorno en el que nos encontremos (producción o desarrollo) incluya los tags HTML necesarios para usar la versión minimizada y unificada o todos los archivos Javascript por separado. Aquí pongo un ejemplo usando el motor de plantillas Smarty:

<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
        <title></title>
    </head>
    <body>
        Hello World
{if $dev}
        <script src="js1.js" type="text/javascript"></script>
        <script src="js2.js" type="text/javascript"></script>
        <script src="xxx/js1.js" type="text/javascript"></script>
{else}
        <script src="js.php" type="text/javascript"></script>
{/if}
    </body>
</html>

Sí, lo sé. Hay un problema con esta solución. Quizás hemos mejorado el rendimiento en el cliente (navegador) reduciendo el número de peticiones HTTP, pero ¿Qué pasa con el rendimiento en servidor? Hemos pasado de servir archivos Javascript estáticos, a necesitar PHP para generar archivos estáticos. Ahora el servidor consume más CPU. Dependiendo del hosting que estemos usando, más CPU supone más caro.

Alojar los recursos y archivos estáticos en servidores independientes al servidor web nos permite descargar en paralelo de forma más rápida y eficiente.

Otra regla de oro del rendimiento Web es poner el contenido estático en un servidor dedicado, o CDN sin PHP. Con esta segunda regla de oro conseguimos realizar descargar múltiples más eficientes de nuestro contenido estático y reducir el consumo de CPU, ya que los servidores que sirven contenido estático no necesitan crear una instancia de PHP ni interpretar ningún código.

Por lo tanto una mejor solución en la siguiente: Generamos el archivo Javascript estático de forma offline cuando desplegamos nuestra aplicación a producción. Yo lo suelo hacer con un simple comando de curl, el un terminal:

curl http://nov/js/js.php -o jsfull.minified.js

Ahora nuestra plantilla Smarty pasa a ser:

<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
        <title></title>
    </head>
    <body>
        Hello World
{if $dev}
        <script src="js1.js" type="text/javascript"></script>
        <script src="js2.js" type="text/javascript"></script>
        <script src="xxx/js1.js" type="text/javascript"></script>
{else}
        <script src="jsfull.minified.js" type="text/javascript"></script>
{/if}
    </body>
</html>

Además de esto es recomendable poner un prefijo a nuestro archivo js para que el nombre sea distinto y asegurarnos así que en navegador renueva la caché y se descarga la última versión.

<script src="jsfull.minified.20110216.js" type="text/javascript"></script>

Conclusión final

Y esto es todo. Como más de uno se habrá dado cuenta esta misma técnica podremos emplearla también para unir archivos CSS y reducir así los tiempos de carga de este tipo de archivos.

¡Nos vemos en la próxima publicación!

Related posts:

1. Cómo validar un formulario utilizando PHP y Javascript (jQuery)
2. Entendiendo los Layouts en Zend Framework PHP
3. Creando servicios de red TCP con PHP y xinetd
4. Reducir el tiempo de carga Web: Minimiza las Peticiones HTTP

Es posible que trabajando en cualquier proyecto por pequeño que sea, tengamos la necesidad de contar el tiempo que transcurre en una determinada actividad y mostrarlo por pantalla, para ello crearemos una pequeña aplicación en Silverlight y mediante code-behind haremos toda la lógica del temporizador.

Una vez nos hemos decidido a medir el tiempo, necesitamos, para nuestro temporizador los siguientes elementos:

• Un botón para iniciar/detener.
• Un campo de texto que nos indique el tiempo que está transcurriendo.
• Un temporizador que actualice nuestro campo de texto (obvio, no?)

El apartado gráfico lo crearemos usando XAML, mientras que la lógica de nuesra aplicación (es decir, la parte que va a contar realmente) la crearemos usando C#

Paso 1: Creando la Interfaz

Lo primero será crear la interfaz en XAML, para lo que necesitamos únicamente un par de botones y una etiqueta. Para ello abrimos Visual Studio 2010 y creamos una solución de tipo Aplicación de Silverlight.

Una vez cargada la aplicación, se nos muestra en el editor de Visual Studio la ventana principal, dividida entre editor y código. Posteriormente agregamos las siguientes líneas entre <Grid x:Name=”LayoutRoot”…> y </Grid>:

<StackPanel>
<TextBlock x:Name="text" Width="130" Height="40" Margin="10" Text="00:00:00" TextAlignment="Right" FontSize="26"/>
<Button x:Name="Start" Width="80" Height="30" Content="Iniciar" Click="Start_Click"/>
</StackPanel>

El resultado de lo que acabamos de crear sería algo similar a esto:

Como se aprecia, hemos agregado una etiqueta, un botón, los hemos metido en un StackPanel para que estén alineados, y hemos cambiado el tamaño de nuestro campo de texto en unas pocas líneas.

Paso 2: Agregando código C#

Una vez tenemos nuestro campo de texto, vamos a darle vida, pero primeramente tenemos que crear e inicializar nuestro timer, para lo cual vamos al fichero MainPage.xaml.cs, o bien hacemos click derecho en el editor y seleccionamos la opción Ver código.

En el constructor de MainPage, justo después de IntializeComponent(); incializamos nuestro contador:

//Agregamos un campo de tipo temporizador, y de carácter global para toda la clase, así como un entero que nos servirá para nuestro conteo
int i = 0;
System.Windows.Threading.DispatcherTimer temporizador;

public MainPage(){
InitializeComponent();
//Agregamos el siguiente código de control del temporizador.
temporizador = new System.Windows.Threading.DispatcherTimer();
temporizador.Interval = new TimeSpan(0, 0, 0, 1);
temporizador.Tick += new EventHandler(temporizador_Tick);
}

Como se aprecia, hemos inicializado nuestro temporizador, le hemos asignado un intervalo de 1 segundo (La opción de TimeSpan que hemos empleado tiene el formato: días, horas, minutos, segundos).

Por último hemos agregado un EventHandler que llamará a nuestra función con cada Tick del temporizador (es decir, cada 1 segundo).

Nuestra función tiene el siguiente formato:

void temporizador_Tick(object sender, EventArgs e)
{
i += 1;
int hour = i / 3600;
int min = i / 60;
int sec = i % 60;
text.Text = hour.ToString("00") + ":" + min.ToString("00") + ":" + sec.ToString("00");
}

Lo que estamos haciendo es dividir nuestro contador en horas, minutos y segundos, y mostrar el resultado en el campo que hemos creado para tal efecto.

Para que funcione, lo único que nos queda es crear el evento para el click del botón, que se crea, curiosamente, haciendo doble click en el botón.

private void Start_Click(object sender, RoutedEventArgs e)
{
temporizador.Start();
}

Veamos ahora cómo extender el temporizador…

Paso 3: Extendiendo nuestro temporizador

Una vez que tenemos nuestro temporizador, puede que queramos hacer dos cosas más:

• Parar (o pausar) el contador.
• Restaurarlo (volver a 0).

Para poder parar o pausar el contador, necesitamos conocer cuándo está funcionando nuestro temporizador, y realizar una acción acorde a ello, para ello agregamos el siguiente código:

private void Start_Click(object sender, RoutedEventArgs e)
{
if (temporizador.IsEnabled)     //Si está en funcionamiento, lo detenemos
{
temporizador.Stop();
Start.Content = "Iniciar";
}
else                            //Si no, lo iniciamos
{
temporizador.Start();
Start.Content = "Detener";
}
}

Ahora sólo nos queda agregar el botón con el que pararemos el reloj:

<Button x:Name="Clear" Width="80" Height="30" Margin="10" Content="Restaurar" Click="Clear_Click" />

Y asociado al click, agregamos el siguiente código, que restaura los valores por defecto del contador:

private void Clear_Click(object sender, RoutedEventArgs e)
{
temporizador.Stop();    //Paramos el contador
text.Text = "00:00:00"; //Ponemos el texto a 0
i = 0;                  //Restauramos el valor de nuestra variable
}

El resultado final se muestra a continuación:

Recordad: Para ejecutar el ejemplo es necesario tener Silverlight instalado, y para editar el código fuente os recomendaría utilizar o bien Visual Studio 2010, o Expression Blend 4… aunque ya se sabe para gustos… editores .

Reflexión final

En este tutorial hemos visto cómo podemos, con pocas lineas de código, crear un contador. Hemos:

• Creado la interfaz usando un Stackpanel en el lenguaje XAML
• Creado un objeto de tipo DispatcherTimer
• Usado eventos para gestionar la función que se llama a cada “tick”

Lo mejor de este sistema es la total separación entre interfaz y funcionalidad, de tal manera que todo el apartado XAML se puede realizar mediante Blend, una herramienta más enfocada al diseño, y el desarrollo se puede preparar con Visual Studio, finalmente para enlazarlo solamente necesitamos la etiqueta x:Name, que se corresponde con los elementos mostrados en el apartado de C#.

Espero que os haya resultado provechoso… ¡Nos vemos en la próxima publicación!

Related posts:

1. Qué son y cómo utilizar los custom fields de WordPress
2. Creando una capa de conexión abstracta a base de datos con PHP
3. Creando servicios de red TCP con PHP y xinetd
4. Acelerando los tiempos de carga uniendo archivos Javascript con PHP

Javascript es un lenguaje puramente orientado a objetos. Sin embargo, en muchas ocasiones comenzamos a programar sin un patrón de diseño y llenamos nuestra aplicación de variables y funciones globales. Esto se considera una mala práctica y puede dar lugar a errores como las colisiones o dificultades para mantener y reusar el código.

En este artículo vamos a revisar las técnicas más recientes para la creación de objetos en Javascript. Gracias a estos patrones, podremos crear aplicaciones más organizadas, mantenibles y reusables.

Malas prácticas desde el día cero

Cuando comenzamos a programar en Javascript es frecuente declarar un sin fin de variables globales que más tarde iremos utilizando en nuestro script conforme las necesitemos.

Sin embargo, la bibliografía moderna nos recomienda reservar el uso de este tipo de variables a aquellos objetos que tienen un impacto general en el entorno de nuestra aplicación. Evitando las variables globales reducimos el riesgo de colisión entre ellas a la vez que evitamos ambigüedades.

Para la mayoría de autores, se resume con la misma frase: hay que evitar la creación de variables y funciones (objetos en general) globales siempre que no sean absolutamente necesarios.

Para ilustrar esto, hay que recordar que en Javascript, cualquier variable global se asigna inmediatamente a un namespace (contexto) general: el objeto window. Esto permite que podamos acceder a ella directamente por su nombre, o como una propiedad del objeto general:

var foo = 'bar'; // Definimos la variable como global
console.log( foo ); // Invocamos a la variable directamente por su nombre
console.log( window.foo ); // Invocamos a la variable como un método

No hay nada nuevo en todo esto. A partir de aquí, ya podemos buscar una estrategia para evitar el uso de variables globales. Para ello, lo ideal es crear un número pequeño de objetos que hagan de contenedores para estas variables o, lo que es lo mismo, recoger todo aquello global que participe de un mismo proceso dentro de un namespace (contexto) propio.

Autores como Douglas Crockford, John Resig, Angus Croll o James Edwards han elaborado sus propias aproximaciones a este modelo. Veamos algunas de ellas comentando sus ventajas e incovenientes…

Creación de un objeto global y asignación de métodos por prefijo

Es la opción más sencilla pero quizá algo desorganizada. En su favor, tenemos que es segura para refactorizar aquellos códigos que presentan un número considerable de variables globales haciendo difícil su reutilización en otros proyectos.

Tomemos el siguiente código:

// Opción mala (antipattern)
var foo = 'Hello';
var bar = 'World';
function sum( param1, param2 ){
return param1 + param2;
}
function myMessage(){
return foo + ' ' + bar;
}

console.log( sum( 10, 5 ) ); // 15
console.log( myMessage() ); // Hello World

En el ejemplo anterior, definimos dos variables globales y dos funciones dentro del namespace general. Como ya hemos visto, esta forma de programar puede traernos problemas de colisión además de que el código no presenta ningua cohesión.

Si quisiéramos reaprovechar parte del script, tendríamos que tener cuidado de no olvidarnos alguna variable o función durante el proceso. Según el método de asignación directa que comentamos, el código anterior quedaría como sigue:

var myApp = {}
myApp.foo = 'Hello';
myApp.bar = 'World';
myApp.sum = function( param1, param2 ){
return param1 + param2;
}
myApp.myMessage = function(){
return myApp.foo + ' ' + myApp.bar;
}

console.log( myApp.sum( 10, 5 ) ); // 15
console.log( myApp.myMessage() ); // Hello World

Hemos creado un único objeto global, myApp, que utilizamos como contenedor para el resto de variables y funciones. De este modo, ganamos legibilidad al poder identificar de un solo vistazo, aquellas partes de código que trabajan conjuntamente. A la hora de portar el código, solo tendríamos que preocuparnos de coger aquellas funciones cuyo prefijo coincida con su contexto.

En el código anterior podríamos utilizar la referencia this en el interior de las funciones para facilitar el mantenimiento en el futuro, pero esto puede dar lugar a errores inesperados. Probemos por ejemplo a asignar uno de los métodos que hemos creado a una nueva función:

var newFunction = myApp.myMessage;
console.log( newFunction() ); // Hello World

Las referencias a las variables se conservan y nuestra nueva función accede a ellas siguiendo la ruta original (myApp.foo y myApp.bar).

Cambiemos ahora la referencia a las variables en el ejemplo original:

// ...
myApp.myMessage = function(){
return this.foo + ' ' + this.bar;
}
// ...
console.log( myApp.myMessage); // Hello World

El código continúa funcionando correctamente pero, si volvemos a asignar el método a una nueva función, el resultado varía:

var newFunction = myApp.myMessage;
console.log( newFunction() ); // Undefined. this está refiriendo al objeto global.

Este ejemplo viene a ilustrar una regla que cada vez más autores defienden: nunca debemos referenciar un objeto que estamos utilizando como namespace (contexto) con ‘this‘ ya que podemos obtener errores cuando importamos métodos de un contexto a otro.

Notación literal

Utilizando la notación literal, podemos evitar hacer referencia al objeto global cada vez que necesitemos crear un nuevo método. Además, conseguimos un código más limpio y ordenado. Partiendo del ejemplo anterior, el resultado sería:

var myApp = {
foo : 'Hello',
bar : 'World',
sum : function( param1, param2 ){
return param1 + param2;
},
myMessage : function(){
return this.foo + ' ' + this.bar;
}
};

console.log( myApp.sum( 10, 5 ) ); // 15
console.log( myApp.myMessage() ); // Hello World

Esta estrategia sería la más sencilla para la creación de una estructura básica de POO en Javascript. La portabilidad de los objetos resulta sencilla al tener ‘encapsulado’ todo el proceso.

Módulos

El patrón que llamamos módulo se configura a partir de una función que actúa como contexto para nuestra aplicación. Por lo general, esta función se autoejecuta devolviendo el objeto que representa la interfaz pública de nuestro módulo.

Este modelo es más familiar para aquellos que provienen de otros lenguajes de programación orientados a objetos al permitir distinguir entre métodos públicos y privados. Ya que Javascript no implementa el concepto de clases de forma nativa, creamos funciones que actúen como tales.

Todas las variables y funciones definidas en el interior de nuestra “clase” se consideran métodos privados. Aquellos métodos que queremos hacer públicos los devolvemos mediantes el comando “return” al ámbito general (módulo) de la aplicación.

var myApp = (function(){
var foo = 'Hello';
var bar = 'World';
var sum = function( param1, param2 ){
return param1 + param2;
}
return {
myMessage: function(){
return foo + ' ' + bar;
}
}
})();

console.log( myApp.myMessage() ); // Hello World
console.log( myApp.sum( 10, 5 ) ); // myApp.sum is not a function. sum es privada

En el código anterior, myApp.sum no se ha incluido en el objeto return por lo que permanece privada y visible únicamente dentro de su contexto. Sin embargo, myMessage, si que ha sido devuelta y añadida al entorno de myApp, por lo que funciona como se espera. Con este modelo, ya no es necesario referenciar a las variables con this, ya que comparten mismo contexto.

El aspecto negativo de este patrón es que accedemos de forma diferente a los métodos según sean públicos o privados. Esto supone que si queremos cambiar su visibilidad, tenemos que modificar el código moviendo funciones desde o hacia el método return. Otro inconveniente es que los métodos privados resultarán innacesibles para aquellas funciones que sean añadidas al objeto padre (módulo) con posterioridad a su definición.

Contexto dinámico

Si declaramos un entorno y lo pasamos como argumento de una función autoejecutable, evitamos tener que asignar variables y métodos al contexto mediante el comando return. Resulta por lo tanto una solución derivada de la anterior pero más legible e intuitiva.

var myApp = {};
(function( context ){
var foo = 'Hello';
var bar = 'World';
context.sum = function( param1, param2 ){
return param1 + param2;
};
context.myMessage = function(){
return foo + ' ' + bar;
}
})( myApp );

console.log( myApp.sum( 10, 5 ) ); // 15
console.log( myApp.myMessage() ); // Hello World

Las variables foo y bar, permanecen como privadas, por lo que solo tienen visibilidad dentro de su contexto. Los métodos asignados al objeto contenedor, se convierten en públicos.

Siguiendo este patrón, incluso podemos asignar el contexto al objeto global tal y como hace, por ejemplo, la librería jQuery. Esto permite al usuario elegir si los métodos de nuestra aplicación se convierten en globales o se restringen a la misma:

(function( context ){
var foo = 'Hello';
var bar = 'World';
context.sum = function( param1, param2 ){
return param1 + param2;
};
context.myMessage = function(){
return foo + ' ' + bar;
}
})( this );

console.log( sum( 10, 5 ) ); // 15
console.log( myMessage() ); // Hello World

Echemos ahora un vistazo al patrón de James Edwards…

Patrón de James Edwards ‘This namespaces proxy’

James Edwards ha creado un patrón cuya simpleza esconde una joya en cuanto a arquitectura de código. Utilizando la referencia this para inyectar métodos al contexto, evita que éstos puedan ser reasignados accidentalmente más adelante.

var myApp = {};
(function(){
var foo = 'Hello';
var bar = 'World';
this.sum = function( param1, param2 ){
return param1 + param2;
};
this.myMessage = function(){
return foo + ' ' + bar;
};
}).apply( myApp );

console.log( myApp.sum( 10, 5 ) ); // 15
console.log( myApp.myMessage() ); // Hello World

Simple y elegante: el uso de los comandos apply y call separan el contexto de los argumentos, lo que mejora aún más el diseño general. Siguiendo este patrón, podemos incluso asignar un mismo módulo a dos contextos direfentes consiguiendo implementaciones paralelas:

var context1 = {}, context2 = {};
var incrementNumber = function( param1 ){
var startNumber = param1 || 0;
this.increment = function(){
return startNumber++;
}
};
incrementNumber.call( context1 );
incrementNumber.call( context2, 10 );

console.log( context1.increment() ); // 0
console.log( context1.increment() ); // 1
console.log( context1.increment() ); // 2
console.log( context2.increment() ); // 10
console.log( context2.increment() ); // 11
console.log( context2.increment() ); // 12

Conclusión final

En la programación Javascript moderna, evitar la creación de variables y métodos globales resulta básico: si pretendemos integrar librerías de terceros o escribir un código que pueda ser reutilizado, tenemos que estructurarlo correctamente para evitar los errores derivados de las colisiones y ambigüedades.

Para ello, recurrimos a la creación de objetos que actúen como contenedores de aquellas piezas de código que compartan funcionalidad. A lo largo del artículo hemos visto diferentes aproximaciones al mismo problema analizando tanto sus ventajas como los inconvenientes.

Corresponde ahora al desarrollador elegir aquel método que mejor se adapte a sus necesidades concretas o crear su propio patrón a partir de los mismos.

Más información:

Os dejamos algunos enlaces para curiosos que quieran seguir profundizando en el tema:

• James Edwards, My Favorite Javascript Design Pattern
• Peter Michaux, Javascript Namespacing
• Angus Croll, Namespacing in Javascript
• Addy Osmani, Essential JavaScript & jQuery Design Patterns For Beginners

Nos vemos en la próxima publicación… ¡Un saludo!

Related posts:

1. Funciones perezosas / Lazy functions en Javascript
2. Cómo validar un formulario utilizando PHP y Javascript (jQuery)
3. Creando una capa de conexión abstracta a base de datos con PHP
4. Cómo crear un Menú Contextual en Javascript mediante jQuery

Cuando desarrollamos una aplicación nos damos cuenta que varias de las pantallas son básicamente iguales y lo único que cambia son los contenidos interiores de estos. Para muestra un pequeño y sencillo ejemplo:

Como podemos ver en el ejemplo, estructuralmente no hay mucha diferencia entre las dos páginas. En la primera mostramos el home, mientras que en la segunda otro texto cualquiera. Las dos tienen un encabezado y un cuerpo, pero si nos fijamos bien, veremos que solo varía el cuerpo.

En el artículo anterior Empezado con Zend Framework, colocamos en las vistas todo el html, desde las etiquetas <html> lo cual está bien porque funciona bien. Pero si tuviésemos una aplicación con más 100 vistas (algo que puede darse perfectamente), entonces no sería práctico. Si hiciéramos algún cambio en la maquetación, tendríamos que hacerlo en todas las vistas. Imáginénlo, nunca terminaríamos.

Los layouts suelen ser una gran ayuda durante la integración del php y el html. Nos ahorran mucho trabajo y aunque no es obligatorio su uso, debería ser un estándar en nuestro trabajo con ZF

Por suerte existen los layouts. Estos incrustarán todo el contenido colocado en la vista y además podrán tener el contenido de otros layouts. Podemos crear todos los layouts que necesitemos, sin límite.

Declarando el layout

Habrá un layout principal para toda la aplicación. La ubicación de estos, debido a que es parte de la aplicación, debería estar dentro de la carpeta de la aplicación, aunque es posible especificar cualquier otra. Esto lo podemos definir en el archivo application.ini de la siguiente manera:

;resources.layout
resources.layout.layoutPath        = APPLICATION_PATH "layouts/scripts"
resources.layout.layout            = "home"

El nombre del archivo del layout será el que nosotros querramos. En nuestro ejemplo home.phtml pero en application.ini no colocaremos la extensión.

Si no declaramos la ruta de los layouts, ZF los buscará en layouts/scripts dentro de la carpeta de la aplicación.

A menudo podremos necesitar layouts para contenido xml o json, o talvez un layout en blanco. Eso dependerá de lo que necesitemos.

Escribiendo un layout

Veamos un sencillo ejemplo de cómo se escribe un layout:

<?php echo $this->doctype(); ?>
<html>
<head>
<?php
$this->headMeta()->appendHttpEquiv('Content-Type', 'text/html; charset='.$this->getEncoding())
->appendHttpEquiv('Content-Language', 'es-ES');
echo $this->headMeta();
$this->headLink()->appendStylesheet('/css/miestilo.css');
echo $this->headLink();
echo $this->headTitle();
$this->headScript()->appendFile('/js/common.js');
echo $this->headScript();
?>
</head>
<body>
<div>
<div><?php echo $this->layout()->content; ?></div>
</div>
</body>
</html>

Como podemos ver, el ejemplo anterior contiene las cabeceras más importantes del html, pero la línea siguiente:

<?php echo $this->layout()->content; ?>

es la encargada de insertar el contenido de la vista en el layout. Absolutamente todo lo que esté en la vista, se guardará en la variable de layout content.

¿Qué ocurre con las demás líneas de código? Pues ellas traen contenido declarado en los controladores o en el bootstrap.php. Veamos ahora como sería nuestra vista:

<?php echo $this->mensaje; ?>
 <br />
 que tal mi aplicacion en ontuts <img src="http://web.ontuts.com/wp-includes/images/smilies/icon_razz.gif" alt=":P">

Podemos notar que el código dentro de la vista se ha reducido a solamente lo que necesitamos de ella.

Es importante darnos cuenta de un detalle: $this->layout()->content; almacena el contenido de la vista, pero está dentro del ámbito $this-&bt;layout() y a este también podemos asignarle otros valores desde el controlador.

Variable de layout

Antes de continuar, quiero regresar unas lineas arribas y que se den cuenta de algo que he escrito y es muy interesante: variable de layout. ¿Y qué es una variable de layout? Desde los controladores, les podemos pasar a las vistas cierta información en forma de variable de vista.

Ya lo hemos visto antes así: $this->view->mensaje. ¿lo recuerdan? El problema está en que este valor es solo para una vista específica y para aquella en la que hemos llamado a su Action().

Las variables de layout nos permitirán reutilizar los valores de las variables en las distintas vistas de nuestra aplicación, en lugar de estar disponibles para una única vista en particular.

Por el contrario, una variable de layout, estará disponible en todas las vistas, sin importar el Action en el que estemos. Es decir, tiene un entorno más amplio. Noten que digo vistas. Las variables de layouts, se pueden utilizar en todos los layouts y en todas las vistas. Es decir, en todos los archivos .phtml.

Pero… ¿para qué quiero una variable de layout? Supongamos que me autentifico en mi aplicación y quiero que en ella aparezca mi nickname (nombre de usuario), siempre en todas las páginas. Podría almacenar ese dato en una variable de layout.

La forma en la que declarao esta variable es muy sencilla:

$this->layout->nickname = 'elericuz';

Por otro lado, en el layout o en la vista, lo único que necesito hacer para mostrarla es imprimir su valor mediante la función echo():

echo $this->layout()->nickname;

Controlando los layouts

Más arriba mencioné que a menudo podríamos necesitar utilizar diferentes layouts para diferentes tareas. Piensen que el diseño del home será diferente al diseño de las páginas internas. En ese caso al menos, necesitaremos 2 layouts: home.phtml y internas.phtml

home.phtml

<?php echo $this->doctype(); ?>
<html>
<head>
    <?php echo $this->headMeta(); ?>
    <?php echo $this->headTitle(); ?>
    <?php echo $this->headStyle(); ?>
    <?php echo $this->headScript(); ?>
</head>

<body>
    <div style="text-align: center;"><?php echo $this->layout()->content; ?></div>
</body>
</html>

internas.phtml

<?php echo $this->doctype(); ?>
<html>
<head>
    <?php echo $this->headMeta(); ?>
    <?php echo $this->headTitle(); ?>
    <?php echo $this->headStyle(); ?>
    <?php echo $this->headScript(); ?>
</head>

<body>
    <div><a href="<?php echo WWW_ROOT; ?>">Home</a> | <a href="<?php echo WWW_ROOT; ?>prueba">Otro link</a></div>
    <br />
    <?php echo $this->layout()->content; ?>
</body>
</html>

En application.ini le hemos indicado a ZF que utilice home.phtml como layout predeterminado. Solo nos faltaría indicarle a ZF que cuando no estemos en el home de nuestra aplicación use internas.phtml como layout. Eso lo hacemos en el controlador/función que queramos así:

$options = array(
  'layout'	 => 'internas',
);
Zend_Layout::startMvc($options);

De esta forma podremos cambiar de layout según nuestras necesidades en cualquier momento de manera cómoda y sencilla.

Reflexión Final

Como hemos visto, los layouts nos ahorran muchas líneas de código y eso los convierte en una herramienta muy importante para nosotros.

Si bien esta ha sido una breve explicación de lo que es un layout, En el siguiente artículo explicaré cómo hacer una estructura de layout y desarrollarlo en forma programática, siempre orientado a objetos.

¡Nos vemos en la próxima publicación!

Related posts:

1. Introducción a Zend Framework PHP
2. Acelerando los tiempos de carga uniendo archivos Javascript con PHP
3. Creando servicios de red TCP con PHP y xinetd
4. Validar y sanear datos en PHP

Desde que el lenguaje Java fue diseñado a principio de la década de los 90, el principal hueco que pretendió ocupar fue el de alternativa mucho más sencilla y portable al lenguaje C++ (principalmente en términos de gestión de memoria y librerías de clases). Posteriormente, con la aparición en el año 1993 de la WWW, Java (y Sun) se adelantó al resto de sus competidores y se convirtió ipso-facto en el estándar de desarrollo de aplicaciones web empresariales, donde actualmente comparte la mayor parte del nicho de mercado junto con la tecnología .NET de Microsoft.

Inicialmente Java se convirtió en poco tiempo en el estándar de desarrollo de aplicaciones empresariales. Hoy comparte el puesto con .NET de Microsoft.

Sin embargo, la evolución que Java ha ido experimentando en términos de facilidad de uso y productividad a la hora del desarrollo de aplicaciones, principalmente web, se ha visto seriamente comprometida desde sus inicios por los tediosos y burócratas procesos establecidos por Sun en torno a sus JCPs (Java Community Process) para producir JSRs (Java Specification Request), esto es, especificaciones estándar para la tecnología Java.

De esta forma, hasta hace sólo unos pocos años, eran las grandes empresas de software las encargadas de decidir qué, cómo y cuándo se podía aplicar una determinada tecnología mediante una especificación a la plataforma Java, en la mayoría de los casos, inexplicablemente compleja y enreversada, como lo prueban ejemplos de sus primeras criaturas denominadas EJBs (Enterprise Java Bean).

La comunidad libre impulsó con una cantidad masiva de proyectos la plataforma Java, mejorándola y haciéndola mucho más potente con adaptaciones de todo tipo.

Como no hay mal que por bien no venga (o como dicen mis amigos americanos, es una bendición disfrazada), y puesto que Java acuñó desde sus inicios una licencia de uso completo y sin modificaciones para la ejecución de programas, esta actitud provocó la masiva respuesta de la comunidad de libre distribución (open-source) en forma de una ingente cantidad de proyectos.

Estos proyectos intentaban complementar las deficiencias de Java como plataforma de desarrollo (cuidado, el lenguaje en sí siempre ha estado a la altura), tanto a nivel web (Struts, Tapestry, Velocity, etc.) como de acceso a datos (Hibernate, iBatis, etc.) o incluso gestión de dependencias (Spring, Guice, etc.). Muchos de estos proyectos open-source son ahora referentes y estándares de-facto en el desarrollo Java, por mucho que desde el comité de JCPs se empeñen en obviarlos (aunque cada vez menos, al césar lo que es del césar).

Lenguajes dinámicos o cómo evitar la verbosidad del lenguaje

Seamos sinceros; a mi me encanta el lenguaje Java, amo el lenguaje Java y para los que jugueteamos, años ha, con Cobol, Fortran, Prologue, OS/2, Clipper, Basic, C/C++ y algunos otros que ya ni quiero recordar, supuso un regalo en forma de tecnología orientada a objetos imposible de rechazar.

Estableciendo esta premisa inicial, la crítica constructiva (aunque a veces pase por destructiva) es un ejercicio de salud tecnológica al que no podemos renunciar, y seguramente en mis primeros desarrollos estaba cegado por el árbol que no me dejaba ver el bosque. Y es que ese bosque apareció delante de mi, por sorpresa, sin realmente buscarlo, cuando tuve noticias del proyecto Groovy, un lenguaje dinámico para Java.

Por entonces, yo ya me tenía que pelear en ocasiones con Javascript (que recordemos no tiene nada que ver con Java, pero incorpora mucha de su sintaxis orientada a objetos, por lo que sus autores probablemente utilizaron el “bombo y platillos” en torno a Java para establecer su nombre), y he de reconocer que sentía una envidia sana por sus características dinámicas y su débil (por no decir inexistente) tipado. Pero ante mi surgió Groovy y mi vida de desarrollador cambió radicalmente a mejor, a mucho mejor, a volver a disfrutar desarrollando. Y no exagero, ni un ápice.

Groovy nos permite ejecutar código precompilado en Java y también código Java en Groovy sin compilación previa.

Para aquellos que no conozcáis Groovy, se trata de un lenguaje de scripting, ágil y orientado a objetos, que nace, vive y muere en la propia máquina virtual de Java. Esto quiere decir que podemos ejecutar código Groovy (previamente compilado a código Java) desde Java, y Java (sin ningún tipo de proceso de compilación) directamente en Groovy, abriéndose ante nosotros las puertas al infinito y más allá. Aunque no es el objetivo de este artículo el detallar las bondades de Groovy, sí me voy a permitir un ejemplo muy gráfico por eso de que “una imagen vale más que mil palabras”:

Ejemplo en Java

import java.util.List;
import java.util.ArrayList;

class Erase {
    private List removeLongerThan(List strings, in length) {
        List result = new ArrayList();
        for (int i = 0; i < strings.size(); i++) {
            String s = (String) strings.get(i);
            if (s.length() <= length) {
                result.add(s);
            }
        }
        return result;
    }

    public static void main(String[] args) {
        List names = new ArrayList();
        names.add("Enrique"); names.add("Adrian");
        names.add("Javier"); names.add("Marisa");
        System.out.println(names);
        Erase e = new Erase();
        List shortNames = e.removeLongerThan(names, 6);
        System.out.println(shortNames.size());
        for (int i = 0; i < shortNames.size(); i++) {
            String s = (String) shortNames.get(i);
            System.out.println(s);
        }
    }
}

Ejemplo en Groovy

names = ["Enrique", "Adrián", "Javier", "Marisa"]
println names
shortNames = names.findAll{ it.size() <= 3 }
println shortNames.size()
shortNames.each{ println it }

Como supongo ya habréis adivinado, ambos códigos producen exactamente el mismo resultado, sólo que si tuviérais que elegir uno, ¿con cuál os quedaríais? No me lo digáis, yo también.

Grails: la búsqueda del grial… ¿ha concluido?

Sin ser, ni pretender ser un buen estratega militar, el objetivo que perseguía con las dos primeras secciones de este artículo, era el de despertar la curiosidad del lector ante un escenario tan sumamente heterogéneo de tecnologías en torno a Java, pero a la vez tan aprovechable utilizando la perla dinámica de Groovy. Espero haberlo conseguido, y como ya no puedo ocultarlo más, pues aquí os presento a Grails, la plataforma de desarrollo (web) que ha cambiado mi aura programadora.

Y es que Grails es uno de esos proyectos que si no existiera habría que inventarlo, porque ha conseguido mediante unas de las técnicas más antiguas del desarrollo, el “no te repitas a ti mismo y no reinventes la rueda” (DRY, en inglés), un framework “completo” (aunque a mi me gusta llamarlo plataforma) compuesto de la unión de otros frameworks “pegamento”. Veamos qué se esconde detrás de este ejercicio de verbilocuencia.

Framework “completo” contra framework “pegamento” (en inglés, ‘full-stack’ vs ‘glue’ frameworks)

• Un framework “completo” es aquel cuyos objetivo principal es proporcionar un conjunto simple de componentes que permitan cubrir el espectro completo de las necesidades requeridas para construir aplicaciones (web), y asegurar que dichos componentes trabajan y se integran de forma óptima unos con otros.
• Un framework “pegamento”, por el contrario, persigue proporcionar un conjunto de adaptadores y código de interfaz que permita gestionar los diferentes componentes en cada capa del desarrollo, y asegurar que dichos adaptadores funcionan correctamente con tantas combinaciones de los componentes como sea posible. Como ejemplo, un framework especializado o focalizado bien en una capa específica, como la capa de presentación (web), o la capa de acceso a datos.

En Grails, no sólo se superan los objetivos marcados por un framework “completo” con matrícula de honor cum-laude, sino que se elevan a la máxima potencia otorgando al desarrollador una plataforma integrada de ejecución de los propios desarrollos, que además es intercambiable, y que permite el “cambio en caliente” del código (algo que muchos desarrolladores no-Java darán por sentado, pero que no estaba tan claro en el mundo Java, salvo con complicadas maniobras de birlibirloque).

Otro punto a favor de Grails es la gran cantidad de plugins que permiten extender la funcionalidad base, son ya más de 500 y no dejan de crecer día a día.

Y si esto no calmara nuestra avivada sed de curiosidad por si sólo, destacar que la arquitectura de Grails ha sido diseñada con orientación abierta y “enchufable”, de forma que existe un ecosistema de más de 500 plugins que permiten extender la funcionalidad de nuestra aplicación con el único techo de nuestra capacidad como desarrolladores.

Diseccionando a Grails de arriba a abajo

Quedaría este artículo huérfano, y similar a una zanahoria flotando eternamente a unos centímetros de la boca del asno (siempre en sentido figurado, que nadie se me ofenda), si no presentáramos las piezas que forman el puzzle mágico del que hablamos. Así, Grails es:

• Una capa de abstración denominada GORM para acceso a datos construida sobre el ORM (Object Relational Mapping) más utilizado por la comunidad Java (y otras muchas más): Hibernate.
• Una tecnología expresiva de presentación / vista, basada en plantillas, denominada GSP (Groovy Server Pages).
• Una capa de control basada en Spring MVC, reconocida como la mejor tecnología MVC del mercado.
• Un entorno de scripting de línea de comando construido sobre Gant, una extensión Ant basada en Groovy.
• Un contenedor Tomcat embebido, configurado para la recarga “en caliente” (fly reloading).
• Gestión de inyección por dependencia (DI) mediante el contenedor de Spring.
• Soporte para internacionalización / localización (i18n) a partir del concepto MessageSource de Spring.
• Gestión transaccional “gratuita” basada en la abstracción transaccional de Spring.

Y recordemos, todas estas piezas sólo como núcleo principal o plataforma, sin olvidar la posibilidad ya comentada de inyectar todo tipo de plugins con todo tipo de funcionalidades: búsqueda “full-text” con Lucene/Solr, integración social con Facebook/Twitter/Tuenti, almacenes NoSQL como MongoDB, GemFire, Redis, CouchDB, seguridad integrada de autenticación/autorización con Spring Security, librerías de widgets gráficos RIA, y un largo etcétera sólo por nombrar unos pocos. Encuentra aquí la lista completa.

Conclusión

Existen múltiples y variados frameworks Java de desarrollo que proporcionan algunas de las piezas del puzzle web, pero se echaba en falta un pegamento que permitiera aglutinarlas en una plataforma “completa” y “extensible” de desarrollo.

Grails ha conseguido este objetivo combinando el lenguaje dinámico Groovy con aquellas tecnologías abiertamente aceptadas como estándares de-facto en la comunidad Java. El “grial” Java ya está aquí, y ha venido para quedarse.

Si quieres ver una aplicación real en acción, deja tu comentario y anímame a ponerme a escribir un tutorial de desarrollo en Grails.

¡Nos vemos en el próximo artículo!

Related posts:

1. Introducción a Object-Relational Mapping (ORM)
2. Introducción a Cookies en la Web