October 2008 - jbpm-dev - Jboss List Archives

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

by jbarrez

(Hijacking the thread again :p) anonymous wrote : 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. Ronald, is it possible to make a blog post about it or was it for a customer? I'm interested in seeing your approach ... perhaps we can exchange our ideas? eg. we had to create a special actorId 'parser' by using a 'role:assigned_to' string: if the assigned_to it meant that no-one was working on it, else the task is visible to anyone of the role. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180740#4180740 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180740

16 years, 1 month

1
0
0 / 0

[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

16 years, 1 month

1
0
0 / 0

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

by jbarrez

(sorry to intervene too ;-) Heiko, IMO is this API stuff. Human tasks are the most used concept of jBPM (in my experience). This needs be discussed properly before being implemented by a single person or you would get situations like this thread where someone needs a cancel-event and it does not exist altough conceptually there are some use cases. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180737#4180737 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180737

16 years, 1 month

1
0
0 / 0

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

by heiko.braun＠jboss.com

anonymous wrote : Let's make sure we address this in the jbpm team meeting. Sorry to intervene at this point, especially when it doesn't relate to this thread. But the team meeting should stay focused. Don't throw in stuff that can easily be discussed in the forums. IMO we need to make sure that conceptual things (bare bone) that relate to the API sand CTS have foremost priority when we meet. At least we should try to draw a line between implementation detail and concepts and leave the details to the person implementing it. Something else: If you come up with things that need to be considered, discussed or reviewed then raise an issue (JIRA) right away. Otherwise it get's easily lost. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180735#4180735 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180735

16 years, 1 month

1
0
0 / 0

[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

16 years, 1 month

1
0
0 / 0

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

by tom.baeyens＠jboss.com

"kukeltje" wrote : Questions were more about declaring vars, typing them, giving default values etc Those should be addressed as well in jBPM 4. Let's make sure we address this in the jbpm team meeting. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180731#4180731 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180731

16 years, 1 month

1
0
0 / 0

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

by kukeltje

"Tom B" wrote : | In jBPM 4, the task lifecycle will be expresssed in a resource file that can be customized by the user. The different states a task can be in | and the events that are fired are then specified in that configuration file. | And we do provide a fully functional jbpm 3 compatable default I hope? 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 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180727#4180727 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180727

16 years, 1 month

1
0
0 / 0

[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

16 years, 1 month

1
0
0 / 0

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

by tom.baeyens＠jboss.com

"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 ... ? That is what I was trying to indicate: In jBPM 4, the task lifecycle will be expresssed in a resource file that can be customized by the user. The different states a task can be in and the events that are fired are then specified in that configuration file. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180717#4180717 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180717

16 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - test

by thomas.diesler＠jboss.com

test View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180700#4180700 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180700

16 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jbpm-dev October 2008