Hace unos días tuve que acercarme, por motivos laborales, a otra empresa para solucionar, o dar solución, sobre un problema Javascript sobre una página que nos estaban haciendo. Al revisar el código que estaban haciendo descubrí el problema y me horrorizé al ver el planteamiento que habían elegido para llevar a cabo dicha tarea.
Pongamos en situación
Imaginemos que queremos hacer una aplicación en la que necesitamos disponer de una serie de combos dependientes, por ejemplo pais/destino. Imaginemos que queremos usar ajax para recargar el combo de destinos al seleccionar un pais. Imaginemos que no tenemos mucha idea y decidimos hacer uso de un setInterval() para controlar el momento en el que el combo cambie…
Veamos el código
var pais = document.getElementByID("pais");
vat tmpPais = "";
function actualizaDestinos() {
// Ajax...
....
}
function compruebaPais(){
if (tmpPais != pais.value) actualizaDestinos();
else tmpPais = pais.value;
}
setInterval("compruebaPais", 1000);Como podemos ver, el planteamiento es el siguiente, una especie de comprobación redundante como esta:
- ¿Estás modificado?
- No
- ¿Estás modificado?
- Si
- Entonces, alla voy!!!
Evidentemente, este sistema no es el más correcto, ya que por una petición satisfactoria se han producido N insatisfactorias. Lo que se puede evitar con un simple cambio de concepto.
Un planteamiento más correcto
Al intentar explicarles, que el uso de Ajax, suele ir ligado a la interacción por parte del usuario creo que les hize comprender que estaban enfocando el problema erroneamente. ¿Por que preguntar cada segundo si algo se ha cambiado, cuando puedes hacer que te avisen cuando algo cambie?
Gracias a métodos como el de onchange, podemos hacer que sea el combo el que nos avise de que hemos realizado el cambio y en ese momento lanzar la petición y cargar el combo correspondiente en el momento adecuado.
Veamos el código
var pais = document.getElementByID("pais");
vat tmpPais = "";
function actualizaDestinos() {
// Ajax...
....
}
function compruebaPais(){
if (tmpPais != pais.value) actualizaDestinos();
else tmpPais = pais.value;
}
pais.addEventListener("change", compruebaPais, false);
//pais.onchange = compruebaPais; (machacando el evento)Como podemos ver, la cosa cambia. La conversación entre los combos es muy diferente y casi nula. Esto es debido a que el planteamiento lógico, conociendo los métodos disponibles nos puede facilitar la tarea.
- Estoy esperando, ya me avisarás.
- ...
- He cambiado, haz lo que te de la gana :D
- Me pongo manos a la obra, gracias.
Evidentemente esta solución evita, además de peticiones constantes, una serie de problemas añadidos al interval, que si no es tratado debidamente, aúnque este cambie los combos de la forma correcta, seguriá lanzando la petición indefinidamente hasta que cambiemos de página.
Conclusión
Con este ejemplo, no quiero decir que sea incorrecto el primer método, por que lamentablemente todo esto funciona y los clientes inexpertos ven una aplicación que funciona y que cubre la idea que ellos tenían, por lo tanto mirando desde el punto de vista del cliente, nunca puede ser erroneo algo que cumple lo que ellos quieren. Solo intento explicar que es necesario formarnos y estar al tanto de novedades relacionadas con el lenguaje que usamos, para realizar una tarea más profesional.
Con respecto al ejemplo número 2, hay que decir que este sistema no es nada accesible y que un usuario sin javascript se dará la vuelta y no volverá a nuestra página, por eso debemos pensar en todo y planear la forma de atacar el problema con todas las herramientas de las que disponemos. Sinó fuera así aún estaríamos usando iframes para cargar porciones de páginas. ¿no creeis?
16 comentarios, 2 referencias
+
#