Ricerca…


Stato di base con AASM

Di solito finirai per creare modelli che conterranno uno stato, e lo stato cambierà durante la vita dell'oggetto.

AASM è una libreria di enabler per macchine a stati finiti che può aiutarti a gestire facilmente il processo di progettazione dei tuoi oggetti.

Avere qualcosa del genere nel tuo modello è piuttosto in linea con l'idea di Fat Model, Skinny Controller , una delle best practice di Rails. Il modello è il solo responsabile della gestione del suo stato, dei suoi cambiamenti e della generazione degli eventi innescati da tali cambiamenti.

Per installare, in Gemfile

gem 'aasm'

Considera un'app in cui l'utente cita un prodotto a un prezzo.

class Quote

  include AASM

  aasm do
    state :requested, initial: true  # User sees a product and requests a quote
    state :priced                    # Seller sets the price 
    state :payed                     # Buyer pays the price
    state :canceled                  # The buyer is not willing to pay the price
    state :completed                 # The product has been delivered.

    event :price do
        transitions from: requested, to: :priced
    end

    event :pay do
        transitions from: :priced, to: :payed, success: :set_payment_date
    end

    event :complete do
        transitions from: :payed, to: :completed, guard: product_delivered?
    end

    event :cancel do
        transitions from: [:requested, :priced], to: :canceled
        transitions from: :payed, to: canceled, success: :reverse_charges
    end

   
  end

  private

  def set_payment_date
    update payed_at: Time.zone.now
  end
end

Gli stati della classe Quote possono andare comunque è meglio per il tuo processo.

Puoi pensare agli stati come passati, come nell'esempio precedente o come algo in altri tempi, ad esempio: determinazione dei prezzi, pagamento, consegna, ecc. La denominazione degli stati dipende da te. Da un punto di vista personale, gli stati del passato funzionano meglio perché il tuo stato finale sarà sicuramente un'azione passata e si collegherà meglio con i nomi degli eventi, che verranno spiegati in seguito.

NOTA: fai attenzione ai nomi che usi, devi preoccuparti di non usare le parole chiave riservate Ruby o Ruby on Rails, come valid , end , being , etc.

Dopo aver definito gli stati e le transizioni ora possiamo accedere ad alcuni metodi creati da AASM.

Per esempio:

Quote.priced  # Shows all Quotes with priced events
quote.priced? # Indicates if that specific quote has been priced
quote.price!  # Triggers the event the would transition from requested to priced.

Come puoi vedere l'evento ha delle transizioni, queste transizioni determinano il modo in cui lo stato cambierà sulla chiamata dell'evento. Se l'evento non è valido a causa dello stato corrente, verrà generato un errore.

Gli eventi e le transizioni hanno anche altre callback, per esempio

guard: product_delivered?

product_delivered? metodo che restituirà un valore booleano. Se risulta falso, la transizione non verrà applicata e se non sono disponibili altre transizioni, lo stato non cambierà.

success: :reverse_charges

Se la traduzione avviene :reverse_charges , verrà invocato il metodo :reverse_charges .

Ci sono molti altri metodi in AASM con più callback nel processo, ma questo ti aiuterà a creare i tuoi primi modelli con stati finiti.



Modified text is an extract of the original Stack Overflow Documentation
Autorizzato sotto CC BY-SA 3.0
Non affiliato con Stack Overflow