Rails, el demonio del client-side

Publicado el by Fernando 8 Mayo, 2006 | Web, Programación, Web 2.0, Rails, Javascript, Ajax, Accesibilidad

Duro título para un post: Rails is the devil in your (client-side) shoulder, o, traducción libre: Rails es el demonio del client-side (por no decir "el enemigo del lado del ciente" que suena bastante mal y puede resultar malinterpretado).

Lo que en dicho post se pretende señalar es que los helpers de Rails (funciones que generan código HTML) que generan código Javascript, es decir, los helpers de Rails que utilizamos para integrar Ajax en nuestras aplicaciones, no tienen en cuenta que un usuario pueda tener el Javascript de su navegador desactivado, y, por tanto, no podrá navegar correctamente por la web en cuestión.

Así, lo que critica Dan, y que me parece muy bien, es que nos olvidemos de que no todo el mundo tiene Javascript habilitado, o un navegador popular con soporte para las últimas tecnologías. De hecho, seguro que habéis leído estos dos artículos que algunos bloggers enlazaron hace pocos días: AJAX, Accessibility & Screen Readers y Accessibility of AJAX Applications; así como otro de lectura obligada para cualquier desarrollador: Ajax Mistakes.

Sin embargo no todo es tan malo como lo pintan, porque Rails sí que incluye una alternativa accesible en el caso de los formularios.

Así pues, los formularios que se envían por Javascript (utilizando el helper form_remote_tag) sí que soportan un argumento :html en el que le podemos pasar la URL de la acción que queramos ejecutar si no está habilitado el Javascript.

Así pues, la llamada clásica funcionaría a pesar de no tener habilitado el Javascript en el navegador:

PLAIN TEXT

RUBY:

form_remote_tag :html => { :action => url_for(:controller => "some", :action => "place") }

Y respecto a los enlaces, la solución es darle valor al atributo href="" con el enlace al que queremos dirigir al usuario si no tiene el Javascript activado y utilizar Javascript no intrusivo para realizar las llamadas en Ajax.

El siguiente código muestra un ejemplo de enlace que realiza una petición Ajax para actualizar un elemento del DOM con el resultado de dicha petición:

PLAIN TEXT

HTML:

<a href="#" onclick="new Ajax.Updater('session_overview', '/sessions/read/1', {asynchronous:true, evalScripts:true}); return false;">Happy Programming with Ruby on Rails</a>

Este enlace, resultado de utilizar el helper link_to_remote de Rails, decimos que utiliza "Javascript intrusivo" porque dota de comportamiento al enlace, al asignarle un evento cuando alguien pinche sobre él. Además, no proporciona alternativas al usuario sin Javascript en el navegador.

El javascript no intrusivo lo que pretende es sacar toda esta capa de comportamiento fuera del HTML, y dotar a los enlaces de eventos cuando se cargue la página.

Así, el enlace no tendría evento onclick, pero ganaría una clase o un identificador. En este caso lo haremos con un identificador para simplificar:

PLAIN TEXT

HTML:

<a href="/sessions/permanent-read/1" id="read-1">Happy Programming with Ruby on Rails</a>

Y ahora debemos de añadir el siguiente código javascript en la página, si queremos que se comporte como antes:

PLAIN TEXT

JAVASCRIPT:

/* una función clásica para añadir eventos con Javascript */
function addEvent(obj, evType, fn){
if (obj.addEventListener){
obj.addEventListener(evType, fn, false);
return true;
} else if (obj.attachEvent){
var r = obj.attachEvent("on"+evType, fn);
return r;
} else {
return false;
}
}
/* actualiza session_overview con la llamada Ajax */
function update_overview() {
new Ajax.Updater('session_overview', '/sessions/read/1', {asynchronous:true, evalScripts:true}); return false;
}
/* dota de comportamiento al elemento read-1 */
function comportamiento() {
var a = document.getElementById('read-1');
addEvent(a,'click',update_overview);
}
window.onload=comportamiento;

Naturalmente me ha quedado un código "un poco chapucilla", pero tal y como se dice en este comentario, ya se está trabajando en dotar de comportamiento en la librería Prototype. Esperemos que no se tarde mucho.

Y mientras tanto, está en manos de los desarrolladores, el preocuparse por la accesibilidad de los sitios web que desarrollen.

9 Comentarios en “Rails, el demonio del client-side”

Feed de este post Dirección para el Trackback Envía este post

1 demimismo 8 May, 2006 a las 9:15 am

Yo no soy ni mucho menos un experto en Rails, me dí cuenta de esto haciendo alguna pruebilla y la verdad es que es una gaita de aquí te espero :-(

Yo siempre digo lo mismo cuando me preguntan sobre esto: primero cueces y luego enriqueces. Quiero decir que lo primero sería hacer que la aplicación funcione sin AJAX y luego acoplarle el AJAX como un extra, lo importante es que el extra sea el comportamiento, no la accesibilidad.

Por lo que he visto se puede utilizar Rails de forma que tu aplicación sea totalmente accesible, el problema es que algunos desarrolladores eliminan los controladores “antiguos” cuando incorporan AJAX (o dejan de preocuparse por ellos y terminan desactualizados)
2 Gonzalo 8 May, 2006 a las 11:17 am

Lo que escribes en este artículo, y comenta demimismo es uno de los aspectos más importantes de esta llamada Web 2.0. Si no conseguimos que las páginas funcionen sin Javascript activado, damos un paso atrás lamentable. Ahora mismo que están surgiendo nuevos dispositivos con conexión a internet (como por ejemplo los teléfonos móviles) dan un punto de vista más amplio a la accesibilidad web y el acceso universal.
Pudiendo utilizar lenguajes de scripts en el servidor, creo que hay una especie de ley moral del desarrollo web que nos empuja a hacer un buen uso de estas técnicas.
Molaría que la primera letra del acrónimo de AJAX fuese el de accesible.
Muy interesante, Fernando.
3 Federico 8 May, 2006 a las 11:13 pm

Rails sí que incluye una alternativa accesible en el caso de los formularios

¿O sea que el verdadero problema no es Rails sino los desarrolladores que “olvidan” usar correctamente la función?
4 Fernando 9 May, 2006 a las 6:56 am

Federico: sí, básicamente es el programador el que se olvida de la importancia de la accesibilidad y no desarrolla una solución apropiada alternativa al Javascript.
5 rdcklinux 6 Mar, 2007 a las 10:36 pm

esta muy bueno esto
pero una pregunta que me tiene en una gran incognita y que nadie ha poido responder
si creo un objeto dinamico de esta forma

tr = tbody.insertRow();

siendo tr una TR dentro de un TBODY de un TABLE

si yo quiero que el evento OnMouseOver por ejemplo gatille una funcion

como se le puede pasar parametros a esta funcion
6 knoopx 13 Mar, 2007 a las 1:29 am

Si nos referimos a accesivilidad en el caso del acceso a la web por parte de personas discapacitadas yo creo que todo el problema con los Screen Readers y AJAX es tarea de los programadores de los Screen Readers, no del programador web.