[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