Navigating Between Two Views

All views within one window can be connected through navigation links. This means that when a user calls a Web Dynpro application the view defined as the start view is the first view displayed on the screen. When an action is triggered (for example, by clicking on a pushbutton), a navigation is triggered resulting in the currently displayed disappearing and a second view being displayed instead.

To set up navigation between two views, you must create an inbound or outbound plug for one view and an outbound plug for the other view. A plug is a connection point through which a view can be entered or left.

For more information about Plugs and Navigation Links, see the Web Dynpro Architecture Manual. For a description of the creation and maintenance of plugs as part of a view, refer to the chapter View: Inbound Plugs and Outbound Plugs in the tools manual. For information on the maintenance of navigation links, which is a part of the window structure, refer to the window layout.

Outbound and inbound plugs have different properties:

Outbound Plugs

Outbound plugs are always the starting point of a navigation. They can be called in any method of the view controller with the following call:

 
WD_THIS->FIRE_MY_OUTBOUND_PLG(  ).

Attribute WD_THIS is always a self-reference to interface IF_<MY_VIEW> of the view controller. For each outbound plug you create for this view, this interface is extended with a method FIRE_<MY_OUTBOUND_PLUG>_PLG.

Note If you create three outbound plugs OUT1, OUT2, and OUT3 for view View_1, methods FIRE_OUT1_PLG, FIRE_OUT2_PLG, and FIRE_OUT3_PLG are created in interface IF_VIEW_1.

Note The outbound plug itself, and the view controller too, do not contain any information about the target of the triggered navigation. The connection to the selected inbound plug of a subsequent view is set up when creating the navigation link in the window layout.

Passing Parameters

A parameter can be passed with method call FIRE_<MY_OUTBOUND>_PLG. This parameter is entered in the parameter table on tab Outbound Plugs.

For the following example, the parameter editable has been added to the method FIRE_<MY_OUTBOUND>_PLG. This parameter of the type WDY_BOOLEAN has either the value 'X' (true) or '' (false). The method call is therefore either

 
WD_THIS->FIRE_MY_OUTBOUND_PLG( EDITABLE = 'X' ).

 
WD_THIS->FIRE_MY_OUTBOUND_PLG( EDITABLE = '' ).

Inbound Plugs

Inbound plugs within a Web Dynpro window are either accessed directly through a navigation link, which has been set up from an outbound plug (see Tools Manual, section Window: Layout). When an inbound plug is called, the call is connected to a uniquely assigned event handler method. This method is automatically created in the view controller when the inbound plug is created. The method is listed in the Methods tab. It is assigned the generic name, HANDLEMY_INBOUND_PLUG:

Note Event handler method HANDLEIN1 is created for an inbound plug IN1.

This event handler method is empty and can be removed from the program code by application developers. Its technical details are not different to other event handler methods of the controller.

Evaluating Parameters

The event handler method of an inbound plug can transfer parameter values from method FIRE_<MY_OUTBOUND>_PLG. The parameter of the same name must be added to the signature of the event handler method.

Note If an outbound plug passes parameter EDITABLE, in order to read the parameter, parameter EDITABLE must be added to the signature of the event handler method of the inbound plug.

The value of the parameter is then known to the event handler method and can be evaluated.

Note One use of the event handler of an inbound plug is to prepare the status information for the new view. It should not be used to transfer application data or to call application logic.

Example of Navigating with Parameter Transfer

In the event handler of an action of a first view an outbound plug has been called and parameter EDITABLE = 'X' transferred. The subsequent view connected to from a navigation link will contain an element that, based on the passed value of parameter EDITABLE, is to be available to the user for changing:

Calling the Outbound Plug OUT in the Event Handler of the First View

Parameter EDITABLE of Dictionary type WDY_BOOLEAN has been created for the outbound plug OUT of the view, as mentioned above. The value of this parameter is passed at runtime with method:

 
WD_THIS->FIRE_OUT_PLG( EDITABLE = 'X' ).

Evaluating the Parameter in the Event Handler HANDLEIN of the Inbound Plug IN of the Second View

Each UI element has property enabled, which is used to enable or disable the entire functions of the element. An element for which the property in its property table is not selected in the View Designer, is displayed on the screen, but the user cannot interact with it (make entries or selections). This means the UI element is disabled. (The default setting of this property of a UI element newly added to the layout is always enabled). Application developers have two ways to control the behavior of the UI element at runtime:

Property enabled can be statically set at design time by selecting the checkbox in the property table in the View Designer. Whenever the associated view is called, the UI element behaves the same way.
Property enabled can be bound to a context node that contains an attribute of type WDY_BOOLEAN. The value of this attribute is not passed until runtime, which means that depending on what has been programmed, the UI element may be available with its full functions, or may only be able to be displayed.

In our example, the second case is illustrated:

The context of the second view contains a node to control the value of the enabled property of one or more UI elements of the view, as well as context nodes containing application data. This node should have the name STATUS, and contains precisely one attribute ENABLED of type WDY_BOOLEAN. The value of this attribute is now set by event handler method HANDLEIN of the second view.

method HANDLEIN .
 
  data:
L_CONTEXT_NODE type ref to IF_WD_CONTEXT_NODE.
 
  L_CONTEXT_NODE = WD_CONTEXT->GET_CHILD_NODE( 'STATUS' ).
  L_CONTEXT_NODE->SET_ATTRIBUTE( NAME = 'ENABLED' VALUE = EDITABLE ).
 
endmethod.

Since the transferred parameter is to be used to specify the property of a context node with varying values, methods of the interface IF_WD_CONTEX_NODE are used in the event handler method (see also chapter Action Event Handlers). In this case, the method SET_ATTRIBUTE is called and the attribute ENABLED is set to the value of parameter EDITABLE.

The attribute ENABLED of the context node STATUS now has the value 'X', which is the value passed by the method WD_THIS->FIRE_OUT_PLG( EDITABLE = 'X' ) of the previous view.

Result

If the ENABLED attribute has the value 'X' this means that this UI element or the UI elements that have bound their property enabled to the ENABLED attribute are now available with their full functions. At the time method FIRE_OUT_PLG transfers the value ' ', the ENABLED attribute is also set to ' ' by the event handler of the inbound plug of the subsequent view and the UI element(s) are displayed on the screen without their functions.