ASCIIcasts - Full Episode Feed

Eredietarità dei template

Tue, 21 Jun 2011 18:30:46 +0000

Una delle nuove features di Rails 3.1 è l’eredietarità dei template. Questa non rivoluzionerà il modo in cui scrivi le tue views, ma può risultare molto utile e in questo episodio ti mostreremo come funziona.

In questo episodio abbiamo una applicazione con lo stesso menu di navigazione in ogni pagina.

Il menu di navigazione è al momento definito nel file di layout dell’applicazione dentro un elemento div con id uguale a side ed è statico.

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

<!DOCTYPE html>
<html>
<head>
  <title>Store</title>
  <%= stylesheet_link_tag "application" %>
  <%= javascript_include_tag "application" %>
  <%= csrf_meta_tags %>
</head>
<body>
  <div id="container">

    <% flash.each do |name, msg| %>
      <%= content_tag :div, msg, :id => "flash_#{name}" %>
    <% end %>

    <div id="side">
      <strong>Pages</strong>
      <ul>
        <li><%= link_to "Home", root_path %></li>
        <li><%= link_to "Products", products_path %></li>
      </ul>
    </div>

    <%= yield %>

    <div class="clear"></div>
  </div>
</body>
</html>

Vogliamo personalizzare il menù in maniera tale cha cambi in base all’attuale controller . Esistono diversi modi per fare questo e noi useremo l’ereditarietà dei template. Per prima cosa spostiamo il menù in un partial chiamato “side”.

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

<div id="side">
  <%= render "side" %>
</div>

Dove dovremmo mettere questo partial in modo tale che qualunque controller possa usarlo? Potremmo metterlo dentro la cartella views/shared oppure dentro layouts ma in Rails 3.1 possiamo salvarlo invece dentro views/application. Questa cartella non esiste di default con Rails 3, dobbiamo quindi crearla.

/app/views/application/_side.html.erb

<strong>Pages</strong>
<ul>
  <li><%= link_to "Home", root_path %></li>
  <li><%= link_to "Products", products_path %></li>
</ul>

Il partial side può ora essere utilizzato da tutti i controller perchè l’ereditarietà delle views funziona allo stesso modo di quella dei controller. Tutti i controller ereditano da ApplicationController quindi tutti i template che si trovano nella cartella application saranno ereditati.

Se adesso carichiamo una delle pagine della nostra applicazione il menu di navigazione funziona come prima.

Abbiamo adesso un partial che possiamo facilmente sovrascrivere in qualunque controller. Per fare questo bisogna creare un file chiamato _side.html.erb nella cartella views del controller in questione. Faremo questo per ProductsController, creando un partial contenente un link in più.

/app/views/products/_side.html.erb

<strong>Pages</strong>
<ul>
  <li><%= link_to "Home", root_path %></li>
  <li><%= link_to "Products", products_path %></li>
  <li><%= link_to "Manage Products", admin_products_path %></li>
</ul>

Caricando qualunque pagina del ProductsController il nuovo link sarà visibile, mentre tutti gli altri controller continueranno ad usare il menù di default.

Abbiamo adesso un posto dove salvare i templates che saranno condivisi da tutti i controller e possiamo sovrascrivere ciascuno di essi creando un template con lo stesso nome nella cartella views del controller desiderato.

Questo approccio funziona anche con controller annidati. La nostra applicazione ha diversi controller sotto il namespace Admin, ciascuno dei quali eredita da BaseController.

/app/controllers/admin/base_controller.rb

module Admin
  class BaseController < ApplicationController
  end
end

Possiamo sovrascrivere anche i templates che si trovano in Base view. Se clicchiamo il link “Manage Products” nella pagina di sopra ci sposteremo nella pagina /admin/products e il menù di navigazione sarà di nuovo quello di default. Cosa dovremmo fare se volessimo sovrascrivere il menù per tutte le pagine di amministrazione?

Dentro /app/views/admin troviamo la cartella base. Possiamo salvare dei templates qui e questi saranno automaticamente ereditati dagli altri controller. Faremo questo aggiungendo un link per distinguere questo template dagli altri.

/app/views/admin/base/_side.html.erb

<strong>Pages</strong>
<ul>
  <li><%= link_to "Home", root_path %></li>
  <li><%= link_to "Products", products_path %></li>
  <li><%= link_to "Manage Products", admin_products_path %></li>
  <li><%= link_to "Manage Categories", admin_categories_path %></li>
</ul>

Se ricarichiamo la pagina admin/products vedremo applicato il template dalla cartella base.

Questo template sarà utilizzato in tutte le pagine del namespace Admin poichè queste ereditano dal BaseController del namespace Admin.

L’ereditarietà dei template funziona non solo per i partial ma per qualunque template view. Nella cartella app/views/admin c’è un template edit.html.erb per entrambe le cartelle categories e products. Entrambe contengono lo stesso codice.

/app/views/admin/categories/edit.html.erb

<h1>Edit</h1>

<%= render 'form' %>

Se spostiamo uno di questi template nella cartella base e rimuoviamo l’altro, entrambi i controller erediteranno dallo stesso. Entrambe le pagine funzionano nella stessa maniera di prima. Questo è molto utile nel caso in cui la nostra applicazione contiene molte pagine di amministrazione. Di solito queste pagine hanno molte cose in comune e usando questa tecnica possiamo astrarre i templates in un controller di base e sovrascriverli se necessario.

E siccome stiamo parlando di come è possibile sovrascrivere templates, ti mostreremo un altro trucco che ti permette di personalizzare templates in base a dei parametri. Ammettiamo che vogliamo fornire una versione mobile del sito usando il sottodominio mobile. Potremmo cambiare le views in base al sottodominio e analizzando l’url. Questa feature non è nuova in Rails 3.1 e funziona anche in Rails 2 ma siccome si sposa bene con l’argomento ne parleremo adesso.

Nei controller dell’applicazione abbiamo qualcosa chiamato view paths. Se chiamiamo controller.view_paths in una view possiamo vedere quale sia il cammino per le views di quel controller.

/app/views/admin/base/edit.html.erb

<h1>Edit</h1>

<%= render 'form' %>

<%= controller.view_paths %>

Se ricarichiamo la pagina troveremo la lista delle view_paths. (Per facilitare l’uso di sottodomini stiamo usando Pow web server durante lo sviluppo della nostra applicazione.)

Questo controller ha una view path di default ma possiamo aggiungerne altre. Un modo per aggiungerne una è usare un before_filter nel nostro ApplicationController.

/app/controllers/application_controller.rb

class ApplicationController < ActionController::Base
  protect_from_forgery
  before_filter :subdomain_view_path
  
  def subdomain_view_path
    if request.subdomain.present?
      prepend_view_path "app/views/#{request.subdomain}_subdomain"
    end
  end  
end

Nel metodo before_filter abbiamo usato prepend_view_path per aggiungere una nuova view path in base al sottodominio della richiesta, se questo è presente. Possiamo vedere la nuova view path ricaricando la pagina.

Il sottodominio mobile viene adesso incluso nella lista delle view_paths. Se rimuoviamo il sottodominio mobile dall’ URL di sopra e ricarichiamo la pagina, questo scomparirà anche dalla lista delle view_paths. Questo trucco può essere usato per personalizzare le views in base al sottodominio. Se creiamo una nuova cartella sotto views e la chiamiamo mobile_subdomain possiamo aggiungervi view templates che sovrascrivono i template di default. Creeremo un nuovo index.html.erb template dentro la nuova cartella products e questo template sarà usato solo in questa pagina quando il sottodominio mobile viene visitato.

/app/views/mobile_subdomain/products/index.html

<h1>mobile version</h1>

Se rimuoviamo il sottodominio vedremo di nuovo la version di default.

Tuttavia quando aggiungiamo il sottodominio il nuovo template viene utilizzato sovrascrivendo quello di default.

Questo è tutto per questo episodio su come sovrascrivere i template, sia nel caso in cui sia fatto con l’ereditarietà che in quello in cui il cammino della richiesta venga analizzato. Entrambi i metodi forniscono molte possibilitè di personalizzazione e diversi metodi per astrarre views e sovrascriverle. Se hai bisogno di ancora più personalizzazione puoi creare un view resolver ma parleremo di questo in un altro episodio.

Concetti base in SASS

Tue, 28 Jun 2011 18:19:53 +0000

Uno dei maggiori cambiamenti con il nuovo Rails 3.1 è il supporto per SASS, il quale rappresenta la soluzione di default per generare CSS. Grazie a concetti come annidamento, variabili e molto altro ancora, gestire lo stile della vostra applicazione diventa molto più semplice. Per dimostrare i vantaggi che comporta usare SASS, in questo episodio mostreremo come tradurre il CSS di una applicazione esistente in SASS.

Il sito su cui lavoreremo si presenta così:

Tutto lo stile è realizzato utilizzando CSS, il nostro obiettivo è mantenere lo stesso stile una volta finita la migrazione. Questo è il file su cui lavoreremo:

/app/assets/stylesheets/layout.css

body {
  margin: 0;
  padding: 0;
  background-color: #FFF;
  font-family: verdana;
  font-size: 14px;
}

#header {
  background-color: #03507B;
  color: #FFF;
  padding: 4px 100px;
  border-bottom: solid 5px #00395A;
}

#header h1 {
  font-size: 30px;
}

a {
  color: #03507B;
  text-decoration: none;
}

a:hover {
  text-decoration: underline;
}

.new_project {
  background-color: #03507B;
  color: #FFF;
  padding: 5px 12px;
  margin: 10px 0;
  font-size: 16px;
  border-radius: 5px;
  -moz-border-radius: 5px;
  -webkit-border-radius: 5px;
}
#container { 
  margin: 0 100px; 
}

.project {
  border: solid 1px #777;
  margin: 20px 0;
  padding: 7px 12px;
  border-radius: 10px;
  -moz-border-radius: 10px;
  -webkit-border-radius: 10px;
}

.project h2 { 
  margin: 0; 
}

Questo file è abbastanza semplice quindi il nostro compito non dovrebbe essere molto difficile.Per prima cosa bisogna rinominare il file aggiungendo l'estensione .scss. Standard CSS è completamente compatibile con SASS quindi ricaricando il browser tutto dovrebbe essere rimasto invariato.

Il nostro sito usa già SASS, ma ovviamente non è tutto qui. È comunque ottimo il fatto che CSS è completamente supportato poichè questo ci permette di scegliere solo le funzionalità che ci interessano. Se abbiamo un sito con un gran numero di CSS già esistenti possiamo rinominarli e modificarli quando e come vogliamo. Ma considerando quello che vi stiamo per mostrare probabilmente vorrette usare tutto immediatemente.

Annidamento

La prima funzionalità che useremo è annidiamento. Guarda questo codice CSS:

/app/assets/stylesheets/layout.css.sass

#header {
  background-color: #03507B;
  color: #FFF;
  padding: 4px 100px;
  border-bottom: solid 5px #00395A;
}

#header h1 { 
  font-size: 30px; 
}

Questo codice definisce lo stile per un element con id uguale a header e per ogni elemento h1 in esso contenuto. Con SASS possiamo annidare lo stile per h1 dentro quello per #header così:

/app/assets/stylesheets/layout.css.sass

#header {
  background-color: #03507B;
  color: #FFF;
  padding: 4px 100px;
  border-bottom: solid 5px #00395A;

	h1 { 
		font-size: 30px; 
	}
}

Quindi non abbiamo più bisogno di specificare il prefisso per elementi interni e siamo anche incoraggiati a mantenere compatto lo stile per elementi annidati. Può risultare semplice abusare di questa funzionalità introducento annidamenti lunghi e complessi ma è meglio invece mantenere il nostro annidamento semplice. In questa maniera basterà un'occhiata per capire cosa è dentro cosa. Questa non è comunque una regola e puoi trovare e usare il livello di annidamento che si adatta meglio ai tuoi gusti.

Possiamo anche usare annidimento auto-referenziale. Nel CSS abbiamo un selector per a ed uno per a:hover.

/app/assets/stylesheets/layout.css.sass

a {
  color: #03507B;
  text-decoration: none;
}

a:hover { 
  text-decoration: underline;
}

Poichè a:hover non è un vero e proprio elemento annidato dobbiamo aggiungere una & al padre.

/app/assets/stylesheets/layout.css.sass

a {
  color: #03507B;
  text-decoration: none;

  &:hover { 
   text-decoration: underline;
  }
}

La & è necessaria perchè stiamo applicando stile a un attributo e non ad un vero e proprio elemento.

Variabili

Un' altra funzionalità veramente utile è data dalla possibilità di definire variabili. Nel nostro file CSS usiamo lo stesso colore in posti diversi. Se volessimo cambiarlo dovremmo modificare tutte le sue occorrenze.

SASS rende questo facile permettendoci di definire variabili. Il nome di una variabile deve cominciare con il simbolo dollaro. Definiremo quindi la nostra variabile così:

$main-color: #03507B;

Possiamo adesso sostituire tutte le occorrenze del colore con la variabile:

/app/assets/stylesheets/layout.css.sass

$main-color: #03507B;

#header {
  background-color: $main-color;
  color: #FFF;
  padding: 4px 100px;
  border-bottom: solid 5px #00395A;

	h1 { 
		font-size: 30px; 
	}
}

a {
  color: $main-color;
  text-decoration: none;

  &:hover { 
   text-decoration: underline;
  }
}

Se ricarichiamo la nostra pagina tutto è rimasto lo stesso. Se adesso volessimo cambiare il colore, basta modificare il valore della variabile per passare da blu a verde.

/app/assets/stylesheets/layout.css.sass

$main-color: #1E7B12;

Quando ricarichiamo la pagina tutti gli stili che usano quel colore sono adesso cambiati: lo sfondo dell'header, i link ed il bottone “New Project” sono adesso verdi.Tutto questo è stato possibile con un singolo cambiamento nel foglio di stile.

Il bordo in basso all'header è ancora blu scuro ma vogliamo che abbia una tonalità più scura dell'header stesso. SASS ci permette di definire colori relativi usando delle funzioni. Sul sito di SASS possiamo trovare la completa lista delle funzioni disponibili, la quale include una funzione darken che fa esattamente quello di cui abbiamo bisogno. Passando un colore e una percentuale come parametri otterremo un colore più scuro come risultato.

Il colore del bordo in basso è definito nella dichiarazione per #header.

/app/assets/stylesheets/layout.css.sass

#header {
  background-color: $main-color;
  color: #FFF;
  padding: 4px 100px;
  border-bottom: solid 5px #00395A;

	h1 { 
		font-size: 30px; 
	}
}

Possiamo sostituirlo con una chiamata a darken in maniera tale che il bordo abbia lo stesso colore dell'header ma più scuro del 10%.

/app/assets/stylesheets/layout.css.sass

#header {
  background-color: $main-color;
  color: #FFF;
  padding: 4px 100px;
  border-bottom: solid 5px darken($main-color, 10%);

	h1 { 
		font-size: 30px; 
	}
}

Ricaricando la pagina il colore del bordo è adesso un verde scuro.

Mix-ins

Mix-ins sono un'altra feature di SASS che ci aiuta a ridurre la duplicazione. Nel nostro CCS ci sono due elementi che hanno il bordo arrotondato. Poiche' ogni vendor ha delle specifiche diverse, risulta essere più difficile del previsto ottenere dei bordi arrotondati che funzionino su tutti i browser.

border-radius: 5px;
-moz-border-radius: 5px;
-webkit-border-radius: 5px;

Spostando questo codice in un mix-in, risulterà molto più semplice aggiungere la dichiarazione per dei bordi arrotondati. Un mix-in viene definito usando la parola chiave @mixin e il nome che verrà poi usato per referenziarlo.

/app/assets/stylesheets/layout.css.sass

@mixin rounded-corners {
  border-radius: 5px;
  -moz-border-radius: 5px;
  -webkit-border-radius: 5px;
}

Possiamo adesso applicare il bordo arrotondato ovunque vogliamo chiamando @include.

/app/assets/stylesheets/layout.css.sass

.new_project {
  background-color: $main-color;
  color: #FFF;
  padding: 5px 12px;
  margin: 10px 0;
  font-size: 16px;
  @include rounded-corners;
}

Per ottenere un border-radius contenente un valore diverso potremmo definire un altro mix-in. Ma fortunatamente è anche possibile passare argomenti ai mix-ins in maniera tale da modificare il nostro rounded-corners mix-in nella seguente maniera:

/app/assets/stylesheets/layout.css.sass

