Macchine a stati finiti (FSM) e il plugin acts_as_state_machine

Una macchina a stati finiti (FSM) è un sistema dinamico costituito da un insieme finito di stati e da una funzione di trasferimento che ne specifica il comportamento, ovvero definisce le regole che determinano i passaggi della macchina da uno stato all’altro.

La macchina può essere rappresentata tramite un grafo diretto i cui nodi rappresentano gli stati e gli archi rappresentano le transizioni di stato delle macchina.

Sono molteplici i problemi che possono essere modellati con una FSM e non poteva certo mancare un plugin Rails che ne rendesse agile la codifica: si tratta di acts_as_state_machine, una manciata di righe di codice sicuramente migliorabili ma che tutto sommato assolvono bene al loro compito. Una volta installato il plugin, occorrerà soltanto aggiungere un campo state di tipo string all’oggetto cui vogliamo assegnare le caratteristiche di FSM.

Facciamo un semplice esempio: vogliamo creare un’applicazione web accessibile attraverso iscrizioni a pagamento. Dopo la registrazione, l’iscrizione sarà attiva e, ogni volta che riceveremo un pagamento, dovrà essere generata la fattura commerciale per il cliente. In caso di mancato pagamento l’iscrizione verrà sospesa mentre, se il cliente deciderà di cancellare la sua registrazione, l’iscrizione verrà eliminata. Ad ogni passaggio di stato dovrà essere inviata una notifica e-mail al cliente.

La prima cosa da fare è modellare gli stati e gli eventi che determinano le transizioni di stato: niente di meglio che usare la vecchia accoppiata carta/penna, creando un diagramma simile a quello della figura precedente.

Utilzzando il plugin risulta estremamente semplice tradurre il diagramma nel seguente modello Rails:

 1 class Subscription < ActiveRecord::Base
 2 
 3 acts_as_state_machine :initial => :active
 4 
 5 state :active
 6 state :suspended
 7 
 8 event :payment do
 9 
 10 transitions :from => :active,
 11 :to => :active,
 12 :guard => :get_payment
 13 
 14 transitions :from => :suspended,
 15 :to => :active,
 16 :guard => :notify_reactivation
 17 end
 18 
 19 event :payment_failure do
 20 
 21 transitions :from => :active,
 22 :to => :suspended,
 23 :guard => :notify_suspension
 24 
 25 transitions :from => :suspended,
 26 :to => :suspended,
 27 :guard => :notify_new_payment_failure 
 28 end
 29 
 30 private
 31 def get_payment
 32  # make payment invoice
 33  # send payment email
 34 end
 35 
 36 def notify_reactivation
 37  # send reactivation email 
 38 end
 39 
 40 def notify_suspension
 41  # send suspension email
 42 end
 43 
 44 def notify_new_payment_failure
 45  # send alert for new payment failure
 46 end
 47 end

Nell’esempio, gli eventi possono essere chiamati attraverso i metodi:

• @subscription.payment!
• @subscription.payment_failure!

Gli eventi signup e cancel del diagramma coincidono invece con l’effettiva creazione e distruzione della subscription e non con delle transizioni di stato.

Il modello è molto semplificato rispetto ad un caso reale, dove dovrebbero essere tenuti in considerazione altri stati ed eventi come la modifica dell’iscrizione o la sospensione definitiva in seguito ad un numero massimo di pagamenti falliti. Quello che conta è l’approccio con cui viene affrontato il problema e la “robustezza” della soluzione che ne scaturisce: un sistema ben modellato è un’ottima base per la scrittura di codice elegante e flessibile e le macchine a stati sono, a mio avviso, uno degli esempi più calzanti di come una buona progettazione porti vantaggi concreti, attribuendo un significato tangibile a quanto raccomandato in tutti i migliori testi di programmazione.

Ruby on Rails: oggetti multipli nella stessa form

