[jbpm-dev] [Design of JBoss jBPM] - Re: Cancelling a task fires task-end event

jbarrez do-not-reply at jboss.com
Tue Oct 7 04:53:46 EDT 2008


Ronald,

If you are using this construction:


  |      if (this.isCancelled) {
  |     	  task.fireEvent(Event.EVENTTYPE_TASK_CANCEL, executionContext);
  |       } else {
  |     	  task.fireEvent(Event.EVENTTYPE_TASK_END, executionContext);  
  |       }
  | 

Then you are missing the TASK_END event if the task is cancelled. People for who see 'finishing a task ' (ie. cancelling or completing)  as the end of a task (which is conceptually also correct) and now simply use an event handler for the TASK_END event are obliged to use 2 event handlers now.

So it comes down to a matter of conceptual view: 
- Ending a task == the task is finished (removed by cancelling or successfully completed)
- Ending a task == completing the task successfully, BUT cancelling means here that the task did not end but simply dissapeared for some reason.

I have implemented both use cases in the past, so this is not some academic example. What we need here is a solid and clear definition ...

anonymous wrote : 
  | Otoh, I've not heard people complaining about taskmanagement regarding the 'states' of task management do you guys? Questions were more about declaring vars, typing them, giving default values etc
  | 

That's true ... but I did have a use case in which the states of a task were THE most import thing: cancelled, suspended, ended, assigned but not taken, working on it, etc.  all those states were possible for a task. So you can imagine I would have been very happy at that moment if I had some more options ... we had to juggle a bit with task variables to get it all done.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180733#4180733

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180733



More information about the jbpm-dev mailing list