Thank you Koen.
A transition from the node to itself is ok if you want to keep executing the 
node until some condition changes, but not if you want to wait in the node 
until some condition changes. 
See, I want the node to get the signal and pass it through to the sub-process, 
but itself must wait until the sub-process is executed for each item in the 
list - and the sub-process must be allowed to have any kind of node. This way 
the program (?) exercising the main process does not have to be aware of the 
fact that a sub-process is being executed.

I eventually modeled it like this:
<?xml version="1.0" encoding="UTF-8"?>
  | 
  | <process-definition
  |   xmlns=""  name="auth.user.edit">
  |     <start-state name="start">
  |             <transition to="PageFlow: Selection screen">
  |          <action name="RetrieveUsers" 
class="com.izazi.service.converse.web.RetrieveUsersActionHandler"></action>
  |       </transition>
  |     </start-state>
  |     <state name="PageFlow: Selection screen">
  |       <event type="node-enter">
  |          <action name="PageFlow" 
class="com.izazi.service.converse.web.PageFlowActionHandler">
  |             <pageName>auth_user_select</pageName>
  |          </action>
  |       </event>
  |       <transition to="end1"></transition>
  |             <transition name="groups" to="Edit groups"></transition>
  |     </state>
  |     <end-state name="end1"></end-state>
  |             <node name="Edit groups">
  |             <action name="ForEach" 
class="com.izazi.service.converse.web.ForEachActionHandler">
  |          <itemExpression>items</itemExpression>
  |          <subProcess>auth.edit.group</subProcess>
  |       </action>
  |       <transition to="PageFlow: Selection screen"></transition>
  |       <transition name="loop" to="Loop Edit Groups"></transition>
  |    </node>
  |    <state name="Loop Edit Groups">
  |       <transition name="" to="Edit groups"></transition>
  |    </state>
  | </process-definition>

This is more messy than I would've like liked, because now the process diagram 
contains extra detail that really should be hidden away in actionhandlers. It 
is a principle put forward in your docs. To quote: anonymous wrote : It is not 
acceptable if the developer must change the graphical diagram to include a 
technical detail in which the business analyst is not interested.
At least now I know it is by design (*sigh*).
Thanks
Johan

View the original post : 
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3936492#3936492

Reply to the post : 
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3936492


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
JBoss-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jboss-user

Reply via email to