ASCIIcasts - Full Episode Feed

Sottodomini in Rails 3

Fri, 23 Jul 2010 20:25:03 +0000

Sono passati quasi due anni da quando è stato trattato l’argomento sottodomini. Rails 3 introduce alcuni supporti ai sottodomini, che vedremo in questo episodio.

L’applicazione che useremo sarà la solita già usata nell’altro episodio sui sottodomini. Si tratta di una semplice applicazione di blogging che supporta più di un blog. Di sotto è riportata la home page che elenca tutti i blog. Ciascun blog ha un insieme di articoli ad esso associati.

Se clicchiamo sul link di modifica di un blog, vedremo che ciascuno ha due attributi: un name e un subdomain. Vogliamo usare l’attributo subdomain come sottodominio nell’URL per tale blog:

Configurazione dei sottodomini nell’ambiente di sviluppo

La prima cosa da configurare è la modalità di gestione dei sottodomini nella modalità di sviluppo. La nostra applicazione ha l’URL http://localhost:3000 che non ci consente di avere sottodomini, per cui dobbiamo trovare un modo alternativo.

Uno dei modi per farlo potrebbe essere quello di configurare la nostra applicazione per usare Passenger. Potremmo quindi assegnarle un dominio tipo http://blog.local e modificare il file /etc/hosts per configurare i sottodomini in questo modo:

/etc/hosts

127.0.0.1 personal.blog.local company.blog.local

Idealmente vorremmo poter usare un carattere wildcard che faccia match con ciascun sottodominio in nodo tale che non dobbiamo continuamente cambiare il file degli host quando sviluppiamo la nostra applicazione. Sfortunatamente non possiamo farlo, per cui dovremo trovare un’altra soluzione.

Una buona soluzione è offerta da Tim Pope sul suo blog. Lui ha comprato il nome di dominio smackaho.st e lo ha reso un wildcard del localhost. Uno dei tizi che ha lasciato un commento sul suo blog ha fatto qualcosa del genere con un nome di dominio più corto, lvh.me. Useremo questo approccio.

Se puntiamo a http://lvh.me:3000/ vedremo la home page della nostra applicazione, poichè lvh.me viene risolto nell’indirizzo IP 127.0.0.1. La differenza sta nel fatto che ora possiamo anteposse un qualunque sottodominio che vogliamo all’URL e questo continuerà a puntare alla stessa applicazione.

Ora che siamo in grado di usare i sottodomini nella nostra applicazione, possiamo configurare i suoi instradamenti in modo tale che il sottodominio personal conduca alla action show del blog Personal. Ecco come attualmente appare il nostro file di route:

/config/routes.rb

Bloggit::Application.routes.draw do |map|
  resources :comments
  resources :articles
  resources :blogs
  root :to => "blogs#index"
end

Per ora l’instradamento radice punta alla action blogs/index. Vogliamo che questo sia vero solo nel caso in cui non sia specificato alcun sottodominio; laddove vi sia indicato un sottodominio, dovrebbe essere mostrata invece la vista associata alla action blogs/show. In Rails 3 si può fare tutto ciò aggiungendo un vincolo:

/config/routes.rb

Bloggit::Application.routes.draw do |map|
  resources :comments
  resources :articles
  resources :blogs
  match '/' => 'blogs#show', :constraints => { :subdomain => /.+/ }
  root :to => "blogs#index"
end

In un’applicazione Rails 2 avremmo dovuto usare un plugin per farlo, ma in Rails 3 tutto ciò è già incluso nel framework. L’opzione :subdomain accetta sia una string, sia un’espressione regolare come argomento: in questo caso abbiamo usato un’espressione regolare che facesse match con almeno un carattere, in modo tale che ogni sottodominio facesse match con l’instradamento. Si noti come sia essenziale che l’instradamento radice venga messo dopo il route di sottodominio. Se così non fosse, l’instradamento di root intercetterebbe tutti gli indirizzi di sottodominio per primo, e gli instradamenti ai sottodomini non verrebbero mai chiamati. Come regola aurea generale, più il route è specifico, più deve stare in alto nella lista.

Se ora visitiamo il sottodominio personal, otteniamo un errore, ma ce lo aspettavamo, dal momento che stiamo eseguendo al action show del BlogsController e non abbiamo fornito un id:

La cosa è semplice da sistemare. Dobbiamo solo modificare la action show in modo tale che trovi un blog in base al sottodominio piuttosto che per id:

/app/controllers/blogs_controller.rb

def show
  @blog = Blog.find_by_subdomain!(request.subdomain)
end

Quando adesso ricarichiamo la pagina, vediamo gli articoli del nostro blog “Personal”:

Se togliamo il sottodominio, vedremo la home page che avevamo in precedenza:

C’è ancora un piccolo problema con gli instradamenti, tuttavia. Se andiamo su http://www.lvh.me:3000, la nostra applicazione cercherà un blog di sottodominio www, mentre invece in questo caso dovrebbe puntare alla pagina index dei blog. Potremmo provare a correggere questa cosa agendo in qualche maniera furba sull’espressione regolare nei vincoli presenti nel file di routes, ma invece, al fine di concederci una maggior flessibilità e controllo sui sottodomini, faremo la stessa cosa nel codice Ruby. Tutto ciò è reso possibile da Rails 3, scrivendo una classe e spostando il codice coi vincoli lì dentro.

Per prima cosa cambieremo il file degli instradamenti affinchè utilizzi una nuova classe chiamata Subdomain. Facciamo ciò, usando il metodo constraints e passandogli la classe come argomento:

/config/routes.rb

Bloggit::Application.routes.draw do |map|
  resources :comments
  resources :articles
  resources :blogs
  constraints(Subdomain) do
    match '/' => 'blogs#show'  
  end
  root :to => "blogs#index"
end

Poi dobbiamo creare la classe Subdomain che andrà nella cartella /lib. Questa classe dovrà avere un metodo di classe denominato matches? che accetta un oggetto request per parametro. Questo oggetto request è esattamente lo stesso oggetto che accediamo nei nostri controller e nelle nostre viste, per cui su di esso possiamo usare gli stessi metodi che usiamo in quei contesti. Questo metodo deve restituire un valore booleano che indica se il route dato fa match con la richiesta o meno. Nel nostro caso vogliamo che il metodo restituisca true solo se la request ha un sottodominio e tale sottodominio non è www, per cui la nostra classe sarà così fatta:

/lib/subdomain.rb

class Subdomain
  def self.matches?(request)
    request.subdomain.present? && request.subdomain != 'www'
  end
end

Quando ora visitiamo http://www.lvh.me:3000, vediamo la home page proprio come volevamo:

Correggere i link

Ora sistemeremo i collegamenti a ciascun blog nella home page in modo tale che puntino al sottodominio corretto anzichè alla normale action show per tale blog, dal momento che se così fosse, verrebbe fuori un errore causato dal fatto che ora la action show si aspetta un sottodominio.

Nel codice della vista per l’action index abbiamo un link standard a ciascun blog fra tag h2:

/app/views/blogs/index.html.erb

<% title "Blogs" %>

<% for blog in @blogs %>
  <div>
    <h2><%= link_to blog.name, blog %></h2>
    <div class="actions">
      <%= link_to "Edit", edit_blog_path(blog) %> | 
      <%= link_to "Destroy", blog, :confirm => 'Are you sure?', :method => :delete %>
    </div>
<% end %>

Cambiamo questo link affinchè punti all’URL radice con l’opportuno sottodominio. Sfortunatamente non possiamo passare una option subdomain al metodo root_url come potremmo fare con subdomain_fu. In questo caso dobbiamo creare il nome dell’host completo da zero e includere in quello il sottodominio. Il nome dell’host sarà creato a partire dal subdomain del blog, dal domain corrente e dalle proprietà port_string dell’oggetto request:

/app/views/blogs/index.html.erb

<h2><%= link_to blog.name, root_url(:host => blog.subdomain + '.' + request.domain + request.port_string) %></h2>

Al ricaricamento della pagina principale, ora i link ai blog punteranno ai sottodomini corretti.

Ripulire il codice per cambiare il sottodominio

Ora tutto funziona bene, ma il codice riportato sopra che crea i link ad altri sottodomini potrebbe essere un po’ più pulito, specialmente se dovessimo usarlo parecchio. Per ripulire il tutto, spostiamo la logica in un metodo helper a parte che chiamiamo with_subdomain e che accetta il subdomain come argomento. Innanzitutto cambiamo il codice della vista, affinchè chiami il metodo che stiamo per implementare:

/app/views/blogs/index.html.erb

<h2><%= link_to blog.name, root_url(:host => with_subdomain(blog.subdomain)) %></h2>

Mettiamo il metodo helper dentro il proprio module, in un file chiamato url_helper.rb:

/app/helpers/url_helper.rb

module UrlHelper
  def with_subdomain(subdomain)
    subdomain = (subdomain || "")
    subdomain += "." unless subdomain.empty?
    [subdomain, request.domain, request.port_string].join
  end
end

Il codice nel module per prima cosa imposta il subdomain ad una stringa vuota, se il valore passato è nil, poi gli aggiunge un punto, nel caso in cui subdomain non sia una stringa vuota. Infine concatena subdomain, domain e port_string e restituisce il valore.

Aggiungiamo il module anche all’ApplicationController, in modo tale che tutti i nostri controller possano utilizzare questo metodo:

/app/controllers/application_controller.rb

class ApplicationController < ActionController::Base
  include UrlHelper
  protect_from_forgery
  layout 'application'
end

Anche se abbiamo ripulito abbastanza il codice della vista, potrebbe esserlo ancor di più se potessimo semplicemente aggiungere un’opzione :subdomain al metodo root_url e ciò è possibile se ridefiniamo il metodo url_for. Tutto ciò che dobbiamo fare è aggiungere il seguente metodo al nostro module UrlHelper:

/app/helpers/url_helper.rb

def url_for(options = nil)
  if options.kind_of?(Hash) && options.has_key?(:subdomain)
    options[:host] = with_subdomain(options.delete(:subdomain))
  end
  super
end

Il metodo ridefinito url_for controlla per vedere se l’hash options ha una chiave denominata :subdomain al suo interno e, se così, imposta l’opzione :host ad essere il valore di with_subdomain per tale sottodominio. Infine chiama la super, in modo tale che tutto il codice di default del metodo originale si eseguito e la parte restante dell’URL sia generata opportunamente. Non c’è bisogno di usare alias_method_chain in questo caso, chiamare la super è sufficiente.

Ora possiamo aggiornare il codice della nostra vista per usare la option :subdomain:

/app/views/blogs/index.html.erb

<h2><%= link_to blog.name, root_url(:subdomain => blog.subdomain) %></h2>

Al ricaricamento della pagina index, cliccando su uno dei link ai blog il link condurra ancora all’URL corretto con il giusto sottodominio:

Sarebbe bello avere un link su ogni blog che potesse riportare alla pagina index. Possiamo aggiungerlo invocando root_url con un valore false per l’opzione :subdomain:

/app/views/blogs/show.html.erb

<p><%= link_to "All Blogs", root_url(:subdomain => false) %></p>

Ciò ci darà il link alla pagina index che volevamo:

Gestire domini di primo livello diversi

Un aspetto che non abbiamo ancora affrontato è come gestire nomi di dominio composti da più di due parti. Ebbene, anche se il nostro codice per il sottodominio funzionerà per i domini .com, non funzionerà invece per i domini che finiscono, per esempio, per .co.uk. Per far sì che funzioni anche per questi ultimi, dobbiamo cambiare la nostra applicazione ovunque chiami request.domain o request.subdomain affinchè possiamo indicare il numero di punti che ha il nome di dominio (al netto dei sottodomini). Rails assume un valore di default di 1, ma come appena citato per i domini del tipo .co.uk dobbiamo impostare tale valore a 2.

Dobbiamo cambiare la nostra applicazione in due punti: nel metodo UrlHelper e nella classe Subdomain usata nei nostri instradamenti:

/app/helpers/url_helper.rb

def with_subdomain(subdomain)
  subdomain = (subdomain || "")
  subdomain += "." unless subdomain.empty?
  [subdomain, request.domain(2), request.port_string].join
end

/lib/subdomains.rb

class Subdomain
  def self.matches?(request)
    request.subdomain(2).present? && request.subdomain(2) != "www"
  end
end

Ovviamente non vogliamo veramente cablare tale valore nel codice. Lo dovremo realisticamente rendere dinamico in modo tale che in modalità di sviluppo possiamo impostare un valore di 1 (per un dominio del tipo lvh.me) mentre in produzione useremo 2. Questo valore può essere impostato in un file di configurazione esterno che carica l’ambiente in modo opportuno.

Cookie

C’è un’ultima questione che affronteremo in questo episodio. Se osserviamo i cookie presenti nel nostro browser e li filtriamo per il nome di dominio che abbiamo utilizzato per questa applicazione, vedremo che viene salvata una sessione diversa per ciascun sottodominio visitato. Non vogliamo che avvenga questo, perchè significa che le sessioni non sono condivise fra i vari sottodomini.

Una soluzione a questo problema è stata presentata nell’episodio 123, ma ora in Rails 3 c’è un modo migliore per risolvere lo stesso problema. Nel file /config/initializers/session_store.rb dobbiamo semplicemente aggiungere l’opzione :domain al metodo Rails.application.config.session_store, dandogli come valore :all:

/config/initializers/sesion_store.rb

Rails.application.config.session_store :cookie_store, :key => '_bloggit_session', :domain => :all

Tuttavia non è sufficiente questo intervento da solo. L’opzione :domain è stata aggiunta solo dopo l’uscita di Rails 3.0 beta 4, che nel momento in cui si sta scrivendo questo episodio è anche la versione corrente. Pertanto occorre lanciare l’applicazione su Edge Rails oppure attendere la prossima release candidate per vedere il tutto funzionare correttamente. Usata con una versione di Rails che la supporta, questa opzione rende le sessioni della nostra applicazione condivise fra i sottodomini. L’opzione :all assume che la nostra applicazione abbia un dominio di primo livello di dimensione 1. Se così non fosse, potremmo definire un nome di dominio al posto di :all e quest’ultimo verrebbe utilizzato come dominio base per la sessione.

E’ tutto per questo episodio. Poter gestire sottodomini senza la necessità di installare plugin di terze parti è una bella novità di Rails 3 e può essere utilizzata in vari modi nelle nostre applicazioni.

PDFKit

Sun, 18 Jul 2010 20:29:36 +0000

Ci sono una serie di buone librerie disponibili per generare file PDF in Ruby. Una delle più popolari è Prawn, che è sicuramente un ottimo modo per generare PDF da zero in Ruby e che è stato trattato nell’episodio 153 [guardalo, leggilo]. In alcune situazioni, tuttavia, può essere più semplice generare un PDF da un documento HTML già esistente, ed è ciò che faremo vedere in questo episodio.

La creazione di documenti PDF a partire dall’HTML non è un’idea nuova, ma fino ad ora la maggior parte delle soluzioni disponibili era a pagamento. Di recente c’è stata parecchia attività sull’argomento, grazie ad una soluzione proposta da Jared Pace e del suo nuovo PDFKit gem. Questo gem dipende da wkhtmltopdf, uno strumento che usa il motore di rendering WebKit per generare documenti PDF, per cui, per installare PDFkit, dovrete innanzitutto installare wkhtmltopdf. PDFKit è distribuito in bundle con wkhtmltopdf, per cui, a seconda del vostro ambiente, ciò potrebbe non essere necessario.

Il gem PDFKit si installa al solito modo:

$ gem install pdfkit

Una volta installato, PDFKit è in grado di generare un file PDF puntando semplicemente ad un file o ad un sito web. In alternativa, il gem viene distribuito anche come middleware rack, una soluzione che può essere sfuttata per generare PDF di qualsiasi pagina di un sito, semplicemente aggiungendo .pdf all’ URL. Useremo questo approccio a middleware nella nostra applicazione dimostrativa.

Creazione di fatture in PDF

L’applicazione che useremo è la stessa già usata nell’episodio su Prawn. Di sotto è mostrata la pagina dell’ordine di una semplice applicazione di e-commerce. Vogliamo aggiungere un link a questa pagina che permetta di avere una versione PDF dell’ordine da scaricare e useremo PDFKit per farlo.

La prima cosa da fare è aggiungere un riferimento a PDFkit nella nostra applicazione. Dal momento che si tratta di una applicazione Rails 3, modifichiamo il Gemfile per farlo:

/Gemfile

gem "pdfkit"

Poi, per assicurarci che il gem venga installato, lanciamo:

$ bundle install

