Hi John, hi All
apart other things in the last weeks i tried to make some considerations
about creating a method to have more comfortably designs like the trouble
ticket process, were the basic idea is that given a workitem positioned into
a particular place in a directed graph when "step" replies, engine would
dispatch to one following "step" (or to a set of them), depending on a
generic choice method.
Starting form this situation i tried to generalize ( in a naive manner ).
Create a new expression, let me call it state-transition.
<state-transition>
...
</state-transition>
this expression should have only two children:
- states
- transitions
States:
--------
<states>
...
</states>
elements in states are a list on "state" expressions
<state name="state_name">
[content_still_unspecified_expression]
</state>
this is to enclose in the state object the full identification label needed
to state-transition to work:
<state name="xyz">
[content_still_unspecified_expression]
</state>
can be expressed as
<state_unspecified_content_expression name="xyz">
but the latter denies state_unspecified_content to have an attribute named
"name" because this one is needed to state-transition to work, the previous
hasn't this constraint .
Now my idea about the content of the state tag is quite simple: it should be
an expression.
example
<state name="">
<participant ref=xyz>
</state>
or
<state name="">
<if test="${f:x} > 3">
<participant ref=x3>
<participant ref=x4>
</if>
</state>
or perhaps
<state name="">
<subprocess ref="yzt">
</state>
or even
<state name="">
<if test="${f:x} > 3">
<set field="x" value="3*${f:x}" >
</if>
</state>
and so on...
Transitions:
--------------
<transitions>
...
</transitions>
elements here should be "selectors of state":
<on state="current_state_name" >
[content_still_undefined]
</on>
this is like a simple switch
the content, in my opinion, should be a ruote "tree formed" expression with
all the "activity" in this form:
<goto state="...">[ or <return/ > see below ]
example
<on state="current_state_name" >
<if test="${f:new_ruote_released?}">
<goto state="go and see what's changed">
<goto state="continue enjoy current release">
</if>
</on>
or with a concurrence
<on state="warm up water" >
<when test="${f:water_boils}">
<concurrence>
<goto state="butta la pasta!">
<sequence>
<sleep for="2min" / >
<goto state="warm up a little the sauce">
</sequence>
</concurrence>
</when>
</on>
Here what is important is that one can also write a expression that doesn't
"deliver" to a next state, but it becomes a wrong process definition and the
error has to be corrected by the user(if needed expression can put the
process-workitem in an error state, though): the engine should not be
responsible to check that the transtition expression is functionally
correct, but has only to be concerned in the formal correctedness.
Notes on transitions
there should be some special transitions:
the boot transition:
----------------------
<on boot >
this is the enter point of the directed graph
note: please correct me if i'm wrong: is not restrictive that only a single
boot transition is defined. if more are needed it should be equivalent to
create one such boot transition and add a "boot" state, pointed by the boot
transition, which makes a dummy action <noaction /> then create as many
transitions as needed as follows:
<on state="boot" goto="state1" />
<on state="boot" goto="state2" />
...
<on state="boot" goto="stateN" />
[ in this situation workitem get duplicated N times, but this is not unusual
in ruote, right? ]
the return transition:
----------------------
<on state="...." >
.... <return /> instead of <goto state="..." />
</on>
i suppose that there is nothing special about having multiple return points,
perhaps in this case, state-transition expression caller should decide how
to deal with multiple sequential returns( this seems similar to concurrences
where one has several exit workitems that are merged, if requested)
wdYt?
Thanks
Tomaso
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"OpenWFEru dev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/openwferu-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
