Navigation Between Two Views 

All views within a window can be connected to each other using navigation links. When the user calls a Web Dynpro application, the start view is displayed first on the screen. You can trigger a specific action – for example, by clicking a button – which triggers navigation. As a consequence, the previously displayed view disappears from the screen and a second view is displayed.

To set up navigation between two views, you must create an inbound plug for one view and an outbound plug for the other view. A plug is always a junction used for accessing or exiting a view.

For more information on Plugs and Navigation Links, refer to the architecture manual for Web Dynpro. 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 plugs and inbound plugs have different properties:

Outbound Plugs

Outbound plugs are always starting points for navigation. They are called in any method of the view controller using the following call:

 

WD_THIS->FIRE_MY_OUTBOUND_PLG(  ).

 

The attribute WD_THIS is always a self-reference to the interface IF_<MY_VIEW> of the view controller. Each time you create an outbound plug for this view, a method FIRE_<MY_OUTBOUND_PLUG>_PLG is added to this interface.

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

 

 The outbound plug itself, which is the controller of the view, does not contain information on 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

You use the method call FIRE_<MY_OUTBOUND>_PLG to pass a parameter. This parameter is entered in the parameter table on the Outbound Plugs tab.

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). Therefore, the method call is either

 

WD_THIS->FIRE_MY_OUTBOUND_PLG( EDITABLE = ‘X’ ).

or

WD_THIS->FIRE_MY_OUTBOUND_PLG( EDITABLE = ‘’ ).

 

Inbound Plugs

Inbound plugs within a Web Dynpro window are always called directly using a previously created navigation link which originates from an outbound plug (see chapter Window: Layout in the tools manual). When an inbound plug is called, an event handler method is called which is uniquely assigned to this inbound plug. 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 generically named HANDLEMY_INBOUND_PLUG:

 In case of an inbound plug IN1, the event handler method HANDLEIN1 is created.

The event handler method is empty and can be filled by the source code of the application developer. From a technical point of view, this method does not differ from other event handler methods of the controller.

Evaluating Parameters

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

 If the parameter EDITABLE is passed by an outbound plug, the parameter EDITABLE must be added to the signature of the event handler method assigned to the inbound plug to read this parameter.

The parameter value is then known by the event handler method and can be used.

 The event handler of an inbound plug is used, for example, to process additional information for the new view. It is not to be used to pass application data or to call application logic.

 

 Example for Navigation with Parameter Transfer

In the first view, an outbound plug has been called in the event handler of an action and the parameter EDITABLE = ’X’ has been passed. The subsequent view connected by a navigation link contains an element that can be edited by the user due to the transferred value of the parameter EDITABLE.

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

The parameter EDITABLE of the Dictionary type WDY_BOOLEAN has been created during the creation of the outbound plug OUT of the view. The value of this parameter is passed at runtime using the following 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 contains the enabled property, which can be used to switch the functions of the element on or off. If this property of an element is not selected in its properties table of the View Designer, the element is still displayed on the screen, but entries, selections, or other interactions of the user are not possible. The UI element is disabled. (The default setting for this property of a UI element newly added to the layout is always enabled.) The application developer has two options to specify the behavior of the UI element at runtime:

·        The enabled property can be statically specified at design time using the checkbox of the properties table in the View Designer. When the corresponding view is called, the behavior of the UI element always remains the same.

·        The enabled property can be bound to a context node which contains an attribute of the type WDY_BOOLEAN. The value of this attribute is passed at runtime. Therefore, the UI element is available with all functions or is only displayed, depending on the specification in the program.

In the following example, the latter case is described:

The context of the second view contains context nodes with application data and a node for specifying the value of the enabled property for one or more UI elements of the view. In this example, the node is called STATUS and contains exactly one attribute ENABLED of the type WDY_BOOLEAN. The value of this attribute is set by the 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 value of the attribute ENABLED is ’X’, UI elements that have their enabled property bound to the attribute ENABLED are available with all their functions. Once the method FIRE_OUT_PLG passes the value ’ ’, the attribute ENABLED is also set to the value ’ ’ by the event handler of the inbound plug of the subsequent view and the UI elements are displayed on the screen without their functions.