@mixin rounded-corners($radius) {
  border-radius: $radius;
  -moz-border-radius: $radius;
  -webkit-border-radius: $radius;
}

Possiamo adesso passare qualunque valore ogni volta che vogliamo avere un bordo arrotondato.

/app/assets/stylesheets/layout.css.sass

.project {
  border: solid 1px #777;
  margin: 20px 0;
  padding: 7px 12px;
  @include rounded-corners(10px);
}

Inoltre è anche possibile specificare un valore di default.

/app/assets/stylesheets/layout.css.sass

@mixin rounded-corners($radius: 5px) {
  border-radius: $radius;
  -moz-border-radius: $radius;
  -webkit-border-radius: $radius;
}

Utilizzare SASS in file differenti

Anche usando SASS i nostri fogli di stile possono diventare lunghi e difficili da mantenere, adesso vedremo come è possibile organizzare il nostro stile separandolo in file differenti. Abbiamo già un file projects.css.scss nella nostra applicazione, il quale venne generato al momento della generazione dello scaffold per Projects. Questo file contiene al momento soltanto un commento, ma possiamo inserire del codice che sarà compilato e incluso da Rails 3.1 in un singolo file chiamato application.css.

Vogliamo quindi spostare qualunque codice SASS specifico per project dentro il file projects.css.scss. Facciamolo e vediamo cosa succede.

/app/assets/stylesheets/projects.css.scss

.new_project {
  background-color: $main-color;
  color: #FFF;
  padding: 5px 12px;
  margin: 10px 0;
  font-size: 16px;
  @include rounded-corners(5px);
}

.project {
  border: solid 1px #777;
  margin: 20px 0;
  padding: 7px 12px;
  @include rounded-corners(10px);
}

.project h2 { 
  margin: 0; 
}

Ricaricando la pagina vedremo che adesso lo stile non è più presente.

Per controllare se SASS ha lanciato un errore possiamo guardare il file di log o il foglio di stile nel browser.

Vediamo che un errore di sintassi ha impedito la generazione del foglio di stile. In questo caso l'errore è dovuto ad una variabile non definita:

Undefined variable: "$main-color".

Sembrerebbe che la variabile definita nel file principale non sia stata propagata negli file rimanenti.

Questo errore è dovuto al modo in cui Sprockets funziona in Rails 3.1. La variabili non vengono condivise fra i file SASS e possiamo vederne il perchè nel file application.css.

/app/assets/stylesheets/application.css

/*
 * This is a manifest file that'll automatically include all the stylesheets available in this directory
 * and any sub-directories. You're free to add application-wide styles to this file and they'll appear at
 * the top of the compiled file, but it's generally better to create a new file per style scope.
 *= require_self
 *= require_tree . 
*/

La linea require_tree . dice a Sprockets di includere qualunque file che si trovi dentro la cartella stylesheets. Il problema è che ogni file SASS viene compilato separatamente in un singolo CSS e soltanto dopo questi files vengono combinati in uno unico, il che significa che le variabili non vengono condivise tra i files. Per risolvere questo problema dobbiamo rimuovere require_tree . ed usare SASS per importare ciascun file. Il vantaggio di questo approccio è che ci permette di definire l'ordine con cui i file vengono caricati. Questo non è possibile usando require_tree. Dobbiamo quindi rinominare application.css in application.css.scss, rimuovere require_tree ed importare i nostri stili.

/app/assets/stylesheets/application.css.scss

/*
 * This is a manifest file that'll automatically include all the stylesheets available in this directory
 * and any sub-directories. You're free to add application-wide styles to this file and they'll appear at
 * the top of the compiled file, but it's generally better to create a new file per style scope.
 *= require_self
*/
@import "layout.css.scss";
@import "projects.css.scss";

Questo preserva tutte le nostre variabili, mix-ins e qualunque cosa abbiamo definito. Quando ricarichiamo la pagina il nostro stile funziona ora correttamente e la varibili definite nel foglio di layout sono disponibili per tutti gli altri.

SCSS vs SASS

Ti potresti chiedere perchè i file hanno una estensione .scss se il linguaggio si chiama SASS. Questo è perchè SASS supporta due sintassi differenti. SCSS è la nuova sintassi a partire da SASS 3 ma quella vecchia è ancora disponibile e continuerà ad essere supportata. Per utilizzarla il file di stile dovrà avere l'estensione .sass. La vecchia sintassi è simile a quella nuova ma non usa parentesi graffe o punti e virgola alla fine di ogni linea, il livello del blocco viene determinato in base al numero di spazi. La sintassi SCSS, essendo in super insieme di CSS, è più facile da usare specialmente se bisogna migrare da fogli di stile esistenti.

Fogli di stile condizionali

Finiamo questo episodio con un piccolo suggerimento. Come possiamo cambiare i file che vengono inclusi in base all'attuale controller? Dato un file projects.css.scss potremmo che pensare che questo venga incluso solo per le azioni incluse in ProjectsController, ma non è così. Tutti i CSS vengono compilati in un singolo file che viene applicato a tutte le pagine dell'applicazione. In genere questo non è un problema se utilizziamo gli scope correttamente ma certe volte potrebbe non essere abbastanza.

Una soluzione è quella di modificare il tag di apertura del body nel file di layout ed aggiungere un attributo id avente il nome dell'attuale controller come valore.

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

<body id="<%= params[:controller].parameterize %>_controller">

Chiamiamo parameterize sul nome del controller per rimuovere qualunque carattere speciale. Avendo adesso un unico id per ciascun controller, possiamo usare questo per introdurre degli scope nei nostri fogli di stile:

/app/assets/stylesheets/projects.css.scss

#projects_controller
{
  .new_project {
    background-color: $main-color;
    color: #FFF;
    padding: 5px 12px;
    margin: 10px 0;
    font-size: 16px;
    @include rounded-corners(5px);
  }

  .project {
    border: solid 1px #777;
    margin: 20px 0;
    padding: 7px 12px;
    @include rounded-corners(10px);
  }

  .project h2 { 
    margin: 0; 
  }
}

Questi stili verranno adesso applicati solo alle azioni del ProjectsController. Questo significa minori possibilità di avere conflitti tra id o class in controller diversi.

Questo è tutto per questo episodio su SASS. Non abbiamo parlato di tutto quello che SASS può fare, quindi suggeriamo di dare un'occhiata alla documentazione sul sito ufficiale per ottenere maggiori informazioni.

Concetti base in Coffeescript

Sun, 03 Jul 2011 18:42:12 +0000

CoffeeScript è un linguaggio che viene compilato in Javascript. Poichè è stato incluso in Rails 3.1 molti sviluppatori gli daranno un occhiata per la prima volta. In questo episodio tradurremo del pre-esistente codice Javascript in Coffeescript, poichè questo è un ottimo metodo per impararlo. Il codice in questione è quello che abbiamo scritto durante l'episodio 261 [guarda, leggi] per la validazione dei numeri di carta di credito.

Se non hai mai usato CoffeeScript il sito ufficiale è un ottimo posto da dove cominciare. Lì potrai trovare alcuni esempi di codice CoffeeScript con l'equivalente Javascript che verrà generato. Il sito ha anche una pagina nella quale puoi programmare e compilare. Il codice Javascript compilato può essere eseguito nel browser e tutto questo avviene lato client senza nessuna chiamata AJAX al server.

Il codice che convertiremo è usato nella pagina sottostante e viene attivato dall'evento blur appena l'utente finisce di inserire il numero di carta di credito. Il numero inserito viene sottoposto a una validazione modulo 10 ed un messaggio di errore viene visualizzato vicino al campo di input in caso di errore.

Il relativo codice Javascript viene mostrato di seguito.

var CreditCard = {
  cleanNumber: function(number) {
    return number.replace(/[- ]/g, "");
  },
  
  validNumber: function(number) {
    var total = 0;
    number = this.cleanNumber(number);
    for (var i=number.length-1; i >= 0; i--) {
      var n = +number[i];
      if ((i+number.length) % 2 == 0) {
        n = n*2 > 9 ? n*2 - 9 : n*2;
      }
      total += n;
    };
    return total % 10 == 0;
  }
};

$(function() {
  $("#order_credit_card_number").blur(function() {
    if (CreditCard.validNumber(this.value)) {
      $("#credit_card_number_error").text("");
    } else {
      $("#credit_card_number_error").text("Invalid credit card number.");
    }
  });
});

La versione di Rails in questione è la 3.1 Release Candidate 1, ed è stata appena annunciata. Per aggiornare basta eseguire gem install rails --pre.

Primi cambiamenti

Per avere un file Coffeescript bisogna aggiungere l'estensione .coffee al nome del file. Possiamo ancora usare normale file JavaScript in Rails 3.1 mantenendo l'estensione .js. CoffeeScript è completamente opzionale.

Cominceremo commentando il codice in Javascript in modo tale da implementare a poco a poco la relativa versione in Coffeescript. La prima funzione da tradurre è cleanNumber la quale pulisce l'input da eventuali spazi o cancelletti.

/app/assets/javascripts/orders.js.coffee

var CreditCard = {
  cleanNumber: function(number) {
    return number.replace(/[- ]/g, "");
  }
}

L'equivalenete Coffeescript è questo:

/app/assets/javascripts/orders.js.coffee

CreditCard =
  cleanNumber: (number) ->
    number.replace /[- ]/g, ""

Con Coffeescript possiamo scrivere molto meno codice. Tabs vengono usati per definire il livello del blocco al posto delle parentesi tradizionali. Questo significa che avremo bisogno di utilizzare gli spazi in maniera consistente.

Possiamo anche rimuovere qualunque var così come non avremo bisogno di usare return alla fine della funzione. Il valore finale di una funzione viene ritornato automaticamente, esattamente come in Ruby. Anche i punti e virgola non sono necessari e possono essere rimossi.

Qualunque chiamata di funzione non ha bisogno nemmeno che i parametri vengano messi fra parentesi. L'eccezione si ha quando la funzione viene chiamata senza parametri, le parentesi sono in questo caso necessarie a Coffeescript per capire che si tratta di una chiamata di funzione.

Dobbiamo infine cambiare il modo in cui una funzione viene dichiarata. La parola chiave function deve essere sostituita da -> dopo gli argomenti della funzione. Un pò di pratica è necessaria per abituarsi a questo tipo di dichiarazioni.

Possiamo adesso compilare il codice e vedere cosa viene generato. Il risultato è molto simile all'originale.

var CreditCard;
CreditCard = {
  cleanNumber: function(number) {
    return number.replace(/[- ]/g, "");
  }
};

Passiamo adesso all funzione validNumber .

/app/assets/javascripts/orders.js.coffee

validNumber: function(number) {
  var total = 0;
  number = this.cleanNumber(number);
  for (var i=number.length-1; i >= 0; i--) {
    var n = +number[i];
    if ((i+number.length) % 2 == 0) {
      n = n*2 > 9 ? n*2 - 9 : n*2;
    }
    total += n;
  };
  return total % 10 == 0;
}

Utilizzando lo stesso procedimento di prima otterremo il seguente codice Coffeescript.

/app/assets/javascripts/orders.js.coffee

validNumber: (number) ->
  total = 0
  number = @cleanNumber(number)
  for i in [(number.length-1)..0]
    n = +number[i]
    if (i+number.length) % 2 == 0
      n = if n*2 > 9 then n*2 - 9 else n*2
    total += n
  total % 10 == 0

Abbiamo rimosso tutte le parentesi e i punti e virgola. Anche le parole chiavi var e return sono scomparse, ed al posto di function abbiamo adesso ->. Ma non è tutto.

Ogni occorrenza della parola chiave this è stata sostituita con @ quindi this.cleanNumber diventa @number. Possiamo rimuovere le parentesi esterne dal blocco if poichè non sono necessarie. Anche l'operatore ternario è cambiato e possiamo sostituirlo con if then else.

Il resto del codice sembra essere ok; dobbiamo solo cambiare il ciclo for. CoffeeScript gestice le iterazioni in maniera differente rispetto a JavaScript.Possiamo iterare sugli elementi di un array in questa maniera:

for number in [1,2,3]
 alert number

Il codice Javascript generato è il seguente:

var number, _i, _len, _ref;
_ref = [1, 2, 3];
for (_i = 0, _len = _ref.length; _i < _len; _i++) {
  number = _ref[_i];
  alert(number);
}

Potremmo generare lo stesso codice così.

alert number for number in [1,2,3]

Possiamo sostituire l'array con un range se trattiamo sequenze di numeri.

for number in [1..3]
 alert number

Questo semplifica il codice generato:

var number;
for (number = 1; number <= 3; number++) {
  alert(number);
}

Se vogliamo decrementare invece che incrementare basta invertire l'input.

for number in [3..1]
 alert number

Questo è molto simile a quello che il ciclo for fa nella nostra funzione.

Possiamo adesso passare all'ultimo pezzo di codice.

/app/assets/javascripts/orders.js.coffee

