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

kukeltje do-not-reply at jboss.com
Tue Oct 7 05:16:33 EDT 2008


anonymous wrote : 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.
  | 

I know, but it should not limit us (and it should not be neccesarilly be in 3.3 (I created my own local patch), or we can even do something like 


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

or even


  |      if (this.isCancelled && jbpm.properties.Task-cancel-event-backwards-compatibility != true) {
  |     	  task.fireEvent(Event.EVENTTYPE_TASK_CANCEL, executionContext);
  |       } else {
  |     	  task.fireEvent(Event.EVENTTYPE_TASK_END, executionContext);  
  |       }
  | 

and make that property by default true.... but that is probably what Tom want's in the task specific config file... 

Still.... I get the feeling that extending the 'task handling process' a little is not wrong, but making it really configurable is imo well.. not realy a waste of time, but certainly not high priority... what we have is not that wrong. Putting two eventhandlers on a definition is supported *now*, making it configurable takes a lot of time

anonymous wrote : 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.
  | 
Hmm... I did something similar once in a p.o.c. but did not use/need any variables. Maybe because we took another angle on it, but I could deduce all from the methods on the task. Otoh, we did not have to query for them, the number of tasks we that limited that we could use the default tasklist query and filter afterwards.


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

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



More information about the jbpm-dev mailing list