designer and delegation

[simonbaker]

Section "18.2. Delegation" of the manual describes how you can add custom "fields" to your custom classes such as AssignmentHandlers.

Such fields include Lists.

Can the process designer support Lists in the UI? (They appear to be treated like simple String fields.) Or must list field initializations be manually entered in the xml file?

[koen.aers]

Generic collections such as list, maps, etc are difficult to support in the designer. I am also not sure if it is good practice to use these collections to configure your delegation classes. Also, editing the xml source pane might for the moment result in all kinds of weird things happening because of various xml synchronization bugs. So the most reliable solution is to open the file in a regular xml editor and add the configurations there for the time being. I am working hard on the xml synchronization bugs though, so stay tuned.

Regards,
Koen

[simonbaker]

Hi Koen: I'm a fan of the GPD because it makes the jBPM feel like a real product for designing workflows, rather than just a well-written, very flexible, but poorly documented core that one is tempted to hack one's own solution to. So we appreciate your efforts in continuing to improve the GPD and hope you take our suggestions as interest rather than just criticism.

I'm realizing that perhaps even more important than supporting lists in the bean/field setter of the GPD would be supporting "enums" or something equivalent.

A significant limitation of the bean/field setter is that we are encouraged to input "magic" constants into the fields whose meaning is only apparent by reading the code for the custom class that processes the fields. Boolean fields are not a problem as they can be named to make them self-documenting. But string fields don't give much clue to the range of inputs they can accept.

It's not a problem for fields like "name" where anything is acceptable. But let's say we want to indicate the workflow "role" that our custom AssignmentHandler should use to select actors for the pooled actors of a task. What role names are we allowed to input? If the role field could be made an "enum" type, and the GPD bean/field setter expose the list of enum values to select from, it would be a very powerful feature that would help decouple the business process design from the code writing.

[koen.aers]

Hi Simon,

Good suggestion again. But maybe this should be supported in the jBPM core as well...
As for the use case you are describing. The custom assignment handling with proper input forms is already supported through the use of extension points in the designer. But then you might not be an Eclipse developer who is used to add his own plugins on top of other plugins of course...
I will nevertheless also (re)implement dropdown boxes to choose the swimlanes in the future. Swimlanes are as you might know the equivalent of roles in the process.
But please continue to give valuable input and file feature request in JIRA for the things you care about...

Thanks,
Koen

[simonbaker]

Thanks for considering suggestions and for steering us on how to use existing features to best get the job done. Often we just don't know the "right" way to use a tool. And true, we're not sophisticated users of Eclipse at this point, especially plugins. I'll be taking a closer look at swimlanes per your comments, and plugins hopefully some day.