Ruby on Rails 2.0: le novità

A tre anni dal suo primo rilascio Ruby on Rails raggiunge la versione 2.0. le novità introdotte dalla major release sono da un lato frutto dell’integrazione del lavoro del core team e della community di Ruby on Rails, dall’altro del consolidamento di concetti che a poco a poco sono stati introdotti nelle ultime versioni del frame work Web.

Interessante notare come a fronte dell’introduzione di funzionalità oggi disponibili come plugin esterni a Ruby on Rails, altre siano state estromesse dalla distribuzione base e rese disponibili loro stesse come plugin (ad esempio Active Web Server per la realizzazione di Web Service in SOAP).

Ruby on Rails 2.0 in breve:

• Migliora le performance generali, a livello Active Record, route, viste e con ottimizzazione dei file di javascript
• Conferma il “RESTful lifestyle” estendendo i suoi concetti a controller e viste
• Introduce una nuova nomenclatura per i file delle viste (i file .rhtml diventano .html.erb, i file .rxml diventano .xml.builder)
• Introduce
• Semplifica la gestione dei plugin

Rails 2.0: Action Pack e Routes

Nel nome del “RESTful lifestyle” sono stati introdotte alcune soluzioni molto comode all’interno del modulo Action Pack ed in particolare nella sezione di definizione del route (ovvero come scegliere controller e action in funzione della Url della richiesta).

Il primo cambiamento, quasi obbligatorio, è l’eliminazione del punto e virgola dalla definizione degli url; il punto e virgola introduce infatti dei problemi con il page caching e con l’autenticazione (in particolare con il browser Safari). Al posto del punto e virgola è reintrodotto il classico slash. /people/1;edit torna quindi ad essere /prople/1/edit.

Nella definizione dei resource-based controller è stata introdotta la convenzione di definirli al plurale; questo permette di mappare una singola risorsa in contesti differenti e di riferirla sempre allo stesso controller.

# /avatars/45 => AvatarsController#show
map.resources :avatars
# /people/5/avatar => AvatarsController#show
map.resources :people, :has_one => :avatar

Rails 2.0: Action Pack e Multiview

Di pari passo alle modifiche introdotte relativamente al reperimento delle risorse tramite routing, sono stati introdotti diversi miglioramenti per il multiview (ovvero differenti viste che rispondono ad uno stesso controller in base al tipo di richiesta effettuata).

Per fare in modo che a fronte di una stessa azione rispondano sistemi di template differenti in base al formato della vista da generare. Anche in questo caso è stata scelta una convenzione che porta a nominare le differenti viste come action.format.renderer, dove action è l’azione del controller da eseguire prima della generazione della vista, format il formato della risposta che sarà generata e renderer il motore da utilizzare per la generazione della vista. Così ad esempio:

• index.html.erb: per l’azione index rispondi in formato HTML utilizzando il sistema si tempate erb (lo stesso utilizzato dai file rhtml)
• list.erb: non avendo specificato un formato particolare, per tutti i formati dell’azione index viene utilizzato lo stesso motore di template (erb)
• show.xml.builder: a fronte di una richiesta per l’action show per il formato xml, utilizzare Builder (lo stesso degli attuali rxml)

Riassumendo i motori di rendering per le viste non sono cambiate, ma ora devono essere espressamente dichiarati per mezzo del nome del file.

Un’applicazione interessante per questa nuova feature è la possibilità di specificare nuovi formati, e di abbinare quindi una rendererizzazione differente. Ad esempio, per riprendere l’esempio del blog di Ruby on Rails, poniamo il caso di voler preparare una nuova vista dedicata a chi accederà alla risorsa tramite iPhone. Per prima cosa definiamo un alias per il mime type:

  # should go in config/initializers/mime_types.rb
  Mime.register_alias "text/html", :iphone

  class ApplicationController < ActionController::Base
    before_filter :adjust_format_for_iphone

    private
      def adjust_format_for_iphone
        if request.env["HTTP_USER_AGENT"] && request.env["HTTP_USER_AGENT"][/(iPhone|iPod)/]
          request.format = :iphone
        end
      end
  end

  class PostsController < ApplicationController
    def index
      respond_to do |format|
        format.html   # renders index.html.erb
        format.iphone # renders index.iphone.erb
      end
    end
  end

