El dichoso Ajax

Hasta ahora, el Ajax siempre ha supuesto una desilusión para mí. El motivo de ello es claro, utilizarlo es farragoso, no aporta claridad al sistema.

Por poner un ejemplo, con Prototype -librería de AJAX más aceptada-, en el desarrollo de cualquier aplicación tienes que andar mezclando funciones en tus scripts PHP con funciones en javascript que tienen que compartir el mismo nombre con la que no estoy de acuerdo.

Opinaba que tenía que existir algo más fácil, más cómodo e independiente del desarrollo en sí.

Hoy gracias a Luís que ha sido el que ha trasteado de forma más intensa con Ajax, hemos dado con la tecla de utilizarlo de forma transparente, y cuando digo transparente, me refiero a ser Transparente Totalmente. Me doy cuenta también, de que es consecuencia también de desarrollar las aplicaciones siguiendo un sistema diferente a lo que se encuentra en la actualidad. En pocos sitios se utiliza un esquema parecido al patrón MVC (Modelo Vista-Controlador). Luís, al igual que yo, es de la opinión que Ajax es marketing, y lo importante es XMLHttpRequest() para agilizar ciertas partes de la interfaz del usuario.

Y además confirma una idea que uso a menudo: 'cuando algo se hace con sentido, utilizarlo para dar otros servicios, es muy cómodo y te ofrece una potencia incalculable'. Sin tocar ninguna línea del sistema que has desarrollado. Poder hacerlo, confirma que antes lo hiciste bien.

Volviendo al tema que quema, mi reticencia al Ajax, venía más porque como estaban hechas las apps web -independiente del lenguaje elegido- que por el Ajax. Trataré de explicarme con un ejemplo desarrollo (utilizando PHP).

Cuando alguien empieza a desarrollar una aplicación, empieza a ir creando scripts dispersos, que van desarrollando tareitas concretas: listadoFacturas.php, encuestaClientes.php, etc. Es lo que yo llamo que la aplicación no tiene un único punto de entrada. Tiene tantos como diferentes funcionalidades se quieran. Uno de los problemas de eso método, es que cuando quieres hacer una modificación que suponga toquetear la base de datos, tienes que estar también cambiando varios ficheros dispersos. Otro problema es el jaleo que se puede montar con los includes/requires.

Esto se soluciona, con un modelo vista controlador, en la que vas montando clases en funcion de las diferentes entidades y relaciones que existen entre ellas (que luego se corresponden con el diagrama ER de la base de datos casi en un 110%). Este sistema, ademas se utiliza para montar clases 'vista' (pública, administración, crontab) fácilmente mantenible, muy organizado y con una eficiencia (y posibilidades de mejorar esa eficiencia) sencillamente brutal (cache de consultas para optimizar en BD, cache de objetos y persistencia de los mismos, cache de scripts para acelerar la intepretación).

Cuidado que me pierdo, lo importante es el punto de entrada, ese punto de entrada se puede hacer como un simple switch que segun código de operación realiza tal o cual característica (centrándose solo en el contenido que debe devolver) que luego se puede incrustar en una plantilla o si se invoca desde una llamada remota a traves de XMLHttpRequest() en un contenedor HTML.

Fin de la historia, sin lios de nombres de funciones, sin mezclar cosas. Desarrollas la aplicacion en modo tradicional y luego, si quieres 'ajaxcizarla' (pedazo de palabra) vas metiendo en la plantillas las llamadas correspondientes invocando el método de entrada con los parámetros que desees. Igual que lo otro. Tienes tu 'gestorcito' del XMLHttpRequest separado del código en el lenguaje que desees, con las plantillas y CSS también por otro lado.

Ejemplos todavía no puedo aportar, puesto que tengo la idea (estoy recuperándome de la impresión) pero no miento al considerar que supone un avance muy grande en las cosas que hasta ahora he hecho.

PD: Soap y los Web Services son una idea similar, pero aplicadas a otro ámbito de trabajo, y complementaria con esta visión.