Layout - SAP ABAP Web Dynpro

This category has UI elements we use to form the layout. Hereunder,we present some of the UI Elements included in this category.

ViewContainerUIElement

This UI element is an area within a view that contains another view. It doesn’t have its own properties,but inherits properties from the abstract base class UIElement. We create a WD Component,a registration form with three views.In the view V_VIEW,we insert two ViewContainerUIElement’s (VCU_1 and VCU_2) required to embed the V_STEP1 and V_STEP2 views. The context node is created in COMPONENTCONTROLLER because we have to share data among different view controllers: V_STEP1, V_STEP2, V_VIEW.

WD component structure

Context structure

The node INFO has the cardinality 0...1, Singleton. The attributes NAME, EMAIL, CITY are of STRING type, and the attribute COUNTRY is of Y_DEFORDOMAIN type defined in the ABAP Dictionary, domain that holds all the EU member states.

At runtime, the view V_VIEW is the default view (e.g. the view that is first displayed when the window is called).

View V_VIEW layout

Because we want to display more views in the same time and in the same window,we are going to use ViewContainerUIElement. At runtime,when the screen is displayed for the first time, we want only the fields from V_VIEW view to be visible until the user presses the LinkToAction UI Element. This is the reason why we embed as default in VCU_1 and VCU_2 EMPTYVIEWs.An EMPTYVIEW is a special type of view, automatically generated, that can be used to hide another view.

Window structure

Runtime

As we can see, only the UI Elements from the default view V_VIEW are displayed, because the VCU_1 and VCU_2 have EMPTYVIEWs as default.

Embedding Views in Window

After the user presses the LinkToAction UI element, we want to show in the VCU_1 the view V_STEP1. To be able to do this, we define an outbound plug in the V_VIEW view.

Definition of an outbound plug in the view V_VIEW

V_STEP1 view layout

To be able to show the view V_STEP1 content when the user presses the LinkToAction UI Element, we have to define an inbound plug in the view V_STEP1.

Definition of an Inbound Plug in the view V_STEP1

Now,we embed the view V_STEP1 in the ViewContainerUIElement VCU_1 and we create the navigation link.

Window structure

When the user presses the LinkToAction UI element, the Framework triggers the event handler method onactionlta1. When we create an outbound plug for a view,a fire method is added to its interface. A fire method of our outbound plug op_to_v_ step1 is called with the statement:

wd_this!fire_op_to_v_step1_plg( ).

We have created a navigation link from OP_TO_V_STEP1 to IP_V_STEP1. When this method is fired, the view V_STEP1 is displayed. To integrate the fire method, we can use the Web Dynpro Code Wizard.

Calling the web Dynpro code wizard

Runtime

Hereunder,we have to display the view V_STEP2 when the user presses the LinkToAction UI element (ID = LTA_NEXT2). To do this, we define an outbound plug named OP_TO_V_STEP2 in the view V_STEP1,and we fire the generated method.

Outbound plug, event handler method

V_STEP2 view layout

After this, we have to define an inbound plug named IP_V_STEP2, we embed the view V_STEP2 into the ViewContainerUIElement VCU_2 and we create the corresponding navigation link.

Window structure

Window structure

Dynamic Programming

RUNTIME CLASS: CL_WD_VIEW_CONTAINER_UIELEMENT

The implementation of a dynamic ViewContainerUIElement contains the following statements (Listing):

data lr_vcu type ref to cl_wd_view_container_uielement. lr_vcu = cl_wd_view_container_uielement=>new_view_container_uielement (id = 'VCU').

In this case, after dynamically creating the View ContainerUI Element,we have to dynamically create the view embedding and the navigation links.

tabStrip

This UI element allows us to display some tabs, and the user can toggle from a tab page to another. We create a WD Component.

WD component structure

We create a TabStrip UI element and add two Tabs. To add tabs, we right-click on the tabStrip name and, from the contextual menu, we choose Insert Tab.When the user presses the Next button, we navigate to the next tab and we show the data entered by the user in the registration form of the first tab.

View layout

Hereunder, we present a table with some of the tabStrip UI element properties that can be bound,and the attribute type in case the property is bindable.

Some of TabStrip UI element properties

The property selectedTab of string type can be used to navigate from a tab to other one. This property set the name of the selected tab. We define a data binding between the selectedTab property and the attribute with the same name (string) defined in the node DYNAMIC in the view context.The node STUDENT has the dictionary structure YSTR_PERSON,cardinality 0...1,Singleton.

Context structure

