Tag Archives: Rails

Generando javascript con código ruby embebido en rails 2.x

Hay veces que es bastante útil y cómodo devolver en una petición código javascript para que sea ejecutado en el cliente (y actualice el interfaz del usuario o lo que tenga que hacer). En vez de realizar (1) Petición, (2) Generar datos, (3) recepción y procesamiento, (4) actualizar página; pasamos a (1) Petición, (2) generar código, (3) actualizar página. Es decir nos ahorramos el parseo, además nos ahorramos tener que cargar javascript (que procesa las respuestas) en el cliente y usando jquery/mootools/* se realiza todo el proceso de forma transparente (indicando en la petición ajax que esperamos recibir un script). Esta técnica será válida solo para pequeñas actualizaciones (que son mayoría) y principalmente para temas de interfaz (que suelen ser triviales), pues en definitiva el código que no se ve, es código difícil de mantener.

En Rails tenemos templates RJS que básicamente consiste en lo que acabo de comentar pero generando javascript con wrappers en vez de usar js sin más, algo que me parece absurdo, pero eso es otro tema. Para rails 1.2.x teníamos este maravilloso plugin de Dan Webb que te permite escribir javascript con ruby embebido en él, algo como:

<% @ids_to_modified.each do |id| %>
   $('#' + <%= id %>).removeClass('<%= @class_to_remove %>').highlightFade();
<% end %>

Desde Rails 2.x ya no es necesario el uso del plugin (en parte porque ya no va), pues podemos hacer esto mismo gracias al nuevo formato de las vistas.

Ahora todas las vistas tienen el formato nombre.formato.template_engine, por ejemplo lo típico sería algo como: nombre.html.erb. Pero, ¿por qué no tener plantillas como nombre.js.erb?. De esta forma tendremos, sin incorporar plugins ni nada, la funcionalidad antes comentada, generar javascript permitiendo ruby embebido (es decir, usando erb).

Para hacernos la vida algo más simple, vendría bien incorporar ciertas funciones y helpers. En tu application.rb, no estaría de más tener algo como:

def respond_with_js
    respond_to{|format| format.js }
end

Por lo que nuestras acciones que vayan a ser llamadas mediante xhr tendrán una pinta tal que:

def vote
   # hacer lo que sea...
   respond_with_js
end

Tenemos que tener en cuenta también, que el javascript generado debe de ser válido (por ejemplo escapar comillas en las cadenas, o similares). Para asegurarnos que algo es javascript válido, nada mejor que usar json por lo que podemos pillar prestado del plugin de MinusMOR su helper (y añadirlo a application_helper.rb)

def js(data)
  if data.respond_to? :to_json
    data.to_json
  else
    data.inspect.to_json
  end
end

Por lo que ahora podemos escribir cosas tal que:

$('div.cancel').append(
    <%=js link_to('Cancelar', :action => 'cancel') %>
);
# o
alert(<%=js error_message_for(@error) %>);

Finalmente, si queremos usar partial’s tendremos que añadir este helper para soportar el nuevo formato de las plantillas (gracias a mad.ly):

def partial(name, options={})
  old_format = self.template_format
  self.template_format = :html
  js render({ :partial => name }.merge(options))
ensure
  self.template_format = old_format
end

Fíjate que no estamos sobreescribiendo el render :partial típico, es un helper simplemente. Para usarlo tendríamos que hacer algo como:

$('#some_div').html(<%=partial 'movie_information', :object => @movie %>);

En definitiva una forma mucho más cómoda, potente y simple de generar javascript desde el lado del servidor. Aunque insisto en que solo se debería de usar esta táctica para cosas triviales y pequeñas.

Ruby on Rails, ¿se acabó lo que se daba?

Hace 3 años se publicó lo que fue la primera versión de un increíble framework para el desarrollo Web en un lenguaje de script no muy conocido, Ruby. Este framework era Ruby On Rails, y comenzó la revolución.

Desde entonces, en los dos años siguientes el tema de moda en la programación Web era lo cool que era RoR, que molaba mogollón, que era la hostia, que viva la madre que lo parió, y esas cosas. Incluso el año pasado me dio por probarlo a ver si realmente merecía la pena. Después de probar algunas de sus características lo dejé por dos razones, (1) ruby me parece parecía un lenguaje de script apestoso (yo lo veo como una mezcla de ada y perl, los cuales tienen unos puntos de vista totalmente opuestos!, ¡eso no se hace!), (2) ninguna de sus características es algo revolucionario, sí, son curiosas y chocan la primera vez, pero nada que no se puede hacer en otro lenguaje (en una tarde te programas la característica X que necesitas).

Últimamente se ha ido tranquilizando la cosa y apenas se hablaba ya de Rails, o al menos no tanto. Y hace un mes, a raíz de este post, empezaron las críticas sin parar hacia éste. Famosa es ya la historia de Twitter, aplicación escrita en RoR, que cuando alcanzó su éxito y comenzó su uso intensivo, estaba más tiempo caída que online (exagerando las cosas claro, pero era muy lenta y con bastantes caídas) y a partir de ésto se atacaba a rails criticando su falta de eficiencia y escalabilidad.

En mi opinión todo se está exagerando, simplemente la moda de Ruby On Rails ha pasado (2 años creo que es ya más que suficiente), lo cual no quiere decir que vaya a desaparecer, pero posiblemente significa que no crecerá mucho más, y dado que en el ámbito empresarial no es que haya entrado muy fuerte (principalmente debido a una falta de soporte o entidad detrás del framework, a diferencia de, por ejemplo, GWT o apestosas tecnologías Java en general), esto significa que la caída ha comenzado y no hay quien la pare.

Si hace un año hubiese dicho que Rails es una mierda, la gente me hubiese escupido, pegado una paliza, Google no me indexaría, Microsoft me mandaría bindous con cada telepizza y los teletubbies me dedicarían una canción. Ahora, una vez que ha pasado la moda, ya se permite tocar al intocable, y quien quiera, puede decir lo que le plazca. Ves que bien. Por mi parte, cuando tenga que realizar una aplicación Web en el futuro, rails será una de mis últimas primeras opciones, puesto aunque que por alternativas, no será.