Suggestion for transitions

[jochen_mader]

A little while ago I opend http://community.jboss.org/thread/153535.

After digging around for a while I'd like to make a suggestion for future versions of jBPM (I hope this is the right place to do this).

We are using jBPM in a webapplication with a lot of different processes and a couple of developers working on them at the same time.

Currently the only available signals are Strings.

As Strings are inherently evil I'd like to tame them a little and use public static final Strings (Enums would be even better) for the transition names.

My suggestion would be to allow JUEL scripts for transition names.

Thanks,

Jochen

[mwohlf]

Can you maybe give an example, I don't really understand.

"allow JUEL scripts for transition names"

would this mean you have transition like this in your process definition:

<transition name="#{someObject.resolvedTransition}" to="nextActivity" />

[jochen_mader]

Yep, that would be my suggestion.

And while we are at it we could enable users to prvoide additional ELResolvers

[mwohlf]

Jochen Mader wrote:

Yep, that would be my suggestion.

And while we are at it we could enable users to prvoide additional ELResolvers

+1 from me for the ELResolvers, the first thing i would resolve would be the #{authenticatedUser} it's a PITA to get this information somehow in jBPM

as for the transition ,

whats the advantage of having EL in transition names compared to using a decision?

http://docs.jboss.com/jbpm/v4/userguide/html_single/#decision

[jochen_mader]

I want to be able to signal the transition.

Example:

There is one user who does a couple of changes on a data item, he then either "submits" (signal execution with the string "submit") or saves the data item.

When he "submits", another user will be able to "accept", "decline" or "defer" the changes with each signal triggering a different workflow.

A decision for me involves some computation which has to be done inside jBPM whereas what I am doing is that a user actively triggers the different workflows.

So I would say that using signalExecution is the correct way in a process sense.

Thanks,

Jochen