Poi dobbiamo aggiungere il middleware. In un’applicazione Rails 3, questo lo si fa nel file /config/application.rb. (Se avessimo dovuto farlo in un’applicazione Rails 2, invece, saremmo dovuti andare nel file di configurazione dell’ambiente.) Modifichiamo il file affinchè l’applicazione usi il middleware PDFKit:

/config/application.rb

require File.expand_path('../boot', __FILE__)

require 'rails/all'

# Auto-require default libraries and those for the current Rails environment.
Bundler.require :default, Rails.env

module Store
  class Application < Rails::Application
    config.secret_token = '6f22fa632e18b338b4babfa5fca632f5454fc97317cb52f372fa0f0fdd7f4d5bd95a060ff412c7230627b5c17906c9762c09208624bc1ab97f8d5344d8d4f467'
    config.filter_parameters << :password
    config.middleware.use "PDFKit::Middleware"
  end
end

Per vedere quali middleware sta usando la nostra applicazione, possiamo lanciare il comando rake middleware come facciamo ora per sincerarci che il nostro PDFKit sia nella lista dei middleware:

$ rake middleware
(in /Users/asalicetti/rails/apps_for_asciicasts/ep220/store)
use ActionDispatch::Static
use Rack::Lock
use ActiveSupport::Cache::Strategy::LocalCache
use Rack::Runtime
use Rails::Rack::Logger
use ActionDispatch::ShowExceptions
use ActionDispatch::RemoteIp
use Rack::Sendfile
use ActionDispatch::Callbacks
use ActiveRecord::ConnectionAdapters::ConnectionManagement
use ActiveRecord::QueryCache
use ActionDispatch::Cookies
use ActionDispatch::Session::CookieStore
use ActionDispatch::Flash
use ActionDispatch::ParamsParser
use Rack::MethodOverride
use ActionDispatch::Head
use PDFKit::Middleware
run Store::Application.routes

PDFKit::Middleware è presente nell’elenco, per cui possiamo andare avanti. Ora possiamo aggiungere .pdf a qualunque URL della nostra applicazione per ottenere una versione PDF di quella pagina. Proviamolo nella pagina degli ordini:

Tutto qua. Per ora non abbiamo dovuto fare praticamente nulla per ottenere una versione PDF dell’ordine. Potrebbe essere prodotta meglio, certamente, ma comunque abbiamo già una buona base da cui partire.

Miglioriamo l’aspetto dell’ordine in PDF

La prima modifica che faremo all’ordine sarà rimuovere lo sfondo blu dalla versione PDF. Dobbiamo poter identificare una versione della risorsa in PDF, in modo tale da poter applicargli uno stile diverso. Possiamo fare tutto ciò cambiando la chiamata al middleware, affinchè PDFKit utilizzi il media type print:

/config/application.rb

config.middleware.use "PDFKit::Middleware", :print_media_type => true

Nel file di layout della nostra applicazione abbiamo un stylesheet_link_tag che include un tag application.css. Per default questo foglio di stile ha un media type pari a screen, che indica che, viste le recenti modifiche al middleware PDFKit, nessuno degli stili presenti in tale foglio di stile verrà applicato alla versione PDF. Modifichiamo il stylesheet_link_tag e impostiampogli all come media type, affinchè tutti gli stili vengano applicati sia alla versione della pagina da monitor (HTML), sia a quella da stampa:

/application/views/layouts/application.html.erb

<%= stylesheet_link_tag "application", :media => 'all' %>

Potremmo creare (sarebbe meglio dal punto di vista dell’ordine) un foglio di stile a parte per il formato da stampa, ma in questo episodio includiamo le regole per il print media nello stesso foglio di stile contenente anche gli altri stili CSS. In fondo a questo file, possiamo aggiungere una regola media type e qualsiasi regola definita all’interno di questa sezione si applicherà esclusivamente ai PDF. Per rimuovere lo sfondo blu dalla versione PDF, aggiungiamo il seguente CSS in fondo al foglio di stile della nostra applicazione:

/public/stylesheets/application.css

@media print {
	body { background-color: #FFF; }
  #container {
		width: auto;
		margin: 0;
		padding: 0;
		border: none;
	}
}

Al ricaricamento del PDF del nostro ordine, ora lo sfondo blu sarà scomparso.

Questo PDF è ora molto simile a quello creato nell’episodio su Prawn, ma abbiamo dovuto scrivere molto meno codice per ottenere lo stesso risultato che non se avessimo fatto la stessa cosa con Prawn. Prawn presenta ancora dei vantaggi, comunque, dal momento che ci permette di avere molto più controllo sul modo in cui viene generato il PDF, in particolare quando si prova a creare documenti multi pagina. Se la tabella degli ordini dovesse debordare su più pagine, cominceremmo ad avere delle difficoltà a controllare il modo in cui le intestazioni e i piè di pagina vengono mostrati su ciascuna pagina.

Controllare le interruzioni di pagina

PDFkit ci fornisce un po’ di controllo sulle interruzioni di pagina. Aggiungendo un paio di paragrafi di testo in cima all’ordine, in modo tale da far slittare in basso la tabella sottostante, vedremo che quest’ultima viene divisa su due pagine:

Possiamo evitare questo comportamento semplicemente agendo sugli stili CSS, in modo da fare aggiungere un’interruzione di pagina subito prima della tabella, così che questa appaia sempre in cima a una nuova pagina. Usiamo la regola page-break-before per ottenere questo risultato:

/public/stylesheets/application.css

@media print {
	body { background-color: #FFF; }
  #container {
		width: auto;
		margin: 0;
		padding: 0;
		border: none;
	}
	
	#line_items {
		page-break-before: always;
	}
}

Quando ricarichiamo il documento PDF, la tabella apparirà, come volevamo, in una pagina a parte:

Dunque, abbiamo un minimo di controllo sulle interruzioni di pagina con PDFkit, ma per la generazione di documenti più complessi è meglio affidarsi a Prawn.

C’è un’ultima modifica che vogliamo fare al documento dell’ordine per concludere questo episodio. Aggiungiamo un link in fondo alla pagina HTML dell’ordine che punti alla versione PDF. Per prima cosa aggiungiamo un link al file PDF in fondo alla pagina:

/app/views/orders/show.html.erb

<p><%= link_to "Download Invoice (PDF)", order_path(@order, :format => "pdf") %></p>

Questa modifica ci fornisce un link dalla maschera HTML al corrispettivo PDF, ma il link comparirà erroneamente anche nel file PDF. Possiamo nasconderlo sul PDF, fornendo un id all’elemento paragrafo che contiene il link:

/app/views/orders/show.html.erb

<p id="pdf_link"><%= link_to "Download Invoice (PDF)", order_path(@order, :format => "pdf") %></p>

e modificando il foglio di stile dell’applicazione in modo tale da nascondere il collegamento alla versione PDF:

/public/stylesheets/application.css

@media print {
	body { background-color: #FFF; }
  #container {
		width: auto;
		margin: 0;
		padding: 0;
		border: none;
	}
	
	#line_items {
		page-break-before: always;
	}
	
	#pdf_link {
		display: none;
	}
}

Ora la versione HTML dell’ordine mostrerà il link alla versione PDF, ma in quest’ultima non comparirà più, come desideravamo.

Una alternativa

Prima di chiudere l’episodio, citiamo un’alternativa a PDFkit, Wicked PDF. Questo plugin usa un approccio diverso rispetto a quello adottato da PDFkit, pur usando anch’esso wkhtmltopdf. Wicked PDF non è un middleware, ma usa un renderer Rails. Wicked PDF ci fornisce un maggiore controllo su quali action possano essere renderizzate in formato PDF, per cui vale la pena di tenerlo in considerazione in una eventuale scelta.

E’ tutto per questo episodio. Abbiamo a questo punto trattato due metodologie piuttosto diverse fra loro per la generazione di documenti PDF all’interno di applicazioni Rails, ciascuna con i propri pro e contro. Sebbene PDFkit sia uno strumento estremamente semplice per la generazione di PDF a partire dall’HTML, Prawn ci fornisce di contro un maggior controllo al prezzo della minor semplicità d’uso. Entrambi gli approcci hanno il loro dominio applicativo e meritano pertanto di essere parimenti presi in considerazione.

Active Model

Sun, 27 Jun 2010 21:36:44 +0000

L’episodio 193 [guardalo, leggilo] ha trattato i modelli completamente non persistenti. In quell’episodio abbiamo creato un modello che usava alcune delle funzionalità di ActiveRecord, ma che non aveva una tabella sul database corrispondente alle spalle. La tecnica utilizzata era un po’ forzata, dal momento che si tentava di fare un qualcosa per cui ActiveRecord non era stato progettato, ma ora, in Rails 3.0, abbiamo a disposizione una nuova funzionalità chiamata ActiveModel, che rende molto più semplice realizzare cose del genere.

Prima di entrare nei dettagli di ActiveModel, diamo una breve descrizione della parte dell’applicazione che cambieremo per usarlo.

Lo screenshot di sopra mostra una form per l’inserimento di un contatto, creata usando lo scaffolding. L’applicazione ha un modello chiamato Message che attualmente viene reso persistente da ActiveRecord, il che significa che stiamo gestendo i messaggi attraverso il database. Cambiamo il modo in cui funziona questa form, in modo tale che invii semplicemente le email e non salvi i messaggi su una tabella del database.

Quando si pensa di fare una cosa del genere, è sempre una buona idea analizzare preventivamente i requisiti ed assicurarsi che non si voglia realmente salvare alcun dato della form sul database, pochè spesso ci sono degli effetti collaterali nel fare in questo modo. Un database può fare da backup e rende anche più semplice lo spostamento dei messaggi inviati in una coda di un processo di background. Per gli scopi di questo esempio, tuttavia, non vogliamo nessuna di quelle funzionalità, per cui siamo liberi di andare avanti e crearci il nostro modello non persistente.

Il codice della classe del messaggio appare così:

/app/models/message.rb

class Message < ActiveRecord::Base
 validates_presence_of :name
 validates_format_of :email, :with => /^[-a-z0-9_+\.]+\@([-a-z0-9]+\.)+[a-z0-9]{2,4}$/i
 validates_length_of :content, :maximum => 500
end

Message eredita da ActiveRecord::Base come ci aspetteremmo, ma dal momento che non vogliamo che questo modello abbia un corrispettivo sul database di backend, rimuoviamo questa discendenza. Nel momento in cui facciamo questa modifica, tuttavia, la nostra form smetterà di funzionare, poichè i validatori sono forniti da ActiveRecord. Fortunatamente, possiamo ripristinare questa funzionalità usando ActiveModel.

Se diamo un’occhiata al codice sorgente di Rails 3, vedremo che ci sono le cartelle activerecord e activemodel. Il team di sviluppo del core di Rails ha estratto da ActiveRecord tutto ciò che non fosse prettamente legato al database e l’ha spostato in ActiveModel. ActiveRecord continua ancora ad affidarsi pesantemente su ActiveModel per tutte le funzionalità che non sono specifiche del database e dal momento che ActiveModel è funzionalmente completo e ben testato, è adatto anche ad essere utilizzato al di fuori di ActiveRecord.

Se diamo un’occhiata alla cartella che contiene il codice di ActiveModel, potremo vedere i servizi che questi mette a disposizione:

Possiamo notare dall’elenco di sopra che ActiveModel include il codice di gestione delle callback, del tracciamento delle modifiche, della serializzazione e della validazione, insieme ad altre cose. L’ultima fra queste è proprio ciò che stavamo cercando.

Il codice per le validazioni ha il seguente commento vicino alla cima e possiamo vedere da quello che è piuttosto semplice aggiungere le validazioni a un modello. Tutto ciò di cui abbiamo bisogno è di includere il module Validations e fornire i metodi getter per gli attributi su cui desideriamo chiamare i validatori:

  # == Active Model Validations
  #   
  # Provides a full validation framework to your objects.
  # 
  # A minimal implementation could be:
  # 
  #   class Person
  #     include ActiveModel::Validations
  # 
  #     attr_accessor :first_name, :last_name
  #
  #     validates_each :first_name, :last_name do |record, attr, value|
  #       record.errors.add attr, 'starts with z.' if value.to_s[0] == ?z
  #     end
  #   end
  #

Ora che sappiamo questa cosa, possiamo applicarla al nostro modello Message:

/app/models/message.rb

class Message
  include ActiveModel::Validations
  
  attr_accessor :name, :email, :content
 
  validates_presence_of :name
  validates_format_of :email, :with => /^[-a-z0-9_+\.]+\@([-a-z0-9]+\.)+[a-z0-9]{2,4}$/i
  validates_length_of :content, :maximum => 500
end

Non è comunque abbastanza per far sì che il nostro modello si comporti come il controller si aspetta che faccia. Ci sono due problemi nel metodo create. Innanzitutto, la chiamata a Message.new non funzionerà poichè il nostro modello Message non ha più un initializer che accetti un hash di attributi per argomento. In secondo luogo, save non funzionerà dal momento che non esiste un backend sul database in cui salvare il nuovo messaggio.

/apps/controllers/messages_controller.rb

class MessagesController < ApplicationController
  def new
    @message = Message.new
  end

  def create
    @message = Message.new(params[:message])
    if @message.save
      # TODO qui si deve inviare il messaggio
      flash[:notice] = "Message sent! Thank you for contacting us."
      redirect_to root_url
    else
      render :action => 'new'
    end
  end
end

Per primo, risolviamo il secondo problema. benchè non si possa salvare un messaggio, possiamo tuttavia controllarne la validità, per cui sostituiamo @message.save con @message.valid?:

/app/controllers/messages_controllers.rb

def create
  @message = Message.new(params[:message])
  if @message.valid?
    # TODO qui si deve inviare il messaggio
    flash[:notice] = "Message sent! Thank you for contacting us."
    redirect_to root_url
  else
    render :action => 'new'
  end
end

Possiamo risolvere il primo problema, invece, scrivendo un metodo initialize nella classe Message che accetti un hash come parametro. Questo metodo itererà su ciascun elemento nell’hash e ne assegnerà il valore all’opportuno attributo del messaggio, usando il metodo send:

/app/models/message.rb

class Message
  include ActiveModel::Validations
  
  attr_accessor :name, :email, :content
 
  validates_presence_of :name
  validates_format_of :email, :with => /^[-a-z0-9_+\.]+\@([-a-z0-9]+\.)+[a-z0-9]{2,4}$/i
  validates_length_of :content, :maximum => 500
  
  def initialize(attributes = {})
    attributes.each do |name, value|
      send("#{name}=", value)
    end
  end
end

Se ora ricarichiamo la form, tuttavia, vedremo che non ci siamo ancora:

Questa volta l’errore è causato dalla mancanza del metodo to_key nel modello Message. L’errore viene lanciato dal metodo form_for, per cui sembra che Rails stesso si aspetti che il nostro modello abbia una funzionalità che ancora non supporta. Aggiungiamogliela ora.

Anzichè provare a indovinare tutto ciò che Rails si aspetterà di vedere implementato dal nostro modello, c’è un simpatico lint test incluso in ActiveModel che ci permette di controllare se il nostro modello personalizzato si comporti o meno come Rails si aspetta che faccia. Se includiamo il module ActiveModel::Lint::Tests in un test per il modello, esso controllerà che il modello abbia tutte le funzionalità necessarie.

Il codice sorgente per il module Lint::Tests mostra i metodi ai quali il modello deve poter rispondere al fine di funzionare come si deve, incluso il to_key. Possiamo fare in modo che il nostro modello funzioni includendo un paio di module ActiveRecord. Il primo di questi è Conversion, che fornisce il metodo to_key ed alcuni altri. L’altro module è Naming, ma in questo caso lo estendiamo nella nostra classe anzichè includerlo, poichè include alcuni metodi di classe.

Oltre a includere il module Conversion, dobbiamo anche definire un metodo persisted?, che dovrà restituire sempre false, dato che il nostro modello non viene mai reso persistente sul database. Con queste modifiche, ora la nostra classe Message appare così:

/app/models/message.rb

class Message
  include ActiveModel::Validations
  include ActiveModel::Conversion
  extend ActiveModel::Naming
  
  attr_accessor :name, :email, :content
 
  validates_presence_of :name
  validates_format_of :email, :with => /^[-a-z0-9_+\.]+\@([-a-z0-9]+\.)+[a-z0-9]{2,4}$/i
  validates_length_of :content, :maximum => 500
  
  def initialize(attributes = {})
    attributes.each do |name, value|
      send("#{name}=", value)
    end
  end
  
  def persisted?
    false
  end
end