Supponiamo di avere 2 model Author e Book in relazione 1:n tra loro: vogliamo scrivere una form per la creazione e la modifica di un author e di uno o più book associati. In particolare vogliamo avere la possibilità di aggiungere e rimuovere un numero qualsiasi di book nella stessa form di author. Il risultato sarà qualcosa di questo tipo:

Cominciamo con l’esprimere la relazione tra i due oggetti:

 1 class Author < ActiveRecord::Base 
 2 has_many :books, :dependent => :destroy 
 3 end

 1 class Book < ActiveRecord::Base 
 2 belongs_to :author
 3 end

Nella action new di /app/controllers/authors_controller.rb costruiamo un’istanza di un author e di 3 book associati nel seguente modo:

 1 def new 
 2 @author = Author.new 
 3 3.times do
 4 @author.books.build
 5 end
 6 end

In /app/views/authors/new.html.erb creiamo la form che contiene i campi dell’autore e dei libri associati (racchiusi nel parziale /app/views/authors/_book.html.erb). Per semplicità consideriamo solo il campo name per l’autore e il campo title per i libri.

 1 <% form_for @author do |f| %> 
 2 <p>Name: <%= f.text_field :name %></p> 
 3 <div id="books"> 
 4 <%= render :partial => 'book', :collection => @author.books %>
 5 </div> 
 6 <p><%= add_book_link "add book" %></p> 
 7 <p><%= f.submit "save" %></p> 
 8 <% end %>

Il codice per add_book_link (riga 6) si trova in /app/helpers/authors_helper.rb e genera un link Ajax che “appende” un nuovo libro alla form:

 1 def add_book_link(name) 
 2 link_to_function name do |page| 
 3 page.insert_html :bottom, :books, :partial => 'book', :object => Book.new 
 4 end 
 5 end

Il codice di /app/views/authors/_book.html.erb è il seguente:

 1 <div class="book"> 
 2 <% new_or_existing = book.new_record? ? 'new' : 'existing' %> 
 3 <% prefix = "author[#{new_or_existing}_book_attributes][]" %> 
 4 <% fields_for prefix, book do |book_form| -%> 
 5 <p> 
 6 Titolo: <%= book_form.text_field :title %> 
 7 <%= link_to_function "remove", "$(this).up('.book').remove()" %> 
 8 </p> 
 9 <% end -%> 
 10 </div>

La chiave sta nell’helper fields_for (riga 4) che si comporta in maniera molto simile a form_for, ovvero renderizza tutti i campi dell’oggetto cui si riferisce ma senza racchiuderli in un tag form.

A questo punto basta definire opportunamente i metodi new_book_attributes e existing_book_attributes, oltre alla callback save_books, in /app/models/author.rb:

 1 after_update :save_books
 2 
 3 def new_book_attributes=(book_attributes) 
 4 book_attributes.each do |attributes| 
 5 books.build(attributes) 
 6 end 
 7 end
 8 
 9 def existing_book_attributes=(book_attributes) 
 10 books.reject(&:new_record?).each do |book| 
 11 attributes = book_attributes[book.id.to_s] 
 12 if attributes 
 13 book.attributes = attributes 
 14 else 
 15 books.delete(book) 
 16 end 
 17 end 
 18 end 
 19 
 20 def save_books 
 21 books.each do |book| 
 22 book.save(false) 
 23 end 
 24 end

Le action edit e create in /app/controllers/authors_controller.rb sono quelle “classiche”. La action update deve essere invece dotata di un accorgimento per fare in modo che tutto funzioni anche nel caso in cui vengano rimossi dalla form tutti i book:

 1 def update 
 2 params[:author][:existing_book_attributes] ||= {} 
 3 
 4  # salvataggio "classico" di @author
 5 end

Questo tutorial è stato riadattato a partire da alcuni screencast di Ryan Bates (episodi 73, 74, 75). Nei nostri progetti abbiamo utilizzato questo sistema per permettere all’utente il caricamento simultaneo di più immagini associate ad un oggetto (utilizzando il plugin attachment_fu), sistema che abbiamo intenzione di evolvere attraverso l’utilizzo di fleximage e swfupload per ottenere la progress bar degli allegati in upload e la loro validazione prima del loro effettivo caricamento.

