Announcement Announcement Module
Collapse
No announcement yet.
rfe: non-blocking (asynchronous) view Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • rfe: non-blocking (asynchronous) view

    I am writing a subflow which can end on four different views. The end states currently look like this:

    <end-state id="submitForApproval.confirm" view="submitforapprovalconfirm"/>
    <end-state id="saveAsDraft.confirm" view="saveasdraftconfirm"/>
    <end-state id="publish.confirm" view="publishconfirm"/>
    <end-state id="cancel" view="main"/>
    Each of these states really represents a "success" state (a successful termination of this subflow), they are just arrived at through different paths.

    Subflows are meant to function as black boxes; they shouldn't expose their inner workings. However if I want to invoke this particular flow from a parent flow (which I do), then I have to make the parent flow aware of these four end states (since it must provide a transition for each of these states), which violates encapsulation and exposes implementation details.

    It would be great if I could configure these views as view-states, but immediately (without waiting for the client) trigger a subsequent state transition to an end-state. For example:

    <view-state id="submitForApproval.confirm" view="submitforapprovalconfirm" event="finish">
    <transition on="finish" to="finish"/>
    </view-state>
    <view-state id="saveAsDraft.confirm" view="saveasdraftconfirm" event="finish">
    <transition on="finish" to="finish"/>
    </view-state>
    <view-state id="publish.confirm" view="publishconfirm" event="finish">
    <transition on="finish" to="finish"/>
    </view-state>
    <view-state id="cancel" view="main" event="finish">
    <transition on="finish" to="finish"/>
    </view-state>

    <end-state id="finish"/>
    Now I document my subflow as only having a "finish" end state, keeping the internal details hidden. This also relieves the end state from having to render a view (separation of concerns).

    Jim

  • #2
    [Regarding the above, I know there has to be a little more to it -- there needs to be a point further in the flow which causes the flow to block again, and it can't be a view because a view has already been rendered.]

    I'd like to mention that one of the key benefits of SWF that I see (at least for our purposes) is the promise of reusability -- the ability to write component flows which are modular and self-contained, and can be used in varying contexts, including being nested within each other. I hope SWF continues to improve in this area.

    In the meantime, I need to get the above scenario working. So I bit the bullet and wrote four transitions in the subflow-state which invokes the above flow from the parent, as follows:

    Code:
    <subflow-state id="parent" flow="child">
     <attribute-mapper>
      ...
     </attribute-mapper>
     <transition on="saveAsDraft.confirm" to="finish"/>
     <transition on="publish.confirm" to="finish"/>
     <transition on="submitForApproval.confirm" to="finish"/>
     <transition on="cancel" to="finish"/>
    </subflow-state>
    
    <end-state id="finish"/>
    But when I test the flow, I get a NullPointerException when any of those transitions in the child are triggered. It seems the ViewDescriptor is null. I surmise that even though the child flow exposed a view, it's lost when the child returns to the parent, and since the parent exposes no view, we get nothing. To confirm, I changed the above to:

    Code:
    <subflow-state id="parent" flow="child">
     <attribute-mapper>
      ...
     </attribute-mapper>
     <transition on="saveAsDraft.confirm" to="saveAsDraft.confirm"/>
     <transition on="publish.confirm" to="publish.confirm"/>
     <transition on="submitForApproval.confirm" to="submitForApproval.confirm">
     <transition on="cancel" to="cancel"/>
    </subflow-state>
    
    <end-state id="saveAsDraft.confirm" view="buyer/saveasdraftconfirm"/>
    <end-state id="publish.confirm" view="buyer/publishconfirm"/>
    <end-state id="submitForApproval.confirm" view="buyer/submitforapprovalconfirm"/>
    <end-state id="cancel" view="main"/>
    As I expected, this works. However, this is even more offensive than before, since more details of the subflow have been moved to the parent flow (and even some of the responsibility; the parent is now responsible for knowing and displaying the child's views). This is another obstacle to reusability. It would be ideal if the view could be rendered either within the child flow, or within the parent flow.

    Also notice that the details of the subflow must be propagated not just to its parent flow, but transitively to any ancestor. This is a particular problem for me because I had intended this parent flow to be called by yet another parent flow.

    Comment

    Working...
    X