Se ricarichiamo la form, ora, riprenderà a funzionare, ad indicare che ora il modello Message soddisfa tutti i requisiti richiesti da Rails 3. Se proviamo a fare il submit della form, vedremo che anche i validatori funzionano:

Abbiamo trattato solo una piccola parte di ciò che mette a disposizione ActiveModel in questo episodio, ma dovrebbe essere abbastanza per stimolare il vostro appetito e darvi una buona ragione per approfondire sul codice sorgente per vedere cosa si può fare. Il codice è ben documentato e strutturato, per cui se troverete qualcosa di utile, ci dovrebbero essere anche le informazioni sufficienti nei commenti per mettervi in grado di utilizzare la funzionalità trovata.

Creare generatori in Rails 3

Fri, 25 Jun 2010 19:59:58 +0000

Come già fatto vedere nell’episodio 216 [guardalo, leggilo] i generatori in Rails 3 sono molto più modulari e possono essere personalizzati in modi che non erano pensabili con Rails 2. Ciononostante ci sono ancora delle volte in cui si ha ugualmente la necessità di creare un generatore completamente nuovo, perchè magari quelli forniti non vengono incontro appieno alle vostre necessità. La creazione di un generatore personalizzato è stata discussa nell’episodio 58 ma la tecnica è cambiata sostanzialmente da allora, per cui riprendiamo il discorso e mostriamo come creare un generatore analogo a quello di tale episodio in Rails 3.

Incominciamo

Il modo più semplice per creare un generatore è farlo da una nuova applicazione Rails 3, er cui partiamo creandone una nuova. Rails 3.0 beta 4 è appena stato rilasciato e la sintassi per la creazione di nuove applicazioni è cambiata, per cui, per creare l’applicazione todo che useremo per scrivere il nostro generatore, anzichè lanciare il comando:

$ rails todo

dovremo lanciare:

$ rails new todo

Dopo che abbiamo creato la nostra nuova applicazione, possiamo partire con la creazione di del nostro generatore, usando uno dei generatori forniti. Il comando rails g generator crea i file di base di cui avremo bisogno per il nostro nuovo generatore. Possiamo esaminare i parametri che il comando accetta, lanciando:

$ rails g generator --help

Il generatore è piuttosto semplice e ha bisogno solo del nome del generatore che si vuole creare. Vogliamo che il nostro generatore generi un file di layout applicativo, per cui lo chiamiamo layout:

$ rails g generator layout
      create  lib/generators/layout
      create  lib/generators/layout/layout_generator.rb
      create  lib/generators/layout/USAGE
      create  lib/generators/layout/templates

Il generatore crea i file sotto la cartella /lib dell’applicazione, il che significa che il generatore sarà disponibile esclusivamente per questa applicazione. Per renderlo disponibile a qualunque applicazione, dovremo fare un po’ di lavoro extra; vedremo come fare anche questa cosa più avanti nel corso dell’episodio.

La struttura creata dal generatore è piuttosto semplice e contiene esclusivamente una classe. Nella classe c’è una linea di codice che dice al generatore di ispezionare nella cartella dei template alla ricerca di ulteriori file:

/lib/generators/layout/layout_generator.rb

class LayoutGenerator < Rails::Generators::NamedBase
  source_root File.expand_path('../templates', __FILE__)
end

Il genratore generator crea anche un file USAGE che serve a descrivere la documentazione per il nostro generatore. Questa documentazione verrà mostrata se si lancierà il nostro generatore con l’opzione --help.

La classe creata dal generatore eredita da Rails::Generators::NamedBase. Questo implica che si dovrà fornire un nome come parametro al lancio del nostro generatore, allo stesso modo di come si è fatto al lancio del generatore generator. Possiamo averne conferma, lanciando il nostro nuovo generatore con l’opzione --help:

$ rails g layout --help
Usage:
  rails generate layout NAME [options]

Runtime options:
  -f, [--force]    # Overwrite files that already exist
  -p, [--pretend]  # Run but do not make any changes
  -s, [--skip]     # Skip files that already exist
  -q, [--quiet]    # Supress status output

Description:
    Explain the generator

Example:
    rails generate layout Thing

    This will create:
        what/will/it/create

Si note che il contenuto del file USAGE viene mostrato in fondo all’output.

Vogliamo rendere opzionale il parametro NAME impostando un valore di default pari a application. Possiamo farlo rendendo la nostra classe figlia di Rails::Generators::Base, anzichè di NamedBase. Ciò renderà opzionali tutti gli argomenti e di conseguenza ci darà più flessibilità nell’adattare il generatore alle nostra esigenze.

Possiamo dichiarare gli argomenti accettati dal nostro generatore mediante il metodo argument. Definire gli argomenti per conto nostro anzichè usare l’opzione di default NAME significa che possiamo stabilire un valore di default per ciascuno argomento. Aggiungiamo un argomento layout_name con un valore di default pari a application:

/lib/generators/layout/layout_generator.rb

class LayoutGenerator < Rails::Generators::Base
  source_root File.expand_path('../templates', __FILE__)
  argument :layout_name, :type => :string, :default => "application"
end

Se lanciamo nuovamente il generatore con l’opzione --help, vedremo il nostro nuovo argomento in lista. E’ mostrato fra parentesi quadre, ad indicare che è un parametro opzionale.

$ rails g layout --help
Usage:
  rails generate layout [LAYOUT_NAME] [options]

I generatori in Rails 3 si basano sulla libreria Thor, che somiglia a rake. Molti dei metodi che chiamiamo nella classe del nostro generatore sono metodi definiti all’interno dello stesso Thor, per cui se vorrete saperne di più potrete consultare il codice sorgente di Thor e la documentazione relativa.

Creiamo i file che verranno usati dal generatore

Vogliamo che il nostro generatore crei due file: un file di layout di applicazione e un foglio di stile. Per fare ciò, creiamo due file nella cartella templates del nostro generatore e facciamo in modo che quest’ultimo copi questi file nelle cartelle corrette dell’applicazione su cui verrà lanciato.

Come definiamo il comportamento del generatore? Ebbene, il modo in cui lo si fa è piuttosto anomalo. Tutti i metodi pubblici definiti nella classe del generatore verranno eseguiti al lancio del generatore. Quindi possiamo definire un metodo chiamato generate_layout e questo sarà automaticamente eseguito al lancio del generatore. E’ un concetto piuttosto strano inizialmente, ma alla fine si rivela un buon sistema per poter organizzare il codice all’interno del generatore.

La prima cosa che facciamo fare al nostro generatore è copiare il foglio di stile dalla cartella templates alla cartella /public/stylesheets dell’applicazione. Possiamo usare il metodo copy_file per questo:

/lib/generators/layout/layout_generator.rb

class LayoutGenerator < Rails::Generators::Base
  source_root File.expand_path('../templates', __FILE__)
  argument :layout_name, :type => :string, :default => "application"
  
  def generate_layout
    copy_file "stylesheet.css", "public/stylesheets/#{layout_name.underscore}.css"
  end
  
end

Il metodo copy_file richiede due parametri. Il primo è il nome del file nella cartella templates da copiare e il secondo è il percorso di destinazione. Si noti che il nome del file di destinazione è basato sul nome dell’argomento layout_name che viene passato al generatore. Il metodo argument crea un metodo layout_name che possiamo utilizzare, ma siccome il nome del layout passato potrebbe essere in camel-case, invochiamo sul quest’ultimo il metodo underscore per essere certi che sia in un formato adatto ai nomi di file.

Infine dobbiamo creare il file stylesheet.css nella cartella templates e incollarvi il contenuto del default CSS che vogliamo per la nostra applicazione.

Se ora invochiamo il nostro generatore senza argomenti, dovrebbe creare un file application.css:

$ rails g layout
      create  public/stylesheets/application.css

Poi dobbiamo fare la stessa cosa per il file di layout. Useremo la versione con gli underscore del nome del layout un paio di volte, per cui è meglio fattorizzare la conversione in un metodo che chiamiamo file_name. Come detto poco fa, ogni metodo pubblico definito nel generatore sarà invocato al lancio del generatore, per cui dobbiamo dichiarare il metodo file_name, che è di servizio, privato.

La prossima cosa che dobbiamo fare nel nostro generatore è creare il file di layout stesso. Potremmo usare nuovamente il metodo copy_file, ma in questo modo avremmo semplicemente una copia esatta del file di template, mentre invece vorremmo far girare un qualche codice erb sul template, in modo che venga modificato al lancio del generatore.

Per fare questo, possiamo usare il metodo template, che accetta argomenti simili a quelli di copy_file, ma che interpreta tutto l’erb che trova all’interno del template prima di copiarlo nella cartella di destinazione:

/lib/generators/layout/layout_generator.rb

class LayoutGenerator < Rails::Generators::Base
  source_root File.expand_path('../templates', __FILE__)
  argument :layout_name, :type => :string, :default => "application"
  
  def generate_layout
    copy_file "stylesheet.css", "public/stylesheets/#{file_name}.css"
    template "layout.html.erb", "app/views/layouts/#{file_name}.html.erb"
  end
  
  private
  def file_name
    layout_name.underscore
  end
  
end

Poi creiamo il vero e proprio file di template nella cartella templates. Il codice contenutovi sarà il seguente:

/lib/generators/layout/templates/layout.html.erb

<!DOCTYPE html>
<html>
  <head>
    <title>Untitled</title>
    <%%= stylesheet_link_tag "<%= file_name %>" %>
    <%%= javascript_include_tag :defaults %>
    <%%= csrf_meta_tag %>
    <%%= yield(:head) %>
  </head>
  <body>
    <div id="container">
      <%% flash.each do |name, msg| %>
        <%%= content_tag :div, msg, :id => "flash_#{name}" %>
      <%% end %>
      <%%= yield %>
    </div>
  </body>
</html>

La prima cosa degna di nota è che dal momento che stiamo usando il metodo template, tutti i tag erb nel codice verranno eseguiti al lancio del generatore. Se vogliamo includere dell’erb nel file generato, dobbiamo farne l’escape col simbolo percentuale all’inizio di ciascun tag erb e ciò è quanto abbiamo fatto per la maggior parte del codice erb qui sopra.

Per includere del contenuto dinamico nel template, possiamo invece usare del normale codice erb. Possiamo accedere ai metodi del generatore, anche privati, per cui chiamiamo file_name per inserire il nome corretto del foglio di stile nella chiamata a stylesheet_link_tag.

Per vedere se tutto funziona, rilanciamo il nostro generatore, questa volta passandogli un nome per il layout:

$ rails g layout admin
      create  public/stylesheets/admin.css
      create  app/views/layouts/admin.html.erb

Questa volta il generatore ha creato due file, ciascuno col nome basato sul nome di layout passato come parametro al lancio, per cui tutto sembra funzionare. Se diamo uno sguardo al file di layout generato, notiamo che il metodo file_name è stato chiamato quando il file è stato generato, per cui il metodo stylesheet_link_tag ha l’argomento corretto. Per gli altri tag erb era stato applicato l’escape, per cui ora li ritroviamo correttamente nel file di layout:

/app/views/layouts/admin.html.erb

<head>
  <title>Untitled</title>
  <%= stylesheet_link_tag "admin" %>
  <%= javascript_include_tag :defaults %>
  <%= csrf_meta_tag %>
  <%= yield(:head) %>
</head>

Rendere le opzioni facoltative

C’è ancora una piccola feature che vorremmo aggiungere al nostro generatore: la possibilità di passare un’opzione che prevenga la generazione del foglio di stile. Possiamo fare questa cosa, usando il metodo class_option:

/lib/generators/layout/layout_generator.rb

class LayoutGenerator < Rails::Generators::Base
  source_root File.expand_path('../templates', __FILE__)
  argument :layout_name, :type => :string, :default => "application"
  class_option :stylesheet, :type => :boolean, :default => true, :description => "Include stylesheet file"
  
  def generate_layout
    copy_file "stylesheet.css", "public/stylesheets/#{file_name}.css" if options.stylesheet?
    template "layout.html.erb", "app/views/layouts/#{file_name}.html.erb"
  end
  
  private
  def file_name
    layout_name.underscore
  end
  
end

Abbiamo chiamato la nostra option stylesheet, dandole il tipo boolean con un valore di default pari a true e fornendole una descrizione. Nella linea copy_file possiamo ora aggiungere una condizione if per cui il foglio di stile venga copiato solo se l’opzione stylesheet vale true.

Analogamente, nel template di layout, vogliamo includere la linea stylesheet_link_tag solo se l’opzione stylesheet è true. Racchiudiamo dunque quella riga di codice in un if affinchè tutto ciò avvenga:

/lib/generators/layout/templates/layout.html.erb

<!DOCTYPE html>
<html>
  <head>
    <title>Untitled</title>
    <%- if options.stylesheet? -%>
    <%%= stylesheet_link_tag "<%= file_name %>" %>
    <%- end -%>
    <%%= javascript_include_tag :defaults %>
    <%%= csrf_meta_tag %>
    <%%= yield(:head) %>
  </head>
  <body>
    <div id="container">
      <%% flash.each do |name, msg| %>
        <%%= content_tag :div, msg, :id => "flash_#{name}" %>
      <%% end %>
      <%%= yield %>
    </div>
  </body>
</html>

Se lanciamo la documentazione di help per il nostro generatore nuovamente, ora vedremo che abbiamo una nuova opzione (facoltativa) stylesheet.

$ rails g layout --help
Usage:
  rails generate layout [LAYOUT_NAME] [options]

Options:
  [--stylesheet]  # Indicates when to generate stylesheet
                  # Default: true

Ora siamo in grado di generare un layout privo di foglio di stile, usando l’opzione --skip-stylesheet (o --no-stylesheet). Così facendo, verrà creato il solo file di layout:

$ rails g layout foo --skip-stylesheet
      create  app/views/layouts/foo.html.erb

E’ tutto per questo episodio sulla creazione di generatori in Rails 3. Siete invitati a provare per conto vostro la creazione di nuovi generatori. Ogniqualvolta dobbiate riprodurre del codice uguale (o molto simile) nelle vostre applicazioni Rails, questo processo può essere convertito e reso più rapido e meno noioso dall’uso di un generatore. Per condividere il vostro generatore con altri, tutto quello che dovrete fare sarà di creare un plugin Rails o un gem e mettere il vostro generatore in una cartella lib/generators. Così facendo, chiunque includa tale gem o plugin nella propria applicazione, avrà, a disposizione anche il vostro generatore.

Wizard Form

Thu, 17 Jun 2010 18:17:03 +0000

Una form multistep, anche nota come wizard, è una form molto grande suddivisa in più pagine in sequenza che l’utente può navigare per completare l’inserimento dei dati. Non tutti amano questo tipo di approccio, alcuni preferiscono far vedere un’unica immensa form suddividendo piuttosto i dati fra più risorse e modelli. Esistono in ogni modo alcuni casi in cui il wizard rappresenta il miglior approccio, per esempio il caso di un sito per la dichiarazione dei redditi online, che richiede molti dati all’utente e che prevede molte ramificazioni a seconda dei dati immessi e che perciò rende sensato l’utilizzo di una form multistep.

Una form multistep ben fatta ricorda i dati inseriti fra i vari passi, permettendo agli utenti di andare avanti e indietro fra le pagine senza perdere nessuna delle informazioni inserite. Se il vostro obiettivo è semplicemente quello di suddividere una form grande per renderla più semplice agli occhi dell’utente, potreste considerare anche il solo utilizzo di JavaScript e CSS per mostrare e nascondere le varie parti della form quando vengono premuti i pulsanti “previous” e “next”. Un esempio di questo approccio lo si può ritrovare nell’Apple’s developer site. Se avete bisogno di qualcosa di più e orientato al lato server, allora dovrete passare necessariamente da Rails stesso e in questo episodio vi mostreremo come farlo.

Una form multistep di ordine

Per spiegare come comporre una form multistep, aggiungeremo un processo di checkout all’applicazione negozio online. Gli utenti dovranno per prima cosa inserire le loro informazioni di spedizione e poi quelle relative al pagamento ed infine, al terzo passo, dovranno vedere un riassunto del loro ordine in cui potranno dare conferma definitiva dei dati e dell’ordine stesso.

Non abbiamo ancora un modello per l’ordine e nemmeno un controller, per cui usiamo uno dei nifty generator di Ryan Bates per creare uno scaffold per la form degli ordini. Si noti come, essendo questa applicazione già stata scritta con Rails 2, si debba usare il comando script/generate. Un modello di ordine vero e proprio dovrebbe avere molti attibuti, ma per i nostri scopi semplifichiamo, dandogliene solamente due. Creiamo anche le action index, show e new per il controller:

$ script/generate nifty_scaffold order shipping_name:string billing_name:string index show new

Poi dobbiamo migrare il database per creare le nuove tabelle sul database:

$ rake db:migrate

La form dell’ordine, così come è stata generata dallo scaffold, ha tutti i campi insiemesu un unica pagina, per cui la prima cosa che dobbiamo fare è suddividere l’inserimento dei dati su più passaggi:

Il codice per la form del nuovo ordine ha tutti i campi riuniti insieme. Per cominciare a realizzare il nostro wizard, spostiamo ciascuno dei tre elementi paragrafo e i campi della form che questi racchiudono in partial distinti:

/app/views/orders/new.html.erb

<% title "New Order" %>

<% form_for @order do |f| %>
  <%= f.error_messages %>
  <p>
    <%= f.label :shipping_name %><br />
    <%= f.text_field :shipping_name %>
  </p>
  <p>
    <%= f.label :billing_name %><br />
    <%= f.text_field :billing_name %>
  </p>
  <p><%= f.submit "Submit" %></p>
<% end %>

<p><%= link_to "Back to List", orders_path %></p>

Prima di fare ciò, tuttavia, aggiungiamo un’intestazione a ciascuna sezione e modifichiamo la sezione finale in modo tale che mostri un riassunto dell’ordine:

/app/views/orders/new.html.erb

<% title "New Order" %>

<% form_for @order do |f| %>
  <%= f.error_messages %>
  <h2>Shipping Information</h2>
  <p>
    <%= f.label :shipping_name %><br />
    <%= f.text_field :shipping_name %>
  </p>
  <h2>Billing Information</h2>
  <p>
    <%= f.label :billing_name %><br />
    <%= f.text_field :billing_name %>
  </p>
  <h2>Confirm Information</h2>
  <p>
    <strong>Shipping Name:</strong>
    <%= h @order.shipping_name %>
  </p>
  <p>
    <strong>Billing Name:</strong>
    <%= h @order.billing_name %>
  </p>
  <p><%= f.submit "Submit" %></p>
<% end %>

<p><%= link_to "Back to List", orders_path %></p>

Una volta fatto questo, possiamo spostare ogni sezione in un proprio partial. Creiamo tre nuovi partial chiamati shipping_step, billing_step e confirmation_step e copiamo le rispettive parti della form all’interno di essi. Dopo aver fatto ciò, la nostra form di nuovi ordini dovrebbe apparire così:

/app/views/orders/new.html.erb

<% title "New Order" %>

<% form_for @order do |f| %>
  <%= f.error_messages %>
  <%= render 'shipping_step', :f => f %>
  <%= render 'billing_step', :f => f %>
  <%= render 'confirmation_step', :f => f %>
  <p><%= f.submit "Submit" %></p>
<% end %>

<p><%= link_to "Back to List", orders_path %></p>

e i tre partial dovrebbero essere così fatti:

/app/views/orders/_billing_step.html.erb

<h2>Billing Information</h2>
<p>
  <%= f.label :billing_name %><br />
  <%= f.text_field :billing_name %>
</p>

/app/views/orders/_shipping_step.html.erb

<h2>Shipping Information</h2>
<p>
  <%= f.label :shipping_name %><br />
  <%= f.text_field :shipping_name %>
</p>

/app/views/orders/confirmation_step.html.erb

<h2>Confirm Information</h2>
<p>
  <strong>Shipping Name:</strong>
  <%= h @order.shipping_name %>
</p>
<p>
  <strong>Billing Name:</strong>
  <%= h @order.billing_name %>
</p>

Dobbiamo modificare anche la classe di modello Order in modo tale che sia consapevole dell’esistenza dei tre passaggi e possa riconoscere quale fra questi sia il corrente. Potremmo usare il plugin state machine per questo scopo, ma dal momento che questo esempio è piuttosto semplice, scriveremo il codice da zero.

Il modello Order dovrà sapere quali sono i vari passi e l’ordine in cui si devono susseguire, per cui scriviamo un nuovo metodo steps per restituire una lista di passi. La nostra lista sarà un semplice array, ma per form più complesse questo metodo può facilmente essere reso più dinamico e gestire i casi in cui la lista di passi dipenda dallo storico delle scelte già fatte nei passi precedenti.

Per ottenere ed impostare il passo corrente per un ordine, creiamo un writer chiamato current_step e un metodo accessor corrispondente che restituirà il passo corrente nel caso in cui sia stato impostato, o altrimenti il primo passo. Fatte queste modifiche, il modello Order dovrebbe apparire così:

/app/models/order.rb

class Order < ActiveRecord::Base
  attr_accessible :shipping_name, :billing_name
  attr_writer :current_step
  
  def current_step
    @current_step || steps.first
  end
  
  def steps
    %w[shipping billing confirmation]
  end
end

Ora che il modello Order a che passo corrisponde il passo corrente, possiamo usare questa informazione per cambiare dinamicamente il partial da renderizzare, modificando leggermente la form del nuovo ordine, in modo che mostri solo il passo corrente:

/app/views/orders/new.html.erb

<% title "New Order" %>

<% form_for @order do |f| %>
  <%= f.error_messages %>
  <%= render "#{@order.current_step}_step", :f => f %>
  <p><%= f.submit "Submit" %></p>
<% end %>

<p><%= link_to "Back to List", orders_path %></p>

Al ricaricamento della pagina con la form del nuovo ordine, ora vedremo mostrata solo la sezione relativa al primo passaggio:

Muoversi fra i vari passi

Se clicchiamo il pulsante di submit sulla form, verrà chiamata la action create sul controller e verrà creato un nuovo ordine, ma questo non è ciò che vogliamo che accada. Vorremmo piuttosto che venisse mostrata la pagina col passo successivo al corrente: modifichiamo dunque la action sul controller per riflettere il comportamento desiderato.

Ci sono una serie di modi per approcciarsi al problema specifico. Potremmo creare una action separata per ogni passo; potremmo usare semplicemente la action create per il passo iniziale e le action edit e update per gli altri passi, che vorrebbe dire che abbiamo un modello parzialmente completato sul database, oppure potremmo rimanere nelle action new e create e salvare i dettagli inseriti fino ad ora in sessione. Ci sono una serie di caveat a quest’utlimo approccio che verranno citati di volta in volta man mano che emergeranno, mostrandone le alternative.

La cosa più semplice che possiamo fare è modificare la action create. Il primo passo che faremo sarà cambiarla in modo tale che non salvi l’ordine, ma che piuttosto mostri il prossimo passo della form.

/app/controllers/orders_controller.rb

def create
  @order = Order.new(params[:order])
  @order.next_step
  render 'new'
end

Sul controller, come si vede, chiamiamo il metodo next_step della classe Order che abbiamo scritto nella classe di modello:

/app/models/order.rb

def next_step
  self.current_step = steps[steps.index(current_step)+1]
end

Ora verremo portati dalla maschera del primo passo a quella del secondo al click del pulsante di submit sulla form, ma al successivo click rimarremo sul secondo passo. Ciograve; a causa del fatto che non stiamo salvando lo stato relativo al passo corrente quando facciamo il submit della form. Nell’action create dobbiamo impostare il passo corrente sul modello Order e poi salvare tale valore. Possiamo fare tutto questo recuperando il passo corrente dalla sessione, muovendoci al passo successivo e poi salvando quest’ultimo nuovo passo in sessione:

/app/controllers/orders_controller.rb

def create
  @order = Order.new(params[:order])
  @order.current_step = session[:order_step]
  @order.next_step
  session[:order_step] = @order.current_step
  render 'new'
end

Se proviamo ora la form, si potrà navigare in avanti da una pagina alla successiva come volevamo, ma si ritorna nuovamente alla prima pagina al submit dell’ultima. Quest’ultima cosa non riflette esattamente ciò che avevamo in mente per l’ultimo passo, ma sistemeremo la cosa più tardi.

Prima però, implementiamo il modo per tornare indietro nei passi precedenti. Al momento la form ci permette di spostarci in avanti, ma non possiamo tornare indietro e fare delle modifiche ai campi che abbiamo già compilato. Aggiungiamo un altro pulsante alla form per fare questo:

/app/views/orders/new.html.erb

<% title "New Order" %>

<% form_for @order do |f| %>
  <%= f.error_messages %>
  <%= render "#{@order.current_step}_step", :f => f %>
  <p><%= f.submit "Continue" %></p>
  <p><%= f.submit "Back", :name => "previous_button" %></p>
<% end %>

<p><%= link_to "Back to List", orders_path %></p>

Si noti che abbiamo dato al pulsate "Back" un attributo denominato name, in modo tale che si possa capire quale pulsante è stato utilizzato per fare il submit della form. Ora possiamo cambiare il controller per farlo andare coerentemente, a seconda di quale pulsante è stato premuto:

/app/controllers/orders_controller.rb

def create
  @order = Order.new(params[:order])
  @order.current_step = session[:order_step]
  if params[:back_button]
    @order.previous_step
  else
    @order.next_step
  end
  session[:order_step] = @order.current_step
  render 'new'
end

Affinchè tutto questo funzioni, dobbiamo aggiungere un metodo previous_step alla classe di modello Order che sia simile al metodo next_step scritto poco fa:

/app/models/order.rb

def previous_step
  self.current_step = steps[steps.index(current_step)-1]
end

Ora ci sono entrambi i pulsanti nella form per permettere di spostarsi avanti e indietro fra i vari passi del wizard:

Non ha senso tuttavia che ci sia un pulsante per andare indietro anche sulla prima pagina, per cui imponiamo che venga nascosto se l’ordine è al primo passo:

/app/views/orders/new.html.erb

<% title "New Order" %>

<% form_for @order do |f| %>
  <%= f.error_messages %>
  <%= render "#{@order.current_step}_step", :f => f %>
  <p><%= f.submit "Continue" %></p>
  <p><%= f.submit "Back", :name => "previous_button" unless @order.first_step? %></p>
<% end %>

<p><%= link_to "Back to List", orders_path %></p>

e ovviamente aggiungiamo il metodo first_step? che viene riferito nel partial alla classe di modello Order:

/app/models/order.rb

def first_step?
  current_step == steps.first
end

Quando ricarichiamo la form ora, non vedremo il pulsante per andare indietro sulla prima pagina:

Fare in modo che i campi ricordino i propri valori

Ora possiamo andare indietro e avanti fra le pagine della form, ma se inseriamo un valore in uno dei campi, questo non viene ricordato se si ritorna su tale passo più tardi. Possiamo risolvere questo problema usando nuovamente la sessione. Sebbene non sia raccomandabile memorizzare oggetti complessi in variabili di sessione, per oggetti semplici come hash o array può andare.

Il primo passo per fare ciò è creare una nuova variabile di sessione nella action new chiamata order_params e impostarne il valore ad un hash vuoto a meno che non abbia già un valore:

/app/controllers/orders_controller.rb

def new
  session[:order_params] ||= {}
  @order = Order.new
end

Nell’action create raggruppiamo i valori dei parametri dell’ordine con i valori della variabile di sessione. Si noti che usiamo una deep merge nel caso ci siano valori innestati fra i parametri dell’ordine mentre faremo un semplice merge se esistono parametri di ordine. Possiamo creare un nuovo oggetto Order da questo hash di merge:

/app/controllers/orders_controller.rb

def create
  session[:order_params].deep_merge!(params[:order]) if params[:order]
  @order = Order.new(session[:order_params])
  @order.current_step = session[:order_step]
  if params[:back_button]
    @order.previous_step
  else
    @order.next_step
  end
  session[:order_step] = @order.current_step
  render 'new'
end

Ora, al riempimento dei dati in form, vedremo i valori immessi nel passo finale, dato che sono stati salvati fra i vari passi:

C’è ancora un piccolo problema, comunque. Se ci spostiamo dalla form mentre è solo parzialmente compilata e subito dopo ritorniamo indietro, le informazioni inserite ed il passo sono persi. Possiamo risolvere questa cosa copiando le due linee che recuperano le informazioni sull’ordine e sul passo corrente dalla variabile di sessione che abbiamo scritto per la action create nella action new:

/app/controllers/orders_controller.rb

def new
  session[:order_params] ||= {}
  @order = Order.new(session[:order_params])
  @order.current_step = session[:order_step]
end

Sistemato questo codice, ora possiamo ritornare alla form ed ogni dato inserito sarà ancora là. Non solo, ma saremo anche ricondotti all’ultimo passo in cui eravamo arrivati.

Salvataggio di un ordine

Ora renderemo completamente funzionante la form, consentendole di salvare l’ordine al termine dell’ultimo passo. Possiamo fare ciò, cambiando il controller in modo tale che salvi l’ordine solo se il passo corrente è l’ultimo e se il pulsante premuto per il submit non è quello per ritornare alla pagina precedente. Dobbiamo anche cambiare il comportamento del rendering in modo che se l’ordine viene correttamente salvato, l’applicazione alla action show per tale ordine e mostri un messaggio flash:

/app/controllers/orders_controller.rb

class OrdersController < ApplicationController
  def index
    @orders = Order.all
  end
  
  def show
    @order = Order.find(params[:id])
  end
  
  def new
    session[:order_params] ||= {}
    @order = Order.new(session[:order_params])
    @order.current_step = session[:order_step]
  end
  
  def create
    session[:order_params].deep_merge!(params[:order]) if params[:order]
    @order = Order.new(session[:order_params])
    @order.current_step = session[:order_step]
    if params[:back_button]
      @order.previous_step
    elsif @order.last_step?
      @order.save
    else
      @order.next_step
    end
    session[:order_step] = @order.current_step
    
    if @order.new_record?
      render 'new'
    else
      flash[:notice] = "Order saved."
      redirect_to @order
    end
  end
end

Per fare funzionare il tutto, dobbiamo anche aggiungere il metodo last_step al modello Order:

/app/models/order.rb

def last_step?
  current_step == steps.last
end

Quando andiamo nella form di inserimento di un nuovo ordine, ora, e compiliamo tutte le informazioni per tutti i passi e salviamo, l’ordine verrà salvato e saremo ridiretti alla pagina di dettaglio di tale ordine:

Non abbiamo ancora finito, però. Se proviamo a creare un nuovo ordine, la form andrà direttamente all’ultimo passo e vedremo il dettaglio dell’ordine precedente. Dobbiamo cambiare nuovamente il controller in modo tale che le informazioni dell’ordine siano cancellate dalla sessione una volta che l’ordine è stato salvato correttamente. Possiamo fare ciò svuotando le informazioni di sessione una volta salvato l’ordine, impostando entrambe le variabili di sessione, order_step e order_params, a nil:

/app/controllers/orders_controller.rb

def create
  session[:order_params].deep_merge!(params[:order]) if params[:order]
  @order = Order.new(session[:order_params])
  @order.current_step = session[:order_step]
  if params[:back_button]
    @order.previous_step
  elsif @order.last_step?
    @order.save
  else
    @order.next_step
  end
  session[:order_step] = @order.current_step
    
  if @order.new_record?
    render 'new'
  else
    session[:order_step] = session[:order_params] = nil
    flash[:notice] = "Order saved."
    redirect_to @order
  end
end

Aggiungere la validazione

L’ultima cosa che trattiamo è come gestire le validazioni nella form. Imponiamo una validazione per il modello Order per gli attributi shipping_name e billing_name:

/app/models/order.rb

validates_presence_of :shipping_name
validates_presence_of :billing_name

Vorremmo che l’errore di validazione comparisse solo nel passo opportuno. Aggiungiamo, per questa ragione, una condizione if ai validatori:

/app/models/order.rb

validates_presence_of :shipping_name, :if => lambda { |o| o.current_step == "shipping" }
validates_presence_of :billing_name, :if => lambda { |o| o.current_step == "billing" }

Vogliamo che la form transiti al passo successivo (o precedente) se l’ordine è valido, per cui dobbiamo cambiare di nuovo la action create sul controller in modo che controlli che l’ordine sia valido. Per fare ciò, racchiudiamo il codice che cambia il passo e salva il record in un blocco if:

/app/controllers/orders_controller.rb

def create
  session[:order_params].deep_merge!(params[:order]) if params[:order]
  @order = Order.new(session[:order_params])
  @order.current_step = session[:order_step]
  if @order.valid?
    if params[:back_button]
      @order.previous_step
    elsif @order.last_step?
      @order.save
    else
      @order.next_step
    end
    session[:order_step] = @order.current_step
  end
  if @order.new_record?
    render 'new'
  else
    session[:order_step] = session[:order_params] = nil
    flash[:notice] = "Order saved."
    redirect_to @order
  end
end

