Novedades en Edge Rails #20

Nota: Esta entrada es una traducción de la publicada por Mike Gunderloy el 17 de Abril de 2009 en el blog de Ruby on Rails.

Por si se les ha escapado la última hora: la rama edge se ha despertado y comienzan a aparecer los cambios relacionados con Rails 3 en la rama maestra en Github. Así que vamos a tener mucho que tratar esta semana. Si desean profundizar en la historia técnica detrás de la rearquitectura en Rails 3, lo mejor es seguir los muy detallados posts que viene publicando Yehuda Katz.

¿Que rama debería usar?

El trabajo de lo que será Rails 3.0 se está efectuando en la rama master del repositorio Rails en Github. Si queremos estar al día con los últimos cambios esta es la rama a seguir, con la advertencia de que se trata de código alfa, si bien es perfecta posible construir una aplicación totalmente operativa utilizando la rama maestra de Rails. El equipo del core de Rails se ha conjurado para hacer que esta rama principal pase todos los tests, y de hecho una de las mejoras en Rails 3 es mejorar la covertura y políticas de integración continua en los tests. Pero es importante que tengan en cuenta que los cambios en Rails harán que algunos plugins tengan que ser reescritos antes de funcionar bien en Rails 3 (por supuesto, habrá plugins que necesiten más trabajo que otros) Esto hará que sea complicado utilizar Rails en despliegues en producción durante algún tiempo.

Para las aplicaciones existentes en producción, deberemos seguir los cambios en la rama 2-3-stable en GitHub. Esta rama contiene correcciones y mejoras en el código de la versión 2.3, y deberá permanecer compatible con los códigos y plugins que venimos usando.

¿Debo seguir enviando parches a Rails

¡Absolutamente! Rails siempre ha sido una obra de muchos y en Rails 3 esto no va a cambiar. Recibimos parches tanto para Rails 2.3 o Rails 3.0; por favor utilicen la etiqueta apropiada (2-3-stable o 3.0) en los tickets de Lighthouse para que sea fácil distinguir en qué rama están basados y probados sus parches. La guía para contribuir a Rails les ayudará en la mecánica de enviar un parche a Rails.

David resumió la visión general para Rails 3 en diciembre y este sigue siendo el plan básico. Si hay algo en lo que deseamos involucrarnos la lista Ruby on Rails: Core nos ayudará a ponernos en contacto con el equipo de desarrollo para coordinar los planes y evitar dolores de cabeza. La mayoría de las tareas ya están en marcha, pero sabemos que las ideas y contribuciones de la comunidad son esenciales para que Rails 3 tenga éxito.

Cambios en Rails 2.3.x

Centrándonos en Rails 2.3, en las últimas semanas hemos visto algunas correcciones, y una funcionalidad bastante interesante: ActiveRecord::Base#touch. La idea es que conseguimos un atajo para insertar la hora actual en los campos updated_at y updated_on:


@customer.touch

Lo que hace que esto sea algo más que un ahorro de pulsaciones el teclado es que también está implementado como opción en las asociaciones belongs_to:


class Order < ActiveRecord::Base
    belongs_to :customer, :touch => :last_order_update
end

Con esta declaración, al guardar o destruir un objeto Order se actualizará el campo correspondiente en el objeto padre Customer. Esto puede ser muy útil cuando estamos tratando de invalidar una copia cacheada del padre.

commit commit

Cambios en Rails 3.0

Al igual que en la 2.3, ActiveRecord::Base#touch también se ha añadido a Rails 3.0. Por lo general va a ser siempre este el caso: cualquier nueva funcionalidad en Rails 2.3 se va a propagar a Rails 3. El equipo del core dedica especial esfuerzo para asegurar que la actualización a Rails 3 sea sencilla cuando se produzca el cambio de versión. Pero ha habido más funcionalidades nuevas en Rails 3, y de eso vamos a tratar en el resto de la anotación.

Organización modular

Hay algunas partes del código de Rails donde hay niveles múltiples de inclusión, herencia y configuración. Como parte del esfuerzo para que sea más fácil entender qué es lo que hace, Rails 3 introduce las nuevas abstracciones depends_on, use y setup, que deberían hacer más legible y obvio lo que hace el código:


