[Design of JBoss jBPM] - Re: Cancelling a task fires task-end event
by kukeltje
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
17 years
[Design of JBoss jBPM] - Re: Cancelling a task fires task-end event
by jbarrez
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
17 years
[Design of JBoss jBPM] - Re: Cancelling a task fires task-end event
by kukeltje
"jbarrez" wrote :
| It is a difficult topic :p
|
I tend to disagree, see below
"jbarrez" wrote :
| I have a use case in which having a cancel event would be great. In that use case is cancelling a task conceptually different from ending a task: ie. a cancelled task is a task which has not been ended (= finished correctly) by someone.
|
| But, Tom is right: for another customer the story could be different ...
|
If they are the same for this user, They will just use one or the other (most likely end() ). But for others, they can put any logic they want on 2 'event-handlers' so..
"jbarrez" wrote :
| Perhaps for jBPM4, something drastical should happen to cover this since it will never be good for everybody... perhaps working with inheritance for events, so that you could catch Task-end and Task-cancel but also Task-finished (parent of end and cancel) event that is a catch-all if it doens't matter ... ?
Could be, but that makes it more difficult to implement. You can get that functionality by declaring 2 event-handlers as mentioned above.... I would not make it overly complicate. But if kind of hierarchical events are introduced, that would be fine to. In that case we agree and is it less complex/difficult than we thought.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180725#4180725
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180725
17 years