Variable type definition in processdefinition.xml (yes again

[kukeltje]

There are several issues that address need for the variable type in the pd. Im realy working on the webui now, and could realy use this for having automagically generated forms with the correct ui components (a dateselector for dates etc) could someone comment on these issues?

http://jira.jboss.org/jira/browse/JBPM-72
http://jira.jboss.org/jira/browse/JBPM-71

Some other related:

http://jira.jboss.org/jira/browse/JBPM-613

[tom.baeyens]

yes, variable type information is a good addition. we didn't really need it so far, but it would be nice to have. when we add it, we should make sure it doesn't become required information all of a sudden. we should try to keep the variable type information optional and maintain the hashmap idea of variables as a viable option.

as for forms, the current status was that i didn't get types working with the 'conversion' property in JSF. i didn't try very hard, though so that would be the first thing to research. once that works, the automatic form generation that will be build by the gpd could use that information to generate the proper conversion in the task forms.

[kukeltje]

YES, YES, YES.. thank you , thank you.

It should indeed be optional for backwards compatibility. But if added, the GPD (or a simple ant task) could take a freemarker template or an xslt and generate a basic form.

No idea about the JBoss preference but I have no freemarker expertise, nor time to spent time on this. I think that someone with some instruction could make a freemarker template or xslt, at least for a basic byt nice looking form.

hmm... I used date/integer from JSF in the webapp for 3.1 and did not need any conversion property or so. Displaying a date object in the process as a human readable string worked without a problem. You can try to install tomahawk and use the datecalendar input type on a variable of Date (create it first in the process instance!!!!) and it works perfectly.

It even is possible to take an array from one process variable, use that as the selection in a dropdown list and have the selected result in another processvariable by just referencing the correct variables.

so since I've not neede the conversion attribute in 3.1, I have no idea why it should be needed now. Can you explain?

Ohhh and... btw, when is the variable-type in the PD???? ;-)

[tom.baeyens]

"kukeltje" wrote:
But if added, the GPD (or a simple ant task) could take a freemarker template or an xslt and generate a basic form.

i don't care how koen does the generation of the .xhtml facelets template it in the gpd. probably programmatic would be the easiest and most portable. at runtime, the forms will be rendered with facelets.

"kukeltje" wrote:
hmm... I used date/integer from JSF in the webapp for 3.1 and did not need any conversion property or so. Displaying a date object in the process as a human readable string worked without a problem.

the problem is when you want to create a form field to enter a new integer process variable. since the task form variables are in a hash map, taskInstance.variables['myNumber'] will be stored as a string if no conversion is specified. i was hoping that specifying a conversion on the input field could do the trick to convert the submitted text to integer before it was inserted in the untyped hashmap.

"kukeltje" wrote:
Ohhh and... btw, when is the variable-type in the PD???? ;-)

what use cases do you see other then generating forms ? it will be a challenge to find a clean and natural behaviour of the system. some people want to use it as a free hashmap. others want the types of variables to be checked. some want the variables to be created at start time, others want lazy initialization,...

[kukeltje]

the problem is when you want to create a form field to enter a new integer process variable. since the task form variables are in a hash map, taskInstance.variables['myNumber'] will be stored as a string if no conversion is specified.

That is correct for a new variable, I missed that part from your previous remark. So that is where converters come in. OK, if I find the time, I'll have a look. But if someone else has an idea.... Maybe using the variable-type from the PD and do some conversion before posting IF the type is not already correct. Or maybe filling the hasmap not with strings (default) but with objects created by using the variable-type from the PD. IF for the variable type we define java types

[kukeltje]

generating programatically... fine, as long as there are enough id/class attributes to do some styling based on css.

Templatizing this could be moved to a later version of the gpd.