Hello Brain,
On Wed, May 09, 2012 at 06:24:23AM -0700, Klaus Schmidtmamn wrote:
>
> Now, I also can give workitem-fields back to the Workflow and use them
> to take different paths through the process-definition.
>
> like this:
>
> participant:
> ...
> $i = Integer(gets)
> workitem.fields['total'] = $i
> end
Please note that using a Ruby global variable ($i) is not a good idea... They
never get garbarge collected. Why use a global variable when a local variable
is sufficient?
i = Integer(gets)
workitem.fields['total'] = i
You can even write
workitem.fields['total'] = Integer(gets)
> reply_to_engine(workitem)
> ...
>
>
> pdef:
> user_3 :task => 'doing user_3 stuff...'
>
> echo 'total was given: ${f:total}'
> echo 'back from participant-implementation...'
>
> user_4 :task => 'doing user_4 stuff now...'
>
> But again some open questions, related to the topic:
>
> 1. It seems as if I have to handle myself which participant will be
> executed by whom. Not like in my "for-klaus" example, where only the
> current user can execute the participants with the same name.
What is the question?
> 2. During combining the "for-klaus" example with a self implemented
> participant, I found out this is asynchronously. Means. If I am
> waiting for a user-prompt within the participant-implementation, My
> Input can also be an Input for the "main-command-loop" in this:
>
> def run
>
> loop do
> print("#{@user}" + (@workitem ? ":#{@workitem.fei.sid}" : '') +
> '> ')
> self.eval(gets)
> end
> end
Yes. Of course when you've got a gun, you can shoot yourself in the foot.
> Is there a way to handle the Participant-Implementation in an other
> terminal (later I would generate some web-output instead)
Your idea of requesting information from a user at the beginning of your
#on_workitem is a bad idea, as you've experienced yourself the "gets"
conflicts with the main loop "gets".
If you get back to the original for_klaus example, you'll notice that the
"note" modifies the workitem fields. It was this command you were supposed to
discover and enhance. You could use the arguments to the command to modify
the workitem, and it would all fit nicely in the for_klaus main loop.
So I'd say that the for_klaus client is showing you a way to do user
interaction with a workitem without having to provide your own class
inherited from Ruote::LocalParticipant.
Try to step back, breathe and look at the big picture. If you keep your nose
within one centimeter of the code you'll never get anything.
> 3. If I connect as a new user to my "for-klaus" client, is there a way
> to join an existing Process-Instance (an already launched one)?
> For me, it seems that only the one (the terminal which launches the
> process-definition) will see the participant-implementation-execution.
Yes, the for_klaus client lets you pick any workitem, whoever the launcher.
> Greetings
> Brain
Brian?
Kind regards,
--
John Mettraux - http://lambda.io/jmettraux
--
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