Se proviamo ora a creare un nuovo ordine e proviamo a fare il submit, nel primo passo vedremo l’errore di validazione per il campo shipping, ma non per il billing:

Analogamente, se andiamo avanti fino al passo della fatturazione e proviamo a lasciare il campo vuoto e a fare il submit, vedremo solo l’errore per tale passo:

Possiamo ripulire un po’ la validazione, spostando le espressioni lambda nei metodi denominati shipping? e billing?, così:

/app/models/order.rb

class Order < ActiveRecord::Base
  attr_accessible :shipping_name, :billing_name
  attr_writer :current_step

  validates_presence_of :shipping_name, :if => :shipping?
  validates_presence_of :billing_name, :if => :billing?

  # other methods omittted.
    
  def shipping?
    current_step == "shipping"
  end
  
  def billing?
    current_step == "billing"
  end
end

E’anche utile avere un metodo che validi tutti i passi in un colpo solo. Per fare ciò, possiamo scrivere un metodo all_valid? che iteri su ogni passo e controlli che sia valido:

/app/models/order.rb

def all_valid?
  steps.all? do |step|
    self.current_step = step
    valid?
  end
end

In questo modo, se mai facessimo delle modifiche alle validazioni o al modo in cui funzionano i passi, potremmo essere tranquilli del fatto che nessun passo è stato invalidato nel processo. Possiamo usare questo nuovo metodo nel controller per assicurarci che l’ordine sia salvato solo se tutti i passi sono validi:

/app/controllers/orders_controller.rb

def create
  session[:order_params].deep_merge!(params[:order]) if params[:order]
  @order = Order.new(session[:order_params])
  @order.current_step = session[:order_step]
  if @order.valid?
    if params[:back_button]
      @order.previous_step
    elsif @order.last_step?
      @order.save if @order.all_valid?
    else
      @order.next_step
    end
    session[:order_step] = @order.current_step
  end
  if @order.new_record?
    render 'new'
  else
    session[:order_step] = session[:order_params] = nil
    flash[:notice] = "Order saved."
    redirect_to @order
  end
end

L’aspetto pratico del metodo all_valid? è che cambia il passo su cui si trova in modo che se uno dei passi non è valido, quello diventi anche il passo corrente, in modo tale che all’utente sia mostrato il primo passo non valido.

E’ tutto per questo episodio sulle form multipasso. Una cosa da tenere a mente è che stiamo salvando i parametri dell’ordine in sessione, il che significa che se un utente apre più finestre o tab del browser, le stesse informazioni saranno condivise fra tali finestre. Se si vuole che più tab o finestre di un medesimo browser siano trattati in modo indipendente, allora potreste voler salvare i parametri dell’ordine sul database e salvare prima il modello dell’ordine, usando la action update per salvare le informazioni aggiuntive provenienti dai vari passi. In alternativa, i parametri potrebbero essere salvati in campi nascosti della form.

Infine, un rapido sguardo alla action create evidenzia che è diventata più corposa e complessa di quello che dovrebbe essere. Anche se per gli scopi della lezione questo può anche andare, se questa tecnica fosse applicata in produzione, necessiterebbe di un po’ di ulteriore refactoring di pulizia.

Generatori in Rails 3

Fri, 11 Jun 2010 20:39:43 +0000

Se avete usato a fondo Rails, sarete avvezzi all’uso dei generatori e avrete sicuramente utilizzato il comando script/generate per creare modelli, controller, scaffold e roba simile. I generatori in Rails 3 sono stati riscritti e sono completamente diversi da quelli che c’erano in Rails 2. Da un lato, ora sono molto più modulari, il che significa che potete personalizzarli per adattarli alle vostre esigenze.

Se lanciamo rails g dalla cartella radice di un applicazione Rails 3, vediamo l’elenco dei generatori disponibili per tale applicazione. Se non abbiamo ancora creato alcun generatore per conto nostro, vedremo solo i generatori inclusi in Rails 3: controller, generator, helper, integration_test, mailer, metal, migration, model, observer, performance_test, plugin, resource, scaffold, scaffold_controller, session_migration e stylesheets. Per la maggior parte dei casi, questi generatori funzionano allo stesso modo in cui funzionavano le rispettive controparti Rails 2.

Se lanciamo un generatore con l’opzione --help, ci vengono mostrate le informazioni di supporto all’uso di tale generatore, unitamente ad un elenco di opzioni. Se proviamo questo comando con il generatore scaffold, vediamo che ci sono molte opzioni a disposizione e che queste ci danno parecchia flessibilità nella personalizzazione del comportamento del generatore.

$ rails g scaffold --help
Usage:
  rails generate scaffold NAME [field:type field:type] [options]

Options:
  -c, --scaffold-controller=NAME  # Scaffold controller to be invoked
                                  # Default: scaffold_controller
      [--singleton]               # Supply to create a singleton controller
      [--force-plural]            # Forces the use of a plural ModelName
  -y, [--stylesheets]             # Indicates when to generate stylesheets
                                  # Default: true
  -o, --orm=NAME                  # Orm to be invoked
                                  # Default: active_record

ScaffoldController options:
  -e, [--template-engine=NAME]  # Template engine to be invoked
                                # Default: erb
      [--helper]                # Indicates when to generate helper
                                # Default: true
  -t, [--test-framework=NAME]   # Test framework to be invoked
                                # Default: test_unit

Runtime options:
  -f, [--force]    # Overwrite files that already exist
  -p, [--pretend]  # Run but do not make any changes
  -q, [--quiet]    # Supress status output
  -s, [--skip]     # Skip files that already exist

TestUnit options:
  -r, [--fixture-replacement=NAME]  # Fixture replacement to be invoked
      [--fixture]                   # Indicates when to generate fixture
                                    # Default: true

ActiveRecord options:
  [--parent=PARENT]  # The parent class for the generated model
  [--timestamps]     # Indicates when to generate timestamps
                     # Default: true
  [--migration]      # Indicates when to generate migration
                     # Default: true

Si noti che certe opzioni hanno un valore di default. Per esempio l’opzione --stylesheets di default vale true. Ma che succede se non vogliamo il foglio di stile creato alla generazione dello scaffold? Beh, essendoci un default booleano a true, possiamo prefissare l’opzione con un --no per disabilitare la stessa. Per farvi vedere il tutto con un esempio, creiamo un nuovo scaffold chiamato project privo di foglio di stile.

$ rails g scaffold project name:string --no-stylesheets
      invoke  active_record
      create    db/migrate/20100602201538_create_projects.rb
      create    app/models/project.rb
      invoke    test_unit
      create      test/unit/project_test.rb
      create      test/fixtures/projects.yml
       route  resources :projects
      invoke  scaffold_controller
      create    app/controllers/projects_controller.rb
      invoke    erb
      create      app/views/projects
      create      app/views/projects/index.html.erb
      create      app/views/projects/edit.html.erb
      create      app/views/projects/show.html.erb
      create      app/views/projects/new.html.erb
      create      app/views/projects/_form.html.erb
      invoke    test_unit
      create      test/functional/projects_controller_test.rb
      invoke    helper
      create      app/helpers/projects_helper.rb
      invoke      test_unit
      create        test/unit/helpers/projects_helper_test.rb

Se guardiamo l’output del comando, vediamo che non sono stati generati fogli di stile dal momento che abbiamo disabilitato l’opzione relativa.

Oltre all’elenco dei file creati, l’output generato dal lancio del generatore mostra una serie di chiamate ad invoke: queste linee indicano l’invocazione di altri generatori. Ciò significa che il generatore dello scaffold non fa in pratica un granchè di per sè, ma piuttosto delega ad altri generatori come active_record, che crea il file di modello e il file di magration. Il generatore active_record a sua volta chiama un altro generatore, test_unit, per creare i file dei test unitari e una fixture. Questo pattern si ripete anche oltre nel generatore scaffold_controller, che invoca i generatori erb, test_unit e helper per creare tutti i file associati al controller e alle viste. Il pattern rende il sistema molto modulare, con la conseguenza che potremmo sostituire alcuni generatori con altri. Se volessimo usare Haml, anzichè erb, nelle viste, o Shoulda o RSpec al posto di Test::Unit per i test, potremmo agganciare questi generatori ed essere già a posto con tutto.

Ora che sappiamo tutto questo, possiamo riguardare l’elenco di opzioni fornite dall’help del generatore scaffold: dovrebbero apparire più sensate. Per esempio, l’opzione --orm ci consente di cambiare l’ORM che genera i modelli, in modo tale da poter usare, ad esempio, DataMapper al posto del default ActiveRecord. Più in giù nella lista delle opzioni c’è una lista di opzioni specifiche per ActiveRecord, che ovviamente riguardano la versione ActiveRecord del generatore, unitamente alle opzioni per i generatori TestUnit e ScaffoldController.

Cambiamo le opzioni di default

Anche se è utile poter passare opzioni tipo --no-stylesheets ai generatori, lo sarebbe ancor di più se potessimo cambiare proprio il comportamento di default delle opzioni, e in Rails 3 ciò è possibile, a livello di singola applicazione, modificando il file application.rb. Il file di default application.rb generato alla creazione dell’applicazione mostra le seguenti sezioni al suo interno, commentate:

/config/application.rb

# Configure generators values. Many other options are available, be sure to check the documentation.
# config.generators do |g|
#   g.orm             :active_record
#   g.template_engine :erb
#   g.test_framework  :test_unit, :fixture => true
# end

Se de-commentiamo questa sezione, possiamo ridefinire il comportamento di default delle opzioni per tutti i generatori dell’applicazione. Le opzioni fornite a titolo di esempio rispecchiano anche i valori di default, ma possiamo sostituire i valori con quelli che vogliamo noi. Per rendere l’opzione stylesheets false per default, possiamo scrivere:

/config/application.rb

# Configure generators values. Many other options are available, be sure to check the documentation.
config.generators do |g|
  g.stylesheets false
end

Se lanciamo nuovamente il comando help per il generatore scaffold, saranno riflessi i nuovi valori di default e l’opzione --stylesheets non comparirà più con un default a true:

$ rails g scaffold --help
Usage:
  rails generate scaffold NAME [field:type field:type] [options]

Options:
  -y, [--stylesheets]             # Indicates when to generate stylesheets
  -c, --scaffold-controller=NAME  # Scaffold controller to be invoked
                                  # Default: scaffold_controller
      [--singleton]               # Supply to create a singleton controller
      [--force-plural]            # Forces the use of a plural ModelName
  -o, --orm=NAME                  # Orm to be invoked
                                  # Default: active_record

Ora proviamo qualcosa di più ardito: cambiamo il framework di test in modo che sia Shoulda anzichè Test::Unit e sostituiamo le fixture con Factory Girl, cambiando l’opzione di default di fixture-replacement.

Per fare ciò, per prima cosa dobbiamo dichiarare i rispettivi gem nel Gemfile dell’applicazione. Abbiamo bisogno di questi gem solamente nell’ambiente di test, per cui li aggiungiamo all’interno del gruppo specifico:

/Gemfile

group :test do
  gem "shoulda"
  gem "factory_girl"
end

Sfortunatamente questi due gem non includono i generatori per Rails 3, ma possiamo usare un altro gem chiamato rails3-generators che include i generatori per una serie di plugin e gem di Rails 3, incluso Factory Girl e Shoulda. Aggiungeremo anche questi gem al Gemfile, ma solo per il gruppo development, in modo tale che siano disponibili solo in tale ambiente:

/Gemfile

gem "rails3-generators", :group => :development

Fatto ciò lanciamo:

bundle install

per installare i gem. Una volta che i gem sono stati installati, possiamo lanciare rails g per vedere un elenco dei generatori disponibili. In fondo all’elenco, ci dovrebbero ora essere tutti i generatori che sono stati creati dal gem rails3-generators.

Ora che abbiamo questi nuovi geneatori, possiamo modificare la configurazione dei generatori nell’application.rb e aggiungere i default che vogliamo per le opzioni test_framework e fixture_replacement:

/config/application.rb

# Configure generators values. Many other options are available, be sure to check the documentation.
config.generators do |g|
  g.stylesheets false
  g.test_framework :shoulda
  g.fixture_replacement :factory_girl
end

Al lancio del comando di help per il generatore di scaffold, ora, vedremo le nostre modifiche ai valori di default.

$ rails g scaffold --help
Usage:
  rails generate scaffold NAME [field:type field:type] [options]
  ...

ActiveRecord options:
  [--parent=PARENT]      # The parent class for the generated model
  [--migration]          # Indicates when to generate migration
                         # Default: true
  [--timestamps]         # Indicates when to generate timestamps
                         # Default: true
  [--textframework=NAME] # Test framework to be invoked
                         # Default: shoulda

Shoulda options:
  [--fixture-replacement=NAME]  # Fixture replacement to be invoked
                                # Default: factory_girl
  [--dir=DIR]                   # The directory where the model tests should go
                                # Default: test/unit

Possiamo testare il tutto generando un nuovo scaffold per un modello task.

$ rails g scaffold task project_id:integer name:string
      invoke  active_record
      create    db/migrate/20100604202823_create_tasks.rb
      create    app/models/task.rb
      invoke    shoulda
      create      test/unit/task_test.rb
      invoke      factory_girl
      create        test/factories/tasks.rb
       route  resources :tasks
      invoke  scaffold_controller
      create    app/controllers/tasks_controller.rb
      invoke    erb
      create      app/views/tasks
      create      app/views/tasks/index.html.erb
      create      app/views/tasks/edit.html.erb
      create      app/views/tasks/show.html.erb
      create      app/views/tasks/new.html.erb
      create      app/views/tasks/_form.html.erb
       error    shoulda [not found]
      invoke    helper
      create      app/helpers/tasks_helper.rb
       error      shoulda [not found]

In cima all’output vediamo che i generatori shoulda e factory_girl sono stati invocati correttamente, ma che un po’ dopo, nel generatore scaffold_controller, non si trova un generatore shoulda per il file erb o per l’helper. Se diamo nuovamente un’occhiata all’elenco degli helper, possiamo notare come di fatto abbiamo a disposizione i generatori shoulda solamente per i modelli e i controller:

$ rails g
  ...
Shoulda:
  shoulda:controller
  shoulda:model

Come dobbiamo procedere, dunque? Beh, leggendo la pagina delle Rails Guides per i generatori vediamo che è possibile aggiungere dei generatori in cascata in modo tale che se un determinato generatore non viene trovato, ne venga usato uno alternativo. Tutto ciò che dobbiamo fare, dunque, è modificare nuovamente il blocco config in application.rb:

/config/application.rb

# Configure generators values. Many other options are available, be sure to check the documentation.
config.generators do |g|
  g.stylesheets false
  g.test_framework :shoulda
  g.fallbacks[:shoulda] = :test_unit 
  g.fixture_replacement :factory_girl
end

Ora potremo finalmente generare senza errori gli scaffold con Shoulda e i generatori usati saranno quelli di Test::Unit, nel caso in cui quelli propri di Shoulda non vengano rintracciati.

Personalizzazione dei template

L’ultima cosa che trattiamo in questo episodio è il modo per personalizzare i template generati. Di sotto è riportata il codice di default della vista per l’action index per il controller dei task che abbiamo appena generato.

/app/views/tasks/index.html.erb

<h1>Listing tasks</h1>

<table>
  <tr>
    <th></th>
    <th></th>
    <th></th>
  </tr>

<% @tasks.each do |task| %>
  <tr>
    <td><%= link_to 'Show', task %></td>
    <td><%= link_to 'Edit', edit_task_path(task) %></td>
    <td><%= link_to 'Destroy', task, :confirm => 'Are you sure?', :method => :delete %></td>
  </tr>
<% end %>
</table>

<br />

<%= link_to 'New Task', new_task_path %>

Poniamo di voler togliere il tag di ritorno a capo presente alla fine del template e di voler anche racchiudere l’ultimo link all’interno di un elemento di paragrafo. Come possiamo cambiare il template affinchè ogni vista index generata sia personalizzata in questo modo?

Per far ciò, possiamo creare un nuovo template personalizzato all’interno di una nuova cartella templates, sotto la cartella lib dell’applicazione. I generatori andranno a vedere qui dentro alla ricerca dei file di template prima di utilizzare i loro default. Al fine di capire quale template sia da ridefinire, dovremo dare un’occhiata al codice sorgente di Rails. Il codice per i generatori è contenuto nella cartella railties/lib/rails/generators ed i template di default delle viste sono in una sottocartella erb/scaffold/templates/. Possiamo copiare il contenuto del file index.html.erb in questa cartella e personalizzarlo secondo il nostro volere.

