On 25 Mar, 08:51, John Mettraux <[email protected]> wrote:
> 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,
Hi,
>
> 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)
It would be fantastic for our project cause it has two ways to
implement participants one is in app/participants and other in process
defining class. Now I am afraid that names of participants can easily
be duplicated by accident in the second case. So registering
participant with process_name and process_version (or as you say
workflow and revision) would make it safer. I really like the idea of
automated participant and task as for duplicates one can use class
inheritance to stay DRY. You are right that processes tend to change
faster than participants (not task forms thou) so I would suggests
changing your auto discovery list a little:
["workflow_name","workflow_revision", "participant_name"]
["workflow_name", "participant_name"]
["workflow_revision", "participant_name"]
["participant_name"]
catch_all
In this way we have shared version for many processes. One weird thing
however is that the number is of a process version and developers need
to remember that but they can always escape to
["workflow_name","workflow_revision", "participant_name"] if needed.
Still I'm not sure if it isn't to strange.
>
> > 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.
>
I think you are right I will put it in a helper function for rendering
buttons in a task form, not in the process.
> Of course, if you rely on :answers to build forms, you cannot drop it.
>
> Thanks for the exchange, best regards,
Thx
Jan
>
> --
> 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