Un’alternativa a Globalize: GetText + Model Localization Plugin

Globalize è un ottimo plugin che copre tutti gli aspetti legati all’internazionalizzazione di un’applicazione Rails, tra cui:

• Traduzione dei testi “statici” (View Translations)
• Traduzione dei testi “dinamici” (Model Translations)
• Localizzazione di date, numeri, valute etc…

Il setup del plugin provvede alla crazione di 3 tabelle sul database già popolate con le informazioni di localizzazione relative a 239 paesi e con le traduzioni comuni (es. giorni della settimana) in 186 lingue.

Sia le View Translations che le Model Translations vengono scritte sul database ed è possibile, quindi, creare un’area (riservata) dell’applicazione che si occupi esclusivamente del CRUD delle traduzioni, gestibili quindi in autonomia dall’utente finale.

La necessità di un’alternativa a Globalize è nata col tempo a partire da alcune considerazioni:

• “Ho veramente bisogno delle informazioni di localizzazione di 239 paesi e 186 lingue se il mio sito supporterà al massimo le 5 lingue europee più comuni?”
• “E’ corretto gestire nello stesso modo la traduzione delle parti statiche e dinamiche di un sito?”
• “Sono realmente necessari tutti gli accessi al database effettuati da Globalize per la localizzazione?”

Le risposte, nel mio caso, credo siano a questo punto evidenti; in particolare ritengo che ci sia una sostanziale differenza tra i due tipi di traduzioni che giustifica la ricerca di due soluzioni diverse.

Per le traduzioni statiche ho scelto (ad oggi con soddisfazione) di utilizzare GetText e la sua implementazione in ruby. A questo indirizzo è disponibilie una guida molto chiara da cui iniziare.

Per le traduzioni dinamiche non sono riuscito a trovare niente di adeguato alle mie esigenze per cui ho scritto un plugin per la localizzazione dei modelli che, unito a GetText, completa la soluzione all’internazionalizzazione da me adottata.

Il suo funzionamento è molto semplice. Supponiamo di avere il model Task con un attributo name che vogliamo rendere traducibile in inglese e francese.

Attraverso una migrazione aggiungiamo gli attributi che conterranno le 2 traduzioni:

 1 class AddTranslationsToTaskName < ActiveRecord::Migration
 2 def self.up
 3 add_column :tasks, :name_en, :string
 4 add_column :tasks, :name_fr, :string
 5 end
 6 
 7 def self.down
 8 remove_column :tasks, :name_en
 9 remove_column :tasks, :name_fr
 10 end
 11 end

Il plugin estende ActiveRecord definendo il metodo localize che si usa così:

 1 class Task < ActiveRecord::Base
 2 localize :name
 3 end

A questo punto basterà utilizzare l’attributo preceduto da un underscore (in perfetto stile GetText) sia nelle form, per la modifica (riga 5):

 1 <h1>Editing task</h1>
 2 
 3 <% form_for(@task) do |f| %>
 4 <%= f.error_messages %>
 5 <p><%= f.text_field :_name %></p>
 6 <p>
 7 <%= f.submit "Update" %>
 8 </p>
 9 <% end %>
 10 
 11 <%= link_to 'Show', @task %> |
 12 <%= link_to 'Back', tasks_path %>

che in visualizzazione (riga 3):

 1 <h1>Showing task</h1>
 2 
 3 <p><%=@task._name%></p>
 4 
 5 <%= link_to 'Edit', edit_task_path(@task) %> |
 6 <%= link_to 'Back', tasks_path %>

La lingua in cui viene modificato o visualizzato l’attributo è la lingua corrente.

Chiaramente nel momento in cui dovessi affrontare lo sviluppo di un’applicazione in 20 lingue, tra cui l’arabo e il giapponese, tornerei a prendere in seria considerazione l’adozione di Globalize!