making references to usercode more consistent in jpdl
tom.baeyens Oct 5, 2009 9:00 AMhi, i wonder if we can make the usage of expressions in jpdl more consistent. currently we have following usages attributes expr and class to refer to user code
<custom class="..." <custom class="..." method="..." <custom expr="..." <custom expr="..." method="..." <event-listener class="..." <decision expr="..." <decision handler-ref="..." <decision ...><handler class="..." <decision ...><handler class="..." method="..." <decision ...><handler expr="..." <decision ...><handler expr="..." method="..." <task ...><assignment-handler class="..." <task ...><assignment-handler class="..." method="..." <task ...><assignment-handler expr="..." <task ...><assignment-handler expr="..." method="..." <java class="..." method="..." <java expr="..." <script expr="..." <object class="..." <object class="..." method="..." <object expr="..." <object expr="..." method="..." <condition expr="..." <condition ref="..." <condition class="..." <condition class="..." method="..."
The general usage of attributes expr, class and method is like this:
* attributes class and expr are mutually exclusive
* class specifies an object that is obtained by instantiating the class name
* expr specifies an object that is obtained as the result of evaluating the expression
* if together with class or expr a method attribute is specified, then the method will be invoked on the object (or on the class if it is a static method) and the return value of the method will be used instead of the original object
Here are the combinations that don't fall into the description given above. After each set of exceptions, I describe a proposal of how I think it should be done.
<decision expr="..." <decision handler-ref="..."
The result of evaluating expr on a decision is assumed to be a String and indicate a outgoing transition name. So <decision expr="..." is a special interpretation of the expression in the context of a decision.
The handler-ref is a name of an object that is searched for in the environment and that will act as the DecisionHandler. The exact same semantics could be expressed with an expression on the handler element: <decision handler-ref="xxx" is exactly the same as <decision ...><handler expr="#{xxx}"
<java expr="..."
The expression will just be executed. Optionally the result will be captured and stored in a variable.
This is the same as <script expr="..." so I think it should be removed.
<script expr="..."
Evaluates the expression. Script is mostly used for multi-line scripting languages like bsh or groovy.
I think that this usage of <script expr="..." is in fact an assignment. And hence I think we should consider to add an assign activity. Where var represents the left hand side and expr represents the right hand side of an assignment statement.
<condition expr="..." <condition ref="..." <condition class="..." <condition class="..." method="..."
This is the most tricky one. The syntax <condition expr="..." is expected to resolve to a Boolean. Where as <condition ref="..." and <condition class="..." are expected to result in an object that implements Condition.
In order to get this consistent I think we should look at decision and sync the condition syntax and classname accordingly:
<condition expr="..." would stay as is. This is similar to <decision expr="...". In both cases the result of evaluating expr is used in the specific context. In case of a decision a String is expected indicating the outgoing transition. In case of a condition a boolean is expected.
I think the interface class Condition should be refactored to ConditionHandler. In that case we can make it consistent with decision. And we can do that as Condition is still in the internal classes.
Then we can rename ref to handler-ref and introduce a sub-element handler, similar to decision:
<condition handler-ref <condition ...><handler class="..." <condition ...><handler class="..." method="..." <condition ...><handler expr="..." <condition ...><handler expr="..." method="..."