decision conditions

[tom.baeyens]

i just finished generalization of the conditions (SEAM request). previously, it was only possible to specify conditions on transitions leaving a decision node.

now, (from 3.2.Alpha3 and onwards) it will be possible to specify conditions on any transition. these will be checked at runtime.

also i added the functionality to the token of getting all the transitions for which there is no condition or a condition that resolves to true. this method is called getAvailableTransitions()

by implementing this in a backwards compatible way, i realized that the current behaviour is still very awkward. a decision will scan and evaluate all transitions that have a condition first. the first transition for which its condition resolves to true will be taken. if no transition with a condition resolves to true, the default (=the first one) will be taken.

with pain in my heart :-( i saw that the docs actually explained different behaviour then what is implemented. so i had to update the docs explain the less intuitive behaviour... snif. A decision will take the first transition that has no condition or that has a condition which resolves to true.

i have kept this strange behaviour for backwards compatibility reasons. As far as i can see now, old processes with decision conditions will still work in the new version. Also if you redeploy processes with decision conditions, they will still work (i have marked the expression attribute on the condition as deprecated). The new versions will never use the JBPM_DECISIONCONDITION table any more. But i left it in the hibernate mappings so that there is no need for a conversion script. If people don't have old deployments with decision conditions, they can just remove that table.

DO YOU THINK THAT IS A WISE 'DECISION' ? Or should i just change the decision behaviour to the more intuitive and backwards incompatible mode ?

[kukeltje]

Tom,

Don't you partly contradict yourself here:

current behaviour is still very awkward. a decision will scan and evaluate all transitions that have a condition first. the first transition for which its condition resolves to true will be taken. if no transition with a condition resolves to true, the default (=the first one) will be taken.

and

explain the less intuitive behaviour... snif. A decision will take the first transition that has no condition or that has a condition which resolves to true.

Assuming the 'order' is the order in the jpdl file.

[tom.baeyens]

explain the less intuitive behaviour... snif. A decision will take the first transition that has no condition or that has a condition which resolves to true.

the second part is indeed the WANTED behaviour and not the less intuitive behaviour. should not have been there. just ignore the second part: 'A decision will take the first transition that has no condition or that has a condition which resolves to true. ' in that paragraph.

[brittm]

As stated, It is very un-intuitive and certainly doesn't clearly document what is going on in the decision. I always try to make all of my transition criteria explicit, and can't imagine ever seriously writing a Decision node that would rely on the old behavior. I imagine other developers aren't relying on it either.

As Tom mentioned, the docs were wrong and no one even noticed.

I would vote for the change.

-Britt