jBPM4 Design Topics
by Thomas Diesler
Hi Folks,
in preparation for the meeting in Antwerp, here a few design considerations
http://www.jboss.org/community/docs/DOC-12855
Thanks for your feedback and look forward to meeting you next week.
cheers
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
BPM Product Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
16 years
[Design of JBoss jBPM] - Re: Behavior when next state in a
by tom.baeyens＠jboss.com
"camunda" wrote :
| anonymous wrote :
| | So I still think a component library that directly knows how to interact with jBPM is something that would be/is great to provide.
| |
| +1! But the problem may be, which technology to provide. But I think Facelets weren't such a bad idea...
Heiko, do you mean to a JSF or GWT component library that people can use to display the task list in their apps ?
Find a replacement for Facelets for the task forms technology might be difficult given that Facelets is:
* a simple library for template rendering
* rendering can be done easily programatically
* based on XHTML, so easy for users to customize the generated templates
Seam also uses Facelets for rendering the content of emails. That is what I would like to move to as well. Then seam (ui and email) and jbpm (task forms and email) are all based on the same simple technology.
Heiko, do you see a viable alternative for Facelets ? Maybe there is some templating component in GWT ?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185955#4185955
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185955
16 years
[Design of JBoss jBPM] - Re: Behavior when next state in a
by 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
16 years
[Design of JBoss jBPM] - Re: Behavior when next state in a
by heiko.braun＠jboss.com
anonymous wrote :
| I've been having very good success (with some agony) of morphing the jbpm-console into a useful "application", instead of a demo, that can have several business processes available and gives users of the processes a good experience. A few new tags and some customized pages with "tab" behavior, etc. have made it very useful. The use of the JSF and s4j tags makes it easy to test and retest without starting and stopping the server or having to redeploy the console ( I use Eclipse with my workspace pointing to the unzipped jbpm-console.war and alter it there ). The only time I have to start and stop the server is when I add a class to the console, of course. Business processes are deployed as usual to the console.
|
Not "end-user" targeted is wrong. The aim of the new console to provide a proper solution for the most common jBPM use cases. If you are interested in contributing or "shaping" the task management functionality, then I'd gladly here about your ideas.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185806#4185806
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185806
16 years
