Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Logging transitions with DRY code? #221

Closed
awendt opened this issue Mar 12, 2015 · 9 comments
Closed

Logging transitions with DRY code? #221

awendt opened this issue Mar 12, 2015 · 9 comments
Assignees
@alto

Comments

@awendt
Copy link

awendt commented Mar 12, 2015

With a fairly complex state machine, we'd like to log transitions so we know how we ended up in the current user state. For each transition, we'll need:

  • aasm.from_state
  • aasm.to_state
  • aasm.current_event

According to the docs:

During the transition's :after callback (and reliably only then) you can access the originating state (the from-state) and the target state (the to state)

This means we'll go from this:

  transitions from:   :initialized,
              to:     :mismatched

to this:

  transitions from:   :initialized,
              to:     :mismatched,
              after:  Proc.new { |*args|
                track(
                  'from_state'         => aasm.from_state,
                  'into_state'         => aasm.to_state,
                  'statemachine_event' => aasm.current_event
                )
              }

for each transition which is undesirable from a maintenance perspective. I'm aware of things like paper_trail for auditing AR but that does not fit into our current architecture.

So I'm wondering if there's a way to get this done while staying DRY? (I'm leaning toward alias_method_chain to add the callback—but there may be another, AASM-supported way I'm not aware of.)
@alto alto self-assigned this Mar 12, 2015
@alto
Copy link
Member

alto commented Mar 12, 2015

@awendt There's already a ticket for something similar (take a look at #108). Would that help you?

What you could do now already is to use methods instead of a Proc, like this:

aasm do
  transitions from:     :initialized,
              to:       :mismatched,
              after:    :tracking
end

def tracking(*args)
  track(
    'from_state'         => aasm.from_state,
    'into_state'         => aasm.to_state,
    'statemachine_event' => aasm.current_event
  )
end

@awendt
Copy link
Author

awendt commented Mar 12, 2015

@alto Thanks for your quick reply. Anything that involves me declaring "I want this code to run after every transition" just once helps here :)

I found #108 but failed to see a connection. After more careful reading I found this comment:

FYI the reason I raised the original issue was to implement an observer pattern on transitions. (Of course possible to observe the state variable but not the transitions).

So, yes, that exactly describes the issue I'm having.

I think I will switch to symbols and add alias_method_chain for the time being but it would be great to have AASM support that in the long run.

@waynn
Copy link

waynn commented Aug 10, 2015

@awendt How exactly are you using alias_method_chain with this? I'm running into the same problem, are you including it in the aasm declaration?

@awendt
Copy link
Author

awendt commented Aug 10, 2015

@waynn I settled for a duplicated after: :track_event for each transition. Sorry.

@jeremywadsack jeremywadsack mentioned this issue Sep 9, 2015
Closed
@alto alto mentioned this issue Oct 16, 2015
Merged
@alto
Copy link
Member

alto commented Oct 16, 2015

Please take a look at #270 and let me know if that works for your problem. Will release soon.

@waynn
Copy link

waynn commented Oct 20, 2015

That looks good!

@awendt
Copy link
Author

awendt commented Oct 20, 2015

@alto

👍 — should I close this then?

@alto
Copy link
Member

alto commented Oct 23, 2015

Closed with #270 .

@alto alto closed this as completed Oct 23, 2015
@alto
Copy link
Member

alto commented Oct 27, 2015

I just released version 4.4.0 including the change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@alto alto

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@alto @awendt @waynn