Creating and Deleting Components and Views

The most important way to save memory is to only call on those resources currently needed. For Web Dynpro, this means only keep those components and views in the memory that are currently being displayed.

The prerequisite for this is that an application has a modular structure, which means it does not have to keep hold of all components at the same time.

If this prerequisite is fulfilled, another important issue is raised concerning dynamic creation and deletion of components and views.

Components

Component COMP_A has component usage USAGE_A_B in component COMP_B. Web Dynpro instantiates component COMP_B for component usage in the following cases:

An interface view from COMP_B is made visible in a currently visible window of COMP_A (see views)
A context mapping exists from COMP_A to the context of COMP_B

Otherwise component COMP_B is not automatically instantiated. If a component is no longer needed, it should be deleted using DELETE_COMPONENT. However, no component views must still be visible, and there must be no context mapping.

Views

The lifespan of a view is defined by its visibility: A view is automatically instantiated as soon as it is made visible. If the view has setting Lifespan: when visible, the view is deleted as soon as it is no longer visible. Otherwise the view can only be deleted by removing the entire component.

The concept, sichtbar, is used in different ways in Web Dynpro and can therefore be easily misunderstood. What is actually visible on the screen ultimately depends on the views visible in the view assembly and on the visibility of the individual UI elements (property visibility).

When we refer to the visibility of views, as above, we are referring to the view assembly. The view assembly is the tree of visible views of a window. One view is always visible for each window and view container. Whether a view is instantiated or not depends only on the view assembly and not on the visibility of UI elements.

A view is made visible and therefore also instantiated when it is embedded in a visible window and marked as a default view, or is navigated to when one of its inbound plugs is activated. It becomes invisible when the user navigates to another view in the same window or view container.

Note Note

To alter a view assembly, a navigation request (outbound plug) must always be triggered.

End of the note.

Memory Saving Scenarios

Use of Lifespan: when visible

If you use this setting, the view is deleted when it becomes invisible as a result of user navigation (as described above). You should choose this setting if the view is not repeatedly used in the application.

If the view becomes invisible, the following happens: Method WDDOEXIT is called. The view controller and its attributes, the local view context, and the UI element tree are deleted. Note that the memory can only be released when these things are not being referenced by other objects. Therefore, do not keep any references from the view, context, UI elements, or context nodes, elements, node infos, and so on, outside of the view. Otherwise, application developers will be responsible for removing these references.

If you think you may want to return later to the UI status (for example, the first visible table row), you have to keep it outside of the view: For example, as an attribute of the assistance class or context node of the component controller that is mapped to the view.

Making Views Visible Dynamically

In the view container for VIEW_A, embed VIEW_B and EMPTY_VIEW in the window. Set EMPTY_VIEW as the default. For VIEW_A create an outbound plug TO_VIEW_B and for VIEW_B create an inbound plug IN. Connect both plugs in the window.

VIEW_B is now not automatically instantiated with VIEW_A. Instead, EMPTY_VIEW is used as the placeholder. By triggering the TO_VIEW_B plug, VIEW_B then becomes visible. You can then also use the plug to notify VIEW_B which object it is to display.

TabStrip: Make visible for active tab only

Each Tab of TabStrips is to make another view visible. For each Tab, a ViewContainerUIElement must be created, which in turn, must have a view container in the window. The view to be displayed is embedded in the view containers. Since there must always be a default view for each view container, they are therefore all default views. This means that all views are immediately instantiated. For this reason, proceed as described in the example below.

Example Example

Example application DEMO_TABSTRIP_VIEWS

In TABSTRIP_VIEW, an outbound plug TO_TAB is defined with parameter TAB type STRING and OLD_TAB type STRING. The onSelect event calls an action that triggers the outbound plug. The parameters TAB and OLD_TAB are filled with the event parameters of the same name.

In the window, an inbound plug SHOW_TAB is defined with the same parameter. The plugs are connected together. For each view container of a tab, the view to be displayed and EMPTY_VIEW are embedded. EMPTY_VIEW becomes the default for all views except the view initially visible. For each tab, one outbound plug to make the view visible and another outbound plug to make the view invisible are created in the window. The plug to make the view visible is connected with the inbound plug of the relevant view, and the plug to make the view invisible is connected to the inbound plug of the empty view.

In the program code for inbound plug SHOW_TAB, both case statements are implemented, as described below.

End of the example.

Syntax Syntax

method handleshow_tab .
  case old_tab.
    when 'TAB_1'.
      wd_this->fire_hide_tab_1_plg( ).
    when 'TAB_2'.
      wd_this->fire_hide_tab_2_plg( ).
    when 'TAB_3'.
      wd_this->fire_hide_tab_3_plg( ).
    when others.
      " Unknown tab
      assert 1 = 2.
  endcase.

  case tab.
    when 'TAB_1'.
      wd_this->fire_show_tab_1_plg( ).
    when 'TAB_2'.
      wd_this->fire_show_tab_2_plg( ).
    when 'TAB_3'.
      wd_this->fire_show_tab_3_plg( ).
    when others.
      " Unknown tab
      assert 1 = 2.
  endcase.
endmethod.

End of the code.

Note Note

Note that SAP_BASIS 700 SP15 or SAP_BASIS 700 EhP1 is required so that memory is fully released by Web Dynpro Framework when views and components are deleted.