On Thu, Mar 24, 2011 at 11:22:23PM -0700, simcha wrote:
>
> With process versioning the problem is that new process versions tend
> to need new task forms and new participants while the old process
> versions are still running and need the old ones. So using :revision
> as you say is only a beginning. The question is how to version tasks
> and participants. From development point of view suffixing classes has
> such an advantage that you just copy your class on the beginning of
> the work leaving old version intact. Adding version as an argument
> would give us nicer code but bring high possibility of braking old
> processes.
Hello,
you're right, but remember that participants (and forms) are sometimes meant to
be shared among workflows.
Of course, versioning the set { workflow, participants[, forms] } is a valid
solution, there will probably be some duplicates (things that do not change but
are still present in the new revision).
Until now, I always worked with processes that changed faster than
participants. And participants shared among processes.
This is not directly related, but it could provide some inspiration :
app/forms/{workflow_name}__{workflow_revision}__{task}.haml
app/forms/{workflow_name}__{task}.haml
app/forms/{task}.haml
app/forms/default.haml
It's a scheme for looking up forms in Rails. There is only one human
participant which loads forms starting with the most detailed path. As soon as
it finds a form, it uses it. default.haml matches always (catch all).
You could think of such a scheme for automated participants
app/participants/{workflow_name}__{workflow_revision}__{participant_name}.rb
app/participants/{workflow_name}__{participant_name}.rb
app/participants/{participant_name}.rb
app/participants/default.rb
(I wonder if I shouldn't provide such an automated participants out of the box,
it's very easy to implement... But it becomes a bit harder to manage for
multiple workers on multiple hosts, you have to make sure the participants/
folder is in sync)
> For rendering "yes" "no", I did not make clear what I mean. I would
> like the task definition in the process to contain sth. like this:
> junior, :task => "fix pipe", :answers => "fixed, not fixed"
> senior, :task => "fix pipe again", :if => "${f:answer} == fixed"
>
> And render "fixed", "not fixed" buttons in place of "proceed" button.
> I now how to do it technically. But my questions are: Was it done
> before? If yes, are there some custom names and format for that? If
> not do you like the names provided here?
> Hope this time it is clearer.
No, there is no convention for this. Feel free to choose a solution you like.
I always thought that
sequence do
junior, :task => "fix pipe", :answers => "fixed, not fixed"
senior, :task => "fix pipe again", :if => "${f:answer} == fixed"
end
could be reduced to
sequence do
junior, :task => "fix pipe"
senior, :task => "fix pipe again", :if => "${f:answer} == fixed"
end
for greater readability and no loss in understanding.
Of course, if you rely on :answers to build forms, you cannot drop it.
Thanks for the exchange, best regards,
--
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
