On Tue, Nov 06, 2012 at 02:13:11PM +0100, Mario Camou wrote:
> Hi all,
Hello Mario,
Glad to read from you. I will try to answer your question, please bear with
me if I give multiple answers (pick the one you like).
> I have the following (simplified) workflow which is called as a subprocess
> in several places in our application:
>
> Ruote.process_definition :name => 'bm_form_multi', :revision => '0.1' do
> cursor do
> sequence do
> wait_for_edit
> concurrence do
> concurrence :forget => true do
> human_action
>
> cursor do
> wait_for_save
> rewind
> end
> end
>
> rewind
> end
> end
> end
> end # process_definition
If I compress/simplify this workflow, it becomes
---8<---
Ruote.process_definition :name => 'bm_form_multi', :revision => '0.1' do
cursor do
wait_for_edit
concurrence do
concurrence :forget => true do
human_action
cursor do
wait_for_save
rewind
end
end
rewind # <------ ???
end
end
end # process_definition
--->8---
(the sequence inside of the cursor shouldn't be necessary, maybe it's just a
remainder of the bigger real workflow definition).
Isn't that a loop? As soon as wait_for_edit is over, the cursor gets
rewound...
> The human_action participant waits for a person to fill in a form. The idea
> is that several users can fill in the same form in parallel and save their
> information at any time (without closing the form). When the user needs to
> fill in the form, the front-end application sends a PUT with proceed to the
> wait_for_edit participant, which then creates a new branch of the
> concurrence for that user to edit.
Wouldn't it be possible to simplify this by having a single step
---8<---
Ruote.define do
# ...
multi_form
# ...
end
--->8---
Where multiform makes available a form, accessible by multiple users, and
each user may save and/or proceed? Ironically, because ruote-kit has no
access control, that's already how it behaves, anybody can edit, the first
one to hit save wins, same thing with "save and proceed".
I think it'd remove the presentation concerns from the process definition
(and isolate them in the participant implementation).
> What I would like to happen is, when the user saves their work, the
> front-end should send a PUT with proceed to the wait_for_save participant.
> My problem is, the wait_for_save participant needs to communicate its FEI
> to the human_action participant so the front-end knows the URI to send the
> PUT to.
Taking ruote-kit as an example again, when you edit a workitem, you're
presented with a form whose action is the URI of the workitem (the method is
PUT). That URI contains the fei (in condensed form).
You can turn a fei into a string with
Ruote.sid(fei)
# => "0_0!5dbf4ce1553453baa17c2213d239e5fa!20101224-bababa"
and turn it back into a fei with
Ruote.extract_fei("0_0!5dbf4ce1553453baa17c2213d239e5fa!20101224-bababa")
# => an instance of FlowExpressionId
I hope this helps, please feel free to refine/develop your question(s) in
this thread.
Best 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