Dobbiamo creare una strutturas di cartelle analoga sotto alla cartella dei generatori e perciò il nostro template personalizzato index deve trovarsi in /lib/templates/erb/scaffold/index.html.erb. Dopodichè possiamo incollargli dentro il contenuto del file di template di default, modificato come volevamo. Un volta fatto ciò, alla creazione di un nuovo scaffold, per esempio per un modello chiamato Category, vedremo la vista index generata a partire dal nostro template personalizzato.

rails g scaffold category name:string

/app/views/categories/index.html.erb

<h1>Listing categories</h1>

<table>
  <tr>
    <th>Name</th>
    <th></th>
    <th></th>
    <th></th>
  </tr>

<% @categories.each do |category| %>
  <tr>
    <td><%= category.name %></td>
    <td><%= link_to 'Show', category %></td>
    <td><%= link_to 'Edit', edit_category_path(category) %></td>
    <td><%= link_to 'Destroy', category, :confirm => 'Are you sure?', :method => :delete %></td>
  </tr>
<% end %>
</table>

<p><%= link_to 'New Category', new_category_path %></p>

E’ tutto per questo episodio. I generatori in Rails 3 si sono nettamente evoluti rispetto a quelli presenti in Rails 2 e sono anche molto più semplici da personalizzare.

Query avanzate in Rails 3

Sat, 29 May 2010 08:45:26 +0000

Questo episodio tratterà le query avanzate di Rails 3. Nell’episodio 202 [guardalo, leggilo] abbiamo parlato delle novità alle query di ActiveRecord di Rails 3; oggi proseguiremo il discorso da lì e mostreremo alcune altre feature avanzate.

Utilizzo dei metodi di classe al posto degli scope

L’applicazione che useremo ha due modelli: Product e Category con il prodotto che appartiene ad una categoria. Il modello prodotto ha due named scope: discontinued, che restituisce tutti i prodotti per i quali il valore del campo discontinued è true e price, che restituisce i prodotti più economici del prezzo passato come argomento:

/app/models/product.rb

class Product < ActiveRecord::Base
  belongs_to :category
  scope :discontinued, where(:discontinued => true)
  scope :cheaper_than, lambda { |price| where("price < ?", price) }
end

Nel secondo named scope si usa un lambda. Se non ne avete mai usato uno di questi in un named scope, potreste valutare piuttosto l’uso di un metodo di classe, specialmente se state passando un consistente numero di parametri o se il contenuto dello scope è complesso. Il nostro invece è piuttosto semplice, ma lo cambiamo ugualmente con un metodo di classe:

/app/models/product.rb

class Product < ActiveRecord::Base
  belongs_to :category
  scope :discontinued, where(:discontinued => true)
  
  def self.cheaper_than(price)
    where("price < ?", price)
  end
end

Il metodo di classe si comporterà alla stessa maniera dello scope. Possiamo fare la stessa cosa anche in Rails 2, ma si comporta molto meglio in Rails 3. Possiamo perfino riusare questo metodo in un altro named scope. Se vogliamo creare uno scope chiamato cheap che restituisce i prodotti che costano meno di cinque euro, possiamo scrivere:

/app/models/products.rb

scope :cheap, cheaper_than(5)

Tuttavia potenzialmente ci può essere un’insidia in tutto ciò. Se usiamo un metodo di classe in uno scope, dobbiamo definire tale scope, all’interno della classe, dopo che è stato definito il metodo di classe, il che significa che lo scope dovrà essere messo più in basso nella classe rispetto al solito.

Usando la console Rails, possiamo vedere l’SQL generato dallo scope:

ruby-1.8.7-p249 > Product.cheap.to_sql
 => "SELECT    \"products\".* FROM      \"products\" WHERE    (price < 5)"

Se chiamiamo semplicemente lo scope, vedremo la lista dei prodotti più economici:

