This thread is somehow related to the following discussion
https://groups.google.com/d/topic/openwferu-users/UcjY0DGcHh4/discussion
When you implement a custom StorageParticipant, here's the list of methods
you might want to override to customize the way the participant manages a
workitem.
- StorageParticipant#consume
- StorageParticipant#proceed
- StorageParticipant#cancel
There are also two additional methods
- StorageParticipant#reply (a deprecated alias for
StorageParticipant#proceed)
- StorageParticipant#update (alias for StorageParticipant#consume)
Here's an example
class CustomParticipant < StorageParticipant
def consume(workitem)
# do something customized when this workitem is created
# then forward to super to finalize the #consume
super
end
def proceed(workitem)
# do something customized when this workitem is proceeding
# then forward to super to finalize the #proceed
super
end
def cancel(workitem)
# do something customized when this workitem is cancelled
# then forward to super to finalize the #cancel
super
end
end
These 3 methods covers the 90% of all workitem cases. You can customize how
the workitem is created, completed and cancelled.
However, I actually found a case that is not covered here: the case when you
simply have to update the payload of the workitem without proceeding.
I was working on an existing codebase and I saw the usage of
storage_participant.update(workitem)
At first glance, I thought that was the case, at least before I realized
#update is just an alias for #consume. It means, if you customize the
#consume logic, you are actually overriding the #update as well.
Let me show a practical example. Let's say in a Rails application I have a
storage participant to handle a workitem assigned to a Rails user. I want
some special validations to be executed when the workitem it created, thus I
customize the #consume method.
Now I want to expose a Rails view to let the user either
- edit the workitem and proceed
- edit the workitem and save the changes for later proceed
The view might look like the following
class WorkitemsController < ApplicationController
def edit
end
def update
# pseudo code
@workitem = RUOTE_ENGINE.find ...
if params[:proceed]
CustomParticipant.new(RUOTE_ENGINE).proceed(@workitem)
flash[:notice] = "Your changed have been saved and the task
proceeded"
redirect_to workitems_path
else
flash.now[:notice] = "Your changed have been saved"
CustomParticipant.new(RUOTE_ENGINE).update(@workitem)
render :action => 'edit'
end
end
I currently solved the issue by aliasing the original :update method before
overriding #proceed,
but IMHO it would be useful to have the ability to customize #consume and
#update separately.
To me, the action update doesn't really sound like a #consume action.
What do you think?
PS. I honestly continue to believe a callback system would probably solve
these and several others problems
related to workflow customization.
I haven't formalized a proposal yet, I still have to study how Ruote handles
some specific cases before,
but I'll eventually try to make a proposal as soon as I understand if it
really makes sense.
--
Simone Carletti
Application Developer
Site & Blog: http://www.simonecarletti.com
Email: [email protected]
LinkedIn: http://linkedin.com/in/weppos
Skype: weppos
--
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