By using the wdDoInit Hook method, we populate the attribute SELECTEDTAB of the node DYNAMIC with the ID of the tab we want to be active at runtime–TAB_1 (Listing ).

Listing The wddoinit Hook method

When the user presses the Next Button,the Framework triggers the event handler method onactionnext (Listing).We set the selectedtab property with the value TAB_2,by selecting in this mode the TAB_2.

Listing Event handler methodMETHOD onactionnext.

Runtime

Dynamic Programming

RUNTIME CLASS: CL_WD_TABSTRIP

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name,with the proper types,in case of dynamic programming of a TabStrip UI element.For the tabStrip UI element we have, as aggregation, the Tab element.Its runtime class is CL_WD_TAB.

Dynamic programming

The implementation of a dynamic TabStrip UI element, with two Tabs,contains the following statements (Listing):

Dynamic programming of a TabStrip UI element

PageHeader

This UI element offers the possibility to create a header for a page.In the title content and the PageHeader Area, we can insert other UI elements. We create a WD component with the structure presented in Fig.

WD component structure

We use the view V_VIEW as Master View. Here, we insert a PageHeader UI element that contains two LinkToAction UI elements, and in the PageHeader Area we insert a ViewContainerUIElement. When the user interacts with the LinkToAction UI elements,we show in the ViewContainerUIElement one of the two slave views V_COUNTRYor V_CANDIDATE.

Application structure

After the PageHeader UI element is inserted into the V_VIEW view,we can insert a PageHeader Title Content and one or more PageHeader Area(s).

Inserting the title content and PageHeader area

In a PageHeaderArea, we can insert how many other UI elements we want.Here, we have chosen to insert only one UI element (ViewContainerUIELement).As design options,it has: Standard, Emphasized and transparent.For our example,we have the default design: Standard. To see on screen the other Page Header Area designs,we can choose values from the list, one by one, and see the result in the view designer, or we can run again the application and see the different changes.In the system,we can find two WD components where we can see the UI elements and the effect of changing certain properties on these UI elements. These components are WDR_TEST_EVENTS and WDR_TEST_UI_ELEMENTS.

V_VIEW view layout

Each view (V_CANDIDATE and V_COUNTRY) has a Table UI element where we show the data stored in our database table YPERSON and YEU_COUNTRIES.

Runtime

Dynamic Programming

RUNTIME CLASS: CL_WD_PAGE_HEADER

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name, with the proper types,in case of dynamic programming of a PageHeader UI element.

Dynamic programming

For the PageHeader UI element we have, as aggregation, the Area and the TitleContent elements. The Area runtime class is CL_WD_PAGE_HEADER_ AREA.

The implementation of a dynamic PageHeader UI element (with pageHeader title) and a PageHeaderArea (with a textView UI element) contains the following statements (Listing):

Dynamic programming of a PageHeader UI element

ContextualPanel

This UI element offers navigation functions. Its navigation list can have many levels.We create the same example as for the PageHeader,but, in this case,we use the two LinkTo Action UIElements to create the content for a ContextualPanel UI element.

In a contextualPanel UI element, we can insert three types of elements: Free- ContextualArea,NavigationList and ViewSwitch. In our example,we have used two FreeContextualArea elements.

In a FreeContextualArea, we can insert a Content and a Header. We can set the header to be expandable or no. The Content is a zone where we can insert other UI elements we want to be displayed within the FreeContextualArea.

FreeContexualArea

V_VIEW view Layout

V_VIEW view Layout

Dynamic Programming

RUNTIME CLASS: CL_WD_CONTEXTUAL_PANEL

For the ContextualPanel UI element, we have, as aggregation, the items: Free- ContextualArea,
ViewSwitch and NavigationList elements.
The FreeContextual- Area runtime class is
CL_WD_FREE_CONTEXTUAL_AREA.

The implementation of a dynamic contextualPanel UI element,with a Free- ContextualArea element that has a Content(linkToAction UI element)and a Header(expandableTitle element),contains the following statements (Listing ):

Dynamic programming of a contextualPanel UI element

Tray UI Element

As all the containers, this UI element includes a set of other UI Elements,but also provides additional functions. We create a WD Component with the structure presented.

WD component structure

In the View Layout,we insert two Tray UI elements. The first element is used to show the candidate information, and the second Tray is used to show some details about the selected candidate. These details are: the country flag and the capital.In the MIMEs folder we import three pictures with the flags we have to display when the user chooses a competitor from that country.

After the Tray UI element is inserted in the View Layout, we can insert a Menuand, in each menu, we can insert a menu option.

Tray menu

