質問は、ステート マシンは常に(クラスで) 静的に定義されているのですか? または、クラスの各インスタンスが独自の状態セットを持つようにする方法はありますか?
タスク エンジンを実装するためにStonepathをチェックしています。そこには「状態」と「タスク」の違いがよくわからないので、タスクを直接状態にマップできると考えています。これにより、次のようなことをしなくても、タスク リスト (またはワークフロー) を動的に定義できるようになります。
aasm_event :evaluate do
transitions :to => :in_evaluation, :from => :pending
end
aasm_event :accept do
transitions :to => :accepted, :from => :pending
end
aasm_event :reject do
transitions :to => :rejected, :from => :pending
end
代わりに、WorkItem (メインのワークフロー/タスク マネージャー モデル) には多くのタスクが含まれます。次に、タスクは状態のように機能するため、次のようなことができます。
aasm_initial_state :initial
tasks.each do |task|
aasm_state task.name.to_sym
end
previous_state = nil
tasks.each do |tasks|
aasm_event task.name.to_sym do
transitions :to => "#{task.name}_phase".to_sym, :from => previous_state ? "#{task.name}_phase" : "initial"
end
previous_state = state
end
ただし、これらのメソッド (および) はクラス メソッドであるため、 aasm gemでそれを行うことはできません。したがって、そのステート マシンを持つクラスのすべてのインスタンスは同じ状態になります。「WorkItem」または「TaskList」が、それが持つタスクに基づいて一連の状態と遷移を動的に作成するようにしたいのです。aasm_state
aasm_event
これにより、ワークフローを動的に定義し、状態をタスクにマップするだけで済みます。
ステート マシンがこのように使用されたことはありますか? このruby ワークフロー gemは、私が説明しているものと似ているようです。
更新: 次のようなことをしているのを見ることができますが、ハックのようです:
@implementation_state_machine = Class::new do
include AASM
aasm_initial_state :initial
tasks.each { |state| aasm_state :"#{task.name}"}
# ...
end
...私のモデルのプロパティはimplementation_state_machine
. 状態関連のメソッド ( ) を実装の匿名クラスmethod_missing
に委任するには、オーバーライドする必要があります。accepted_phase?