Can you see the transition from the validator? That's the only (bad) solution I found right now.
that is because there is not only validation on the form (with the required=true) but also in the PD. That validation cannot be bypassed.
Please file a jira issue with this request. It might be picked up, it might not be.
Maybe required=true is inappropriate here, since it isn't actually required by all transitions.
Can you set the required=false, then do transition specific validation?
difficult... Since in this case the process does validation to (as it should, never trust the UI). you can do conditional required here with e.g. a EL with reference to the transition name. Difficult , but it could be done. Doing this on the process level is more difficult. I therefore started a discussion in the design forum to make jBPM more flexible in this area. See http://www.jboss.org/index.html?module=bb&op=viewtopic&t=115022
One of the reasons I'm using the JSF form validation is that the "required" attribute isn't enforced in the process definition, e.g. :
<task-node name="MyTaskNode"> <task name="MyTask" > <controller> <variable name="MyVar" access="write,required"></variable> </controller> </task> <transition to="MyNextNode" name="Next Node"></transition> </task-node>
You can open the corresponding form for this node in the jbpm console, omit a value for MyVar, and click Next Node to transition to the next node without any validation error occurring. I looked at the code in TaskController::submitParameters() and it is simply checking for variable's existence in a map, regardless of contents. But this will never fail because an empty variable for MyVar is automatically created by JBPM when it creates the task.
JSF posts an empty value in many cases. So the required attribute IS enforced (the required attribute is in the pd), only with an empty value!!!.
I can't think of a case where I'd want empty string to be a valid value. Is there some use-case I'm not thinking of?
It seems like it would be a pretty good usability increase to consider empty strings as invalid.
I also don't see the point of requiring a value but allowing it to be an empty string. The point of requiring a value is so that you obtain the required user input. In addition, sometimes you need to verify that the non-empty value meets additional validation requirements (such as being a valid date).
As you pointed out, specifying the validation in the PDL is preferable to performing validation in the UI. I would recommend that the jpdl schema be enhanced to support more validation.
As a work-around, I have written an action handler that validates based on "rules" read from the tag content. It is not very sophisticated, but it supports my current needs. I can add the action handler to a node-leave event which enforces validation on all transitions, or I can add the handler to just a single transition event so that other transitions do not require validated input. When a validation error occurs, an exception is thrown which results in a message being displayed to the user in the jbpm console.
Here's an example of it's use:
<task-node name="GetData"> <task name="GetDataTask"> <transition to="NextTask" name="Accept Data"> <action class="mypackage.AssertRequiredVariables"> <assertions> <entry><key>MyDate</key><value>date</value></entry> <entry><key>MyString</key><value>string not-empty</value></entry> </assertions> </action> </transition> <transition to="AlternateStep" name="Date Not Required"></transition> </task-node>
In this case, the data is only required on the Accept Data transition. This allows canceling or going to a step that doesn't require the input without forcing the user to enter data that passes the normal validation.
As you pointed out, specifying the validation in the PDL is preferable to performing validation in the UI. I would recommend that the jpdl schema be enhanced to support more validation.enhancing the schema is not that difficult, creating the code behind it is.
If it is done it should seamlesly (pun intended) integrate with the ui frontend. So imo the variable type, vaildator and maybe even a message should be configurable. But then again I also want the read, write, required in separate attributes see topic in the design forum)