Wondering about where the best place for forms really is

[rmoskal]

I've been developing a fairly substantial app and as I work I've been going back and forth on task forms. I keep wanting to be able to assign them to transitions instead of task nodes as is supported by the jpdl.

This way way use cases like a a review task, where a manager can "reject", "approve", or "ask for "rework from a another department" can be handled elegantly: I simply show a different form for each transition.

I actually started down this path a fair way then become worried that I would freak out my client making such an non-idiomatic use of jbpm. So I started reworking my forms to be task node based.

When I moved my forms to the task nodes, they suddenly need to become a lot smarter. I have to show different you elements based on which transition I want to take anyway. The UI is a bit different when one approves something than when one rejects (one might want to reassign the work for example). And different again if I want to send the task to another department for rework.

I have many scenarios like the above, and they were handled elegantly when I associated tasks with transitions. I thought about making the reassignment or the rework step to be separate task nodes, but this complexifies the work flows and it seems that from the users and the systems perspective this should be thought of as one task and not many.

Has anyone had thoughts down these lines? Am I being perverse? My app has a completely custom admin console (written in extjs) so I'm not losing anything by not having the jbpm console.

Color me curious,

Robert Moskal
Brooklyn, USA

[kukeltje]

This is not a strange thing to think, not at all. I implemented something like this on jbpm 3 once. I added custom tags to the transitions and used the forms on the task to present the INCOMING data. The user then got the choice of transitions and when picked did not take the transition but displayed a form that I configured on the transition. Only after submitting the form, the transition was taken.

I did this without creating custom jBPM classes, but just by reading the process xml from the database.

Personally I would think this could be a very nice enhancement to at least the core of jBPM and in a second step maybe the console (but I do not use that either for end-users)