Entendiendo el concepto de Hijax
Demos continuidad al artículo anterior sobre Ajax y jQuery agregando un concepto muy importante a la tecnología Ajax.
El concepto de Hijax es muy interesante aunque realmente no lo suelo escuchar mucho y realmente me costo un poco encontrar una manera de implementarlo, más por el hecho de encontrar una manera sencilla de hacerlo y sin dar tantas vueltas antes que por desarrollar código.
Básicamente se trata de no permitir que nuestro código Ajax elimine la posibilidad de que la funcionalidad normal de nuestra página continúe normalmente. Cuando empezamos a usar Ajax nos entra como una desesperación de usarlo en todo y considero que ese concepto no es el más acertado ya que hay que tener en cuenta a los clientes que no pueden interpretar JavaScript o cuando una página está aún cargando y los usuarios ya quieren dar click a los elementos.
Para ir entendiendo el concepto utilicemos un ejemplo que me parece bastante interesante: twitter.com. No se si lo habrán notado pero cuando entran al sitio y quieren ingresar el usuario y contraseña vemos que hay un botón “Iniciar Sesión”, el cual tiene dos comportamientos diferentes
- Si el JavaScript necesario ya fue descargado veremos que abre un div para que introduzcamos los datos
- En caso de que todavía no fue descargado y ya lo presionamos nos daremos cuenta que directamente nos redirecciona a una página diferente para ingresar los datos.
Si la página fuese solo preparada para usar JavaScript el botón no funcionaria hasta que la descarga se completara y por supuesto un navegador que no soporta JavaScript o que lo tiene desactivado no podría ni siquiera loguearse al sitio.
Este concepto es llamado “JavaScript no obstructivo”, lo que indica que el código JavaScript no obstruye el funcionamiento normal de las páginas sino que le dan un soporte especial, en este caso permitir que el logueo de usuario sea más rápido.
Esto lógicamente ocurre también cuando usamos Ajax sin pensar es este concepto y utilizar JavaScript no obstructivo para implementar Ajax es Hijax. En otras palabras el Ajax no debe ser utilizado para reemplazar el flujo normal de una página sino para acelerar ciertas acciones útiles en el caso de que el navegador tenga el soporte correspondiente.
La idea sería programar un sitio como si no existiera Ajax y una vez que lo tenemos funcionando agregamos las funcionalidades especiales. La otra opción sería hacer directamente dos sitios como lo hace Google con Gmail.
Ejemplo de Hijax
Empecemos con un ejemplo sencillo sobre esto. Muchos años los programadores JavaScript nos acostumbramos a usar los eventos directamente sobre los objetos html como por ejemplo un botón en un formulario. Supongamos el siguiente ejemplo:
<form id="test1" action="procesar_form.php" method="post">
<input type="text" name="user" id="user" />
<input type="password" name="password" id="password" />
<input type="button" value="Submit" id="btnEnviar" onclick="enviar()" />
</form>
Ese onclick sobre el botón para enviar hacía que solo funcione el formulario con JavaScript ya que el type es button y no submit. El botón no hacía nada pero cuando se ejecutaba el onclick llamaba a una función que validaba el formulario y luego por medio de JavaScript ejecutabamos el submit del formulario.
Gracias a la aparición de los listeners con JavaScript nos permitió separar el código js del html
jQuery('#btnEnviar').click(function(){
//-- ejecutamos la validación
});
De esta manera estamos haciendo lo mismo sin tener que escribir la llamada a la validación dentro del onclick="enviar()". Los listeners se encargan de escuchar el evento del objeto y ejecutar el código necesario. Pero seguimos teniendo el mismo problema ya que el “type” del input sigue siendo “button” por lo que solo funcionaria con JavaScript.
Aquí es donde entendemos que la solución sería usar el evento onsubmit del formulario y no el onclick del botón, así que cambiaremos el type del botón a submit.
<form id="test1" action="procesar_form.php" method="post">
<input type="text" name="user" id="user" />
<input type="password" name="password" id="password" />
<input type="submit" value="Submit" />
</form>
Y es interesante saber que si la función ejecutada en el onsubmit de un fomulario retorna false el submit finamente no se ejecutará
<script type="text/javascript">
//-- Cuando el DOM esta listo
jQuery('document').ready(function(){
//-- Agrega un listener que se encargará de saber cuando se
// intente ejecutar el submit del form
jQuery('#test1').submit(function(){
alert('ejecutando código');
return false;
})
});
</script>
Entonces nuestra programación Ajax para envío del formulario debería estar escrito en el evento submit permitiendo que si por alguna razón el JavaScript no pudo ser interpretado o ocurre algún error el submit se ejecutará normalmente mientras que si fue posible la utilización de JavaScript se procesará el código Ajax al servidor y luego terminará parando el envío normal del submit del form retornando false para que no vuelva a realizar la acción.
Utilicemos el código completo del artículo anterior con las modificaciones para respetar el concepto de Hijax
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<script type="text/javascript" src="jquery-1.5.min.js"></script>
<script type="text/javascript">
jQuery('document').ready(function(){
jQuery('#test1').submit(function(){
jQuery.post(jQuery('#test1').attr('action'), jQuery('#test1').serialize(), function(datos_devueltos){
if(datos_devueltos)
alert('Datos procesados correctamente');
else
alert('Ha ocurrido un error');
});
return false;
})
});
</script>
</head>
<body>
<form id="test1" action="procesar_form.php" method="post">
<input type="text" name="user" id="user" />
<input type="password" name="password" id="password" />
<input type="submit" value="Submit" />
</form>
</body>
</html>
Una buena observación es que para los links tenemos la misma funcionalidad pero con el evento onclick, donde al retornar false no se procesa el link.
Para pensar
Aquí surge una pregunta interesante. ¿Qué pasa con los formularios que no ejecutan el código JavaScript para validarlo?, ¿Donde queda la seguridad del formulario para los navegadores que no contemplan JavaScript o los que lo tienen desabilitado?. La respuesta es simple. JavaScript no fue creado para dar seguridad al sitio sino para dar dinamismo. Las validaciones de formularios son “obligatorias” en el lado del servidor, con PHP por ejemplo, y las validaciones JavaScript son “útiles” en el cliente para responder con mayor rapidez y no esperar que la página ejecute un request/response para dar los avisos de errores, pero no tiene la misma obligatoriedad que la primera. Hay que tener en cuenta también que si solo tenemos validaciones del lado del cliente con una herramienta como FireBug podemos perfectamente eliminarlas y ejecutar los formularios, es ahí donde el concepto de seguridad nos obliga a tener validaciones en el servidor. Ojo!! no digo que no se deban usar, digo que son muy útiles pero siempre un formulario debería tener una validación en el servidor.
Me parece interesante entender que usar Ajax no debe ser una locura colectiva de usarlo en todas partes sino usarlo en los lugares en donde valen la pena y tienen un objetivo. Me parece muy interesante compartir este artículo con ustedes sobre donde usar y no usar Ajax.
Espero que se haya entendido el concepto de Hijax y que lo puedan ir investigando un poco más para ir agregando a sus proyectos. Los comentarios son siempre bienvenidos.
Puedes ver el siguiente artículo sobre esta serie aquí.