userTask with formProperty using activiti:expression
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-18-2012 06:00 AM
Given the following userTask defintion, the formProperty gets no value assigned. Assumption: activiti:expression raises the issue.
<userTask id="sid-E646E275-5000-48BB-A728-0016198C9158" "name="Weighing" >
<extensionElements>
<signavio:signavioMetaData metaKey="bgcolor" metaValue="#FFFFCC"/>
<activiti:formProperty id="deviceID" name="ID of Device:" activiti:expression="${measurement.getDeviceID()}" required="true" />
</extensionElements>
</userTask>
When using the following userTask definition, the value gets properly assigned. Why does the first case not work?
<userTask id="sid-E646E275-5000-48BB-A728-0016198C9158" "name="Weighing" >
<extensionElements>
<signavio:signavioMetaData metaKey="bgcolor" metaValue="#FFFFCC"/>
<activiti:formProperty id="deviceID" name="ID of Device:" expression="${measurement.getDeviceID()}" required="true" />
</extensionElements>
</userTask>
In both cases the following service task runs in upfront, so that both userTasks have a valid process variable measurement.
<serviceTask id="sid-8BA4EC63-5264-46A0-AFB9-661AA8882AF0" activiti:class="server.controller.CreateMeasurementDelegate" name="Create Measurement">
<extensionElements>
<signavio:signavioMetaData metaKey="bgcolor" metaValue="#ffffcc"/>
</extensionElements>
<incoming>sid-F022415D-63DB-4A5F-BC63-160AED34DAE9</incoming>
<outgoing>sid-54134A6F-F14F-4559-BFFD-699FFFF2DCC3</outgoing>
</serviceTask>
Best regards,
Marco
<userTask id="sid-E646E275-5000-48BB-A728-0016198C9158" "name="Weighing" >
<extensionElements>
<signavio:signavioMetaData metaKey="bgcolor" metaValue="#FFFFCC"/>
<activiti:formProperty id="deviceID" name="ID of Device:" activiti:expression="${measurement.getDeviceID()}" required="true" />
</extensionElements>
</userTask>
When using the following userTask definition, the value gets properly assigned. Why does the first case not work?
<userTask id="sid-E646E275-5000-48BB-A728-0016198C9158" "name="Weighing" >
<extensionElements>
<signavio:signavioMetaData metaKey="bgcolor" metaValue="#FFFFCC"/>
<activiti:formProperty id="deviceID" name="ID of Device:" expression="${measurement.getDeviceID()}" required="true" />
</extensionElements>
</userTask>
In both cases the following service task runs in upfront, so that both userTasks have a valid process variable measurement.
<serviceTask id="sid-8BA4EC63-5264-46A0-AFB9-661AA8882AF0" activiti:class="server.controller.CreateMeasurementDelegate" name="Create Measurement">
<extensionElements>
<signavio:signavioMetaData metaKey="bgcolor" metaValue="#ffffcc"/>
</extensionElements>
<incoming>sid-F022415D-63DB-4A5F-BC63-160AED34DAE9</incoming>
<outgoing>sid-54134A6F-F14F-4559-BFFD-699FFFF2DCC3</outgoing>
</serviceTask>
Best regards,
Marco
Labels:
- Labels:
-
Archive
4 REPLIES 4
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-18-2012 11:47 AM
Why does the first case not work?
Because you've repeated the 'activiti:' prefix. Seems not to be valid XML.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-19-2012 05:03 AM
Ok, your remark makes sense, but when I deployed this usertask it gets accepted by the activiti explorer.
Nevertheless, I would expect that in this case the phaser should throw an exception saying that "the attribute 'expression' is already bound to namespace 'activiti'" so that I can fix this issue. Just ignoring the invalid bpmn and letting the phaser succeed the validation isn't a good design. In addition at execution time the attriubte is ignored as well. In this case a user absolutly has no clue that he did a mistake.
thanks,
Marco
Nevertheless, I would expect that in this case the phaser should throw an exception saying that "the attribute 'expression' is already bound to namespace 'activiti'" so that I can fix this issue. Just ignoring the invalid bpmn and letting the phaser succeed the validation isn't a good design. In addition at execution time the attriubte is ignored as well. In this case a user absolutly has no clue that he did a mistake.
thanks,
Marco
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-21-2012 04:17 AM
You're absolutely right. We're currently completely rewriting the parser and things like these will be picked up.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-21-2012 04:26 AM
Altough it might be tricky to do … because according to the XSD it is of course valid …