module AbstractController
  module Helpers
    depends_on Renderer

    setup do
      ...
    end
    ...
  end
end

module ActionController
  class Base2 < AbstractBase
    use AbstractController::Callbacks
    use AbstractController::Helpers
    ...
  end
end

commit más información

AbstractController

Probablemente el cambio arquitectural más grande hasta ahora en Rails 3 es la introducción de la clase base AbstractController. Se trata de una nueva implementación de la funcionalidad compartida entre ActionController::Base y ActionMailer::Base. La intención no es sólo proporcionar código que utilizarán las aplicaciones y los plugins directamente, sino también construir una API sólida sobre la que puedan depender otras cosas. Por ejemplo, un consumidor de AbstractController podrá implementar su propia lógica para encontrar plantillas, o añadir opciones adicionales al método básico render.

commit commit Más información

ActionDispatch

Otro cambio de arquitectura es la introducción de ActionDispatchmiddlewares y librerías HTTP que antes vivían en ActionController, incluyendo cosas como la gestión de peticiones, análisis de parámetros, códigos de estado, y nuestra propia copia de Rack. commit

Definición de la superficie de trabajo

Uno de los objetivos de Rails 3 es distinguir claramente entre los métodos públicos de API en los que pueden confiar las aplicaciones y los plugins y los métodos internos de Rails que podrían estar sujetos a cambios. Un ejemplo de esto puede ser la refactorizaión que se ha hecho en ActionView::Template. Aquí el cambio ha consistido en identificar laos métodos que no son usados por ninguna otra clase y hacerlos privados. Esto hace que se pueda entender de manera más clara la API de esta clase y a largo plazo significa que le dará a los plugins un contrato acerca de cómo pueden interactuar con el código del core. Después de que esta superficie de trabajo se haya definido formalmente, probablemente dará lugar a una API más limpia. commit

AJAX y los testigos de autenticación

Si hemos estado escribiendo mucho javascript a mano, habremos descubierto la molestia de tener que incluir el testigo de autenticación de Rails en nuestras peticiones. Un análisis más detallado del problema revela que realmente no es necesario incluir este testigo en las peticiones AJAX porque la política del origen único que aplican los navegadores ya las protege. Así que Rails 3 dejará de coprobar estos testigos en las peticiones AJAX, así que tendremos un poquito menos de javascript que escribir. commit

Mejoras en los tests

Otra área de trabajo en Rails 3 consiste en poner al día los tests internos con las mejores prácticas. Hay algunos puntos en el códgo donde los tests son menos sistemáticos de lo que podrían ser; los cambios se han venido aplicando con cobertura de tests pero nadie se ha ocupado de garantizar que haya una cobertura de test completa del flujo de ejecución de una petición feliz. Para echar un vistazo a lo que se viene haciendo en este aspecto, véase algunos de los ficheros de test en actionpack/test/new_base (el código new_base es una reescritura en curso de ActionController::Base). También se está trabajando en mejorar las historias de integración continua y agrupar algunos tests de integración de altov nivel que puedan ejercitar Rails como un todo.

Cabos sueltos

Hay algunas funcionalidades de Rails 2.3 que aún no están implementadas en la rama 3.0. Algunos cambios no han podido ser fusionados con la nueva arquitectura y otros están siendo vueltos a implementar de diferente manera. Encontrarán más detalles en este mensaje de entrega pero las piezas que faltan incluyen la mejora de rendimiento en el procesado de plantillas en modo de desarrollo y su recompilación en producción, así como alguna lógica en el código que las escoge. Los desarrolladores han manifestado su intención de hacer que intentan conseguir la paridad de funcionalidades lo antes posible. De hecho ya se ha hecho una pasada sobre estos cambios: committed.

Eliminado: Soporte de CGI

Rails 3 dejará de servir peticiones a través de CGI. Esto fue declarado a extinguir en Rails 2.3 así que no debería sorprender a nadie que se elimine por completo. Por supuesto, si necesitan procesar CGI por algún motivo recuerden que se soporta a través de Rack. commit

blog comments powered by Disqus