Recherche…


Etat de base avec AASM

Habituellement, vous finirez par créer des modèles qui contiendront un état et cet état changera pendant la durée de vie de l'objet.

AASM est une bibliothèque d'activateur de machine à états finis qui peut vous aider à gérer facilement la conception de processus de vos objets.

Avoir quelque chose comme ça dans votre modèle va assez bien avec l'idée de Fat Model, Skinny Controller , l'une des meilleures pratiques de Rails. Le modèle est le seul responsable de gérer son état, ses modifications et de générer les événements déclenchés par ces changements.

Pour installer, dans Gemfile

gem 'aasm'

Considérons une application où l'utilisateur cite un produit pour un prix.

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

Les états de la classe de devis peuvent aller, mais c'est le mieux pour votre processus.

Vous pouvez penser aux états comme étant passés, comme dans l'exemple précédent ou à d'autres moments, par exemple: tarification, paiement, livraison, etc. La désignation des États dépend de vous. D'un point de vue personnel, les états passés fonctionnent mieux car votre état final sera sûrement une action passée et sera mieux lié aux noms des événements, ce qui sera expliqué plus tard.

REMARQUE: Faites attention aux noms que vous utilisez, vous devez vous soucier de ne pas utiliser les mots-clés réservés Ruby ou Ruby on Rails, tels que valid , end , being , etc.

Après avoir défini les états et les transitions, nous pouvons maintenant accéder à certaines méthodes créées par AASM.

Par exemple:

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.

Comme vous pouvez voir que l'événement a des transitions, ces transitions déterminent la manière dont l'état changera lors de l'appel de l'événement. Si l'événement est invalide en raison de l'état actuel, une erreur sera générée.

Les événements et les transitions ont également d'autres callbacks, par exemple

guard: product_delivered?

product_delivered? le product_delivered? méthode qui retournera un booléen. S'il s'avère faux, la transition ne sera pas appliquée et si aucune autre transition n'est disponible, l'état ne changera pas.

success: :reverse_charges

Si cette traduction réussit, la méthode :reverse_charges sera appelée.

Il existe plusieurs autres méthodes dans AASM avec plus de rappels dans le processus, mais cela vous aidera à créer vos premiers modèles avec des états finis.



Modified text is an extract of the original Stack Overflow Documentation
Sous licence CC BY-SA 3.0
Non affilié à Stack Overflow