La nueva versión de Ruby on Rails está cada vez más cerca, y son muchas las novedades que nos trae. Así que me he decidido a recopilarlas y a enumerar algunas de las que considero más interesantes para que os vayáis haciendo una idea.
Debido a que estas novedades son muy numerosas, y para no escribir un artículo excesivamente largo, trataré de recoger las que más han llamado mi atención en al menos un par de posts.
Si quieres ir disfrutando ya de la primera beta, así como probar algunos de los cambios que paso a comentaros a continuación, podéis instalarla utilizando Rubygems mediante el comando:
$ gem install rails --pre
Os aconsejo utilizar Ruby Version Manager (rvm) para poder tener instaladas varios entornos, y así no comprometer vuestro trabajo diario con Rails. Al igual que las versiones anteriores más recientes de Rails, el framework es perfectamente compatible con la versión 1.9.2 de Ruby, con lo que recomiendo encarecidamente su uso (¿todavía no usas Ruby 1.9.2 en tu entorno de producción?):
$ bash < <(curl -s https://rvm.beginrescueend.com/install/rvm) $ rvm install 1.9.2 $ rvm 1.9.2@rails31 --create $ gem install rails --pre
jQuery pasa a ser la librería oficial
Pues sí, jQuery pasa a desbancar a Prototype y scriptaculous como las librerías de Javascript por defecto. He de decir que no me sorprende, pues la mayoría de los desarrolladores Rails que conozco usan ya esta librería para casi todos sus proyectos. Por supuesto, es muy sencillo usar otra si no te convence, pero ya sabemos que Rails se caracteriza por ser "opinionated software", así que es normal que haya siempre una favorita.
Para mayor comodidad, la comunidad ha preparado un par de gemas que podemos añadir a nuestro fichero Gemfile, proveyendo así a nuestro proyecto de los ficheros necesarios correspondientes a estas librerías. En concreto, jquery-rails y prototype-rails. Es de esperar que aparezcan otras con el tiempo. Si quieres indicar la librería deseada desde el mismo momento en que creas el esqueleto de tu aplicación, puedes hacerlo utilizando el parámetro "-j", seguido del nombre de la librería ("jquery" o "prototype").
SASS incluido en Gemfile por defecto
SASS, o "Syntactically Awesome Stylesheets", es una herramienta que merece ser nombrada en un artículo por separado. No obstante, resumiré que nos sirve para facilitar la escritura de nuestras hojas de estilo, permitiendo incluir en ellas reglas anidadas, variables, módulos que definen funciones que a su vez definen un conjunto de estilos, condiciones, bucles... En definitiva, nos permite eliminar código redundante en las CSS, simplificándolo bastante, de modo que sean más sencillas de mantener. SASS se encargará luego de convertir esos ficheros en hojas de estilo convencionales, que son las únicas que entiende el navegador.
Pues bien, en Rails 3.1 la gem para la integración de esta herramienta con nuestro proyecto viene incluida por defecto en el fichero Gemfile de dependencias.
Coffeescript de serie
Poco he de añadir a este hecho que ya fue comentado por mi compañero Toni el mes pasado. Pero consideré necesario incluirlo de nuevo en este artículo, para recordarlo. Si aún no has probado Coffeescript, te recomiendo enormemente que lo hagas, pues hará que tu código Javascript se reduzca a unas pocas líneas al mismo tiempo que disfrutarás de una sintaxis más parecida a Ruby para escribir código del frontend de tu aplicación.
Hojas de estilo y ficheros javascript fuera de public
Pues sí, a partir de ahora el lugar preferido para almacenar estos ficheros es en app/assets/stylesheets y app/assets/javascripts, respectivamente. Además, se utilizan nombres de fichero parecidos a las vistas, donde una primera extensión del fichero indica el formato de éste (ej: "js" o "css"), y una segunda extensión sirve para indicar el motor que se utilizará para generar este formato a partir del fichero original (por ejemplo, "coffee" para convertir un fichero escrito con Coffeescript en Javascript). En el directorio public sólo se almacenarían los ficheros ya procesados, los cuales además serían unidos para formar un único fichero Javascript y un único fichero CSS para toda la aplicación, gracias a Sprockets.
Preferencia por la sintaxis de Ruby 1.9
Los generadores de código de Rails 3.1 van a comenzar a usar sintaxis de Ruby 1.9 cuando estés usando esta versión del intérprete del lenguaje. Esto significa que los hashes por ejemplo van a empezar a escribirse de forma similar a los hashes escritos en JSON, que es la forma preferida de escribir un hash con Ruby 1.9:
redirect_to posts_path, notice: "El post ha sido creado correctamente."
Mejor salida para la ejecución de tests
Los resultados de la ejecución de los tests son ahora más claros con la inclusión de la gema turn, la cual utiliza un formato de salida a color para destacar mejor los tests que pasan y los tests fallidos, y en lugar de marcar simplemente los tests válidos como puntos y los tests erróneos o fallidos con los caracteres E y F, los describe cada uno en una línea utilizando el nombre del método definido en el fichero de tests (sustituyendo símbolos de subrayado por espacios), e incluyendo por cada uno de ellos el tiempo de ejecución.
Nuevos Rack en la pila de aplicaciones middleware por defecto
La utilización de aplicaciones Rack para tratar diferentes funcionalidades en cada petición se generaliza, con la inclusión de las siguientes al stack por defecto: Rack::Etag, Rack::ConditionalGet, Rack::Cache.
Soporte para streaming
Gracias a la inclusión de ActionController::Streaming, ahora se pueden responder a determinadas acciones mediante HTTP Streaming, si el servidor web lo soporta. Para activarlo en ciertas acciones de tus controladores, puedes incluir una llamada al método de clase "stream" con unos parámetros cuya sintaxis recuerda a la de los filtros de controladores. Por ejemplo:
class PostsController < ActionController::Base
stream :only => :index
end
Definición de atributos accesibles según ciertas condiciones
¿Cansado de especificar tus propios métodos de actualización de atributos en tus modelos porque update_attributes no te basta, al querer diferentes comportamientos según el rol del usuario que esté realizando el cambio, o según se den ciertas condiciones? Con Rails 3.1, puedes proteger la actualización de diferentes atributos según el rol que se utilice durante dicha operación. Por ejemplo:
class Post < ActiveRecord::Base
attr_accessible :title, :published_at, :as => :admin
end
Post.new(params[:post], :as => :admin)
Más información | The Changelogs for Rails 3.1 Beta 1