default generated forms

[tom.baeyens]

previously, a form could be generated from a task based on the default task controller. originally, all process variables were not visible from task instances. so if variables were needed in a form, it was mandatory that they were copied from the process variables and stored as separate task instance local variables.

with that background, at the time, we could generate a default form based on the configuration of the default task controller.

but now things have changed. task instances now CAN see process variables. so a task controller only becomes necessary if you want to create task local copies of the process variables. so in general, i think that the task controllers will be less used. and hence they can't be used as the source information to generate default task forms.

afaik, a forms.xml was always necessary, no ?

so the idea we have now is that the graphical process designer will have to be used to generate forms. the graphical process designer will still be able to generate the default form based on a few process variables as input. but now, a facelets .xhtml form will be generated that could potentially have the same layout as before.

variable declarations in the process definition would help a lot, i think.

but overall, do you think that we could provide a simpler way to distill the task forms ?

[tom.baeyens]

btw, the origin of this discussion is kukeltje's jira comment on http://jira.jboss.com/jira/browse/JBPM-732

[tom.baeyens]

see also http://jira.jboss.com/jira/browse/JBPM-715

[kukeltje]

forms.xml is new since 3.2. It was not needed in 3.1

In a kind of real life situation, there is a lot of overlap in the variables used in different task, with a major difference. The 'read', 'required' and 'write' differ. So I always use task-local copies. That is nice to for auditing (but that might be read from the logs as well)

for designing the .xhtml files, I currently use exadel (free version) in addition to eclipse/wtp/gpd. We should not try to build an editor ourselves. I have some ideas on how to do things (e.g. generate beans for tasks so it is not needed to have things like "taskVariable['variableName']" but task1.variableName or process1.variableName2. Code completion then works in jsf editors, but these beans have to be put in a faces.config file (maybe a jsf editor can be augmented by reading aspects, that would be nice).

I'll put some additional text up tomorrow