A seguito di un aggiornamento della piattaforma, alcuni degli articoli che stavi cercando potrebbero non essere qui presenti. In tal caso effettua una ricerca all'interno di old.therubymine.com. Ci scusiamo per il disagio che verrà risolto nel più breve tempo possibile.
26
Mar

Free your gems to the wild

Open to the wild Capita più spesso di quanto pensiamo di divertirci giocando con il nostro linguaggio preferito, risolvendo un problema che abbiamo incontrato al lavoro, o semplicemente scrivere provando qualche tutorial trovato qui e li. Il problema è che solitamente si dice “ok, adesso lo sistemo un pò, lo metto su un repository pubblico e ci faccio pure un bel articoletto che spiega quanto ho fatto”. Nella realtà, questo succede troppe poche volte.

La conseguenza è che piccole gemme scritte in Ruby o nel proprio linguaggio preferito rimangano chiuse nei nostri “cassetti” ed inizino a far polvere. Dopo un pò di tempo ci saremo dimenticati della loro esistenza, e probabilmente qualcuno che ne aveva bisogno non potrà mai essere a conoscenza del nostro lavoro.

Proprio per cambiare questa abitudine, domenica 29 marzo, negli uffici di Mikamai, ci sarà il quarto Hack Up. Senza andare nei dettagli, l’Hack Up è un incontro informale in cui persone con diverse conoscenze si incontrano, condividono le proprie esperienze e creano dei micro-progetti da rilasciare open source a fine giornata. In questo Hack Up lo scopo sarà duplice, in quanto oltre a sviluppare piccole applicazioni basate su temi caldi come Facebook o Arduino, ci saranno dei gruppi orientati alla discussione di progetti precedentemente creati. Ognuno potrà portare i progetti che aveva chiuso nel cassetto, potrà discutere con altri del lavoro fatto, e cercherà di renderli pubblici creando ad esempio delle gemme o dei repository su github.

Per il piano della giornata, ci troveremo a mezzogiorno al Frida per fare un branch, per poi andare alla sede di Mikamai alle 14 dove inizieremo a divertirci tutti assieme. Ovviamente, chi vuole, può saltare il branch e dormire un pochino di più visto che sempre di domenica si parla :-). Maggiori dettagli sulla giornata la trovate nel wiki dell’Hack Up.

Free your gems to the wild, on a bright sunday.

11
Mar

Novità in Rails 2.3: nested forms

matrioska

Rails 2.3 presenta una serie di interessanti novità, nessun stravolgimento sia chiaro, ma comunque migliorie degne di nota. Spesso ci capita di avere dei form “scorrelati” da un modello in particolare, ovvero dove ci sono campi che non appartengono ad un unico modello, ma che per questioni di usabilità è meglio presentare insieme.

Supponiamo che il nostro modello dei dati voglia rappresentare una piccola biblioteca, avremo:

  • un modello Book (titolo, numero di pagine)
  • un modello Author (nome)
  • un libro avrà almeno un autore

Volendo presentare un form per l’inserimento di un nuovo libro dovremmo prevedere il seguente flusso:

  1. inserimento del libro
  2. inserimento dell’autore (se non è già presente nello storico)
  3. infine: associazione dell’autore al libro appena inserito (e salvataggio)

E’ molto più naturale presentare il tutto in un unico form. Per esigenze di questo tipo in Rails 2.3 sono stati introdotti i nested forms (a dire la verità è da tempo che se ne parla come dice lo stesso Ryan). Ad ogni modo, riprendendo l’esempio precedente, avremo per i modelli l’aggiunta del metodo accepts_nested_attributes_for:

class Author < ActiveRecord::Base
  has_and_belongs_to_many :books
end
 
class Book < ActiveRecord::Base
  has_and_belongs_to_many :authors
  accepts_nested_attributes_for :authors
end

Mentre per il controller relativo al libro è necessario creare il modello nidificato (nested).

def new
  @book = Book.new
  @book.authors.build
end

La differenza sostanziale sta però nella view views/book/new.html.erb dove grazie all’uso del metodo fields_for è possibile instaziare un form nidificato per il modello indicato.

  ...
  <% form_for @book do |book_form| %>
  <%= book_form.error_messages %>
 
    <p>
        <%= book_form.label :title, 'Title:' %>
        <%= book_form.text_field :title %>
    </p>
 
    <p>
        <%= book_form.label :pages_number, 'Pages:' %>
        <%= book_form.text_field :pages_number, :size => 5 %>
    </p>
 
    <strong>authors</strong>
    <p>
        <% book_form.fields_for :authors do |author_form| %>
            <%= author_form.label :name, 'Name:' %>
            <%= author_form.text_field :name, :size => 30 %>
        <% end %>
    </p>
    ...

Giusto per chiarirci le idee vediamo come apparirebbe il form.

nested form

Inoltre vediamone il corretto funzionamento.

nested form processed

A questo punto per salvare correttamente i dati nel controller non è necessario fare assolutamente nulla. Il modello Book si preoccuperà di creare una nuova istanza per l’author inserito, di salvarla e linkarla opportunamente ad esso. Potremmo chiederci: e se questa catena di salvataggi si spezzasse per un qualsiasi motivo? Nessun problema: le operazione di salvataggio sono atomiche in questo caso.

Inoltre, se un oggetto figlio (author nel nostro esempio) non fosse valido (es: nel sottoform abbiamo omesso qualche dato indispensabile) questo rientrerebbe nel normale flusso di salvataggio dell’oggetto padre. Infatti, gli errori per gli oggetti figli vengono aggiunti all’oggetto padre. Ovviamente è anche possibile specificare di permettere la cancellazione degli oggetti figli.

Dopo aver dato una scorsa veloce ai nested forms, ecco alcuni link per chiunque desiderasse approfondire l’argomento. Prima di tutto segnaliamo l’ annuncio ufficiale sul blog di RubyOnRails.org, per poi passare all’ ottimo esempio di Eloy Duran (la persona che ha sottoposto questa feature al core team) e concludere in bellezza con l’articolo di Ryan Daigle che espone questa nuova funzionalità.

Come ultima cosa, per chi l’avvesse “persa”, vi segnaliamo la versione in italiano (gratuita!) del libro “RubyOnRails 2.2 - What’s new?” contenente le novità dell’attuale (2.2) versione di Rails. Buon divertimento a tutti!