$(function() {
  $("#order_credit_card_number").blur(function() {
    if (CreditCard.validNumber(this.value)) {
      $("#credit_card_number_error").text("");
    } else {
      $("#credit_card_number_error").text("Invalid credit ↵
        card number.");
    }
  });
});

Questo codice jQuery lega l'esecuzione della validazione all'evento blur, il quale viene lanciato non appena l'utente finisce di riempire il campo per il numero di carta di credito. Per gestire jQuery in CoffeeScript non abbiamo bisogno di nulla di particolare. L' equivalente codice CoffeeScript è questo:

/app/assets/javascripts/orders.js.coffee

jQuery ->
  $("#order_credit_card_number").blur ->
    if CreditCard.validNumber(@value)
      $("#credit_card_number_error").text("")
    else
      $("#credit_card_number_error").text("Invalid credit ↵
        card number.")

Come prima abbiamo rimosso parentesi e punti e virgola, sostituito function con -> e referenziato this con @. L'ultima cosa da cambiare è sostituire $ con jQuery. Questo non ha alcun impatto sulla funzionalità ma mette in evidenza il fatto che stiamo usando jQuery.

È giunto il momento di ricaricare il browser e vedere se tutto continua a funzionare come prima.

Funziona. Se inseriamo un numero invalido vedremo un messaggio di errore il quale scompare appena inseriamo un valore valido. Se guaridiamo alla fine del file risultante troveremo il codice Javascript generato.

http://localhost:3000/assets/application.js

(function() {
  var CreditCard;
  CreditCard = {
    cleanNumber: function(number) {
      return number.replace(/[- ]/g, "");
    },
    validNumber: function(number) {
      var i, n, total, _ref;
      total = 0;
      number = this.cleanNumber(number);
      for (i = _ref = number.length - 1; _ref <= 0 ? i <= 0 : ↵
        i >= 0; _ref <= 0 ? i++ : i--) {
        n = +number[i];
        if ((i + number.length) % 2 === 0) {
          n = n * 2 > 9 ? n * 2 - 9 : n * 2;
        }
        total += n;
      }
      return total % 10 === 0;
    }
  };
  jQuery(function() {
    return $("#order_credit_card_number").blur(function() {
      if (CreditCard.validNumber(this.value)) {
        return $("#credit_card_number_error").text("");
      } else {
        return $("#credit_card_number_error").text("Invalid ↵ 
          credit card number.");
      }
    });
  });
}).call(this);

Debuggare

Ma cosa succede se abbiamo un errore di sintassi in CoffeeScript? Se cambiamo il nostro CoffeeScript in maniera tale che non compili correttamente non riceveremo alcun messaggio dal browser. Ma se invece diamo un'occhiata alla console troveremo l'errore.

Ci sono abbastanza informazioni per capire quale sia l'errore e quale linea abbia causato.

Questo è tutto per questo episodio su CoffeeScript, ci sono molte altre cose da imparare a proposito di questo divertente linguaggio, quindi consigliamo di dare un'occhiata al sito ufficiale.

OmniAuth - Parte 1

Sun, 03 Jul 2011 18:35:39 +0000

Circa due settimane fa, nell’episodio 233 [guarda, leggi] ho presentato un servizio chiamto Janrain Engage, un modo centralizzato per gestire l’autenticazione tramite servizi Twitter, OpenID and Facebook. E’ un servizio fantastico ma è come se ci fosse qualcuno tra la tua applicazione e il provider di autenticazione e questo è un aspetto negativo. Una soluzione migliore potrebbe essere una gemma o un plugin che ti permetterebbe di usare nella nostra applicazione l’autenticazione fornita da terze parti senza utilizzare servizi esterni.

OnmiAuth è una gemma nuova che fornisce un’unica soluzione per connettersi a diversi servizi. Se il servizio che vuoi usare per autenticarti non è supportato da OmniAuthm, aggiungere un proprio provider è davvero semplice. OmniAuth è una una collezione di Rack middleware che da molta flessibilità su come usarla.

C’è un bel articolo nel blog di Rails Rumble blog che spiega in dettaglio come aggiungere OmniAuth ad una applicazione Rails. L’articolo mostra come creare un sistema di autenticazione da zero, ma qui spiegheremo come integrare OmniAuth in una applicazione che possiede già un sistema di autenticazione. Qui useremo Devise, si potrà adattare ad Authlogic o ad altri sistemi di autenticazione specifici facilmente.

Aggiungere OmniAuth alla nostra applicazione

Prenderemo come esempio l’episodio 209, una semplice todo-list, che usa Devise per gestire l’autenticazione degli utenti. I link “Sign up ” “Sign in ” portano l’utente ad una pagina dove si può accedere o registrarsi fornendo un nome utente e password. Inizieremo entrando con on un account già esistente in modo da renderci più semplice lo sviluppo di autenticazione tramite provider.

OmniAuth si presenta come una gemma ed è facile includerlo nella nostra applicazione modificamndo il Gemfile.

/Gemfile

source 'http://rubygems.org'

gem 'rails', '3.0.0'

gem 'sqlite3-ruby', :require => 'sqlite3'
gem 'devise', '1.1.3'

gem 'omniauth'

Eseguiamo il bundle install (o solo bundle) per istallare le gemme e tutte le sue dipendenze. OmniAuth ha diverse dipendenze ma sarà il budler che si occuperà di installarle tutte.

Il prossimo passo è quello di andare nella directory dell’applicazione /config/initializers e creare un nuovo file. Lo chiameremo omniauth.rb ma il nome non è importante. In questo file aggiungiamo OmniAuth::Builder al middleware della nostra applicazione e definiamo i provider che vogliamo utilizzare.

/config/initializers/omniauth.rb

Rails.application.config.middleware.use OmniAuth::Builder do
  provider :twitter, 'CONSUMER_KEY', 'CONSUMER_SECRET'
  provider :facebook, 'APP_ID', 'APP_SECRET'
  provider :linked_in, 'CONSUMER_KEY', 'CONSUMER_SECRET'
end

In questa applicazione noi andremo ad usare solo Twitter, anche se ci sono molti provider che si potrebbero scegliere, quindi rimuoviamo le ultime due linee. Per supportare l’autenticazione attraverso Twitter abbiamo la necessità di fare il setup della nostra applicazione andando alla sezione per gli sviluppatori per registrarci. Il form di registrazione è facile da compilare ed una volta registrata la nostra applicazione, avremo la chiave e un charset segreto che dovremo copiare nel nostro file initializer.

/config/initializers/omniauth.rb

Rails.application.config.middleware.use OmniAuth::Builder do
  provider :twitter, 's3dXXXXXXXXXXXX', 'lR23XXXXXXXXXXXXXXXXXXXX'
end

Se avviamo il server dell’applicazione già possiamo vedere OmniAuth in azione . Se visitiamo l’url /auth/twitter saremo rediretti a Twitter e ci verrà chiesto se vogliamo permettere l’accesso a questa applicazione

Se clicchiamo su “Allow ” saremo rediretti alla nostra applicazione con l’URL /auth/twitter/callback. La nostra applicazione ha bisogno di gestire questa URL che riguarda ciò che succede dopo che un utente ha effettuato l’accesso, il modo in cui gestiamo questa risposta dipende sa noi e questo rende OmniAuth molto flessibile. In questo caso creeremo una risorsa separata che la chiameremo Authentication

Potremmo creare il model a il controller sepratamente, ma per rendere le cose più semplici useremo il Nifty Scaffold generator di Ryan Bates per creare il model, la view e il controller con un solo comando. La risorsa Authentication avrà un campo user_id, un campo provider che sarà valorizzato con il nome del provider, e .g. “ Twitter ” o “Facebook ” e un campo uid nel quale verrà memorizzato l’identificativo utente del provider. Per il controller ci serviranno le action index, create e destroy

$ rails g nifty:scaffold authentication user_id:integer
provider:string uid:string index create destroy

Dopo che si esegue questo comando, facciamo partire il migrate del database.

$ rake db:migrate

Successivamente settiamo le relazione tra i modelli User e Authentication . Un utente potrà autenticarsi in un un numero di modi differenti così da avere più autenticazioni.

/app/models/user.rb

class User < ActiveRecord::Base
  has_many :authentications
  # Include default devise modules. Others available are:
  # :token_authenticatable, :lockable, :timeoutable and :activatable
  # :confirmable,
  devise :database_authenticatable, :registerable, 
         :recoverable, :rememberable, :trackable, :validatable

  # Setup accessible (or protected) attributes for your model
  attr_accessible :email, :password, :password_confirmation
end

Allo stesso modo Authentication 'belong to' User.

/app/models/authentication.rb

class Authentication < ActiveRecord::Base
  belongs_to :user
end

Lo scaffold ha pure generato un AuthenticationsController che possiamo usare per gestire le risposte di OmniAuth. Mapperemo l’URL di risposta alla action create, modificando il file di routes

/config/routes.rb

ProjectManage::Application.routes.draw do |map|
  match '/auth/:provider/callback' => 'authentications#create'
  devise_for :users
  resources :projects
  resources :tasks
  resources :authentications
  root :to => 'projects#index'
end

Da notare la colonna della stringa che viene matchata . Questo significa che noi possiamo fare il matching di ogni provider come parametro.

Dentro la action create possiamo fare il fetch dei dettagli di autenticazione con una chiamata arequest.env["rack.auth"]. (Nelle versioni di OmniAuth successive sarà request.env["omniauth.auth"]). Per ora ci limiteremo fare il render del testo in modo da vedere quali sono le informazioni contenute.

/app/controllers/authentication_controller.rb

class AuthenticationsController < ApplicationController
  def index
  end
  
  def create
    render :text => request.env["rack.auth"].to_yaml
  end
  
  def destroy
  end
end

Se visitiamo /auth/twitter adesso e ci autentichiamo su Twitter avremo come risposta molte informazioni.

Le Informazioni restituite sono un hash di hash. All’inizio della lista c’è il provider e il campo uid che ci interessano. Conserveremo sia il nome del provider che che l’uid nel nostro modello di Authentication. Alla fine del file c’è qualche informazione sull’utente che potrebbe essere utile salvare in User model.

user_info: 
  nickname: eifion
  name: Eifion
  location: North Wales
  image: http://a1.twimg.com/profile_images/434158309/Adium_Icon_normal.png
  description: Web developer using .Net and Windows by day and Ruby and Rails on OS X the rest of the time. I run http://asciicasts.com
  urls: 
    Website: http://asciicasts.com

Salvare le Informazioni di Authentication

Abbiamo bisogno di modificare la action create e cambiare il suo comportamento a seconda dello stato corrente dell’utente, ma prima vedremo l’esempio più facile. Quando un utente è attualmente connesso vogliamo solo aggiungere questa nuova autenticazione ai loro account utente.

/app/controllers/authentications_controller.rb

def create
  auth = request.env["rack.auth"] current_user.authentications.create(:provider => auth ['provider'], :uid => auth['uid'])
  flash[:notice] = "Authentication successful."
  redirect_to authentications_url
end

Nella action create possiamo ottenere informazioni per l’autenticazione in un hash e creare una nuova Authentication per l’utente basata su due parametri grazie alle informazioni ritornate dal provider di autenticazione. Quindi creiamo un messaggio flash e ritorneremo nella action index.

Se visitiamo /auth/twitter and ci autentichiamo, saremo rediretti nella pagina index dove potremo vedere i dettagli della nuova autenticazione appena effettuata con il provider e l’uid corretto.

Migliorare il Look della pagina Index

C’è un account molto utile su GitHub chiamato Authbuttons, che ha le icone per molti provider differenti. Possiamo usarli per migliorare il look della pagina dove si sceglie il provider di autenticazione. Per convenienza andremo a gestire tutto dentro la action index di AuthenticationsController ma in produzione si potrebbe spostare in una pagina separata.

Prima di fare questo abbiamo bisogni di cambiare il codice nella index. Il codice dello scaffolding generato farà la fetch di tutte le autenticazioni. Cambiamolo in modo che venga selezionato solo l’autenticazione del current_user.

/app/controllers/authentications_controller.rb

def index
  @authentications = current_user.authentications if current_user
end

Allo stesso modo possiamo cambiare la action destroy così che non si possono eliminare autenticazione che non belong_to al current user.

/app/controllers/authentications_controller.rb

def destroy
  @authentication = current_user.authentications.find(params[:id])
  @authentication.destroy
  flash[:notice] = "Successfully destroyed authentication."
  redirect_to authentications_url
end

Successivamente abbiamo bisogno di cambiare il codice della view, nulla di complicato solo qualche modifica.

/app/views/authentications/index.html.erb

<% title "Sign In" %>
<% if @authentications %>
 <% unless @authentications.empty? %>
  <p><strong>You can sign in to this account using:</strong></p>
   <div class="authentications">
    <% for authentication in @authentications %>
     <div class="authentication">
      <%= image_tag "#{authentication.provider}_32.png", :size => "32x32" %>
      <div class="provider"><%= authentication.provider.titleize%></div>
      <div class="uid"><%= authentication.uid %></div>
       <%= link_to "X", authentication, :confirm => 'Are you sure you want to remove this authentication option?', :method => :delete, :class => "remove" %>
     </div>
     <% end %>
     <div class="clear"></div>
    </div>
   <% end %>
   <p><strong>Add another service to sign in with:</strong></p>
  <% else %>
  <p><strong>Sign in through one of these services:</strong></p>
<% end %>

<a href="/auth/twitter" class="auth_provider">
  <%= image_tag "twitter_64.png", :size => "64x64", :alt => "Twitter" %>Twitter</a>
<a href="/auth/facebook" class="auth_provider">
  <%= image_tag "facebook_64.png", :size => "64x64", :alt => "Facebook" %>Facebook</a>
<a href="/auth/google_apps" class="auth_provider">
  <%= image_tag "google_64.png", :size => "64x64", :alt => "Google" %>Google</a>
<a href="/auth/open_id" class="auth_provider">
  <%= image_tag "openid_64.png", :size => "64x64", :alt => "OpenID" %>OpenID</a>
<div class="clear"></div>

Se ricarichiamo la pagina di autenticazione possiamo vedere come sia migliorata nel look.

La nostra applicazione non supporta tutti i servizi mostrati negli screenshoot, ma quelli che si potrebbero supportare. Anche se questa pagina è migliorata nel look, ha un bug. Autenticandosi con Twitter proviamo a fare una seconda autenticazione sempre con Twitter, verrà creato un nuovo record già esistente in Authentication.

Il problema è abbastanza facile da risolvere, basta modificare la create action di AuthenticationController così da usare find_or_create_by_ per vedere se l'utente si è autenticato con quel provider prima di crearne uno nuovo record in Authentication.

/app/controllers/authentication_controller.rb

def create
  auth = request.env["rack.auth"]
  current_user.authentications.find_or_create_by_provder_and_uid(auth['provider'], auth['uid'])
  flash[:notice] = "Authentication successful."
  redirect_to authentications_url
end

Adesso se vogliamo rimuovere la seconda autenticazione e riprovare ad autenticarci sempre via Twitter avremo solo una autenticazione per utente

Una delle cosa che non abbiamo affrontato è l’autenticazione tramite provider per utenti non registrati. Se andiamo a guardare nella action create vedremo che il codice presuppone che noi abbiamo un current_user. cosa succede quando si prova ad autenticarsi via Twitter senza essere già registrati al sito? Parleremo di questo problema nel prossimo episodio.

Simple Form

Sun, 31 Oct 2010 21:54:28 +0000

Pochi mesi fa abbiamo trattato in un paio di episodi il gem Formtastic [guarda, leggi]. Questo plugin offre la possibilità di generare rapidamente il codice delle viste per le form in Rails. In questo episodio daremo un’occhiata ad un gem alternativo, chiamato SimpleForm. Come Formtastic, SimpleForm fornisce un modo più semplice per generare il codice delle viste rispetto allo standard Rails. Se conoscete già Formtastic, le chiamate ai metodi SimpleForm vi sembreranno familiari, dal momento che in effetti lo sono.

La domanda da un milione di dollari è, viste tutte queste analogie fra i due gem, perchè preferire SimpleForm a Formtastic? Una delle ragioni è che SimpleForm è più leggero. Non include un foglio di stile che si aspetta essere usato, ma si concentra esclusivamente sulla generazione del markup HTML. E’ anche più personalizzabile ed estendibile di Formtastic. Se avete usato Formtastic e vi è sembrato che vi condizionasse un po’ troppo a fare a modo suo e che vi forzasse ad usare del markup che non avreste voluto, allora vale la pena che esploriate anche SimpleForm.

Integrare SimpleForm in un’applicazione

Per dimostrare SimpleForm, aggiornaremo una form già scritta usando codice di vista standard di Rails. L’applicazione è una semplice applicazione di e-commerce con una serie di prodotti, ciascuno dei quali appartiene ad una categoria e la form che abbiamo intenzione di modificare è quella di creazione di un nuovo prodotto. Questa form ha una serie di diversi tipi di campo, per cui fungerà molto bene da esempio per convertire all’uso di SimpleForm.

Per usare SimpleForm dobbiamo per prima cosa aggiungere il gem al Gemfile dell’applicazione:

/Gemfile

gem "simple_form"

Poi, per assicurarci che venga installato tutto, dobbiamo lanciare:

$ bundle install

Ora che il gem è installato, dobbiamo lanciare un generatore che aggiunga all’applicazione un paio di file di cui ha bisogno SimpleForm:

$ rails g simple_form:install
    create  config/initializers/simple_form.rb
    create  config/locales/simple_form.en.yml
    create  lib/templates/erb/scaffold/_form.html.erb

Questi file generati sono usati principalmente per la personalizzazione delle form e li esamineremo in dettaglio fra poco. Prima, però, aggiorneremo la form dei prodotti che attualmente appare così:

/app/view/products/new.html.erb

<%= form_for @product do |f| %>
  <%= f.error_messages %>
  <p>
    <%= f.label :name %>
    <%= f.text_field :name %>
  </p>
  <p>
    <%= f.label :price %>
    <%= f.text_field :price %>
  </p>
  <p>
    <%= f.label :released_on %>
    <%= f.date_select :released_on %>
  </p>
  <p>
    <%= f.label :category_id %>
    <%= f.collection_select :category_id, Category.all, :id, :name %>
  </p>
  <p>
    <%= f.label :rating %>
    <%= f.select :rating, 1..5 %>
  </p>
  <p>
    <%= f.label :discontinued %>
    <%= f.check_box :discontinued %>
  </p>
  <p><%= f.submit %></p>
<% end %>

Le due principali modifiche che dobbiamo fare alla form sono di sostituire form_for con simple_form_for e tutte le coppie label ed input con un unico metodo di SimpleForm:

/app/view/products/new.html.erb

<%= simple_form_for @product do |f| %>
  <%= f.error_messages %>
  <%= f.input :name %>
  <%= f.input :price %>
  <%= f.input :released_on %>
  <%= f.association :category %>
  <%= f.input :rating %>
  <%= f.input :discontinued %>
  <%= f.button :submit %>
<% end %>

Per la maggior parte dei control della form possiamo usare il metodo f.input. Uno dei campi per il quale dobbiamo utilizzare qualcosa di diverso è il category. Nella form originale questo campo usava collection_select per renderizzare una tendina contenente tutte le categorie.

/app/view/products/new.html.erb

<%= f.collection_select :category_id, Category.all, :id, :name %>

Con SimpleForm possiamo sostituire tutto ciò con f.association che fa la stessa cosa.

Possiamo ora ricaricare la form e vedere come viene mostrata da SimpleForm:

La form appare piuttosto diversa ora rispetto a prima, perchè non ha più lo stile che aveva in precedenza, ma è semplice rimediare adattando i nostri fogli di stile ai nomi delle classi usate da SimpleForm nelle sue form:

/public/stylesheets/application.css

.simple_form label {
  float: left;
  width: 100px;
  text-align: right;
  margin: 2px 10px;
}

.simple_form div.input {
  margin-bottom: 10px;
}

.simple_form div.boolean, .simple_form input[type='submit'] {
  margin-left: 120px;
}

.simple_form div.boolean label {
  float: none;
  margin: 0;
}

Quando usate SimpleForm nelle vostre applicazioni, dovrete personalizzare questi stili per adattarli all’aspetto della vostra applicazione, ma il CSS riportato qui sopra vi dà già un’idea circa i nomi delle classi usati dagli elementi HTML generati da SimpleForm. Sistemati gli stili, la nostra form ora appare migliore:

Campi personalizzati

Per i campi per i quali abbiamo usato f.input, SimpleForm ha automaticamente capito il tipo della colonna e per questo vediamo che “Released on” è stato renderizzato come una colonna di tipo data mentre invece “Discontinued” come checkbox, dal momento che rappresenta una colonna booleana. In quanto associazione, il campo “Category” è stato renderizzato come tendina con l’opzione vuota. Se volessimo personalizzare questi campi, facendoli apparire in modo diverso, dovremmo aggiungere alcune option. Per esempio, possiamo rimuovere l’opzione vuota dalla tendina “Category”, aggiungendo l’opzione :include_blank:

/app/view/products/new.html.erb

<%= f.association :category, :include_blank => false %>

La form originale aveva una tendina per il campo rating, ma ora ci troviamo un campo di testo. Possiamo ripristinare la tendina, usando l’opzione :collection e passando ad essa un intervallo:

/app/view/products/new.html.erb

<%= f.input :rating, :collection => 1..5 %>

Se invece volessimo visualizzare la lista come radio button, potremmo usare l’opzione :as:

/app/view/products/new.html.erb

<%= f.input :rating, :collection => 1..5, :as => :radio %>

Al ricaricamento della form, ora vedremo che l’opzione vuota è scomparsa dalla tendina e che il campo rating è mostrato come radio button.

Un’altra bella funzionalità di SimpleForm è il riconoscimento automatico dei campi obbligatori. Possiamo illustrarvi la cosa, rendendo obbligatori i campi name e price nel modello Product:

/app/models/product.rb

class Product < ActiveRecord::Base
  attr_accessible :name, :price, :released_on, :category_id, 
  :rating, :discontinued
  belongs_to :category  
  validates_presence_of :name, :price
end

E’ tutto ciò che dobbiamo fare. Al ricaricamento della form vedremo questi due campi contrassegnati da un asterisco e se provassimo a fare il submit della form senza averli compilati, vedremmo i messaggi di errore relativi:

Possiamo anche facilmente aggiungere un messaggio di suggerimento per ogni campo. Poniamo di voler dare un suggerimento che indichi che i prezzi si intendono in sterline. Dobbiamo solo aggiungere un’opzione :hint al campo:

/apps/views/products/_form.html.erb

<%= f.input :price, :hint => "prices should be in UKP." %>

Ciò aggiungerà un suggerimento subito dopo il campo della form:

Ci sono ulteriori informazioni su tutte queste opzioni di campo nella documentazione di README di SimpleForm. Vale la pena dare un’occhiata anche alla documentazione di Formtastic, visto che molte delle opzione usate da quest’ultimo plugin possono essere usate anche da SimpleForm.

Personalizzazione di SimpleForm

Quando prima abbiamo lanciato il generatore di SimpleForm, sono stati creati tre file:

$ rails g simple_form:install
    create  config/initializers/simple_form.rb
    create  config/locales/simple_form.en.yml
    create  lib/templates/erb/scaffold/_form.html.erb

Se volessimo personalizzare SimpleForm per tutta un’applicazione (non solo per una singola form), potremmo farlo cambiando uno o più di questi tre file. Il primo contiene una serie di opzioni di configurazione commentate che si possono sfruttare per le personalizzazioni. Per esempio, potremmo cambiare l’ordine in cui ciascun campo viene mostrato; potremmo modificare componente container per ogni campo di form, così come la dimensione di default del campo di testo. Vogliamo che i campi di testo della nostra applicazione siano più stretti, perciò cambiamo il valore di default da 50 a 30:

/config/initializers/simple_form.rb

# Use this setup block to configure all options available in SimpleForm.
SimpleForm.setup do |config|

  # Other options removed...

  # Default size for text inputs.
  config.default_input_size = 30
end

Il secondo file generato è quello di I18n:

/config/locales/simple_form.en.yml

en:
  simple_form:
    "yes": 'Yes'
    "no": 'No'
    required:
      text: 'required'
      mark: '*'
      # You can uncomment the line below if you need to overwrite the whole required html.
      # When using html, text and mark won't be used.
      # html: '*'
    error_notification:
      default_message: "Some errors were found, please take a look:"
    # Labels and hints examples
    # labels:
    #   password: 'Password'
    #   user:
    #     new:
    #       email: 'E-mail para efetuar o sign in.'
    #     edit:
    #       email: 'E-mail.'
    # hints:
    #   username: 'User name to sign in.'
    #   password: 'No special characters, please.'

Anche se la vostra applicazione non ha bisogno di mostrarsi in più di una lingua, questo file resta comunque un punto pratico in cui modificare alcune delle opzioni di SimpleForm, come ad esempio il testo da mostrare in caso di errore su campi obbligatori.

L’ultimo file generato ridefinisce il partial della form per il generatore di scaffold:

/lib/templates/erb/scaffold/_form.html.erb

<%%= simple_form_for(@<%= singular_name %>) do |f| %>
  <%% if @<%= singular_name %>.errors.any? %>
    <div id="error_explanation">
      <h2><%%= pluralize(@<%= singular_name %>.errors.count, "error") %> prohibited this <%= singular_name %> from being saved:</h2>

      <ul>
      <%% @<%= singular_name %>.errors.full_messages.each do |msg| %>
        <li><%%= msg %></li>
      <%% end %>
      </ul>
    </div>
  <%% end %>

  <div class="inputs">
  <%- attributes.each do |attribute| -%>
    <%%= f.<%= attribute.reference? ? :association : :input %> :<%= attribute.name %> %>
  <%- end -%>
  </div>

  <div class="actions">
    <%%= f.button :submit %>
  </div>
<%% end %>

In Rails 3 possiamo fare l’override di un qualunque template in un generatore, aggiungendolo alla nostra applicazione, per cui se volessimo personalizzare il modo in cui un generatore funziona per adeguarlo al modo in cui noi vogliamo che funzioni, potremmo farlo semplicemente creando un nuovo file di template.

E’ tutto per questo episodio. SimpleForm rende ancor più semplice la creazione di form nelle vostre applicazioni Rails e vale la pena esaminarlo.

Conosciamo Devise

Wed, 13 Oct 2010 21:46:06 +0000

Nella recente gara Rails Rumble i partecipanti hanno provato a creare un’applicazione Rails in 48 ore. La pagina di login alla competizione era interessante, perchè permetteva di autenticarsi mediante una serie di servizi differenti.

Dare la possibilità di autenticarsi mediante una serie di servizi differenti può richiedere uno sforzo notevole in termini di sviluppo, ma il sito Rails Rumble ha risolto il problema usando Janrain, che fornisce un servizio chiamato Janrain Engage (conosciuto anche come RPX). Si tratta di un servizio di autenticazione centralizzato; c’è un API con cui una applicazione può comunicare per abilitare l’autenticazione mediante una pletora di altri provider. Janrain è un servizio commerciale, ma ne esiste anche una versione gratuita, più limitata, che va più che bene per gli scopi di un sito come Rails Rumble.

Autenticazione mediante Engage

L’autenticazione basilare mediante il servizio Janrain Engage à semplice. Una volta registrati al servizio e aver fornito un nome per la nostra applicazione, veniamo portati alla home page del nostro account. Da qui dobbiamo prendere nota della chiave per le API e del nome dell’applicazione, in questo caso ‘asciicasts’. Dobbiamo anche dichiarare i provider che desideriamo usare. Se ci autentichiamo e poi clicchiamo sul tab ‘Providers’, veniamo portati a una pagina da cui potremo scegliere i servizi attraverso i quali gli utenti della nostra applicazione potranno autenticarsi:

L’account gratuito consente solo di scegliere fra sei provider, ma già questi sono sufficienti per darci un’ampia scelta. Si noti che alcuni di questi richiedono una configurazione extra. Per esempio, per usare Twitter, dovremmo configurare la nostra applicazione come un client OAuth, ma è piuttosto semplice farlo. Per la nostra applicazione, useremo i quattro provider proposti per default.

Modifichiamo la nostra applicazione per usare Engage

Ora che ci siamo registrati, possiamo utilizzare Engage in un’applicazione Rails. Se stessimo creando un meccanismo di autenticazione partendo da zero,potremmo utilizzare il gem RPXNow, che offre molte funzionalità per aiutarci a usare Engage nella nostra applicazione. Se la nostra applicazione usava già Authlogic, esiste un gem denominato Authlogic RPX, che vale la pena di considerare. Infine c’è il gem RPX Connectable per l’utilizzo con Devise. L’applicazione con cui stiamo lavorando in questo episodio usa Devise, per cui utilizziamo proprio quest’ultimo gem per integrare Engage in esso. Se non conoscete bene Devise, date uno sguardo all’episodio 209 [guardalo, leggilo] per una breve presentazione.

La nostra applicazione ha già i collegamenti “Sign up” e “Sign in” che portano l’utente ad una semplice form da riempire con un indirizzo email e una password:

Vogliamo sostituire questi link con uno unico che conduce l’utente a una pagina dove può autenticarsi mediante Engage ed è proprio qui che potremo avvalerci del gem RPX Connectable.

Per usare il gem nella nostra applicazione dobbiamo innanzitutto aggiungerne il riferimento nel Gemfile:

/Gemfile

source 'http://rubygems.org'

gem 'rails', '3.0.0'
gem 'sqlite3-ruby', '1.2.5', :require => 'sqlite3'
gem 'devise'
gem 'nifty-generators'
gem 'devise_rpx_connectable'

e poi installarla con:

$ bundle install

Per usare RPX, dobbiamo aggiungere un campo rpx_identifier alla nostra tabella Users. Genereremo una nuova migrazione per fare ciò:

$ rails g migration add_rpx_to_users rpx_identifier:string

Poi possiamo lanciare la migrazione per aggiungere il nuovo campo:

$ rake db:migrate

Poi dobbiamo modificare la chiamata a devise nella classe di modello User, affinchè abbia :rpx_connectable nella sua lista di module:

/app/models/user.rb

class User < ActiveRecord::Base
  devise :database_authenticatable, :registerable, 
         :recoverable, :rememberable, :trackable, :validatable, :rpx_connectable

  # Setup accessible (or protected) attributes for your model
  attr_accessible :email, :password, :password_confirmation
end

Infine dobbiamo aggiornare il file di configurazione di Devise della nostra applicazione per indicare il nome che abbiamo utilizzato per la nostra applicazione quando ci siamo registrati per essa ad Engage, oltre alla chiave API che ci è stata fornica:

/config/initializers/devise.rb

Devise.setup do |config|
  # Configure the e-mail address which will be shown in DeviseMailer.
  config.mailer_sender = "test@example.com"
  config.rpx_application_name = 'asciicasts'
  RPXNow.api_key = "aaabbbcccdddeeefff" # real key goes here.
end

Ora che abbiamo configurato tutto, possiamo sostituire i due link “Sign up” and “Sign in” nel file di layout con l’unico link alla pagina di autenticazione Engage, passando l’URL a cui vogliamo ritornare subito dopo l’autenticazione:

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

<%= link_to_rpx "Sign in", user_session_url %>

Autenticazione

Abbiamo tutto il codice in regola per provare ad autenticarci. Quando clicchiamo sul link di “Sign in” nella nostra applicazione, verremo ridiretti ad una pagina presente sui server di Janrain:

Possiamo ora autenticarci usando uno degli account proposti qui sopra e, nell’ipotesi che abbiamo inserito correttamente i nostri dati, saremo ridiretti alla nostra applicazione:

Si noti che ora siamo autenticati nella nostra applicazione.

Una pagina di login migliore

Se volessimo che il pannello di log-in fosse più carino, facendolo diventare un overlay Javascript, anzichè una pagina a parte, potremmo farlo includendo la seguente linea di codice subito prima del tag di chiusura del body nel file di layout:

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

<%= javascript_include_rpx(user_session_url) %>

Ciò aggiungerà del JavaScript alla nostra applicazione, che mostrerà un overlay sul sito quando uno tenta di autenticarsi:

In alternativa potremmo inserire il pannello di autenticazione ovunque nella nostra applicazione, usando un iframe. Per farlo, tutto ciò che dovremmo fare sarebbe di aggiungere la seguente linea di codice da qualche parte nel codice della vista:

<%= embed_rpx user_session_url %>

Questo codice è bene metterlo da qualche parte vicino alla maschera di login, per consentire un metodo alternativo di autenticazione.

Tutto ciò che vi abbiamo mostrato in questo episodio si trova nel file README di Devise RPX Connectable, insieme ad alcune informazioni su certe opzioni aggiuntive che possono essere passate affinchè sia possibile richiedere informazioni aggiuntive su ciascun utente autenticato.

Esploriamo il routing di Rails 3 (parte 2)

Wed, 13 Oct 2010 21:41:07 +0000

In questo episodio continueremo da dove eravamo rimasti la settimana scorsa e riprenderemo a esaminare il codice interno di Rails 3 deputato al routing. Al termine dello scorso episodio, il file di route appariva più o meno così:

/config/routes.rb

Store::Application.routes.draw do
  match 'products', :to => ProductsController.action("index")
  match 'products/recent'
end

L’ultima volta abbiamo visto il codice interno del metodo match e abbiamo scoperto cosa accade quando si invoca il match nel file di route, tuttavia ci sono diversi altri metodi che possiamo richiamare che vedremo proprio in questo episodio.

Esaminando il codice sorgente di Rails 3.0, ritroviamo le logiche di routing nella cartella actionpack/lib/actiondispatch/routing. Ci focalizzeremo sulla classe Mapper presente in tale cartella poichè, come già discusso la volta scorsa, il blocco presente all’interno del file di route è inquadrato nell’ambito di questa classe. In altre parole, ogni metodo richiamato all’interno del blocco è chiamato su di un’istanza di Mapper, ragion per cui possiamo richiamare un qualsiasi metodo di istanza della classe Mapper all’interno del nostro file di route.

Il codice della classe Mapper può apparire un po’ destabilizzante. Il codice è tanto, quasi 1000 linee, e complesso, ma la buona notizia è che si tratta in effetti del file più verboso per quel che concerne il routing di Rails, per cui se riuscirete ad afferrare le logiche che intercorrono in questo file e a capirle, vi sarete fatti un’idea piuttosto buona del funzionamento interno complessivo del routing in Rails.

Al fine di ottenere una buona vista di insieme del codice, collasseremo il corpo dei metodi. In TextMate la pressione dei tasti Command-Option-0 causerà appunto il collassamento di tutto quanto è collassabile all’interno del file. Fatto ciò espandiamo il module di radice ActionDispatch, il suo sottomodulo Routing ed infine la classe Mapping stessa, per avere un quadro della sua struttura:

I primi due elementi nella classe Mapper sono la definizione delle classi Constraints e Mapping. Le abbiamo viste entrambe nell’ultimo episodio, ma ciò che è significativo notare qui è come queste siano innestate sotto alla classe Mapper. Tutto ciò potrebbe apparire strano se vi siete appena avvicinati a Ruby e vi potreste giustamente domandare perchè dovreste aver bisogno di innestare le classi in un modo simile. Nulla di magico: la classe Constraints è completamente separata dalla classe Mapper. La ragione per cui è stata realizzata una simile struttura è che l’innestamento delle classi definisce il namespace per le classi Constraints e Mapping in modo tale che queste appaiano sotto il namespace di Mapper. Non c’è alcuna ereditarietà o condivisione di comportamento quando si realizzano simili innestamenti di classi in Ruby.

Spostandoci più in basso, troviamo due metodi di classe, self.normalize_path e self.normalize_name. Si tratta di metodi di utilità che sono utilizzati frequentemente all’interno della classe. Sotto di questi, c’è un insieme di module:

rails/actionpack/lib/action_dispatch/routing/mapper.rb

module Base...

module HttpHelpers...

module Scoping...

module Resources...

module Shorthand...

include Base
include HttpHelpers
include Scoping
include Resources
include Shorthand

Questi cinque module sono inclusi nella classe Mapper. Il codice al loro interno è stato confinato in module semplicemente per pulizia.

Base

Abbiamo visto il primo module, Base, nell’ultimo episodio. Contiene il metodo match, il metodo root che utilizza match e anche un metodo mount che fornisce un altro modo di mappare un’applicazione Rack ad un URL:

rails/actionpack/lib/action_dispatch/routing/mapper.rb

module Base
  def initialize(set) #:nodoc:

  def root(options = {})
    match '/', options.reverse_merge(:as => :root)
  end

  def match(path, options=nil)...

  def mount(app, options = nil)...

  def default_url_options=(options)...
  alias_method :default_url_options, :default_url_options=
end

HttpHelpers

Il module successivo è HttpHelpers, all’interno del quale sono definiti i metodi get, post, put e delete. Questi metodi sono usati per mappare i route a determinati tipi di richieste:

rails/actionpack/lib/action_dispatch/routing/mapper.rb

module HttpHelpers
  def get(*args, &block)
    map_method(:get, *args, &block)
  end

  def post(*args, &block)
    map_method(:post, *args, &block)
  end

  def put(*args, &block)
    map_method(:put, *args, &block)
  end

  def delete(*args, &block)
    map_method(:delete, *args, &block)
  end

  def redirect(*args, &block)...

  private
  def map_method(method, *args, &block)
     options = args.extract_options!
     options[:via] = method
     args.push(options)
     match(*args, &block)
     self
   end
end

Tutti questi metodi al loro interno chiamano il metodo privato map_method. Questo metodo imposta l’opzione :via a seconda del metodo passatogli e infine chiama il metodo match. Noterete nel vostro codice di routing che molti dei metodi delegano al metodo match, passandogli e personalizzando a priori determinate opzioni. Per cui, se vogliamo che un certo route risponda solo a una richiesta GET, potremmo scrivere, usando l’opzione via:

match 'products/recent', :via => :get

All’atto pratico, facciamo la stessa cosa usando il metodo più conciso get, che crea proprio un route con la stessa opzione:

get 'products/recent'

I metodi post, put e delete funzionano in modo analogo al get per gli altri tipi di richieste HTTP. Il metodo redirect, invece, si differenzia dagli altri ed è interessante perchè restituisce un’applicazione Rack:

rails/actionpack/lib/action_dispatch/routing/mapper.rb

def redirect(*args, &block)
  options = args.last.is_a?(Hash) ? args.pop : {}

  path      = args.shift || block
  path_proc = path.is_a?(Proc) ? path : proc { |params| path % params }
  status    = options[:status] || 301

  lambda do |env|
    req = Request.new(env)

    params = [req.symbolized_path_parameters]
    params << req if path_proc.arity > 1

    uri = URI.parse(path_proc.call(*params))
    uri.scheme ||= req.scheme
    uri.host   ||= req.host
    uri.port   ||= req.port unless req.standard_port?

    body = %(<html><body>You are being <a href="#{ERB::Util.h(uri.to_s)}">redirected</a>.</body></html>)

    headers = {
      'Location' => uri.to_s,
      'Content-Type' => 'text/html',
      'Content-Length' => body.length.to_s
    }

    [ status, headers, [body] ]
  end
end

Il metodo restituisce un’applicazione Rack, restituendo un array comprendente uno stato, alcuni elementi di header e un body. Lo stato è impostato per default a 301 che impone al browser un semplice redirect 301 Moved Permanently. Potremmo usare questo metodo redirect direttamente all’interno del nostro file di route se volessimo che un URL ridirigesse ad un altro. Nel nostro file di route abbiamo già un route che utilizza il parametro :to e questo parametro accetta un’applicazione Rack:

match 'products', :to => ProductsController.action("index")

Dato che il metodo redirect restituisce un’applicazione Rack, lo possiamo usare in questo caso per fare un redirect a un altro URL in questo modo:

match 'products', :to => redirect("/items")

Questa funzionalità diventa davvero utile nel momento in cui si decide di modificare gli URL dell’applicazione, ma si desidera continuare a fornire supporto agli URL vecchi. Si può usare redirect per ridirigere questi URL ai nuovi ad essi corrispondenti.

Shorthand

I moduli successivi sarebbero Scoping e Resources, ma li vediamo fra poco. Per ora, focalizziamoci sul module Shorthand. E’ un module interessante che ridefinisce il metodo match, che era stato precedentemente definito nel module Base. Questo metodo match supporta una sintassi diversa per le opzioni che è possibile passargli. Il metodo shorthand rappresenta un modo alternativo per scrivere l’opzione :to in un route tipo il redirect che abbiamo scritto poc’anzi:

match 'products', :to => redirect('/items')

Si tratta di una sintassi comune nei file di route. Il metodo shorthand ci permette di scrivere il route con un semplice hash fatto dal route e da qualunque cosa a cui il route debba puntare. Come si può fare con la sintassi estesa, è possibile aggiungere parametri in coda al route:

match 'products' => redirect('/items')

Il metodo match ridefinito in Shorthand imposta il parametro :to se non è ancora stato impostato. Poi chiama il super, ma dal momento che Mapper non eredita da un’altra classe, cosa comporta, in questo caso, la chiamata a super?

rails/actionpack/lib/action_dispatch/routing/mapper.rb

module Shorthand
  def match(*args)
    if args.size == 1 && args.last.is_a?(Hash)
      options  = args.pop
      path, to = options.find { |name, value| name.is_a?(String) }
      options.merge!(:to => to).delete(path)
      super(path, options)
    else
      super
    end
  end
end

Ogni volta che si usa super in questo modo, Ruby cerca un metodo con lo stesso nome che sia stato definito in un module a monte. Il module Shorthand è definito come ultimo nella lista di module inclusi nel Mapper, per cui Ruby controllerà nei module precedenti alla ricerca di un metodo match e delegherà ad esso. In questo caso chiamerà il match presente nel module Base.

Questa tecnica è usata spesso nel codice sorgente di Rails 3. Le prime versioni di Rails usavano l’alias_method_chain per ridefinire comportamenti specifici, ma ora, in Rails 3, possiamo più semplicemente usare il super.

Resources

Chiuso il discorso sul module Shorthand, ci occuperemo ora del Resources. Come ci si potrebbe aspettare, questo module contiene il metodo resources e tutti i metodi ad esso associati. Usiamo il metodo resources nel nostro file di route per creare route RESTful:

rails/actionpack/lib/action_dispatch/routing/mapper.rb

def resources(*resources, &block)
  options = resources.extract_options!

  if apply_common_behavior_for(:resources, resources, options, &block)
    return self
  end

  resource_scope(Resource.new(resources.pop, options)) do
    yield if block_given?

    collection_scope do
      get  :index if parent_resource.actions.include?(:index)
      post :create if parent_resource.actions.include?(:create)
    end

    new_scope do
      get :new
    end if parent_resource.actions.include?(:new)

    member_scope  do
      get    :edit if parent_resource.actions.include?(:edit)
      get    :show if parent_resource.actions.include?(:show)
      put    :update if parent_resource.actions.include?(:update)
      delete :destroy if parent_resource.actions.include?(:destroy)
    end
  end

  self
end

Questo metodo è piuttosto complesso, ma osservandone la struttura generale assume un certo significato. Ci sono un paio di metodi di collezione, get :index e post :create; c’è un metodo get :new e infine get :edit, get :show, put :update e delete :destroy. Dovreste riconoscere questi come le famose sette action RESTful che sono create per un controller quando si dichiara resources per esso nel file di route.

Si noti la prima linea di codice nel blocco del metodo resource_scope. Se viene passato un blocco al metodo, di conseguenza il metodo farà yield a tale blocco prima di creare le action RESTful. Tutto ciò ci consente di creare le nostre action personalizzate nel file di route. Per esempio, potremmo aggiungere un route di collection che restituisce i prodotti in sconto:

/config/routes.rb

Store::Application.routes.draw do
  match 'products', :to => redirect('/items')
  get 'products/recent'
  resources :products do
    collection do:
      get :discounted
    end
  end
end

Il codice dentro al blocco passato a resources nel route riportato qui sopra verrà eseguito dalla chiamata a yield in resource_scope e successivamente verranno definite le action RESTful standard. Nel blocco riportato qui sopra possiamo usare codice simile a quello presente nel metodo resources dei sorgenti di Rails, per definire le nostre action personalizzate.

Guardando i blocchi, nel file di route di sopra riportato, potreste essere indotti a pensare che l’oggetto cambi ogni volta che si crea un nuovo blocco, ma non è così. Stiamo ancora lavorando con lo stesso oggetto Mapper con cui abbiamo lavorato all’inizio, per cui chiamare get nel blocco più innestato esegue esattamente la stessa cosa che eseguirebbe richiamandolo dal più esterno. La sola cosa che cambia è che siamo in uno scope differente, ma nel parleremo a breve di questo.

Se tornate a esaminare il metodo resources del codice sorgente di Rails, vedrete che il codice utilizza una chiamata collection_scope quando definisce le action index e create, mentre all’interno dei nostri file di route utilizziamo semplicemente collection. Che differenza c’è? Beh, in realtà non molta. Se diamo un’occhiata al metodo collection nella classe Mapper, vedremo che questi delega proprio a collection_scope:

rails/actionpack/lib/action_dispatch/routing/mapper.rb

def collection
  unless @scope[:scope_level] == :resources
    raise ArgumentError, "can't use collection outside resources scope"
  end

  collection_scope do
    yield
  end
end

Riguardiamo rapidamente il file di route:

/config/routes.rb

Store::Application.routes.draw do
  match 'products', :to => redirect('/items')
  get 'products/recent'
  resources :products do
    collection do:
      get :discounted
    end
  end
end

Entrambe le chiamate a get nel codice di sopra invocano lo stesso metodo, ma quello che invoca da dentro il blocco collection assumerà un po’ di comportamento aggiuntivo a seconda dello scope in cui si trova all’interno dei blocchi resources e collection.

Se torniamo a vedere il module Resources, vedremo un metodo familiare: match. Questo metodo ridefinisce il metodo match, aggiungendo un po’ di comportamento aggiuntivo in base a resources:

rails/actionpack/lib/action_dispatch/routing/mapper.rb

def match(*args)
  options = args.extract_options!.dup
  options[:anchor] = true unless options.key?(:anchor)

  if args.length > 1
    args.each { |path| match(path, options.dup) }
    return self
  end

  on = options.delete(:on)
  if VALID_ON_OPTIONS.include?(on)
    args.push(options)
    return send(on){ match(*args) }
  elsif on
    raise ArgumentError, "Unknown scope #{on.inspect} given to :on"
  end

  if @scope[:scope_level] == :resources
    args.push(options)
    return nested { match(*args) }
  elsif @scope[:scope_level] == :resource
    args.push(options)
    return member { match(*args) }
  end

  action = args.first
  path = path_for_action(action, options.delete(:path))

  if action.to_s =~ /^[\w\/]+$/
    options[:action] ||= action unless action.to_s.include?("/")
    options[:as] = name_for_action(action, options[:as])
  else
    options[:as] = name_for_action(options[:as])
  end

  super(path, options)
end

Se osserviamo, circa a metà del codice qui sopra riportato, vedremo la linea di codice che verifica lo scope attuale per vedere se è resources. Se lo è, viene aggiunto un po’ di comportamento differente. La logica è piuttosto complessa; tutto quello che dovete sapere è che il module Resources ridefinisce il metodo match. Si noti che alla fine chiama super affinchè sia invocato il metodo match del module Base. Si tenga presente che il metodo get invoca il match ed è qui che si trova la logica addizionale per gestire la get e gli altri metodi che sono definiti in resources.

Scoping

Siamo ora giuti all’ultimo metodo della classe Mapping: Scoping. Ovunque vi sia un blocco, all’interno dei vostri file di route, dietro le quinte c’è anche una chiamata al metodo scope di Scoping. Ciò significa che questi definirà del comportamento addizionale per il codice presente all’interno del blocco.

Oltre al metodo scope, ci sono una serie di altri metodi, che delegano tutti a scope:

rails/actionpack/lib/action_dispatch/routing/mapper.rb

def initialize(*args) #:nodoc:
  @scope = {}
  super
end

def controller(controller, options={})
  options[:controller] = controller
  scope(options) { yield }
end

def namespace(path, options = {})
  path = path.to_s
  options = { :path => path, :as => path, :module => path,
              :shallow_path => path, :shallow_prefix => 			path }.merge!(options)
  scope(options) { yield }
end

def constraints(constraints = {})
  scope(:constraints => constraints) { yield }
end

def defaults(defaults = {})
  scope(:defaults => defaults) { yield }
end

Questi metodi sono tutti abbastanza semplici e delegano tutti ad un metodo più generico, previa impostazione di alcune opzioni. Per esempio, defaults chiama scope dopo aver settato alcune opzioni defaults. Analogamente, constraints invoca scope impostando alcune opzioni constraints. Il metodo namespace è un po’ più complesso, ma fa sostanzialmente la stessa cosa. Il module ha anche un metodo initialize che crea semplicemente una variabile di istanza @scope e la imposta per essere un hash vuoto. Vi potreste ancora domandare cosa ci fa in un module un metodo initialize. Anche in questo caso, nel module si sta facendo l’override di un metodo che sarà in realtà definito nella classe che include tale module. Quando il module Scoping viene incluso nella classe Mapper questo metodo initialize ridefinirà quello definito nel metodo initialize, aggiungendo la variabile @scope e poi richiamando il super.

Infine abbiamo il metodo scope, dove viene fatto il lavoro sporco. C’è molta complessità in questo metodo, ma sostanzialmente tutto ciò che fa è riempire la variabile @scope con alcune informazioni, basandosi sulle opzioni che sono state passate nello scope. Il metodo unisce le opzioni usando una serie di metodi privati nel module. Tutto ciò che fa è di immagazzinare l’informazione di scope affinchè possa essere utilizzata successivamente all’interno di qualsiasi chiamata match abbiata. Sostanzialmente aggiunge utleriori funzionalità in base allo scope corrente.

Ecco come funzionano, fondamentalmente, i blocchi definiti all’interno dei file di route. Se definiamo un route del genere:

/config/routes.rb

Store::Application.routes.draw do
  controller :products do
    match #...
  end  
end

Ogni volta che chiamiamo match nel blocco controller (e si ricordi che questi delega allo scope) le opzioni del controller saranno automaticamente fornite all’interno di questi.

E’ tutto per questo episodio. Spero che tutto ciò vi abbia chiarito meglio di come siano trattati i metodi all’interno del file di route. Anche se esistono molti metodi fra cui scegliere all’interno del file di route, molti di questi sono semplici deleganti o al metodo match o allo scope, che passano in più solo alcune opzioni.

Esploriamo il routing di Rails 3

Tue, 05 Oct 2010 20:08:14 +0000

L’episodio di questa settimana sarà un po’ diverso. Andremo infatti ad esplorare le parti interne di Rails 3 e a spulciare fra il suo codice, focalizzandoci su quello che gestisce il routing. Qui sotto è riportato il file di route dell’applicazione del negozio virtuale dell’ultimo episodio. Per poter sapere ciò che fa di fatto questo codice di routing, daremo un’occhiata al codice Rails che viene richiamato quando lo si lancia:

/config/routes.rb

Store::Application.routes.draw do
  resources :products do
    resources :reviews
  end
  root :to => "products#index"
end

Potreste domandarvi quale sia il punto di tutto ciò e se serva a qualcosa andare a vedere del codice non nostro, ma secondo me leggere codice Ruby scritto da altri è un eccellente modo di migliorare le proprie competenze in Ruby. Vedrete trucchi e tecniche che altri usano e che potrete in seguito riciclare per il vostro codice. Leggere il codice sorgente di Rails è anche un buon modo per imparare ad usare meglio Rails e proprio in questa occasione potremo scoprire modi migliori di scrivere il file di routing. Se avete intenzione di provare a debuggare un problema o di ottimizzare del codice in uno dei vostri progetti, o se state persino per considerare seriamente l’idea di contribuire a Rails, allora leggere le sue parti interne rappresenta un ottimo modo per cominciare.

Partiamo

Questo episodio tratterà alcuni aspetti avanzati, per cui si assume che conosciate già il funzionamento del routing in Rails 3. Se così non fosse, o se voleste rinfrescare le vostre conoscenze in merito, potreste guardare o leggere l’episodio 203 prima di questo, considerato anche che la sintassi di Rails 3 differisce abbastanza rispetto a Rails 2.

Il codice sorgente di Rails è conservato su Github ed è semplice clonare il repository per consultare il codice contenutovi. Dobbiamo solo lanciare:

$ git clone git://github.com/rails/rails.git

Il branch master del repository che abbiamo scaricato è per Rails 3.1, che è la versione attualemente in sviluppo, ma noi vogliamo consultare i sorgenti della stessa versione su cui gira la nostra applicazione. Possiamo spostarci alla versione taggata 3.0.0 lanciando:

$ git checkout v3.0.0

Aprendo la cartella di Rails notiamo subito che Rails è composto da tante parti differenti. Tutto ciò che concerne i controller, le viste o i route, si trova sotto la cartella actionpack, per cui è questa la parte del codice che ci interessa:

Sotto actionpack la maggior parte del codice riguardante il routing è sotto la cartella lib/action_dispatch:

I metodi `routes` e `draw`

Prima di cominciare a guardare il codice sorgente di Rails, ritorniamo alla nostra applicazione e guardiamo nuovamente il file di route:

/config/routes.rb

Store::Application.routes.draw do
  resources :products do
    resources :reviews
  end
  root :to => "products#index"
end

La prima linea del codice riportato di sopra chiama un metodo chiamato routes sulla classe Store::Application, dove Store è il nome della nostra applicazione. Se guardiamo al file application.rb, vedremo che tale nome dell’applicazione è definito proprio là:

/config/application.rb

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

require 'rails/all'

# If you have a Gemfile, require the gems listed there, including any gems
# you've limited to :test, :development, or :production.
Bundler.require(:default, Rails.env) if defined?(Bundler)

module Store
  class Application < Rails::Application
     # Configure sensitive parameters which will be filtered from the log file.
    config.filter_parameters += [:password]
  end
end

La classe Store::Application è dove molte delle configurazioni dell’applicazione avvengono e specializza da Rails::Application. Ogni cosa prefissata dal namespace Rails è tipicamente definita nella cartella railties nel codice sorgente Rails; il codice della classe per Rails::Application è definito in rails/railties/lib/rails/application.rb e in questo file troveremo il metodo routes:

rails/railties/lib/rails/application.rb

def routes
  @routes ||= ActionDispatch::Routing::RouteSet.new
end

Questo è il metodo che viene richiamato nel file di route della nostra applicazione e tutto ciò che fa è di creare una nuova ActionDispatch::Routing::RouteSet. Il metodo route restituisce questo nuovo RouteSet e nella prima riga del nostro file di route chiamiamo proprio la draw su questo oggetto. Vediamo ciò che fa il metodo draw.

Nel codice sorgente di Rails una classe la si può spesso trovare in un file omonimo o dal nome analogo, infatti la classe RouteSet non fa eccezione. All’interno della classe troviamo il metodo draw:

rails/actionpack/lib/action_dispatch/routing/route_set.rb

def draw(&block)
  clear! unless @disable_clear_and_finalize

  mapper = Mapper.new(self)
  if block.arity == 1
    mapper.instance_exec(DeprecatedMapper.new(self), &block)
  else
    mapper.instance_exec(&block)
  end

   finalize! unless @disable_clear_and_finalize

   nil
end

Il metodo draw accetta un blocco per argomento. Per prima cosa ripulisce qualsiasi eventuale route già presente, poi crea un nuovo oggetto Mapper, passando ad esso self (il RouteSet). (Approfondiremo la classe Mapper fra poco.) Dopodichè il metodo controlla l’arity del blocco, ossia quanti argomenti sono stati passati ad esso. Se gli è stato passato un unico argomento, allora significa che il file di routing sta usando una sintassi Rails 2. Tutto ciò viene fatto ovviamente per avere retrocompatibilità con le versioni precedenti a Rails 3, che passano una variabile map al blocco, in questo modo:

/config/routes.rb

Store::Application.routes.draw do |map|
  # Instaradamenti a la Rails 2...
end

A prescindere poi che l’applicazione usi una sintassi di routing stile Rails 2 piuttosto che Rails 3, viene chiamata una instance_exec. Nel caso di sintassi Rails 3, si passa direttamente il blocco a tale metodo, mentre invece se si tratta di sintassi Rails 2, viene creato un nuovo oggetto DeprecatedMapper che viene passato come primo argomento oltre al blocco. In entrambi i casi, ciò farà sì che il blocco sia eseguito come se fosse stato definito all’interno dell’istanza del mapper. La conseguenza di questa azione implica che tutto ciò che è definito all’interno del blocco nel file di route, viene invocato sull’istanza di un oggetto Mapper. Questo trucco ci rende disponibile quella potente sintassi domain-specific dei file di route in Rails 3, nei quali è possibile chiamare semplicemente dei metodi tipo resources senza la necessità di dover esplicitamente farlo su istanze specifiche di una determinata classe, come invece si faceva in Rails 2, quando si usava la map.resources.

L’ultima cosa che viene fatta dal metodo draw è la chiamata al finalize!, che è definito nella classe RouteSet e che "congela" l’insieme dei route.

Come avviene il mapping di un route

Ora che sappiamo che tutto quanto si trova dentro al file di route in Rails 3 viene invocato su di un’istanza di Mapper, usiamo un semplice route come esempio e vediamo come viene processato:

/config/routes.rb

Store::Application.routes.draw do
  match 'products', :to => 'products#index'
end

Diamo un’occhiata alla classe Mapper per vedere cosa fa il metodo match. Ci sono molti metodi denominati match all’interno di quella classe; quello che ci interessa è nel module Base:

rails/actionpack/lib/action_dispatch/routing/mapper.rb

module Base
  def initialize(set) #:nodoc:
    @set = set
  end

  def root(options = {})
    match '/', options.reverse_merge(:as => :root)
  end

  def match(path, options=nil)
    mapping = Mapping.new(@set, @scope, path, options || {}).to_route
    @set.add_route(*mapping)
    self
  end

  # other methods

end

Per creare un nuovo oggetto Mapper, dobbiamo passare al costruttore un oggetto RouteSet. Infatti, quando viene invocato il metodo match nel file di route per creare un nuovo route, questo nuovo route viene aggiunto all’insieme passato. Tutto ciò avviene mediante la creazione di un nuovo oggetto di tipo Mapping e la conseguente invocazione su di esso del metodo to_route. Si noti anche il metodo root, che è molto semplice. Tutto ciò che fa è chiamare match, passandogli l’URL di root e aggiungendo l’opzione :as => :root, affinchè diventi un named route. Ogni volta che si definisce nella propria applicazione Rails un URL di root, dietro le quinte viene dunque semplicemente invocato il metodo match.

Ora vediamo più in dettaglio la classe Mapping, definita nel file mapper.rb:

rails/actionpack/lib/action_dispatch/routing/mapper.rb

class Mapping #:nodoc:
  IGNORE_OPTIONS = [:to, :as, :via, :on, :constraints, :defaults, :only, :except, :anchor, :shallow, :shallow_path, :shallow_prefix]

  def initialize(set, scope, path, options)
    @set, @scope = set, scope
    @options = (@scope[:options] || {}).merge(options)
    @path = normalize_path(path)
    normalize_options!
  end

  def to_route
    [ app, conditions, requirements, defaults, @options[:as], @options[:anchor] ]
  end

  private 

  def normalize_options!
    path_without_format = @path.sub(/\(\.:format\)$/, '')

    if using_match_shorthand?(path_without_format, @options)
      to_shorthand    = @options[:to].blank?
      @options[:to] ||= path_without_format[1..-1].sub(%r{/([^/]*)$}, '#\1')
      @options[:as] ||= Mapper.normalize_name(path_without_format)
    end

    @options.merge!(default_controller_and_action(to_shorthand))
  end

  # other private methods omitted.

end

All’atto dell’inizializzazione del Mapper, sono impostate alcune variabili di istanza in base ai parametri passati, dopodichè viene invocato il normalize_options!. Il metodo normalize_options! esegue un controllo per vedere se si sta utilizzando un determinato tipo di sintassi "abbreviata" nel file di route e nel metodo using_match_shorthand? che viene chiamato, osserviamo un interessante escamotage. Esiste un modo rapido per definire le action di un controller in cui si separa il controller e i nomi delle action con uno slash:

rails/actionpack/lib/action_dispatch/routing/mapper.rb

# match "account/overview"
def using_match_shorthand?(path, options)
  path && options.except(:via, :anchor, :to, :as).empty? && path =~ %r{^/[\w\/]+$}
end

Se abbiamo definito il nostro route in questo modo, allora le opzioni :to e :as saranno impostate per noi, a seconda del nome dell’URL. Verifichiamolo tornando al file di route della nostra applicazione, aggiungendo un altro route che utilizzi la sintassi smart:

/config/routes.rb

Store::Application.routes.draw do
  match 'products', :to => 'products#index'
  match 'products/recent', :to => 'products#recent'
end

Abbiamo fornito un parametro :to a questo nuovo route, ma verrebbe comunque aggiunto automaticamente se non lo avessimo specificato. Il metodo di shortcut crea automaticamente per noi anche un parametro :as, come se avessimo aggiunto :as => :products_recent.

Come viene usato Rack nel routing

Tornando al metodo match, una volta creato un nuovo oggetto Mapping, richiamiamo il metodo to_route su di esso. Questo metodo restituisce un array di opzioni che sono usate per creare un nuovo route:

rails/actionpack/lib/action_dispatch/routing/mapper.rb

def to_route
  [ app, conditions, requirements, defaults, @options[:as], @options[:anchor] ]
end

I primi quattro elementi nell’array di sopra sono i valori restituiti dalle chiamate ai metodi presenti nella classe Mapper:

rails/actionpack/lib/action_dispatch/routing/mapper.rb

def app
  Constraints.new(
    to.respond_to?(:call) ? to : Routing::RouteSet::Dispatcher.new(:defaults => defaults),
    blocks,
    @set.request_class
  )
end

def conditions
  { :path_info => @path }.merge(constraints).merge(request_method_condition)
end

def requirements
  @requirements ||= (@options[:constraints].is_a?(Hash) ? @options[:constraints] : {}).tap do |requirements|
    requirements.reverse_merge!(@scope[:constraints]) if @scope[:constraints]
    @options.each { |k, v| requirements[k] = v if v.is_a?(Regexp) }
   end
end

def defaults
  @defaults ||= (@options[:defaults] || {}).tap do |defaults|
    defaults.reverse_merge!(@scope[:defaults]) if @scope[:defaults]
    @options.each { |k, v| defaults[k] = v unless v.is_a?(Regexp) || IGNORE_OPTIONS.include?(k.to_sym) }
  end
end

La prima opzione è app; ogniqualvolta vediate un qualcosa chiamato app nel codice sorgente di Rails, è molto probabile che si faccia riferimento a un’applicazione Rack. Questo metodo app restituisce un nuovo oggetto Constraints, per cui vediamo se si tratta effettivamente, in questo caso, di un’applicazione Rack.

La classe Constraints è definita nello stesso file mapper.rb. Accetta una serie di metodi, uno dei quali è chiamato call e prende in ingresso come parametro un environment:

rails/actionpack/lib/action_dispatch/routing/mapper.rb

def call(env)
  req = @request.new(env)

  @constraints.each { |constraint|
    if constraint.respond_to?(:matches?) && !constraint.matches?(req)
      return [ 404, {'X-Cascade' => 'pass'}, [] ]
    elsif constraint.respond_to?(:call) && !constraint.call(*constraint_args(constraint, req))
      return [ 404, {'X-Cascade' => 'pass'}, [] ]
    end
  }

  @app.call(env)
end

La classe Constraints sembra proprio un’applicazione Rack. Una cosa interessante sulla classe Constraints è che fa l’override del metodo self.new. Potreste domandarvi il perchè, dal momento che esiste già anche un metodo initialize:

rails/actionpack/lib/action_dispatch/routing/mapper.rb

def self.new(app, constraints, request = Rack::Request)
  if constraints.any?
    super(app, constraints, request)
  else
    app
  end
end

attr_reader :app

def initialize(app, constraints, request)
  @app, @constraints, @request = app, constraints, request
end

La ragione dietro a questa scelta è solo di performance. Constraints è un pezzo del middleware di Rack; in altri termini, racchiude un’altra applicazione Rack. Il primo argomento passato al self.new è app, che rappresenta un’applicazione Rack; quando viene invocato il metodo call, se viene scatenato uno dei constraints, restituisce un errore 404, altrimenti scatenerà l’applicazione Rack che sta wrappando. Il metodo self.new fa parte di logiche di ottimizzazione di performance e serve affinchè, quando viene chiamato, Rails non allochi un altro oggetto in memoria, wrappandolo e usandolo, ma piuttosto restituisca semplicemente l’applicazione Rack iniziale stessa.

Torniamo ora al codice che richiama tutto ciò. Si noti che i primi due argomenti sono una applicazione Rack e un array di vincoli. Il tutto viene richiamato nel metodo app della classe Mapping. Quando qui si crea un nuovo vincolo, controlliamo per vedere se il metodo to risponde al call. (Il metodo to restituisce semplicemente l’opzione :to che era stata definita per il route.) In caso affermativo, si tratta di un’applicazione Rack e viene passata questa; altrimenti si passa un nuovo oggetto RouteSet::Dispatcher con un paio di opzioni di default:

rails/actionpack/lib/action_dispatch/routing/mapper.rb

def app
  Constraints.new(
    to.respond_to?(:call) ? to : Routing::RouteSet::Dispatcher.new(:defaults => defaults),
    blocks,
    @set.request_class
  )
end

E’ questo codice a darci la possibilità di passare un’applicazione Rack ad un route in questa maniera:

  root :to => proc { |env| [200, {}, ["Welcome"]] }

Ci sono più approfondimenti sull’uso di Rack nei route nell’episodio 222 [guardalo, leggilo]. Poterlo usare nei route ci da molta flessibilità.

Se non passiamo un’applicazione Rack all’opzione :to, allora viene creato un nuovo oggetto RouteSet::Dispatcher. Vediamo ora come viene gestito quest’ultimo.

La classe Dispatcher gestisce lo smistamento di una richiesta al controller corretto che dovrà servirla. Nel suo metodo controller_reference si può vedere il codice dove viene identificato l’opportuno controller:

rails/actionpack/lib/action_dispatch/routing/route_set.rb

def controller_reference(controller_param)
  unless controller = @controllers[controller_param]
    controller_name = "#{controller_param.camelize}Controller"
    controller = @controllers[controller_param] =
       ActiveSupport::Dependencies.ref(controller_name)
  end
  controller.get
end

Questa classe ha anche dei metodi per fare cose tipo impostare l’action di default a index se non ne è stata definita una e un metodo dispatch che chiama la action stessa e che restituisce un’applicazione Rack. Tutto ciò significa che possiamo prendere uno qualsiasi dei nostri controller, chiamare action su di esso, passandogli il nome della action e ottenendo un’applicazione Rack in risposta:

ruby-1.9.2-p0 > ProductsController.action("index")
 => #<Proc:0x00000100ec56c0@/Users/asalicetti/.rvm/gems/ruby-1.9.2-p0/gems/actionpack-3.0.0/lib/action_controller/metal.rb:172>

Questo è quel che succede dietro le quinte quando passiamo un file di route tipo questo:

match 'products', :to => 'products#index'

La stringa products#index è convertita in ProductsController.action("index") e questa restituisce un’applicazione Rack. La sintassi della stringa è una banale scorciatoia per fare la stessa cosa.

C’è molto altro in merito al routing che potremmo dire in questo episodio, ma questo sembra anche un buon momento per fermarsi. Ci sono i metodi resources che generano una serie di route, ci sono i vari metodi che permettono di limitare le condizioni a determinati scope e passare blocchi a queste affinchè sia possibile realizzare un cascade di scope, ma in effetti fin qui c’è abbastanza per incoraggiarvi ad esplorare per conto vostro il codice di routing.

Il routing è una delle aree più complicata di Rails, per cui se siete un po’ intimoriti dalla complessità del codice che vi troverete di fronte, non vi preoccupate: è davvero complesso. Partite con alcune altre parti del codice di Rails prima e fateci il callo prima di affrontare parti più complesse.

Risorse ereditate

Mon, 20 Sep 2010 09:14:58 +0000

In questo episodio daremo un’occhiata al gem di José Valim chiamato Inherited Resources. Questo gem estrae funzionalità comuni dai controller RESTful e ci permette in tal modo di rimovere alcune duplicazioni dal codice dei nostri controller. Non si tratta del primo gem Rails a fornire questo genere di funzionalità: nell’episodio 92 abbiamo parlato di un gem chiamato make_resourceful analogo e esistono anche diversi plugin che fanno la stessa cosa. Ciascuno segue un approccio lievemente diverso, per cui, al solito, vale la pena cofrontarli fra loro prima di decidere quale usare. Noi abbiamo scelto Inherited Resources dal momento che funziona bene con Rails 3.0 e sembra anche quello più aggiornato.

L’applicazione Rails con cui lavoreremo in questo episodio sarà una semplice applicazione di e-commerce. Questa applicazione ha un elenco di prodotti e ciascuno di essi ha una serie di recensioni ad esso associate:

Usereme Inherited Resources per ripulire un po’ il codice di questa applicazione e vedere quanto codice dei controller potremo rimuovere senza intaccare le funzionalità applicative.

Installazione di Inherited Resources

Il codice del ProductController attualmente appare così:

/app/controllers/products_controller.rb

class ProductsController < ApplicationController
  def index
    @products = Product.all
  end

  def show
    @product = Product.find(params[:id])
  end

  def new
    @product = Product.new
  end
  
  def create
    @product = Product.new(params[:product])
    if @product.save
      flash[:notice] = "Successfully created product."
      redirect_to @product
    else
      render :action => 'new'
    end
  end
  
  def edit
    @product = Product.find(params[:id])
  end
  
  def update
    @product = Product.find(params[:id])
    if @product.update_attributes(params[:product])
      flash[:notice] = "Successfully updated product."
      redirect_to @product
    else
      render :action => 'edit'
    end
  end
  
  def destroy
    @product = Product.find(params[:id])
    @product.destroy
    flash[:notice] = "Successfully destroyed product."
    redirect_to products_url
  end

end

Se avete diversi controller RESTful nella vostra applicazione, vi troverete a scrivere del codice tipo questo in ciascuno di essi ed è proprio in situazioni del genere che Inherited Resources si rivela molto utile. Se, tuttavia, in generale tendete a rendere molto personalizzate le logiche dei controller, allora un’astrazione come quella proposta da Inherited Resources potebbe non fare al caso vostro. Il controller riportato di sopra aderisce al pattern RESTful abbastanza bene, per cui possiamo usarlo per vedere ciò che è offerto dal gem Inherited Resources.

La nostra applicazione di e-commerce è scritta in Rails 3, per cui aggiungiamo Inherited Resources ad essa, includendo il gem nel nostro Gemfile:

/Gemfile

source 'http://rubygems.org'

gem 'rails', '3.0.0'

gem 'sqlite3-ruby', :require => 'sqlite3'
gem 'nifty-generators'
gem 'inherited_resources'

Lo si installa al solito modo con:

$ bundle install

Ciò, come sempre, causerà l’installazione del gem e di un paio di dipendenze: has_scope e responders.

Una volta installati i gem, si può aggiornare il nostro ProductsController per fargli usare le Inherited Resources. Per farlo, renderemo il controller specializzazione di InheritedResources::Base anzichè di ApplicationController. InheritedResources::Base specializza ApplicationController, per cui esporrà anche tutte le funzionalità del padre.

Poichè il ProductsController è un controller RESTful abbastanza standard, possiamo sostituire tutti i suoi metodi con il codice ereditato da Inherited Resources, riducendo così il codice:

/app/controllers/products_controller.rb

class ProductsController < InheritedResources::Base

end

Dobbiamo riavviare il server per fare in modo che i nuovi gem vengano ricaricati, ma una volta fatto, vedremo che le pagine relative ai prodotti funzionano esattamente come prima. Possiamo persino creare un nuovo prodotto con successo e avere anche il messaggio flash di conferma:

Personalizzare una action

Quando abbiamo creato un nuovo prodotto, prima, siamo stati ridiretti alla pagina di dettaglio (show) dello stesso al termine dell’operazione, ma come potremmo fare per far sì che l’applicazione ci mandi piuttosto alla action index? Inherited Resources ci permette di ridefinire una qualunque delle proprie action di default, semplicemente ridefinando il metodo opportuno nel controller, per cui potremmo scrivere un metodo create nel ProductsController che crei il nuovo prodotto e che rimandi alla action index.

Non c’è bisogno, tuttavia, di riscrivere completamente la action create solo per modificare il redirect. Possiamo includere il comportamento di Inherited Resource chiamando il metodo create! e passandogli un blocco. Il cambio dell’URL di redirect alla creazione di un nuovo oggetto di modello è un’operazione piuttosto comune che si vorrebbe poter fare, per cui possiamo semplicemente restituire l’URL desiderato nel blocco:

/app/controllers/products_controller.rb

class ProductsController < InheritedResources::Base
  def create
    create! { products_path }
  end
end

Ci sono altre cose che potremmo fare nel blocco e sono tutte spiegate nella documentazione.

Ora, creando un nuovo prodotto, siamo ridiretti alla action index proprio come volevamo:

Lavorare con formati differenti

Se vogliamo che il controller sia in grado di rispondere in diversi formati, tipo XML e HTML, è semplice. Basta aggiungere la respond_to proprio come faremmo in un normale controller Rails 3:

/app/controllers/products_controller.rb

class ProductsController < InheritedResources::Base
  respond_to :html, :xml

  def create
    create! { products_path }
  end
end

Ciò funzionerà allo stesso modo mostrato nell’episodio 224 [guardalo, leggilo]. Se ora visitiamo /products.xml otterremo una lista di prodotti in XML:

Nested Resource

Ora che abbiamo ripulito il ProductsController, spostiamo l’attenzione sul ReviewsController. Le opinioni sono annidate sotto i prodotti, per cui la review di un articolo sarà all’URL /products/1/reviews per il prodotto di id pari a 1. Questo per quel che riguarda la action index del ReviewsController. Analogamente, se aggiungiamo una opinione, l’URL sarà sempre innestato sotto i prodotti:

Il codice per il ReviewsController appare così:

/app/controllers/reviews_controller.rb

class ReviewsController < ApplicationController
  def index
    @product = Product.find(params[:product_id])
    @reviews = @product.reviews
  end

  def new
    @product = Product.find(params[:product_id])
    @review = Review.new
  end
  
  def create
    @product = Product.find(params[:product_id])
    @review = @product.reviews.build(params[:review])
    if @review.save
      flash[:notice] = "Successfully created review."
      redirect_to product_reviews_path(@product)
    else
      render :action => 'new'
    end
  end

end

La differenza più evidente fra questo controller e il ProductsController è che il primo ha solo tre delle sette action RESTful. L’altra differenza è che, siccome gestisce l’innestamento, ciascuna action ottiene il prodotto di riferimento basandosi su un parametro nell’URL.

Anche se in questo contesto si tratta di una risorsa innestata, il comportamento è fondamentalmente lo stesso che quello nel ProductsController e le Inherited Resources funzioneranno bene anche qui. Possiamo rimuovere il codice esistente nel controller e cambiare la tassonomia della classe, affinchè erediti da InheritedResources::Base. Tutto quello che dobbiamo fare per gestire l’innestamento è di aggiungere belongs_to, che è un metodo fornito da Inherited Resources e che può essere usato nella definizione di relazioni fra controller allo stesso modo in cui lo si fa fra modelli. Sistemato tutto ciò, Inherited Resources gestisce il recupero del prodotto corretto al posto nostro:

/app/controllers/reviews_controller.rb

class ReviewsController < InheritedResources::Base
  belongs_to :product
end

Per come è ora, il ReviewsController esporrà tutte e sette le action di default, dal momento che questo è il comportamento di default di Inherited Resources, ma noi vogliamo che questo controller si limiti a rispondere solamente a index, new e create. Possiamo usare il metodo actions per limitare le action disponibili:

/app/controllers/reviews_controller.rb

class ReviewsController < InheritedResources::Base
  belongs_to :product
  actions :index, :new, :create
end

Come fatto già per il ProductsController, vogliamo anche cambiare l’URL a cui rimandiamo a seguito della creazione di una nuova opinione. Ci sono molti metodi helper per gli URL forniti da Inherited Resources per ridirigere a varie action, che tornano utili in questo caso in cui abbiamo un innestamento. In questo caso possiamo usare un metodo chiamato collection_url che ridirige alla action index e gestisce l’innestamento per noi:

/app/controllers/reviews_controller.rb

class ReviewsController < InheritedResources::Base
  belongs_to :product
  actions :index, :new, :create
  
  def create
    create! { collection_url }
  end
end

Possiamo testare il tutto aggiungendo una opinione:

Dopo che abbiamo fatto il submit della nuova opinione verremo ridiretti alla pagina delle opinioni per tale prodotto proprio come volevamo:

Scope pubblici

Inherited Resources ha un’altra utile funzionalità chiamata has_scope. Per usarla, dobbiamo solo aggiungere un riferimento al gem nel Gemfile e poi rilanciare bundle install:

/Gemfile

source 'http://rubygems.org'

gem 'rails', '3.0.0'

gem 'sqlite3-ruby', :require => 'sqlite3'
gem 'nifty-generators'
gem 'inherited_resources'
gem 'has_scope'

Installato il tutto, possiamo chiamare has_scope in qualsiasi dei nostri controller passandogli il nome di uno scope presente sul modello associato. Per questo esempio, aggiungeremo lo scope limit, che è fornito per default a tutti i modelli in Rails 3, al ProductsController:

/app/controllers/products_controller.rb

class ProductsController < InheritedResources::Base
  respond_to :html, :xml
  
  has_scope :limit

  def create
    create! { products_path }
  end
end

Con questo codice, possiamo aggiungere scope come parametri all’URL, per cui se passiamo un parametro limit, verrà chiamato tale scope e ridurremo il numero di prodotti mostrati:

Se volessimo applicare lo scope per tutte le query su quel controller, implicitamente, senza che sia necessario aggiungerlo come parametro alla stringa di query, potremmo dichiararlo con l’opzione default e un valore per il parametro:

/app/controllers/products_controller.rb

class ProductsController < InheritedResources::Base
  respond_to :html, :xml
  
  has_scope :limit, :default => 3

  def create
    create! { products_path }
  end
end

Ora, se non passiamo un parametro limit verrà usato il valore di default e, in questo caso, vedremo solo tre prodotti:

Tutto ciò funziona naturalemente anche con gli scope personalizzati. Aggiungeremo uno scope al modello Review che ci permetterà di filtrare le opinioni in base al loro punteggio:

/app/models/review.rb

class Review < ActiveRecord::Base
  belongs_to :product
  scope :rating, proc { |rating| where(:rating => rating) }
end

Ora rendiamo lo scope pubblico, aggiungendolo al ReviewsController:

/app/controllers/reviews_controller.rb

class ReviewsController < InheritedResources::Base
  belongs_to :product
  actions :index, :new, :create
  has_scope :rating
  
  def create
    create! { collection_url }
  end
end

Possiamo ora usare un parametro rating nell’URL, per limitare le opinioni in base al loro punteggio.

Il gem has_scope può essere utilizzato al di fuori di Inherited Resources usando il metodo apply_scopes all’interno della action index. Ci sono ulteriori dettagli su tutto ciò nella documentazione su Github.

Personalizzare il messaggio flash

L’ultima cosa che tratteremo sarà come personalizzare il messaggio flash. Quando creiamo una nuova opinione, il messaggio di default è “Review was successfully created.”, ma noi vorremo modificarlo affinchè sia qualsiasi cosa che vogliamo, cambiando il file di internazionalizzazione. Anche se la vostra applicazione non supporta linguaggi multipli, questi file sono il posto migliore dove mettere le stringhe che verranno mostrate sull’interfaccia utente. Ogni applicazione Rails 3 ha un file di localizzazione inglese incluso al suo interno, sotto /config/locales/en.yml.

Per ridefinire il messaggio flash di default di Inherited Resources, creiamo una chiave flash:, sotto la quale avremo una chiave contenente il nome del controller, in questo caso reviews:. Sotto di essa, aggiungiamo una chiave per la action e sotto quest’ultima, una per il nome del messaggio di flash. Per il nostro controller delle opinioni, il file di configurazione apparirà così:

/config/locales/en.yml

# Sample localization file for English. Add more files in this directory for other locales.
# See http://github.com/svenfuchs/rails-i18n/tree/master/rails%2Flocale for starting points.

en:
  flash:
    reviews:
      create:
        notice: "Your review has been created!"

Se non vogliamo dover configurare tutto ciò per ogni controller della nostra applicazione, possiamo sostituire il nome del controller con actions: e di conseguenza i messaggi saranno applicati a tutti i singoli controller. Possiamo usare una variabile resource_name a mo’ di placeholder, per attualizzare il nome del modello corrente.

/config/locales/en.yml

# Sample localization file for English. Add more files in this directory for other locales.
# See http://github.com/svenfuchs/rails-i18n/tree/master/rails%2Flocale for starting points.

en:
  flash:
    actions:
      create:
        notice: "Your {{resource_name}} has been created!"

Possiamo provare il tutto, creando una nuova opinione.. Al submit, verrà mostrato il messaggio flash così personalizzato:

E’ tutto per questo episodio. Se vi trovate a creare sempre lo stesso codice per i controller, vale la pena dare un’occhiata a Inherited Resources. Il file README è piuttosto esaustivo e tratta anche di parti che non abbiamo menzionato in questo episodio. Vale anche la pena consultare la wiki page.

Fare polling per verificare modifiche

Mon, 20 Sep 2010 09:00:01 +0000

Si immagini di avere un’applicazione di blogging che consenta ai suoi utenti di aggiungere commenti agli articoli. Il blog è molto popolare, per cui vengono aggiunti nuovi commenti abbastanza di frequente. Se qualcuno arriva sul sito per leggere un articolo e i suoi commenti e poi decide di aggiungere il proprio commento, è possibile che nel momento che intercorre fra il suo arrivo sul sito e il suo commento, altri nuovi commenti siano nel frattempo stati aggiunti all’articolo, rendendo potenzialmente il commento che quell’utente voleva inserire scorretto o irrilevante. Perciò sarebbe utile che la pagina dell’articolo si mantenesse aggiornata automaticamente, aggiungendo, sempre in automatico, tutti i nuovi commenti aggiunti a seguito dell’ultimo caricamento della pagina. Vi mostreremo come farlo in questo episodio.

Configurazione di jQuery

Dovremo usare del JavaScript per aggiornare la pagina al volo ed in particolare useremo jQuery al posto di Prototype come nostra libreria JavaScript preferita. Dal momento che la nostra applicazione è scritta in Rails 3, possiamo utilizzare il gem jquery-rails per rendere semplice la sostituzione dei file di Prototype con quelli di jQuery.

Per usare il gem, dobbiamo semplicemente aggiungere un riferimento ad esso nel Gemfile della nostra applicazione:

/Gemfile

gem 'jquery-rails'

Poi possiamo fare in modo che il tutto sia scaricato e installato lanciando:

$ bundle install

Dopo che Bundler avrà finito il suo lavoro, sarà disponibile un nuovo generatore che potremo lanciare per configurare jQuery nella nostra applicazione. Quando lo lanciamo, questi rimuoverà i file di Prototype, aggiungerà quelli di jQuery e infine sovrascriverà il file di default rails.js della nostra applicazione con una versione dello stesso compatibile con jQuery (se volete installare la libreria UI di jQuery insieme a jQuery, potete passare l’opzione --ui al generatore):

$ rails g jquery:install
      remove  public/javascripts/controls.js
      remove  public/javascripts/dragdrop.js
      remove  public/javascripts/effects.js
      remove  public/javascripts/prototype.js
      create  public/javascripts/jquery.min.js
      create  public/javascripts/jquery.js
    conflict  public/javascripts/rails.js
Overwrite /Users/asalicetti/rails/apps_for_asciicasts/ep229/blog/public/javascripts/rails.js? (enter "h" for help) [Ynaqdh] Y
       force  public/javascripts/rails.js

Una delle cose più utili del gem jquery-rails è che ridefinisce in automatico i default che sono inclusi quando si usa la linea:

<%= javascript_include_tag :defaults %>

nel nostro file di layout, per cui non c’è bisogno di fare modifiche là.

Configurare Polling

Ora che abbiamo configurato jQuery nella nostra applicazione, possiamo cominciare a fare il lavoro necessario per l’auto-aggiornamento dei commenti. Ci sono due modi in cui possiamo affrontare il problema. Uno prevede l’utilizzo del polling. La nostra applicazione può inviare delle richieste AJAX al server a periodi di tempo regolari per capire se il numero dei commenti è cambiato. L’alternativa è di usare WebSockets per fornire una connessione permanente al server e ricevere in push le notifiche da esso non appena sono disponibili. Il polling è la scelta più semplice fra le due, considerato anche che WebSockets non è ancora supportato da tutti i browser e che necessiterebbe della stesura di una maggior quantità di codice e introdurrebbe anche una nuova dipendenza con una libreria di terzi, tipo Cramp per funzionare. Non abbiamo bisogno di un sincronismo così stretto per il nostro caso, per cui un ritardo di qualche secondo è perfettamente accettabile e per questo seguiremo l’approccio a polling.

Scriveremo il JavaScript che si occuperà di fare le richieste in polling alla ricerca di cambiamenti nel file application.js. Questo file è presente in tutte le pagine dell’applicazione, per cui dovremo anche assicurarci che lo stesso esegua solamente nelle pagine che contengono commenti al loro interno. Il codice per il polling è il seguente:

/public/javascripts/application.js

$(function () {
  if ($('#comments').length > 0) {
    setTimeout(updateComments, 10000);
  }
});

function updateComments() {
  $.getScript('/comments.js');
  setTimeout(updateComments, 10000);
}

Il codice riportato qui sopra comincia con una chiamata alla funzione jQuery $. Quando questa funzione viene chiamata con un argomento di tipo funzione, come in questo caso, il codice all’interno della funzione esegue solo dopo che il DOM della pagina è stato caricato completamente. In questo caso, quando il DOM si carica, controlliamo se la pagina corrente è quella di un articolo, cercando la presenza di un elemento con id uguale a comments. Se lo si trova, allora usiamo la setTimeout per chiamare la funzione updateComments dopo un ritardo di dieci secondi.

All’interno della funzione updateComments vogliamo recuperare tutti i commenti aggiornati per l’articolo. Ci sono molti modi per farlo. Potremmo chiedere al server i nuovi commenti in formato JSON e usarli per creare l’HTML per i nuovi commenti, ma in questo caso il problema sarebbe che la updateComments dovrebbe poi generare l’HTML corretto per questi nuovi commenti. Sarebbe più semplice generare l’HTML già lato server e restituire il JavaScript che aggiornerà la pagina per aggiungere tale HTML al posto giusto.

Per fare tutto questo, usiamo la funzione jQuery getScript. Se passiamo a questa funzione un URL, essa farà una richiesta AJAX a tale URL ed eseguirà qualsiasi script che le verrà restituito in risposta. Useremo dunque la getScript per chiamare la action index del CommentsController con un formato JavaScript. Dobbiamo aggiungere alcuni parametri di query all’URL affinchè la action sappia quali commenti dovrebbero esserci restituiti, ma ritorneremo su questo punto in seguito.

Dopo che la getScript ha completato la sua esecuzione, invochiamo nuovamente la setTimeout, affinchè la updateComments sia nuovamente chiamata dopo dieci secondi. Avremmo potuto usare la setInterval al posto della setTimeout per il controllo dell’esistenza dell’elemento dei commenti, in modo tale da non dover richiamare la funzione anche qui, ma in realtà c’è un vantaggio nel seguire il nostro approccio. Se avessimo utilizzato la setInterval, di conseguenza la updateComments sarebbe stata chiamata ogni dieci secondi a prescindere dal tempo necessario alla risposta AJAX. Invece, per come l’abbiamo implementata noi, tale richiesta di aggiornamento verrà fatta sempre dieci secondi dopo che ci è arrivata la risposta: in questo modo evitiamo di sovraccaricare ulteriormente il server quando è già molto carico di suo.

Al momento, il CommentsController non ha una action index, per cui dovremo scriverla. Dovrà recuperare gli opportuni commenti usando i parametri passati dal JavaScript di prima, ma per ora lasciamo vuoto il metodo:

/app/controllers/comments_controller.rb

def index

end

Dovremo anche avere un template JavaScript da associare alla action. In esso, sempre momentaneamente, metteremo del codice di test per controllare che il polling stia funzionando a dovere:

/app/views/comments/index.js.erb

alert('Comments go here');

Facendo ripartire il server e visitando la pagina dell’articolo, ora vedremo comparire un alert circa ogni dieci secondi dopo che la pagina si è caricata, che significa che il JavaScript di sopra viene restituito dal server ed eseguito correttamente sul client:

Recupero dei commenti corretti

Ora che il polling funziona, il prossimo passo è quello di recuperare i commenti significativi. Dobbiamo aggiungere due parametri alla chiamata della action index del CommentController: l’id dell’articolo corrente e un timestamp, in modo tale che sappiamo quali commenti recuperare:

/public/javascripts/application.js

function updateComments() {
  $.getScript('/comments.js?article_id=' + article_id + "&after=" + after);
  setTimeout(updateComments, 10000);
}

Ciò che dobbiamo ancora capire del codice sopra è da dove prendere i valori per le variabili article_id e after, che non abbiamo ancora definito. In questo caso possiamo generare i valori in Rails e passarli al JavaScript dal documento HTML. Questa applicazione usa HTML 5, per cui possiamo utilizzare gli attributi data per aggiungere dati al documento.

Aggiungeremo gli attributi al codice della vista relativa alla action show del ArticleController. Gli attributi data possono avere un qualsiasi nome, purchè iniziante per data-, per cui aggiungeremo un attributo data-id al div contenitore dell’articolo, con valore pari all’id dell’articolo e in modo analogo, nel div contenitore dei commenti, aggiungeremo un nuovo attributo data-time, contenente il valore created_at del commento, convertito a intero:

/app/views/articles/show.html.erb

<% title @article.name %>

<div id="article" data-id="<%= @article.id %>">
  <%= simple_format @article.content %>
  
  <p><%= link_to "Back to Articles", articles_path %></p>
  
  <% unless @article.comments.empty? %>
    <h2><%= pluralize(@article.comments.size, 'commment') %></h2>
    
    <div id="comments">
    <% for comment in @article.comments %>
      <div class="comment" data-time="<%= comment.created_at.to_i %>">
        <strong><%= comment.name %></strong>
        <em>on <%= comment.created_at.strftime('%b %d, %Y at %I:%M %p') %></em>
        <%= simple_format comment.content %>
      </div>
    <% end %>
    </div>
  <% end %>
  
  <h3>Add your comment</h3>
  <%= render :partial => 'comments/form' %>
</div>

Possiamo ora ritornare alla funzione updateComments e impostare i valori delle variabili article_id e after da quegli attributi data. Ottenere l’id dell’articolo è semplice: lo prendiamo banalmente dall’elemento che ha id uguale a article. Ci potrebbero invece essere molti commenti nella pagina e ciò che ci occorre è solo l’ultimo, per cui useremo il selettore .comment:last per identificarlo, dopodichè leggeremo il suo attributo data-time:

/public/javascripts/application.js

function updateComments() {
  var article_id = $('#article').attr('data-id');
  var after = $('.comment:last').attr('data-time');
  $.getScript('/comments.js?article_id=' + article_id + "&after=" + after);
  setTimeout(updateComments, 10000);
}

Ora che abbiamo a disposizione i valori per entrambe le variabili, possiamo usarli per recuparere i soli commenti che sono stati creati per quell’articolo dopo la data dell’ultimo presente in pagina.

E’ una buona idea quando si fa qualcosa di simile, controllare i log di sviluppo per accertarsi che tutto sembri funzionare come dovrebbe. Se visitiamo la pagina degli articoli e poi guardiamo i log, vedremo che la richiesta per i commenti in JavaScript viene fatta ogni dieci secondi più o meno, come ci aspettavamo a anche i parametri sembrano a posto:

Started GET "/comments.js?article_id=1&after=1283173233" for 127.0.0.1 at 2010-09-02 19:58:53 +0100
  Processing by CommentsController#index as JS
  Parameters: {"article_id"=>"1", "after"=>"1283173233"}
Rendered comments/index.js.erb (0.4ms)
Completed 200 OK in 41ms (Views: 41.1ms | ActiveRecord: 0.0ms)


Started GET "/comments.js?article_id=1&after=1283173233" for 127.0.0.1 at 2010-09-02 19:59:07 +0100
  Processing by CommentsController#index as JS
  Parameters: {"article_id"=>"1", "after"=>"1283173233"}
Rendered comments/index.js.erb (0.4ms)
Completed 200 OK in 34ms (Views: 33.6ms | ActiveRecord: 0.0ms)

ora che sappiamo che i parametri sono passati correttamente, possiamo usarli nella action index del CommentsController per avere i nuovi commenti:

/app/controllers/comments_controller.rb

def index
  @comments = Comment.where("article_id = ? and created_at > ?", params[:article_id], Time.at(params[:after].to_i))
end

Possiamo ora aggiornare il template associato al JavaScript affinchè mostri i commenti anzichè mostrare solo un alert. Prima di farlo, comunque, dobbiamo spostare il codice che mostra un commento fuori dalla vista show dell’articolo, in un partial separato, in modo tale che lo si possa usare nel template del Javascript. Muoveremo dunque tale codice in un nuovo file partial chiamato _comment.html.erb:

/app/views/comments/_comment.html.erb

<div class="comment" data-time="<%= comment.created_at.to_i %>">
  <strong><%= comment.name %></strong>
  <em>on <%= comment.created_at.strftime('%b %d, %Y at %I:%M %p') %></em>
  <%= simple_format comment.content %>
</div>

Dopodichè, nella vista relativa alla action show, possiamo semplicemente renderizzare il partial per la collezione di commenti:

/app/views/comments/show.html.erb

<% title @article.name %>

<div id="article" data-id="<%= @article.id %>">
  <%= simple_format @article.content %>
  <p><%= link_to "Back to Articles", articles_path %></p>
  <% unless @article.comments.empty? %>
    <h2><%= pluralize(@article.comments.size, 'commment') %></h2>
    <div id="comments">
    <%= render @article.comments %>
    </div>
  <% end %>
  <h3>Add your comment</h3>
  <%= render :partial => 'comments/form' %>
</div>

Possiamo aggiornare il template JavaScript della pagina index dei commenti affinchè generi il JavaScript per aggiornare i commenti:

/app/views/comments/index.js.erb

$('#comments').append("<%= escape_javascript(raw render(@comments))%>");

Questo codice renderizza la collezione di commenti usando il partial che abbiamo appena scritto. Dobbiamo racchiudere l’output del partial in un metodo raw, poichè per default Rails 3 farebbe l’escape dell’HTML e noi non lo vogliamo. Poi dobbiamo chiamare l’escape_javascript sull’output di quel comando, affinchè l’HTML sia sicuro per essere racchiuso in una stringa JavaScript. Il JavaScript che viene rimandato indietro al browser aggiunge questa stringa in fondo al div dei commenti.

Possiamo dare un’occhiata alla pagina nel browser, ora, per vedere se i commenti si aggiornano automaticamente ed otteniamo dei risultati solo parziali. Sebbene i commenti siano aggiornati, continuiamo a vedere che l’ultimo commento continua ad essere aggiunto:

Ciò avviene perchè quando otteniamo i nuovi commenti, il timestamp che passiamo ha una precisione al secondo. In questo caso stiamo chiedendo i commenti posteriori alle 13:00:33 del 30 agosto 2010, ma se guardiamo sul database, il commento è stato inserito alle 13:00:33.892041 e, anche se apparentemente dei millisecondi non ce ne potrebbe fregare di meno, per il controllo che facciamo, questa minima differenza è sufficiente a far considerare il commento sul database posteriore come timestamp a quello passato come parametro in query. Per sistemare questa cosa, dobbiamo arrotondare e chiedere i commenti lasciati almeno un secondo dopo l’ultimo commento attuale, per cui aggiungiamo 1 al valore intero ricevuto dal parametro nella query:

/app/controllers/comments_controller.rb

def index
  @comments = Comment.where("article_id = ? and created_at > ?", params[:article_id], Time.at(params[:after].to_i + 1))
end

Ora non vedremo più l’ultimo commento comparire di continuo. Possiamo testare che l’aggiornamento funziona, aprendo la pagina degli articoli su due finestre del browser differenti, inserendo un commento in una e controllando che appaia anche nell’altra:

Dopo pochi secondi il polling interviene e il commento compare sull’altra finestra del browser.

Aggiornamento del contatore dei commenti

Anche se il nuovo commento è stato correttamente aggiunto per polling, la testata che mostra il numero totale dei commenti non è stata aggiornata di conseguenza. Sistemiamo la cosa:

Possiamo aggiornare il contatore dei commenti nello stesso file utilizzato anche per l’aggiornamento dei commenti stessi. Di primo impatto, la cosa ovvia da fare potrebbe essere qualcosa del genere:

/app/views/comments/index.js.erb

$('#comments').append("<%= escape_javascript(raw render(@comments))%>");
$('#article h2').text('<%= @comments.first.article.comments.size %> comments');

Questo approccio implica tuttavia una chiamata al database per ottenere il totale dei commenti e dal momento che questo codice sarà chiamato piuttosto frequentemente, ha senso cercare di evitarlo, se possiamo. Possiamo ottenere il totale dei commenti direttamente dalla pagina, banalmente contanto il numero di elementi di classe comment presenti sulla pagina stessa:

/app/views/comments/index.js.erb

$('#comments').append("<%= escape_javascript(raw render(@comments))%>");
$('#article h2').text($('.comment').length + ' comments');

Questo codice non gestirà la pluralizzazione, per cui mostrerà sempre la dicitura “commenti”, anche se c’è solo un commento, ma tralasciamo questo particolare. Come tocco finale, aggiungeremo una clausola affinchè il JavaScript sia impostato solo se ci sono dei nuovi commenti:

/app/views/comments/index.js.erb

<% unless @comments.empty? %>
$('#comments').append("<%= escape_javascript(raw render(@comments))%>");
$('#article h2').text($('.comment').length + ' comments');
<% end %>

Quando aggiungiamo un altro commento in un browser, ora, i commenti vengono aggiornati anche nell’altra finestra del browser, aperta sulla stessa pagina, insieme al contatore:

Un’ultima correzione

C’è solo ancora un piccolo problema con questo codice che deve essere sistemato. Nella funzione updateComments, il valore della variabile after è impostata da un attributo preso dall’ultimo commento presente sulla pagina. Se non ci sono commenti per un certo articolo, allora questo valore sarà vuoto, per cui dovremo fare in modo che la variabile sia associata, in questi casi, al valore di default di 0, affinchè siano restituiti tutti i commenti:

/public/application.js

$(function () {
  if ($('#comments').length > 0) {
    setTimeout(updateComments, 10000);
  }
});

function updateComments() {
  var article_id = $('#article').attr('data-id');
  if ($('.comment').length > 0) {
    var after = $('.comment:last').attr('data-time');
  }
  else {
    var after = 0;
  }
  
  $.getScript('/comments.js?article_id=' + article_id + "&after=" + after);
  setTimeout(updateComments, 10000);
}

Ci sono altre cose che potrebbero essere migliorate. Per esempio, potremmo rendere l’intervallo di aggiornameno dinamico, affinchè, se l’ultimo commento è stato aggiunto molto tempo fa, diciamo per esempio più di un’ora fa, la frequenza del polling sia ridotta. In questo modo si riduce il carico sul server quando si osservano articoli che non hanno avuto commenti di recente.

Potremmo anche migliorare un po’ l’interfaccia utente, aggiungendo un evidenziazione, per indicare quando viene aggiunto un nuovo commento alla pagina. In altrenativa, potremmo aggiungere un link che indica che ci sono nuovi commenti disponibili e che li mostra solamente al click dell’utente sullo stesso.

ASCIIcasts - Full Episode Feed

Eredietarità dei template

Concetti base in SASS

Annidamento

Variabili

Mix-ins

Utilizzare SASS in file differenti

SCSS vs SASS

Fogli di stile condizionali

Concetti base in Coffeescript

Primi cambiamenti

Debuggare

OmniAuth - Parte 1

Aggiungere OmniAuth alla nostra applicazione

Salvare le Informazioni di Authentication

Migliorare il Look della pagina Index

Simple Form

Integrare SimpleForm in un’applicazione

Campi personalizzati

Personalizzazione di SimpleForm

Conosciamo Devise

Autenticazione mediante Engage

Modifichiamo la nostra applicazione per usare Engage

Autenticazione

Una pagina di login migliore

Esploriamo il routing di Rails 3 (parte 2)

Base

HttpHelpers

Shorthand

Resources

Scoping

Esploriamo il routing di Rails 3

Partiamo

I metodi routes e draw

Come avviene il mapping di un route

Come viene usato Rack nel routing

Risorse ereditate

Installazione di Inherited Resources

Personalizzare una action

Lavorare con formati differenti

Nested Resource

Scope pubblici

Personalizzare il messaggio flash

Fare polling per verificare modifiche

Configurazione di jQuery

Configurare Polling

Recupero dei commenti corretti

Aggiornamento del contatore dei commenti

Un’ultima correzione

I metodi `routes` e `draw`