>Product.cheap
 => [#<Product id: 1, name: "Top", price: 4.99, discontinued: nil, category_id: 3, created_at: "2010-05-24 21:01:59", updated_at: "2010-05-24 21:01:59">, #<Product id: 2, name: "Milk", price: 2.99, discontinued: nil, category_id: 2, created_at: "2010-05-24 21:02:38", updated_at: "2010-05-24 21:02:38">]

Associazioni

Finchè siamo in console, vi mostriamo un altro trucco, che coinvolge l’utilizzo degli scope mediante le associazioni. Come abbiamo citato in precedenza, nella nostra applicazione un prodotto appartiene ad una categoria. Ciò significa che possiamo usare il metodo joins per ottenere una query SQL che esegua una inner join fra le tabelle prodotti e categorie:

ruby-1.8.7-p249 > Category.joins(:products).to_sql
 => "SELECT     \"categories\".* FROM       \"categories\" INNER JOIN \"products\" ON \"products\".\"category_id\" = \"categories\".\"id\""

Vogliamo trovare tutte le categorie che hanno un prodotto che faccia match con un certo scope; tanto per fissare le idee, vogliamo trovare tutte le categorie che hanno almeno un prodotto che costi meno di cinque euro. Ci sono due metodi che possiamo usare a questo scopo. Possiamo usare il metodo merge in questa maniera:

> Category.joins(:products).merge(Product.cheap)
 => [#<Category id: 3, name: "Games", created_at: "2010-05-24 21:00:57", updated_at: "2010-05-25 18:30:18">, #<Category id: 2, name: "Groceries", created_at: "2010-05-24 21:00:50", updated_at: "2010-05-25 18:30:39">]

Oppure in alternativa possiamo usare una e commerciale che è un alias alla stessa cosa, per cui restituirà lo stesso risultato:

> Category.joins(:products) & Product.cheap
 => [#<Category id: 3, name: "Games", created_at: "2010-05-24 21:00:57", updated_at: "2010-05-25 18:30:18">, #<Category id: 2, name: "Groceries", created_at: "2010-05-24 21:00:50", updated_at: "2010-05-25 18:30:39">]

Usando questi metodi, possiamo mettere in join qualsiasi altra query, anche se non si trova sullo stesso modello, consentendoci di trovare tutte le categorie che hanno dei prodotti che costano meno di cinque euro. Se invochiamo la to_sql sulle query in join vedremo che è stata usata la inner join e che la clausola di WHERE del named scope è stata aggiunta in fondo all’istruzione:

> (Category.joins(:products) & Product.cheap).to_sql
 => "SELECT     \"categories\".* FROM       \"categories\" INNER JOIN \"products\" ON \"products\".\"category_id\" = \"categories\".\"id\" WHERE     (price < 5)"

Questa può rivelarsi una tecnica potente, allorchè usata all’interno della definizione di un named scope. La possiamo usare, per esempio, per creare uno scope nel modello Category, che trovi le categorie aventi prodotti economici:

/app/models/category.rb

class Category < ActiveRecord::Base
  has_many :products
  scope :with_cheap_products, joins(:products) & Product.cheap
end

Questo nuovo named scope restituirà le stesse categorie della query in join che abbiamo scritto poco fa:

> Category.with_cheap_products
 => [#<Category id: 3, name: "Games", created_at: "2010-05-24 21:00:57", updated_at: "2010-05-25 18:30:18">, #<Category id: 2, name: "Groceries", created_at: "2010-05-24 21:00:50", updated_at: "2010-05-25 18:30:39">]

Una cosa di cui stare attenti quando si tratta con condizioni fra associazioni è il nome delle tabelle. Se diamo un’occhiata all’SQL prodotto alla chiamata del named scope, possiamo vedere che non c’è alcun nome di tabella che qualifichi il campo nella clausola di WHERE:

> Category.with_cheap_products.to_sql
 => "SELECT     \"categories\".* FROM       \"categories\" INNER JOIN \"products\" ON \"products\".\"category_id\" = \"categories\".\"id\" WHERE     (price < 5)"

Questa cosa sarebbe un problema se entrambe le tabelle avessero una colonna chiamata price, perchè si creerebbe un’ambiguità sul nome della colonna nella query SQL. Si può superare questa ambiguità definendo esplicitamente il nome della tabella nel modello Product:

/app/models/product.rb

def self.cheaper_than(price) 
  where("products.price < ?", price)
end

Ora non c’è più alcun pericolo di ambiguità sul nome della colonna. Dovreste sempre specificare il nome della tabella quando usate stringhe SQL nelle condizioni di find. Comunque, se state usando un hash, come negli scope, non c’è bisogno di preoccuparsi del nome della tabella, dal momento che Rails lo aggiunge in automatico per noi.

Costruire record mediante named scope

La prossima cosa che vi mostriamo è il modo di costruire record usando i named scope. Abbiamo un named scope definito nella nostra classe di modello Product, chiamato discontinued, che trova tutti i prodotti dismessi:

> Product.discontinued
 => [#<Product id: 3, name: "Some DVD", price: 13.49, discontinued: true, category_id: 1, created_at: "2010-05-25 19:45:05", updated_at: "2010-05-25 19:45:05">]

Poichè il named scope usa un hash, possiamo chiamare il metodo build questo per costruire un nuovo prodotto con l’attributo discontinued già impostato a true:

> p = Product.discontinued.build
 => #<Product id: nil, name: nil, price: nil, discontinued: true, category_id: nil, created_at: nil, updated_at: nil>

Il nuovo prodotto così creato risulterà già dismesso in quanto questo attributo fa parte della condizione di where. Tutto ciò funziona in maniera simile ad una associazione, in quanto quando si chiama il metodo build sull’associazione, automaticamente viene impostata la foreign key associata a quel record. In questo caso, tuttavia, stiamo più semplicemente assegnando il valore agli attributi che sono inclusi nella condizione di where. Questa è una cosa utile da sapere se si ha la necessità di creare dei record che rispettino un determinato named scope.

Arel

Concludiamo questo episodio presentando Arel. Arel gestisce le query ActiveRecord dietro le quinte. Probabilmente non avrete molto spesso il bisogno di interfacciarvi direttamente con questo livello, ma è utile capire come il tutto funzioni e comprendere ciò di cui questo framework è capace, nel caso in cui ci sia mai il bisogno di doverlo usare direttamente.

Per accedere direttamente ad Arel in Rails 3, si può richiedere al modello una arel_table, per cui prendiamo l’arel_table per il modello Product dalla console e assegnamola ad una variabile:

> t = Product.arel_table

Questo oggetto è una rappresentazione della tabella dei prodotti. Possiamo avere accesso alle colonne nella tabella in questo modo:

>t[:price]
 => <Attribute price>

Possiamo chiamare metodi sugli attributi per eseguire delle condizioni di find. Per esempio, se vogliamo trovare tutti i prodotti che costano 2.99 euro, possiamo lanciare:

> t[:price].eq(2.99)
 => #<Arel::Predicates::Equality:0x1040dd9f0 @operand1=<Attribute price>, @operand2=2.99>

Questa istruzione restituisce un predicato che fondamentalmente è la condizione di find. Ci sono anche altri metodi che possiamo chiamare, come il metodo matches, che esegue una query di tipo LIKE. Come per le altre query, possiamo invocare il to_sql per vedere l’effettivo codice SQL prodotto dalla query.

> t[:name].matches('%lore').to_sql
 => "\"products\".\"name\" LIKE '%lore'"

Possiamo usare il metodo or per concatenare i predicati, per cui, per esempio, possiamo cercare i prodotti che costano 2.99 euro o che hanno un nome che termina per ‘lore’:

t[:price].eq(2.99).or(t[:name].matches('%lore'))

Questa istruzione restituirà una combinazione dei due predicati: possiamo vedere l’SQL prodotto chiamando to_sql come abbiamo fatto anche prima:

> t[:price].eq(2.99).or(t[:name].matches('%lore')).to_sql
 => "(\"products\".\"price\" = 2.99 OR \"products\".\"name\" LIKE '%lore')"

Possiamo passare i predicati come argomenti al metodo where di un oggetto ActiveRecord. Ciò significa che possiamo passare il predicato che abbiamo creato alla chiamata Product.where al fine di restituire tutti i prodotti il cui prezzo sia 2.99 euro, o il cui nome termini per ‘lore’:

>   Product.where(t[:price].eq(2.99).or(t[:name].matches('%lore')))
 => [#<Product id: 2, name: "Milk", price: 2.99, discontinued: nil, category_id: 2, created_at: "2010-05-24 21:02:38", updated_at: "2010-05-24 21:02:38">, #<Product id: 4, name: "Knight Lore", price: 2.99, discontinued: nil, category_id: nil, created_at: "2010-05-26 19:36:02", updated_at: "2010-05-26 19:36:02">]

Abbiamo solo dato uno sguardo rapido ad Arel in queste poche righe; Arel è in grado di fare molte più cose e ActiveRecord espone solo una piccola parte di queste. Ci sono una serie di plugin che sfruttano tutta la potenza di Arel e la rendono disonibile in una interfaccia più semplice, come ad esempio MetaWhere. Questo plugin da accesso ai metodi di Arel come il matches e l’eq dall’interno dell’hash delle condizioni, in questo modo:

Product.where(:price.eq => 2.99, :name.matches => '%lore')

Questo vi da molta più flessibilità sulla definizione dell’hash delle condizioni e vale la pena darci un’occhiata se avete la necessità di eseguire query più complesse sui vostri modelli.

A/B Testing con A/Bingo

Thu, 27 May 2010 15:33:12 +0000

L’ A/B testing, anche noto come split testing, è un grand metodo per testare versioni alternative di un’applicazione e capire quali di queste sia la più efficace. Di sotto è riportata la maschera di registrazione di una applicazione. In cima alla form c’è un paragrafo che spiega ciò che l’utente deve fare. Vogliamo determinare quanto sia efficace questo paragrafo nella persuasione degli utenti a registrarsi e possiamo farlo creando un A/B test.

Il modo in cui tutto ciò funziona è il seguente: ogni utente che visita la pagina vedrà o meno il parametro in cima alla pagina: possiamo usare l’A/B testing per determinare quale opzione porta ai migliori risultati. Per fare ciò abbiamo bisogno di un evento che, quando scatta, marchi l’opzione come vincente. In questo caso, l’evento sarà sollevato alla compilazione e conseguente submit della form.

Scegliere lo strumento di test opportuno

Ci sono una serie di diversi strumenti per l’A/B testing disponibili. Uno che potremmo usare è il Website Optimizerdi Google. Non è specifico di Rails, può essere usato con qualunque applicazione web, persino con siti web statici. Questo tool ci consente di fornire diversi URL per il sito o usare del JavaScript per tracciare le conversioni per voi. E’ una soluzione carina, ma se volete testare un’applicazione Rails, allora potreste voler usare qualcosa che magari si integri anche nell’applicazione stessa e che gestisca da sè il tracciamento dei comportamenti degli utenti.

Una delle soluzioni più popolari specifiche per Rails è Vanity. Questo strumento fornisce risultati meravigliosi ed è anche piuttosto completo a livello di funzionalità. Non lo tratteremo in questo episodio, ma lo faremo probabilmente in uno dei prossimi. Può risultare un po’ ostico da configurare, in quanto richiede un database Redis per ragioni di performance, ma vale la pena darci un’occhiata per vedere se fa al caso vostro.

Il plugin che invece useremo in questo episodio è A/Bingo. Ha un buon DSL per la definizione degli esperimenti ed è semplice da mettere su. L’applicazione su cui eseguiremo i test è scritta in Rails 2, per cui possiamo installare questo plugin eseguendo:

	script/plugin install git://git.bingocardcreator.com/abingo.git

dalla cartella della nostra applicazione. Quando termina l’esecuzione, dovremo generare una migrazione con:

  script/generate abingo_migration

e poi applicarla con:

	rake db:migrate

Questa migrazione genererà due nuove tabelle sul database: experiments e alternatives ed è in queste tabelle che verranno memorizzati i risultati dei nostri test.

In un ambiente di produzione è meglio configurare il caching di A/Bingo, ma in questo contesto possiamo saltare questa configurazione, visto che siamo in sviluppo.

Scrivere il primo test

Ora che abbiamo installato A/Bingo, possiamo scrivere il primo test. Vogliamo mostrare o meno il paragrafo in cima alla form di registrazione in modo tale che si veda per alcuni utenti, mentre per altri resti nascosto. Possiamo farlo usando il metodo ab_test:

/app/views/users/new.html.erb

<% title ("Sign up") %>

<% if ab_test "signup_intro" %>
<p>Complete the form below to create a new user account. You will then be able 
to create projects and tasks, and mark them as complete when finishing them.</p>
<% end %>
<p>Already have an account? <%= link_to "Log in", new_user_session_path %>.</p>

<% form_for @user do |form| %>
 <!-- form omitted -->
<% end %>

Il primo argomento passato al metodo ab_test è il nome del test, che in questo caso è “signup-intro”. Se non forniamo ulteriori argomenti, questo metodo restituirà in modo casuale true o false ai vari utenti che via via chiederanno la pagina, di conseguenza il paragrafo sarà mostrato o nascosto a second di chi carica la pagina.

Poi aggiungiamo un trigger di evento in modo tale che possiamo tracciare i risultati. Vogliamo che l’evento sia tracciato quando l’utente viene salvato con successo. Per questa ragione, modifichiamo la action create sul controller UsersController:

/app/controllers/users_controller.rb

def create
  @user = User.new(params[:user])
  if @user.save
    bingo! "signup_intro"
    session[:user_id] = @user.id
    flash[:notice] = "Thank you for signing up. You are now logged in."
    redirect_to root_url
  else
    render :action => 'new'
  end
end

Nell’action create tutto ciò che dobbiamo fare è chiamare il metodo bingo! e passargli il nome del test quando l’utente viene correttamente salvato.

Se ricarichiamo la pagina di registrazione ora, potremo vedere che per noi ab_test ha restituito false, per cui non vediamo il paragrafo in cima alla pagina. Possiamo provare a ricaricare la pagina nuovamente, ma il paragrafo continuerà ad essere nascosto, dal momento che la nostra identità viene ricordata (come, ve lo faremo vedere fra poco).

Se completiamo la compilazione della form e facciamo il submit, ci registreremo con successo e per questo scateneremo un evento.

Vedere i risultati

Al momento è difficile vedere i risultati del test, ma possiamo comunque farlo creando un controller per vederli. Per fare ciò, generiamo un controller che chiamiamo abingo_dashboard:

	script/generate controller abingo_dashboard

Dentro a questo controller dobbiamo includere il module dashboard di A/Bingo:

/app/controllers/abingo_dashboard_controller.rb

class AbingoDashboardController < ApplicationController
  # TODO aggiungere logica di autorizzazione.
  include Abingo::Controller::Dashboard
end

Ovviamente, se questa applicazione andasse in produzione, non vorremmo che chiunque potesse vedere la dashboard, per cui dovremmo implementare un qualche meccanismo di autorizzazione sul controller. Per ora comunque lasciamo solo un commento per ricordarcelo in futuro.

Dobbiamo anche aggiungere un nuovo instradamento in modo che possiamo accedere alla dashboard.

/config/routes.rb

	map.abingo_dashboard "/abingo/:action/:id", :controller => :abingo_dashboard

Sistemato tutto ciò, possiamo andare all’indirizzo http://localhost:3000/abingo e vedremo la dashboard:

Al momento non ci sono stili applicati alla dashboard, ma è abbastanza semplice cambiare il template della vista e darle uno stile per venire incontro all’aspetto del resto dell’applicazione. Con lo stile di default possiamo già vedere i resultati degli esperimenti, per cui non c’è bisogno di occuparsi degli stili per ora. Dando uno sguardo ai risultati, possiamo vedere che c’è un esperimento con un partecipante (si tratta della mia visita alla pagina di registrazione) ed una conversione che è avvenuta quando ho fatto correttamente il submit dei dati della form. Il paragrafo in cima alla form non era visibile all’atto della registrazione, per cui il participante e la conversione sono mostrati fra i risultati false (f).

Riconoscere gli utenti

Se rivisitassimo la form di registrazione nuovamente, continueremmo a non vedere il paragrafo sopra alla form, fintanto che A/Bingo saprà che la nostra identità è costante. Dobbiamo istruirlo per gestire le identità utente e dargli un modo per distinguere un utente da un altro. Tutto ciò viene fatto dentro l’application controller scrivendo un before_filter:

/app/controllers/application_controller.rb

# Filters added to this controller apply to all controllers in the application.
# Likewise, all the methods added will be available for all controllers.

class ApplicationController < ActionController::Base
  helper :all # include all helpers, all the time
  protect_from_forgery # See ActionController::RequestForgeryProtection for details
  before_filter :set_abingo_identity

  private
  def set_abingo_identity
    session[:abingo_identity] ||= rand(10 ** 10)
    Abingo.identity = session[:abingo_identity]
  end
end

Nell’application controller abbiamo aggiunto un before filter chiamato set_abingo_identity e nel metodo set_abingo_identity c’è il codice che determina l’identità di ogni utente. Il metodo controlla per prima cosa l’esistenza di una variabile di sessione chiamata abingo_identity e se non ne trova una, la crea con un valore numerico casuale. Ciò significa che, fintanto che gli utenti mantengono attive le loro sessioni, saranno sempre trattati allo stesso modo da A/Bingo e vedranno sempre la maschera come l’hanno vista la prima volta.

Se avessimo l’autenticazione nella nostra applicazione, vorremmo che la dipendenza fosse rispetto all’utenza piuttosto che alla sessione. Possiamo cambiare il metodo set_abingo_identity in modo che usi l’id univoco di utente se l’utente corrente è autenticato, ricadendo nella gestione basata su sessione per i soli utenti anonimi:

/app/controllers/application_controller.rb

def set_abingo_identity
  if current_user
    Abingo.identity = current_user.id
  else
    session[:abingo_identity] ||= rand(10 ** 10)
    Abingo.identity = session[:abingo_identity]
  end
end

Possiamo anche controllare per vedere se il sito è stato visitato da un web crawler o un bot e dare a ciascun bot la stessa identità, in modo tale che i risultati non siano falsati da questi visitatori non umani:

/app/controllers/application_controller.rb

def set_abingo_identity
  if request.user_agent =~ /\b(Baidu|Gigabot|Googlebot|libwww-perl|lwp-trivial|msnbot|SiteUptime|Slurp|WordPress|ZIBB|ZyBorg)\b/i
     Abingo.identity = "robot"
   elsif current_user
     Abingo.identity = current_user.id
   else
     session[:abingo_identity] ||= rand(10 ** 10)
     Abingo.identity = session[:abingo_identity]
   end
end

Identifichiamo i crawler e i bot confrontandone il loro user agent contro una lista di nomi noti corrispondenti a questo genere di navigatori e se riscontriamo un match impostiamo l’identità a “robot”. In questo modo tutti i bot che visitano la pagina saranno considerati come un unico utente.

Mentre scrivevo questa applicazione, ho visitato la pagina di registrazione con una serie di differenti identità portando a termine la registrazione un paio di volte. Questo mio comportamento è ora riflesso nella dashboard di A/Bingo. Ci sono ora infatti otto partecipanti, due dei quali che hanno visto il paragrafo nella pagina di registrazione e sei che non l’hanno visto:

Test più complessi

Concludiamo l’episodio mostrandovi come fornire più alternative per singolo test. Il test signup_into è un semplice test booleano, ma se volessimo fornire più di due diverse alternative, per esempio mostrando una serie di devrsi titoli di pagina, potremmo fare anche questo.

Vale la pena ricordarsi che avere test multipli su una singola pagina può incasinare i risultati, dal momento che questi possono derivare da quelle opzioni che vengono mostrate più frequentemente. Per un’applicazione di produzione tutto ciò è importante, ma dal momento che questa è solo un’applicazione di esempio, in realtà non conta molto.

Per creare un test con opzioni multiple, possiamo chiamare la ab_test con due argomenti, il secondo dei quali è un array delle diverse opzioni che vogliamo testare. Nello specifico, vogliamo testare tre diversi titoli di pagina. Possiamo cambiare la pagina per mostrarne uno dei tre, usando:

/app/views/users/new.html.erb

<% title ab_test("signup_title", ["Sign up", "Registration", "Free Sign up"]) %>

Messo a posto ciò, ogni utente che visiterà la pagina vedrà a caso uno di questi tre titoli. Questo è sufficientemente accettabile per qualcosa di semplice come il titolo di una pagina, ma se volessimo usare gli stessi valori casuali più di una volta sulla pagina, lo potremmo fare utilizzando il metodo ab_test con un blocco:

/app/views/users/new.html.erb

<% ab_test("signup_title", ["Sign up", "Registration", "Free Sign up"]) do |signup_title| %>
<% title signup_title %>
<% end %>

Provando questo codice, potreste vedere un errore che dice “can’t modify frozen array” nel caso in cui non si stia usando l’ultima versione di A/Bingo. Ryan Bates ha reso disponibile una patch per questo problema che sembra sia stata inclusa direttamente nel codice sorgente del progetto, per cui se vedete questo errore, provate a fare l’upgrade del plugin e a riprovare.

Visitando ora la pagina di registrazione, vedremo uno dei titoli relativi ad una delle tre opzioni e la pagina mostrerà o meno il paragrafo in testata. C’è ancora una cosa da sistemare, tuttavia. Anche se abbiamo configurato i test nella vista, non ne stiamo registrando i successi sul controller. Lo possiamo fare semplicemente aggiungendo un’altra chiamata a bingo! nella action create:

/app/controllers/users_controller.rb

def create
  @user = User.new(params[:user])
  if @user.save
    bingo! "signup_intro"
    bingo! "signup_title"
    session[:user_id] = @user.id
    flash[:notice] = "Thank you for signing up. You are now logged in."
    redirect_to root_url
  else
    render :action => 'new'
  end
end

Se abbiamo molti test in una determinata action, tutto ciò può, diventare poco manutenibile. Piuttosto, dunque, potremmo fare una sola chiamata a bingo!, col nome di una conversione e usare il nome di tale conversione come argomento extra da passare al metodo ab_test nella vista.

Per cui, possiamo sostituire nel controller le due invocazioni a bingo! con una sola:

/app/controllers/users_controller.rb

def create
  @user = User.new(params[:user])
  if @user.save
    bingo! "signup"
    session[:user_id] = @user.id
    flash[:notice] = "Thank you for signing up. You are now logged in."
    redirect_to root_url
  else
    render :action => 'new'
  end
end

Mentre nella vista possiamo passare il nome della conversione come parte di un hash di argomenti:

/app/views/users/new.html.erb

<% ab_test("signup_title", ["Sign up", "Registration", "Free Sign up"], :conversion => "signup") do |signup_title| %>
  <% title signup_title %>
<% end %>

<% if ab_test "signup_intro", nil, :conversion => "signup" %>
<!-- resto della vista -->

Si noti che, dal momento che il secondo test è un semplice booleano, gli abbiamo passato nil come secondo argomento.

E’ tutto per questo episodio. L’A/B testing fornisce un ottimo metodo per sperimentare versioni diverse di maschere in un’applicazione web e tracciare il tasso di successo dei risultati. Vi esorto a provarlo nelle vostre applicazioni, o usando Google Website Optimizer o Vanity o A/Bingo.

Calendari

Thu, 27 May 2010 15:28:30 +0000

Ogni volta che si gestiscono delle date in un’applicazione è spesso utile mettere a disposizione un calendario nell’interfaccia utente. Se l’utente deve infatti scegliere una data per un certo campo, sarà sicuramente più semplice per lui farlo da una popup che mostra un calendario, piuttosto che doverne inserire una scegliendo da una serie di tendine (giorno, mese e anno) o peggio ancora inserendo testualmente la data in un campo di testo. Può anche capitare che si abbia una tabella di modello nell’applicazione che abbia un campo data e che quindi serva un calendario per permettere di scegliere per data fra i record di tale tabella. Vi mostreremo in questo episodio come poter fare entrembe le cose.

L’applicazione con cui lavoreremo è una semplice applicazione di blogging che ha un certo numero di articoli a database, ma quasi tutte le applicazioni si aspettano che i campi di input per le date beneficino di questa funzionalità di selezione. Quando creiamo o modifichiamo un articolo, possiamo scegliere una data di pubblicazione usando un classico date picker di Rails. Cambieremo questo sistema per poter usare un calendario in popup come metodo alternativo per scegliere tale data.

I calendari sono complicati da creare e gestire da zero, ma per fortuna ci sono parecchie soluzioni di terze parti disponibili, che ci permetteranno di fare praticamente tutto ciò che vorremmo fare con i calendari e le date. Uno di questi è il plugin calendar_date_select. Questo plugin ci fornisce un metodo helper che funziona con le librerie Prototype e che invoca un calendario attraverso del JavaScript. Non useremo questo plugin, tuttavia, ma useremo piuttosto una soluzione diversa che fa uso di unobtrusive JavaScript e che si basa su jQuery. Non si tratta di una soluzione specifica per Rails, ma l’abbiamo comunque scelta in quanto fornisce un metodo facile da capire per aggiungere un calendario ad un campo di data.

La libreria jQuery UI fornisce un Datepicker che permette l’inclusione pulita di un calendario ad un qualunque campo di testo di una pagina. Quando il campo di testo ottiene il focus, o perchè viene selezionato con click, o perchè viene selezionato mediante tab da tastiera, una popup mostrante un calendario appare per consentire la selezione di una data. Una volta scelta in questo modo la data, il campo di testo si ritrova il valore selezionato impostato. Questo calendario può essere personalizzato mediante temi, usando il Themeroller di jQuery: in questo modo ci viene data la possibilità di scegliere l’aspetto che più ci piace. Se vogliamo ottenere rapidamente ciò che vogliamo, possiamo usare i file JavaScript e gli stili presenti sui server di Google per includere il codice jQueryUI ed uno dei temi di default. Dobbiamo solo referenziare i corretti file nella sezione HEAD della pagina di layout:

/app/views/layouts/application.html.erb

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
  <%= stylesheet_link_tag "http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/themes/redmond/jquery-ui.css", "application" %>
  <%= javascript_include_tag "http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js", "http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.1/jquery-ui.min.js", "application" %>
  <title><%= yield :title %></title>
</head>

Si noti che l’applicazione con cui lavoriamo qui è scritta in Rails 2. Se stessimo usando Rails 3, avremmo bisogno di aggiungere una versione compatibile con jQuery del file rails.js, come già trattato nell’episodio 205 [guardalo, leggilo].

Ora che abbiamo incluso le librerie jQuery e jQueryUI, possiamo cminciare a modificare la nostra applicazione per farla funzionare con il Datepicker. La prima cosa da fare è modificare il campo published_on nella form dell’articolo, in modo tale che usi un text_field al posto di un date_select:

/app/views/articles/_form.html.erb

<%= f.label :published_on %>
<%= f.text_field :published_on %>

Poi dobbiamo aggiungere un calendario in maniera non invasiva e lo possiamo fare aggiungendo del JavaScript al file application.js:

/public/javascripts/application.js

$(function (){
	$('#article_published_on').datepicker();
});

Questo codice eseguirà al termine del caricamento del DOM, aggiungendo un date-picker ad ogni elemento che abbia id ugauale a article_published_at. Se ricarichiamo la pagina di modifica dell’articoloe clicchiamo nel campo di testo published_on, vedremo la popup del calendario e potremo scegliere una data da quella popup:

Al submit della form, Rails interpreterà la data dal valore presente nel campo di testo e aggiornerà la data relativa al campo published_on nella tabella articles sul database.

Una vista calendario

Ora che abbiamo il nostro selettore di date funzionante, vediamo gli altri usi dei calendari di cui abbiamo discusso: fornire una vista basata su calendario degli articoli nella nostra appicazione. Questo potrebbe non essere il modo più efficiente di elencare gli articoli in un blog, ma lo forniremo comunque come modo alternativo per sfogliare gli articoli presenti.

Ci sono molteplici soluzioni a questo problema e trovare quella corretta dipende dalle necessità dell’applicazione. Se c’è bisogno di mostrare dei record che si sviluppano su più giorni, allora ha senso dare un’occhiata al plugin event_calendar che può mostrare eventi che spaziano su di un range di date. Se tale funzionalità non è richiesta, una buona alternativa è il plugin table_builder. Questo plugin offre un metodo helper chiamato calendar_for che rende semplice raggruppare un dato insieme di record in giorni su di un calendario. Quest’ultimo corrisponde meglio ai nostri bisogni, per cui lo useremo nella nostra applicazione.

Possiamo installare table_builder lanciando il seguente comando:

script/plugin install git://github.com/p8/table_builder.git

Dopo che si sarà installato, potremo cominciare a lavorare sulla nostra vista a calendario cambiando la vista index nel nostro controller degli articoli. Attualmente appare così:

/app/views/articles/index.html.erb

<% title "Articles" %>
<div id="articles">
<% @articles.each do |article| %>
  <h2>
    <%= link_to h(article.title), article %>
    <span class="comments">(<%= pluralize(article.comments.count, 'comment') %>)</span>
  </h2>
  <div class="author">from <%=h article.author %> on <%= article.written_date.strftime('%b %d, %Y') %></div>
  <div class="content"><%= h(article.content) %></div>
<% end %>
</div>
<p><%= link_to "New Article", new_article_path %></p>

Sostituiremo il codice che itera su ogni articolo e lo mostreremo con una chiamata al metodo calendar_for per mostrare gli articoli in una vista a calendario:

/app/views/articles/index.html.erb

<% title "Articles" %>

<div id="calendar">
  <% calendar_for @articles do |calendar| %>
    <% calendar.day(:day_method => :published_on) do |date, articles| %>
      <%= date.day %>
    <% end %>
  <% end %>
</div>

Chiamiamo il calendar_for passandogli la nostra collezione di articoli. Il blocco viene eseguito una volta e accetta un oggetto di tipo calendar, per cui possiamo chiamare il calendar.day per iterare su ogni giorno. Dobbiamo specificare una property dell’articolo che restituisca una data, per poter raggruppare gli articoli per giorno, per cui gli passiamo un parametro :day_method col valore di :published_on. Il blocco in questione ha due parameteri: una data e una lista di articoli che sono stati pubblicati per giorno. Possiamo mettere il codice che ci pare dentro a questo blocco, ma per ora restituiremo semplicemente in output il giorno del mese:

Se ricarichiamo la pagina ora, non vedremo una lista di articoli, quanto piuttosto una lista di date che assomigliano un po’ ad un calendario:

Non sembra ancora molto carino, ma possiamo aggiungere un po’ di CSS per migliorarne l’aspetto:

Possiamo migliorare l’usabilità del calendario, aggiungendo i nomi dei giorni in testata, usando il metodo calendar.head:

/app/views/articles/index.html.erb

<% title "Articles" %>

<div id="calendar">
  <% calendar_for @articles do |calendar| %>
    <%= calendar.head('Sunday', 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday')%>
    <% calendar.day(:day_method => :published_on) do |date, articles| %>
      <%= date.day %>
    <% end %>
  <% end %>
</div>

Quando ricarichiamo la pagina nuovamente, i giorni della settimana saranno stati aggiunti in cima al calendario:

Così com’è, il nostro calendario può solo mostrare delle date del mese corrente, per cui il prossimo passo sarà di aggiungere un seletore del mese che mostri il mese corrente e che abbia dei link su entrambi i lati per permetterci di cambiare il mese mostrato.

Per fare questo, partiamo dalla action index del controller degli articoli, dove creeremo una variabile che manterrà la data del mese che vogliamo sia mostrata. Per ora impostiamo semplicemente la data di oggi:

/app/controllers/articles_controller.rb

def index
  @articles = Article.all
  @date = Date.today
end

Poi modifichiamo la vista in modo tale che siano mostrati il mese e i link:

/app/controllers/articles_controller.rb

<% title "Articles" %>

<div id="calendar">
  <h2 id="month">
    <%= link_to "<", :month => (@date.beginning_of_month-1).strftime("%Y-%m-01") %>
    <%= h @date.strftime("%B %Y") %>
    <%= link_to ">", :month => (@date.end_of_month+1).strftime("%Y-%m-01") %>
  </h2>
  <% calendar_for @articles, :year => @date.year, :month => @date.month do |calendar| %>
    <%= calendar.head('Sunday', 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday') %>
    <% calendar.day(:day_method => :published_on) do |date, articles| %>
      <%= date.day %>
    <% end %>
  <% end %>
</div>

I link puntano entrambi alla action index che è mostrata attualmente, ma con l’aggiunta di un parametro alla stringa di query, chiamato month, che indica il mese precedente o il mese successivo. Ora possiamo ritornare al codice del controller, controllare l’esistenza di quel parametro month e usarlo per impostare il valore della variabile @date se esiste:

/app/controllers/articles_controller.rb

def index
  @articles = Article.all
  @date = params[:month] ? Date.parse(params[:month]) : Date.today
end

Al ricaricamento della pagina, vedremo il nome del mese sopra il calendario e le freccie su entrambi i lati di questo, che ci permetteranno di scorrere fra i vari mesi:

La nostra vista a calendario ora appare carina, ma non mostra gli articoli che ci sono per un dato giorno. Abbiamo già accesso agli articoli di un determinato giorno nel blocco calendar.head, per cui possiamo iterare attraverso questa collection e mettere un link per ciascun articolo di quel giorno in una lista:

/app/views/articles/index.html.erb

<% calendar_for @articles, :year => @date.year, :month => @date.month do |calendar| %>
  <%= calendar.head('Sunday', 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday')%>
  <% calendar.day(:day_method => :published_on) do |date, articles| %>
    <%= date.day %>
    <ul>
      <% for article in articles %>
        <li><%= link_to h(article.title), article %></li>
      <% end %>
    </ul>
  <% end %>
<% end %>

Quando ricarichiamo la pagina un’ultima volta, vedremo elencati gli articoli per ciascun giorno e potremo cliccare su ciascuno per essere portati al dettaglio di quell’articolo:

Per questo episodio è tutto. Come abbiamo mostrato, è semplice usare i calendari per scegliere date o per mostrare una lista di record a seconda di una determinata property di tipo data. Siete invitati a considerare l’utilizzo di una vista a calendario tipo questa ogni volta che possa rivelarsi utile rispetto ai dati delle vostre applicazioni.

Refactoring e Dynamic Delegator

Thu, 27 May 2010 15:23:21 +0000

L’episodio di questa settimana è un po’ diverso dal solito. E’ un esercizio di refactoring che ci consentirà di scoprire una simpatica tecnica Ruby che chiameremo Dynamic Delegator.

Per mostrarvi il tutto, ci avvarremo di una semplice applicazione di negozio on-line che ha un modello Product con associato un ProductsController. La action del controller index permette che la lista di prodotti sia filtrata per nome o per prezzo. Fornendo uno o più parametri fra name, price_lt e price_gt alla stringa di query, possiamo cercare prodotti che corrispondano a tali criteri di ricerca, per trovare, ad esempio, i soli prodotti il cui nome contenga “video” e che costino più di £50:

Prima di iniziare il il refactoring della action index, diamo un’occhiata a ciò che fa attualmente:

/app/controllers/products_controller.rb

class ProductsController < ApplicationController
  def index
    @products = Product.scoped
    @products = @products.where("name like ?", "%" + params[:name] + "%") if params[:name]
    @products = @products.where("price >= ?", params[:price_gt]) if params[:price_gt]
    @products = @products.where("price <= ?", params[:price_lt]) if params[:price_lt]
  end

  # Altre action
end

Si tratta di un’applicazione Rails 3, dunque si usa il metodo where per aggiungere condizioni alla query se è stato passato il parametro corrispondente. Prima di fare ciò, tuttavia, usiamo Product.scoped per ottenere l’insieme di tutti i prodotti. Potreste non conoscere ancora questo metodo, ma essenzialmente è un ulteriore modo per dire Product.all. La differenza rispetto al primo è che il metodo all determina istantaneamente una query sul database, restituendo un array di prodotti. Siccome non vogliamo intraprendere una chiamata al database fintanto che non abbiamo applicato i nostri filtri, allora usiamo il metodo scoped al posto di all, che ci permette di aggiungere condizioni alla query prima che questa sia eseguita.

Ora pensiamo al refactoring dell’action. Il primo passo che faremo sarà di rimuovere parte della logica dal controller, dal momento che quello non è il posto più indicato per quel genere di codice. In qualunque linguaggio object-orientated, se siete nella situazione in cui un oggetto di un certo tipo sta chiamando molti metodi su un altro oggetto di un altro tipo, probabilmente significa che dovreste spostare tutte quelle chiamate e quella logica all’interno di un metodo dell’altro oggetto. In questo caso,nella action index della classe di ProductController, stiamo chiamando ben quattro metodi della classe di modello Product per creare la nostra query e ciò ci suggerisce che questo codice debba appartenere al modello stesso piuttosto che al controller.

Sostituiamo dunque il codice all’interno della action index con una chiamata al nuovo metodo di classe nel modello Product chiamato search, a cui passiamo un hash params in modo che quest’ultimo sappia su cosa deve essere fatta la query.

/app/controllers/products_controller.rb

class ProductsController < ApplicationController
  def index
    @products = Product.search(params)
  end

  # Altre actions
end

Poi definiamo il metodo in questione nella classe Product. Il metodo deve essere di classe, per cui lo definiamo come self.search. Il codice nel metodo sarà lo stesso che avevamo prima all’interno del controller, ma con una variabile locale (products) che sostituisce la variabile di istanza che avevamo prima: questa variabile è restituita alla fine del metodo:

/app/models/product.rb

class Product < ActiveRecord::Base
  belongs_to :category
  
  def self.search(params)
    products = scoped
    products = products.where("name like ?", "%" + params[:name] + "%") if params[:name]
    products = products.where("price >= ?", params[:price_gt]) if params[:price_gt]
    products = products.where("price <= ?", params[:price_lt]) if params[:price_lt]    
    products
  end 

end

Se ora ricarichiamo la pagina, vedremo che funziona tutto esattamente come prima.

Naturalmente, ricaricando la pagina abbiamo solo constatato che le modifiche al codice funzionano per quegli specifici parametri; è solo in scenari di sviluppo Test-Driven che si può veramente avere una riprova effettiva del corretto funzionamento della pagina post-refactoring. Ricaricare la pagina diventa rapidamente piuttosto tedioso e non controlla comunque ogni ramo del codice dal momento che la query di ricerca è costruita in modo diverso a seconda dei parametri che vengono passati. E’ una buona idea, specialmente quando si fa del refactoring sul codice, quella di mettere su un sistema di test per assicurarsi di non introdurre regressioni con le modifiche.

Spostare questo codice nel modello presenta l’ulteriore beneficio di rendere più semplice anche il test, dal momento che dovremmo solo scrivere un test unitario sulla classe di modello, anzichè un test completo sull’intero stack.

Introduzione al Dynamic Delegator

Abbiamo un po’ rivisto il codice spostando la logica di ricerca nel modello ed ora andremo oltre, togliendo la necessità di reimpostare la variabile products ogni volta che aggiungiamo una condizione di ricerca. E’ un pattern ricorrente quando si tratta con le opzioni di ricerca e se ne vedete molti nella vostra applicazione, potreste considerare la tecnica che vi stiamo per mostrare, che abbiamo chiamato dynamic delegator.

Piuttosto che spiegare come funziona un dynamic delegator, ve lo mostreremo usandone uno per il refactoring del nostro codice di ricerca. Cominciamo creando la classe del dynamic delegator nella cartella /lib della nostra applicazione:

/lib/dynamic_delegator.rb

class DynamicDelegator
  def initialize(target)
    @target = target
  end  
  
  def method_missing(*args, &block)
    @target.send(*args, &block)
  end
end

La classe DynamicDelegator accetta un argomento nel suo costruttore, un oggetto target, e imposta una variabile di istanza a quell’oggetto. Fa anche l’override del metodo method_missing, in modo tale che qualsiasi chiamata a questo oggetto che non sia supportata sia catturata e passata all’oggetto insieme allo stesso blocco e argomenti.

Possiamo pensare al nostro DynamicDelegator come ad un oggetto proxy che passa ogni chiamata al proprio oggetto target: questo significa che possiamo usarlo ovunque vogliamo al posto dell’oggetto target. Se lo creiamo su un certo oggetto target, si comporterà come se fosse quel tipo di oggetto. Ciò significa che possiamo sostituire l’oggetto scoped nel nostro metodo di ricerca di Product con un nuovo DynamicDelegator che prenda quell’oggetto come argomento:

/app/models/product.rb

class Product < ActiveRecord::Base
  belongs_to :category
  
  def self.search(params)
    products = DynamicDelegator(scoped)
    products = products.where("name like ?", "%" + params[:name] + "%") if params[:name]
    products = products.where("price >= ?", params[:price_gt]) if params[:price_gt]
    products = products.where("price <= ?", params[:price_lt]) if params[:price_lt]    
    products
  end 

end

Possiamo verificare che tutto ciò funzione, ricaricando nuovamente la pagina: dovremmo vedere lo stesso insieme di risultati.

Ha funzionato, ma a questo punto vi starete probabilmente domandando quale sia il vantaggio nell’usare un DynamicDelegator al posto dell’oggetto originale scoped. Il vantaggio del delegator è che possiamo fare qualsiasi cosa vogliamo all’interno del metodo method_missing. Anzichè delegare sempre passivamente la stessa cosa all’oggetto target, possiamo modificare il nostro target e renderlo più dinamico.

Per esempio, vogliamo catturare il risultato della chiamata al metodo method_missing e, se restituisce un oggetto della stessa classe del target, impostare il target stesso come il risultato:

/lib/dynamic_delegator.rb

class DynamicDelegator
  def initialize(target)
    @target = target
  end  
  
  def method_missing(*args, &block)
    result = @target.send(*args, &block)
    @target = result if result.kind_of? @target.class
    result
  end
end

Ora possiamo rimuovere il codice che resetta la variabile products in ogni linea del metodo search nel modello Product:

/app/models/product.rb

class Product < ActiveRecord::Base
  belongs_to :category
  
  def self.search(params)
    products = DynamicDelegator.new(scoped)
    products.where("name like ?", "%" + params[:name] + "%") if params[:name]
    products.where("price >= ?", params[:price_gt]) if params[:price_gt]
    products.where("price <= ?", params[:price_lt]) if params[:price_lt]    
    products
  end 

end

Possiamo farlo perchè la chiamata alla where restituirà lo stesso tipo di oggetto dello scoped e in questo modo il target verrà sostituito ogni volta. Ricarichiamo di nuovo la pagina e vediamo se funziona ancora tutto:

Non funziona più, e la ragione è che non stiamo delegando esattamente tutti i metodo dell’oggetto target. In questo caso la fonte dei problemi è il metodo class: possiamo usare la console per mostrare il perchè. Se chiamiamo Product.search con un hash vuoto e chiamiamo class sul risultato, vedremo che questo è di tipo DynamicDelegator:

ruby-head > Product.search({}).class
 => DynamicDelegator

Ciò indica che il nostro dynamic delegator non sta delegando tutto all’oggetto target dal momento che ha alcuni metodi già definiti di per sè. Il motivo per cui ce li ha, è dovuto semplicemente al fatto che la classa DynamicDelegator li eredita da Object e Object ha molti metodi definiti al suo interno, incluso class:

ruby-head > Object.instance_methods.count
 => 108 
ruby-head > Object.instance_methods.grep /class/
 => [:subclasses_of, :class_eval, :class, :singleton_class]

Se abbiamo bisogno di una classe più semplice da cui derivare, da Ruby 1.9 esiste un’altra classe che possiamo usare, chiamata BasicObject, che ha definiti molti meno metodi:

ruby-head > BasicObject.instance_methods
 => [:==, :equal?, :!, :!=, :instance_eval, :instance_exec, :__send__]

Questo tipo di classe serve meglio a fare da base per un oggetto delegator o un proxy che si basano sul method_missing per ridefinire il comportamento dei metodi. Possiamo cambiare il DynamicDelegator per estendere da BasicObject in modo tale che il metodo class non sia ereditato (perchè non definito nell’ancestor) e di conseguenza la chiamata a tale metodo sia ricondotta alla gestione mediante method_missing e quindi delegata effettivamente al target object:

/lib/dynamic_delegator.rb

class DynamicDelegator < BasicObject
  def initialize(target)
    @target = target
  end  
  
  def method_missing(*args, &block)
    result = @target.send(*args, &block)
    @target = result if result.kind_of? @target.class
    result
  end
end

Se ora ricarichiamo la pagina, funzionerà nuovamente tutto.

C’è un altro po’ di refactoring che potremmo considerare di fare nella classe di modello Product. Il DynamicDelegator non esprime le proprie intenzioni in modo molto chiaro, per cui potremmo scrivere un metodo nella classe Product, chiamato scope_builder e creare lì il DynamicDelegator:

/app/models/product.rb

class Product < ActiveRecord::Base
  belongs_to :category
  
  def self.search(params)
    products = scope_builder
    products.where("name like ?", "%" + params[:name] + "%") if params[:name]
    products.where("price >= ?", params[:price_gt]) if params[:price_gt]
    products.where("price <= ?", params[:price_lt]) if params[:price_lt]    
    products
  end 
  
  def self.scope_builder
    DynamicDelegator.new(scoped)
  end

end

Ora è più chiaro capire che stiamo trattando con uno scope che abbiamo costruito dinamicamente. Se usiamo questa tecnica su più modelli di record, allora potremmo fattorizzare questo metodo scope_builder in ActiveRecord::Base, in modo tale da averlo disponibile su tutti i modelli. Quest’ultima cosa la potremmo realizzare propriamente in un initializer.