I'm trying your first suggestion but I'm not sure how to implement it:
concurrent_iterator :on => '${f:coauthor_emails}', :tag =>
'coauthor_forms', :to_var => 'v' do
concurrence do
participant 'coauthor-${v:v}', :task =>
'complete_information', :unless => '${v:v}_info_present'
participant 'coauthor-${v:v}', :task => 'submit_copyright'
participant 'coauthor-${v:v}', :task => 'submit_disclosure'
end
end
RuoteKit.engine.launch(self.pdef, {'coauthor_emails' =>
'[email protected],[email protected]', '[email protected]_info_present' =>
'true' })
With this code, both [email protected] and [email protected] skip over the
"complete_information" task. I need the :unless to check if this
particular user's information is present.
On Dec 13, 7:03 am, John Mettraux <[email protected]> wrote:
> On Mon, Dec 12, 2011 at 09:07:45AM -0800, Reed Law wrote:
>
> > Thanks for the welcome but I've posted here before (as R Law).
>
> This post was moderated so I quickly assumed you were new.
>
> > You understood me correctly for the most part. The problem with the
> > cursor is that each participant would only receive one workitem at a
> > time, but I wanted to hand off several (one for each step in the
> > checklist).
>
> Your interface could aggregate those distinct workitems, their feis (#fei)
> being quite close (same wfid, same expid root).
>
> > Your suggestion works and I'll probably go with something like that.
> > Quarderno looks nice but we've already got UI elements for checklists.
> > A question that came up as I looked into this was: how do you
> > implement a participant that replies immediately if some condition is
> > met? I know I could use the if expression in the process definition,
> > but it seems like that is only suitable for testing equality.
>
> With the upcoming ruote 2.2.1, it can do better than testing equality.
>
> https://github.com/jmettraux/ruote/blob/master/test/unit/ut_6_conditi...
>
> > I want to check if some data is present in an external service. If the
> > information is present I want to copy it over (#1); if not, the
> > coauthor needs to complete a form (#2). So the participant
> > implementation will first attempt #1, and if it's successfully, simply
> > reply to the workitem (proceed). If #1 fails, the participant should
> > work as a normal storage participant for #2. Is this possible?
>
> What about making those steps explicit in the process definition ?
>
> ---8<---
> sequence do
> copy_info_over
> human :unless => '${info}'
> end
> --->8---
>
> If you really want to pack that into one participant you could do something
> like:
>
> ---8<---
> class Acme::StorageParticipant < Ruote::StorageParticipant
>
> # Returns false so that the on_workitem operations are performed in
> # a new thread, not blocking the worker.
> #
> def do_not_thread
>
> false
> end
>
> def on_workitem
>
> workitem.fields['copying'] = true
> super
>
> info = ExternalService.copy_info_over
>
> wi = by_fei(fei) # re-fetch
>
> return unless wi
> #
> # workitem gone, probably cancelled, work over.
>
> if info
> #
> # information was fetched successfully, let's proceed
> #
> wi.fields['info'] = info
> proceed(wi)
> else
> #
> # re-put with updated info
> #
> # this will fail silently if the workitem is gone, not much to do
> # anyway
> #
> wi.fields['copying'] = false
> @context.storage.put(doc)
> end
> end
>
> # no need to override #on_cancel
> end
> --->8---
>
> I hope it helps.
>
> Best regards,
>
> --
> John Mettraux -http://lambda.io/processi
--
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