The menu options are: Menu, MenuActionItem,MenuCheckBox, MenuRadio- Button and MenuSeparator. In our case,we have chosen the option MenuAction- Item.

Creating a menu element

View layout structure

The first Tray has two menu options, used to show the second Tray UI element or to hide it. As we have mentioned above, most of the UI element properties can be bound. Hereunder, we show a list with some of the Tray UI elements properties that can be bound, and the attribute type in case the property is bindable.

Some of the tray UI element properties

We want to manipulate the UI element via the data held in the context. Therefore, we create a context node named DYNAMIC, with three attributes: two attributes of WDY_BOOLEAN type (ENABLED_OPTION1,ENABLED_OPTION2) and one attribute named VISIBLE, of WDUI_VISIBILITY type.To show the concurrent information and the corresponding details, we have created a context node with the dictionary structure YVIEW_CMPETITION, a database view defined in the ABAP Dictionary.

Context structure.

The context node DETAIL is populated via the supply function method SUPPLY_COMPETITION (Listing).

Supply function method

To be able to manipulate the enabled properties of the menu options created in the first Tray UI elements, we define the following data binding:

Data binding

To be able to manipulate the visible property of the second Tray with the ID “TRAY_DETAIL”,we define a data binding between these properties and the context attribute VISIBLE:

At initialisation, we want the second Tray to be hidden, the MENU_OPTION1 to be enabled and the MENU_OPTION2 to be not enabled. To realise this,we encode the wdDoInit Hook method (Listing).

The wddoinit Hook method

When the user selects the first menu option “MENU_OPTION1”,the Framework triggers the event handler method onactionshow (Listing ).

The onactionshow event handler method

When the user selects the second menu option MENListingU_OPTION2,the Framework triggers the event handler method onactionhide (Listing).

The onactionhide event handler method

At runtime,we can choose to show or to hide the details about the competitor

Runtime.

Message Area

This UI element represents the placeholder of the messages; it helps us to specify where they appear in the view. As we have seen, the messages are displayed by default in the upper part of the screen. The message location can be moved by adding a MessageArea UI element. We need only a MessageArea UI element per View layout.

We create an example to filter an input from the end user. In case the user enters a combination of small and capital letters from A to Z or spaces,we show a message with the text “Your input is string” If not, we show a message “Your input is not string”. To show these messages,we use a MessageArea UI element.

There are small programs used to test the regexes, which offer the possibility to test the regexes created before using them. Such a program is demo_ regex_toy. By using the transaction SA38 or SE38, we can run this program (Fig.) By using regexes,we can filter the values that the user enters in a Web Dynpro screen.

Regex toy screen

View Layout

As we can see, in this case we have entered a MessageArea UI element in the Group container.This is the place where all the messages will be displayed. When the user presses the button with the id “BTN”,the Framework triggers the event handler method onactioncheck (Listing ).

Checking the data entered by the user methode

As we can see, in this case we have entered a MessageArea UI element in the Group container.This is the place where all the messages will be displayed. When the user presses the button with the id “BTN”,the Framework triggers the event handler method onactioncheck (Listing ).

Checking the data entered by the user methode

By using the static method MATCHES of the CL_ABAP_MATCHER class,we check the value that the user enters in the inputField UI element.In case this value matches our condition specified in the local variable lv_pattern,we use the methode REPORT_MESSAGE to display a message of information type. Otherwise,we use the same method to display an error message. Because we want to show to the user whether the value he entered in the input field is a string or not,we use a parameter required to integrate,in the string that he sees on the screen,the value he has just entered.For this purpose, we have used for the method report_message a parameter named “params”.By double-clicking on name of the method report_message,we navigate forward and we can see all the parameters that this method has and the typethat the parameters should be. For the “parms” parameter, we need a variable owdr_name_value_list type that is actually a table type with a structure of line type.From this structure, we have used the name(the parameter name,in our case “first_name”)and the value (the value with what we want to replace,at runtime,the parameter name “lv_firstname”).In Chap. 10, we will see more abou the message manager and parameters, along with the modality we can display a message into a window, or the modality we can use the ABAP classesto create messages and exceptions. In Fig.the messages are displayed by using the MesageArea UI element.

Runtime with MessageArea UI element

Dynamic Programming

RUNTIME CLASS: CL_WD_MESSAGE_AREA

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name,with the proper types,in case of dynamic programming of a MessageArea UI element (Table).

The implementation of a dynamic MessageArea UI element contains the following statements (Listing ):

Dynamic programming

The dynamic programming of a MessageArea UI element