Forum: Rails France comment gérer des changement d'états en restant CRUD/Rest

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
997433f165140d58f52b8c0d1d005dc1?d=identicon&s=25 Patrick Aljord (Guest)
on 2007-08-01 02:06
(Received via mailing list)
Salut à tous,
J'ai un model Job et ce job peut être opened, closed et fulfilled. Il
peut aussi être re-open, re-closed et "re-fulfilled" et je veux
pouvoir garder une trace de chaque changement (en gardant la date du
changement).
Est-ce que vous avez une idée de comment gérer cette situation en pure CRUD?

merci d'avance

Pat
047a4fc673336a70a6b58338bc6d677d?d=identicon&s=25 Michel Belleville (Guest)
on 2007-08-01 07:42
(Received via mailing list)
Une table "job_status" avec un model JobStatus et une table "status"
avec un
model Status.
Dans Status tu met une string wording pour le libellé (trois valeurs au
final : "opened", "closed", "fulfilled").
Dans JobStatus tu met un integer job_id, un integer status_id, un
datetime
time (qui gardera le moment du changement) et tous les champs que tu
veux
mettre pour préciser la raison, etc. du changement.
Une liaison has_many :through dans ton model Job qui traverse le model
JobStatus pour connecter le model Job et Status, comme ça tu pourras
enregistrer facilement les changement de status de ton job.

Après, pour l'interface, je te laisse maître de ton oeuvre...

On 8/1/07, Patrick Aljord <patcito@gmail.com> wrote:
> merci d'avance
>
> Pat
>
> >
>


--
Michel Belleville
997433f165140d58f52b8c0d1d005dc1?d=identicon&s=25 Patrick Aljord (Guest)
on 2007-08-01 07:50
(Received via mailing list)
On 8/1/07, Michel Belleville <michel.belleville@gmail.com> wrote:
> Une table "job_status" avec un model JobStatus et une table "status" avec un
> model Status.
> Dans Status tu met une string wording pour le libellé (trois valeurs au
> final : "opened", "closed", "fulfilled").
> Dans JobStatus tu met un integer job_id, un integer status_id, un datetime
> time (qui gardera le moment du changement) et tous les champs que tu veux
> mettre pour préciser la raison, etc. du changement.
> Une liaison has_many :through dans ton model Job qui traverse le model
> JobStatus pour connecter le model Job et Status, comme ça tu pourras
> enregistrer facilement les changement de status de ton job.

ok merci c'est un peu ce que j'avais en tête. Pour économiser une
table je pourrais faire une table job_status avec pour champs job_id,
statusid en tant que integer qui peut être égal à 1, 2 ou 3 pour
opened, closed et fulfilled?
2fd0206c71a1b22a9cc6293f38537461?d=identicon&s=25 Cyril Mougel (shingara)
on 2007-08-01 09:32
(Received via mailing list)
On 8/1/07, Patrick Aljord <patcito@gmail.com> wrote:
>
> Salut à tous,
> J'ai un model Job et ce job peut être opened, closed et fulfilled. Il
> peut aussi être re-open, re-closed et "re-fulfilled" et je veux
> pouvoir garder une trace de chaque changement (en gardant la date du
> changement).
> Est-ce que vous avez une idée de comment gérer cette situation en pure CRUD?
>

Tu peux peut-être tenter l'utilisation du plugin act_as_versioned[1]

[1] : http://wiki.rubyonrails.org/rails/pages/ActsAsVersioned
--
Cyril Mougel
047a4fc673336a70a6b58338bc6d677d?d=identicon&s=25 Michel Belleville (Guest)
on 2007-08-01 10:14
(Received via mailing list)
Je vois pas trop l'intérêt d'économiser une table si tu y gagnes en
lisibilité...

Maintenant, ActAsVersioned ça semble sympa en effet, peut-être serait-il
plus judicieux de réutiliser un code déjà développé même si encore
expérimental.
997433f165140d58f52b8c0d1d005dc1?d=identicon&s=25 Patrick Aljord (Guest)
on 2007-08-01 18:22
(Received via mailing list)
J'ai choisi Acts as State Machine et Acts as Audited, le premier
permet de générer des events pour chaque changement d'état
(http://blog.methodmissing.com/2006/11/16/beyond-ca...)
et acts_as_audited permet de versionner plusieurs models dans une même
table grâce au polymorphisme (contrairement à ActAsVersioned ou on
doit créer une table par model) et on peut aussi choisir les champs à
auditer (contrairement à ActAsVersioned où on doit versionner tout les
champs).
This topic is locked and can not be replied to.