extending form / task functionality
kukeltje Jun 13, 2006 12:58 PMOne of our customers has a requirement which we are evaluating to see if we are going to meet these or not. Let me explain.
The application has several tasks that have to be performed in sequence. These tasks can be performed directly, one after another, but it could also be that there is a one day delay between them. So it is not realy a wizard or pageflow, but real tasks. So far no problem. The customer also wants that IF the user performs the task he/she should automatically see the next task in that process if it is one for him. Currently the ui goes back to the tasklist. This is highly unwanted by the customer and we (not higly, buy to some extend) agree. I'm currently looking into ways of achieving this. If there is any hint or tip on how to achieve this, I'll be greatfull. Especially if this is functionality interesting enough for jBPM.
The other requirement is that the customer has is a kind of wizard functionality
jBPM has pageflow functionality (wizard?), process/workflow and there is the forms.xml file. It would be nice if the pageflow.xml and form.xml would become one. There is a lot of overlap
<page name="Task1" view-id="/task1Page.xhtml" redirect="true"> <transition name="checkout" to="checkout"/> <transition name="complete" to="complete"/> </page>
could be easily used instead of
<form task="Task1" form="/task1Page.xhtml" />
If there is no transition, the default 'tasklistpage' is shown if there is a transition, the corresponding page is looked up and displayed. This way a pageflow can be used in a task. The only thing is that the last page should contain a call to a method which ends the task, whereas the other pages contain calls to methods which just update the processvariables, other beans or do whatever is needed, just not end the task. This could be done either based on explicitly in the form or by adding an attribute in the pageflow to explicitly (e.g. a conversation) tag around several pages, or a pageflow file per task.
I'd like to discuss these here, since if it is interesting for the jBPM webapp framework, we can contribute. If it is not, we have to implement something ourselves and will probably not use the jBPM webapp at all
Ronald
(not as moderator)