Rails 2.0: Action Pack e Identificazione dei Record

In un ottica sempre più RESTful sono state introdotte una serie di semplificazioni per il recupero degli URL a partire da una istanza di un oggetto Active Record:

  # post è un oggetto Post
  redirect_to(post)
  link_to(post.title, post)
  form_for(post)

Al di là delle praticità di queste scorciatorie è interessante notare come il paradigma RESTful offra la possibilità di stendere codice chiaro ed intuitivo.

Rails 2.0: Action Pack e autenticazione Http

Da qualche tempo Ruby on Rails ha voluto sfruttare appieno il protocollo http, ad esempio utilizzando oltre ai classici metodi GET e POST anche i metodi PUT e DELETE. In Ruby on Rails 2.0 l’utilizzo del protocollo http si estende all’autenticazione, offrendo in ActionController::HttpAuthentication tutto quello che serve per implementare l’autenticazione tramite http:

  class PostsController < ApplicationController
    USER_NAME, PASSWORD = "user", "secret"

    before_filter :authenticate, :except => [ :index ]

    def index
      render :text => "Risorsa pubblica"
    end

    def edit
      render :text => "Risorsa con autenticazione"
    end

    private
      def authenticate
        authenticate_or_request_with_http_basic do |user_name, password|
          user_name == USER_NAME && password == PASSWORD
        end
      end
  end

L’autenticazione tramite http è già possibile nell’attuale versione di Ruby on Rails per mezzo dell’installazione di un apposito plugin http://blog.caboo.se/articles/2006/05/28/htpasswd-plugin.

Rails 2.0: compressione e caching di Javascript

All’iterno della cartelle public/javascript è possible sistemare I file javascript da utilizzare per le nostre applicazioni Ruby on Rails. Quando il numero di file javascript sale, al caricamento di una pagina il browser deve scaricare tutti i file necessari, aprendo una serie di richieste indipendenti verso il serverm una per ogni file da scaricare.

Ruby on Rails 2.0 permette di “comprimere” tutti i file javascript in un unico file chiamato all.js usando il tag javascript_include_tag(:all, :cache => true).

Il file all.js viene generato a partire dai singoli file javascript all’avvio dell’applicazione Ruby on Rails in modalità sviluppo; in questo modo durante lo sviluppo dell’applicazione sarà possibile intervenire sui singoli file, mentre in modalità produzione sarà servito un unico grande file, con notevole risparmio di carico verso il server.

Rails 2.0: distribuzione degli asset

I browser di norma aprono un numero limitato di connessioni verso uno stesso host; se ad esempio accediamo alla pagina http://example.com/index.html e la pagina richiede di scaricare 20 immagini, il browser procederà a scaricare 4 immagini contemporaneamente, sistemando in una coda interna le 20 immagini e scaricandone solo quattro alla volta.

Per fare in modo che più immagini siano scaricate contemporaneamente, una pratica comune è quella di distribuire gli stessi asset su sottodomini differenti (http://asset1.example.com, http://asset2.example.com, http://asset3.example.com, http://asset4.example.com).

Ruby on Rails 2.0 permette utilizzare questa tecnica specificando ActionController::Base.asset_host = "assets%d.example.com"; in questo modo il browser aprirà più connessioni verso i differenti host aumentando la velocità percepita dell’applicazione.

Ruby on Rails 2.0: Action Pack e gestione delle eccezioni

Alcune eccezioni sono tipiche di un’applicazione web in generale e occorrono in differenti punti dell’applicazione. Con la versione 2.0 Ruby on Rails permette di gestire in modo centralizzato differenti tipi di eccezioni.

Nell’esempio riportato in basso l’eccezione User::NotAuthorized, sollevata quando un utente cerca di attivare una action di cui non detiene i permessi, viene catturata per tutte le azioni del controller PostsController e viene scatenata la action privata deny_access:

  class PostsController < ApplicationController
    rescue_from User::NotAuthorized, :with => :deny_access

    protected
      def deny_access
        ...
      end
  end

La gestione centralizzata delle eccezioni comuni a differenti action porta senza dubbio ad una chiarezza di codice.

Altri articoli interessanti:

1. IronRuby: Ruby e Rails su piattaforma .NET
2. RVM: Installare tante versioni di Ruby e tante versioni di Rails
3. Rails 3.0: Release candidate