Transitions

Transitions define how to route a user from one subdialog to another.

As subdialogs are represented by pages or portlets, they reference transition endpoints defined earlier. See Transition endpoints.

In detail, transitions consist of two main subsections, one subsection defines a source, the other a target.
Both, sources and targets reference transition endpoints associated with events. In other words, sources and targets consist of tuples of references to transition endpoints and events.
A source can reference only either one single transition endpoint that points to a portlet or a special reference that is denoted by an asterisk ( * ). The referenced endpoint can be associated only with one single event. A target can reference multiple transition endpoints that point to either a page or a portlet. The referenced endpoint can be associated with one or more events. The transition defines when a user is routed from one step to the next as follows:

• From the subdialog represented by the transition endpoint referenced by the source

• To any of the transition endpoints the target references

In fact, a user is routed from the transition endpoint of the source after this endpoint emits the associated event. The user is then routed to the subdialog that is holding one or more transition endpoints the target references. These endpoints are then fed with the associated events of these targets.

Code samples 5 - 9 show different examples.

Code sample 9 shows a simple transition. The source points to a single transition endpoint, which is a portlet. The target points to another single transition endpoint, which is also a portlet. After the source portlet, portlet1 emits the event e1, the user is routed to the target portlet2, which is fed with event e2.

Code sample 9:

01  <transition>
 02      <source>
 03          <transition-endpoint nameref="portlet1">
 04              <event qname="e1"/>
 05          </transition-endpoint>
 06      </source>
 07      <target>
 08          <transition-endpoint nameref="portlet2">
 09              <event qname="e2"/>
 10          </transition-endpoint>
 11      </target>
 12  </transition>

Code sample 10 shows a target that points to a page instead of a portlet. As a result, the event is propagated to all portlets on the page. This action is called broadcast. In this sample, all portlets on the page page1 the transition endpoint references receive the event e2.

Code sample 10:

01  <transition>
 02      <source>
 03          <transition-endpoint nameref="portlet1">
 04              <event qname="e1"/>
 05          </transition-endpoint>
 06      </source>
 07      <target>
 08          <transition-endpoint nameref="page2">
 09              <event qname="e2"/>
 10          </transition-endpoint>
 11      </target>
 12  </transition>

In code sample 11, the target points to multiple portlets instead of a single one. Each portlet is associated with a different event. As a result, each portlet receives a different event. In this sample, the portlets receive events as follows:

• The portlet referenced by transition endpoint portlet2a receives the event e2a.

• The portlet referenced by transition endpoint portlet2b receives the event e2b.

If more than one portlet is referenced, all referenced portlets must be on the same page.

Code sample 11:

01  <transition>
 02      <source>
 03          <transition-endpoint nameref="portlet1">
 04              <event qname="e1"/>
 05          </transition-endpoint>
 06     </source>
 07      <target>
 08          <transition-endpoint nameref="portlet2a">
 09              <event qname="e2a"/>
 10          </transition-endpoint>
 11         <transition-endpoint nameref="portlet2b">
 12              <event qname="e2b"/>
 13          </transition-endpoint>
 14     </target>
 15  </transition>

In code sample 12 the target points to a page and multiple portlets. The page and each portlet are associated with a different event. As a result, each portlet receives the event associated with the page and the event associated with the specific portlet. In this sample, the portlets receive events as follows:

• The portlet referenced by the transition endpoint portlet2a receives the events e2 and e2a.

• The portlet referenced by the transition endpoint portlet2b receives the events e2 and e2b.

If pages and portlets are referenced as targets, all portlets must be on the referenced page.

Code sample 12:

01  <transition>
 02      <source>
 03          <transition-endpoint nameref="portlet1">
 04              <event qname="e1"/>
 05          </transition-endpoint>
 06      </source>
 07      <target>
 08          <transition-endpoint nameref="page2">
 09              <event qname="e2"/>
 10          </transition-endpoint>
 11          <transition-endpoint nameref="portlet2a">
 12              <event qname="e2a"/>
 13          </transition-endpoint>
 14          <transition-endpoint nameref="portlet2b">
 15              <event qname="e2b"/>
 16          </transition-endpoint>
 17      </target>
 18  </transition>

We can also transmit multiple events to one single transition endpoint. Code sample 13 is similar to code sample 12. The page and the portlets are referenced as follows:

• The page referenced by the transition endpoint page2 is associated with the events e2-1 and e2-2.

• The portlet referenced by the transition endpoint portlet2a is associated with the events e2a-1 and e2a-2.

• The portlet referenced by the transition endpoint portlet2b is associated with the event e2b-1.

In this sample, portlet2a receives the events e2-1, e2-2, e2a-1, and e2a-2, and portlet2b receives the events e2-1, e2-2, and e2b-1.

Code sample 13:

01  <transition>
 02      <source>
 03          <transition-endpoint nameref="portlet1">
 04              <event qname="e1"/>
 05          </transition-endpoint>
 06      </source>
 07      <target>
 08          <transition-endpoint nameref="page2">
 09              <event qname="e2-1"/>
 10              <event qname="e2-2"/>
 11          </transition-endpoint>
 12          <transition-endpoint nameref="portlet2a">
 13              <event qname="e2a-1"/>
 14              <event qname="e2a-2"/>
 15          </transition-endpoint>
 16          <transition-endpoint nameref="portlet2b">
 17              <event qname="e2b-1"/>
 18          </transition-endpoint>
 19      </target>
 20  </transition>

• Start and End Transitions
  When the tuple that consists of the referenced transition endpoint and event matches the source of a start transition, dialogs are started. Start transitions differ from other transitions only in they carry the attribute type, with the value start. Similarly, end transitions carry the attribute type, with the value end. See code sample 14.

• Start transitions and wildcards
  In some scenarios, we might want to define that a dialog is started if one of several source transition endpoints emits a specific event. In this case, the start of the dialog depends only on the event and not on the tuple of the referenced transition endpoint and event.

• Start transitions and special events
  In other scenarios, we might define a dialog that starts if a special start event is being emitted from a specific source or from an arbitrary source.

• End transitions and special events
  Similar to the special start event, end transitions can emit a special end event.

• Other special transitions
  UX Screen Flow Manager supports several more special transitions, or more precisely, transition endpoints.

• Exclusive transitions or dialogs
  Special forms of dialogs are the so called exclusive dialogs. They are also referred to as null or one-step dialogs. They consist of a single transition only. Use them to go into a dialog, run only one transition, and use it to end the dialog immediately afterward.

• Dialog chaining
  Dialogs can also start other dialogs. This mechanism is called dialog chaining. From a modeling perspective, the starting dialog references the dialog that is started as the target part of one or more of its end transitions. The dialog that is started is called with the event the calling dialog emitted.

• Rules and restrictions
  When we model a transition certain rules and restrictions apply.

• Undetermined events
  It might happen that a JSR-286 event is emitted by a portlet that participates in a dialog, but is not defined as part of a transition. Events that occur outside of a screen flow transition are not affected by the UX Screen Flow Manager. They are delivered as if UX Screen Flow Manager was not present.

• Conditional routing
  The UX Screen Flow Manager does not support conditional routing. When conditional routing is not supported it means that currently, it does not support triggering different transitions based on data stored in the dialog context (DCX).

• Deploy dialog sets using xmlaccess.sh
  Use the portal XML configuration interface (xmlaccess) to work with dialog sets.

Parent Screen Flow Definitions

Related concepts:

Transition endpoints