[jbpm-dev] [Design of JBoss jBPM] - Re: Behavior when next state in a

[kukeltje]

Heiko,

anonymous wrote : The aim of the new console to provide a proper solution for the most common jBPM use cases.

Most common 'end-user' *BPM* usecases were (almost all) supported in the older console as well. 
- Start processes
- See personal and group tasklist
- act on task (via generated forms)
- (re-)assign tasks

End-user being one of the actors in a process, not jBPM 'customers' in general

What users requested from the console are things like:
- Can I remove/adapt/change menus
- Can I customize look and feel (sometimes even per process)
- Can I customize forms
- Can I have taskbuttons be displayed or not based on e.g. transition conditions in the task (guarded transitions)
- Can I integrate my own (JSF/seam) backingbeans
- Can I go directly to the next task if it is in the same swimlane
- ... and more

Some of these could be put in the console, but many of these kinds of customizations make it hard to upgrade to e.g. a newer console. If we want to encourage people to do these kinds of changes, it would require a lot more documentation. Besides that, marketing/sales/... can come up with more requirements than we can (should) support in a generic console.

Looking back, the type of 'developers' that wanted to do these kinds of changes, were not the most bright ones or people under a lot of pressure thinking they had a quick win adapting something that is already there. The brighter ones probably were aware of these issues and developed their own UI.

The intention of e.g. jbpm4jsf library would have made it even easier then it already is to create your own webapp. The combination of jbpm4jsf and gravel never took off due to a lack of documentation, promotion and to complex usage. Gravel (ajax?) functionality should have been hidden in jbpm4jsf components. So I still think a component library that directly knows how to interact with jBPM is something that would be/is great to provide.

So my conclusion would be that the target usage of the console would still be:
- RAD (initial demonstration of a process)
- management things.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185935#4185935

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185935