On Thu, Jun 03, 2010 at 08:44:48AM -0700, threetee wrote:
>
> Thanks for the quick response! I hadn't thought about setting up a
> separate class and registering that as a participant in order to
> accomplish the state change; I'll try that approach.
>
> Regarding the contents of Server.all being set at process definition
> time and not changing later despite changes in the database, would
> this also be a viable alternative?
>
> ---------------
> # Model
> def self.pdef_create_email
> servers = Server.all
> Ruote.process_definition :name => 'create_email' do
> cursor do
> concurrence do
> servers.each do |server|
> remote_server :command => '/account/disable', :queue =>
> "ruote_uuid-#{server.uuid}"
> end
> end
> end
> end
>
> # Controller
> @email = Email.create(:address => '[email protected]')
> @email.wfid = RuoteKit.engine.launch(Email.pdef_create_email,
> :address => @email.address,
> :object_type => :email,
> :object_id => @email.id)
> ---------------
>
> Please note that I like your method of using concurrent_iterator and
> passing in the UUIDs better than this method, and I understand why you
> would want to avoid mixing Ruby code into the pdef. However, I'm still
> curious about whether or not the above method would work.
Hello,
yes, this would be a viable alternative.
Thus, note that :
---8<---
Ruote.process_definition do
concurrence do
%w[ a b c ].each do |target|
participant "#{target}"
end
end
end
--->8---
produces the same output (ruote syntax tree) as :
---8<---
Ruote.process_definition do
concurrence do
participant 'a'
participant 'b'
participant 'c'
end
end
--->8---
Having a generator method is 100% viable/kosher/approved/...
Cheers,
--
John Mettraux - http://jmettraux.wordpress.com
--
you received this message because you are subscribed to the "ruote users" group.
to post : send email to [email protected]
to unsubscribe : send email to [email protected]
more options : http://groups.google.com/group/openwferu-users?hl=en
