Callback after_add

[popayan]

Pour plus de clarté, je crée un nouveau post sur mon problème.

ma question

J'aimerai que quelqu'un me donne un éclaircissement sur le callback after_add, j'ai fait

has_and_belongs_to_many :teams, :after_add => et_statut

 

def set_statut

   if (self.teams.count == 6)

      self.update_attribute(tatut, 1)

      self.save

   end

end

mais ca n'a pas l'air de faire ce que je voudrais que ca fasse 12
je ne vois pas dans ma console s'exécuter le count par exemple...

La réponse de Sephi

Crée plutôt un nouveau sujet pour ce genre de question, assez spécifique. 16

Je n'utilise pas souvent ces callbacks (ils sont peu utilisés de manière générale, car leur documentation est assez succinte et que leur implémentation initiale était un peu bancale) et je ne peux pas faire de test dans l'immédiat, mais j'ai peut-être des pistes.
Es-tu sûr que self correspond bien à ton objet (je ne sais pas dans quelle classe tu es puisque tu as tronqué ton modèle) ?
La méthode update_attribute effectue une sauvegarde de l'objet, tu n'as pas besoin d'appeler save derrière.

Enfin, cette manipulation devrait plutôt se faire dans le callback after_create de ton modèle de relation, puisque after_add est appelé même si l'association n'est pas sauvegardé en base de données alors que dans l'esprit, tu ne veux passer le status à 1 que si tu as atteint les 6 joueurs. D'ailleurs, je te conseille d'utiliser une constante avec un nom parlant plutôt qu'un nombre (même si cette constante contient en effet un nombre).

Exemple si j'implémentais ça comme je te le conseille (en extrapolant sur les modèles) :

class GameTeam < ActiveRecord::Base

 

  belongs_to :game

  belongs_to :team

 

 

  after_create et_status

 

 

  private

 

  def set_status

    if game.teams.count == 6

      game.update_attribute(tatus, GAME::STARTED)

    end

  end

 

end

Quand je serais chez moi, je ferais quelques essais pour t'indiquer comment ça aurait pu avoir le comportement souhaité.


Sephi-Chan

Pour compléter un peu, le code de ma classe League et ma classe Team :

class League < ActiveRecord::Base

	has_and_belongs_to_many :teams, :after_add => et_statut

	

	def self.find_or_create_open_league

		League.where(:level => 1, tatut => 0).first || League.create

	end

	

	private



		def set_statut

			if (teams.count == 6)

				update_attribute(tatut, 1)

				save

			end

		end

	

end



class Team < ActiveRecord::Base



	has_and_belongs_to_many :leagues	

	before_create :add_to_league

	

	private

	

		def add_to_league

			league = League.find_or_create_open_league

			self.leagues = [league]

		end

end

et un peu d'explication:

Le joueur crée un compte puis se connecte, à sa première connexion il est redirigé vers la création de son équipe (Team#new), il remplit son formulaire puis je veux que automatiquement, il soit inscrit à une ligue. Lorsque la ligue compte 6 joueurs, je veux que celle ci soit fermée aux inscriptions et ensuite généré un calendrier (mais ca, ca sera une autre histoire )

Par rapport à la réponse:

Es-tu sûr que self correspond bien à ton objet (je ne sais pas dans quelle classe tu es puisque tu as tronqué ton modèle) ?

effectivement, en fonction des exemples que j'ai pu trouvé, le self est soit présent soit absent, mais dans les 2 cas, j'ai le même soucis.

La méthode update_attribute effectue une sauvegarde de l'objet, tu n'as pas besoin d'appeler save derrière.

au moins une chose d'apprise aujourd'hui

Enfin, cette manipulation devrait plutôt se faire dans le callback after_create de ton modèle de relation, puisque after_add est appelé même si l'association n'est pas sauvegardé en base de données alors que dans l'esprit, tu ne veux passer le status à 1 que si tu as atteint les 6 joueurs.

Je vois bien l'idée mais je voulais utiliser une relation habtm sans un modèle de relation. Enfin, si c'est vraiment mieux de cette manière, je ferais ca

[Sephi-Chan]

Les associations has_and_belongs_to_many (HABTM) sont dépréciées en faveur de l'association has_many through (HMT).

Dans ton cas, j'appellerai le modèle de jointure Membership (avec la table memberships, donc). L'avantage de cette méthode est qu'on peut enrichir le modèle de jointure (ainsi, si on veut donner des permissions, on peut les définir dedans).


Sephi-Chan

[popayan]

Merci Sephi, j'ai opté pour ta solution et après m'être heurté à un léger problème (pas compris qu'il fallait mettre en plus du has_many through un second has_many...) ca marche nickel

[NicoMSEvent]

[hors sujet]
dis Sephi, dans l'écran de recherche, le tag [ruby] ne s'affiche pas... ça serait bien de pouvoir voir cette info
[/hors sujet]

[Sephi-Chan]

Je sais mais hélas, le plugin utilisé n'est pas bien fait et il ne suffit pas de modifier les templates… Du coup, il faut aller modifier le code source et c'est chiant. Du coup c'est sur la todo mais… Un peu loin.


Sephi-Chan