streching the expression language

[tom.baeyens]

"Jeff" wrote:
Tom,

I have two problems with this process model.

1) does not like <= , complains that it must not contain the '<' character. But this is legit in the JSF expressions guide.

2) even if I change to LT, the Yes transition is always taken, no matter the value of basePrice. However if I switch the order of the transitions in the file, the No transition is taken. This remains the case if the value of basePrice is greater than 300.

I have used similar expression before with success (well not the <), so I am not sure what is going on here. basePrice is an int, if that makes a difference. I can print out the value of basePrice, and know that has been set correctly (by JBoss rules). Changing basePrice from an int to an Integer or String does not help.

Any ideas?

Thanks,

Jeff

<?xml version="1.0" encoding="UTF-8"?>

<process-definition
 xmlns="urn:jbpm.org:jpdl-3.2" name="InsuranceProcess">
 <start-state name="start">
 <transition name="" to="Execute Underwriting Rules"></transition>
 </start-state>
 <node name="Execute Underwriting Rules">
 <action class="org.jbpm.action.RulesActionHandler">
 <ruleFile>pricing/PolicyPricing.xls</ruleFile>
 <ruleFileType>XLS</ruleFileType>
 <objectNames>
 <element>driver</element>
 <element>policy</element>
 </objectNames>
 </action>
 <transition name="" to="Manual Review Required?"></transition>
 </node>
 <decision name="Manual Review Required?" >
 <transition name="No" to="end">
 <condition expression="#{policy.price LT 300}" />
 </transition>
 <transition name="Yes" to="Underwriter Signoff">
 <condition expression="#{policy.price > 300}" />
 </transition>
 </decision>
 <task-node name="Underwriter Signoff">
 <task name="Underwriter Signoff">
 <assignment class="org.jbpm.assignment.RulesAssignmentHandler">
 <ruleFile>/Assignment.drl</ruleFile>
 <group>underwriter</group>
 <objectNames>
 <element>policy</element>
 </objectNames>
 </assignment>
 </task>
 <transition name="" to="end"></transition>
 </task-node>
 <end-state name="end"></end-state>
</process-definition>

Maybe it has to do with the fact that i took and tweaked some older version (pre-unified-expression-language) from the apache commons stuff.

I have not yet been able to get the same things out of the EL RI. Once I get that to work properly it could replace the commons EL and solve these problems.

I'm a bit afraid of the backwards incompatibility, though. Now I have this abstraction of method binding and value binding. If the expression is used to get a value and a method is given, then the return value of the method is taken. Something that will probably be hard to get in the RI of EL.

regards, tom.

[tom.baeyens]

as for the '<' character, try removing the namespace reference. that should deactivate the schema validation. I have this in the unit tests:

public ProcessDefinition createConditionProcess() {
 return ProcessDefinition.parseXmlString(
 "<process-definition>" +
 " <start-state>" +
 " <transition to='d'/>" +
 " </start-state>" +
 " <decision name='d'>" +
 " <transition to='high-numbered-customer'>" +
 " <condition expression='#{customer.number > 5}' />" +
 " </transition>" +
 " <transition to='medium-numbered-customer'>" +
 " <condition expression='#{customer.number == 5}' />" +
 " </transition>" +
 " <transition to='low-numbered-customer' />" +
 " </decision>" +
 " <state name='high-numbered-customer' />" +
 " <state name='medium-numbered-customer' />" +
 " <state name='low-numbered-customer' />" +
 "</process-definition>"
 );
 }

and that works. I don't know what I have to put in the schema to allow for '<' characters. Anyone ?

regards, tom.

[dmlloyd]

I don't know what I have to put in the schema to allow for '<' characters. Anyone ?

My understanding is that there is nothing you can do. You have to use an XML entity like &lt; - similarly if you want a literal "&" you must use "&amp;". This is why they have named forms of relational operators in EL - such as "lt", and "and".

[estaub]

David's right.
-Ed Staub

[tom.baeyens]

3 times hurray for the feature called 'deactivation of xml validation' :-)

[kukeltje]

I'm surprised that removing the schema results in no validation at all... not even wellformedness.

[dmlloyd]

"kukeltje" wrote:
I'm surprised that removing the schema results in no validation at all... not even wellformedness.

This kind of behavior is not something I'd rely upon. But that's just me.

[kukeltje]

Correct, but maybe it is something Tom build in on purpose ;-). You can add your own elements by disabling the validation, But I'd rather have that it could be done via namespaces. Since the processfile is stored in the db now, that opens up interesting things...

[kukeltje]

btw, Seam uses an enhanced version of EL, wasn't there a jira issue to move to that one instead of the RI?

[jeffdelong]

Putting aside the issue with '<', I am finding that the process takes the first ransaction from the decision regardless of what I put in the condition. I.e., the transition with

<condition expression="#{foo.price > 3000}" />

is taken if it is first and not if it is second, even though foo is not a context variable. This is all with 3.2 Beta2.

[tom.baeyens]

i can't see how your process is different from the test that i pasted in above...

if you have a clue on that, that would be helpfull.

[andyredhead]

Going back to using > and < in attribute values question/issue.

I reckon that if the doc was validated against a dtd and the type of the expression attribute was specified in the dtd to be type CDATA then you could use > and < (or most other standard text things) without a problem.

I'm not familiar with xsd. I've just taken a look in the file jpdl-3.1.xsd and it looks like the expression attributes are set to type xs:string. Does anyone know:

1) what this type allows in terms of text content

2) is there an equivalent of CDATA for xsd (and what is it) - if there is an equivalent then the expression attributes could be changed to xs:cdata-equivalent in the xsd and it might all work.

I really don't like the idea of not using a validating xml parser on process definitions :(

Cheers,

Andy

[andyredhead]

After a quick google it looks like:

xs:CDATA

might be worth a try...

[jeffdelong]

I am having the same issue with expressions in conditions on decision node transitions in the ruleFlow example. If you check it out and create a new rule project (see its readme), and run it, you will see from the logging that the premium calculation path is being taken even if the decline count is non-zero.