Me mudo

Este blog no recibirá ya más actualizaciones. Ve al nuevo blog enricflorit.com o averigua por qué me mudo.

domingo, 17 de febrero de 2013

PHP Orientado a Objetos 1: base teórica

Hola, si quieres puedes leer este artículo en la nueva URL:

http://www.enricflorit.com/php-orientado-a-objetos-base-teorica/

sábado, 9 de febrero de 2013

Procesadores de css para acelerar la producción de una web

Puedes leer este artículo en el siguiente enlace:

http://www.enricflorit.com/procesadores-de-css-para-acelerar-la-produccion-de-tu-web/

sábado, 2 de febrero de 2013

Creando un compilador de Javascript con PHP


Hoy voy a hablaros de una técnica para la producción de páginas web. Como de costumbre, usaré PHP, pero supongo que debe ser algo fácil de implementar en cualquier otro lenguaje para servidor.

Normalmente, las páginas web grandes suelen tener una estructura compleja. Más últimamente, que usamos todo tipo de bibliotecas para mejorar nuestras aplicaciones. A nivel de cliente, se ha puesto muy de moda Javascript, con un gran abanico de usos: páginas que cargan dinámicamente con AJAX, efectos en menús, cambios de estilos, objetos escondidos...

Centrándonos en la parte del cliente de una aplicación web: al menos personalmente, tiendo a separar las diferentes partes de mi código en más de un archivo. Uno contiene algunas funciones de uso general, otro la lógica para el árbol de carpetas o menú de la página, otro para ajustar la página a la pantalla del usuario (como complemento al Responsive Design en CSS)... En una de las páginas web que mantengo, el número de estos archivos *.js llega a alcanzar los veinte scripts diferentes.

A nivel de organización, todo esto está más que bien: cualquier problema será detectado (en principio) con facilidad, y sabremos en todo momento a qué archivo acudir en caso de que una parte de la web nos falle. Pero, mirándolo de otro modo, esto sólo nos beneficia a nosotros como programadores y no tanto al usuario. Y es que no es precisamente rápido en términos de velocidad de Internet tener que descargar 20 archivos adicionales (a parte de la página web propiamente).

Cuando vi las dimensiones que estaba alcanzando la página web de los 20 .js, me preocupé un poco. Pensé en lo que acabo de decir: no es mucha carga para el usuario? Ya no te digo si la página se descarga desde un dispositivo móvil, donde la velocidad no suele ser el fuerte. Así que me hice con el siguiente pedazo de código PHP:

<?php
require 'jsmin.php';
$files = array('script1.js','script2.js','script3.js');

foreach( $files as $file) {
$parts = explode('.',$file);
$extension = strtolower( end($parts) );
if ($extension === 'js') {
$f = fopen($file,'r');
$buffer[] = fread($f,200000);
}
}
$output = JSMin::minify(implode(";\n", $buffer));

header("Content-type: application/x-javascript; charset: UTF-8");
echo $output;
?>

Digamos que le pasamos a PHP una lista de los archivos a usar. Simplemente los lee y los comprime usando una clase que encontré “por ahí”. Luego declara una cabecera de archivo Javascript y devuelve la cadena con todo nuestro código comprimido. Podríamos llamarlo un “compilador” de código javascript (aunque es muy mejorable).

Como le damos la cabecera application/x-javascript, podemos incluir este archivo directamente:

<script src=”/js/javascript.php”></script>

Es de lo más útil, y solo se tiene que cambiar los nombres de archivo del array $files.

Con este código, no sólo conseguimos que el usuario tenga que descargar un único archivo javascript. También nos libramos de un problema entre las fases de desarrollo y producción: en vez de usar una web al estilo jscompress.com cada vez que queramos liberar una nueva versión de un script javascript, php lo hará por nosotros con solo subir el archivo modificado (en bruto, sin comprimir ni nada) al servidor.

Os dejo el código fuente y la clase jsmin.php aquí.

Hasta la semana que viene ;-)

Related Posts Plugin for WordPress, Blogger...