NET311
Advanced ABAP Web Dynpro
SAP NetWeaver Date Training Center Instructors Education WebsiteParticipant Handbook
Course Version: 2006 Q2Course Duration: 2 Day(s) Material Number: 50084905
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
Trademarks
• Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered trademarks of Microsoft Corporation.
• IBM®, DB2®, OS/2®, DB2/6000®, Parallel Sysplex®, MVS/ESA®, RS/6000®, AIX®, S/390®, AS/400®, OS/390®, and OS/400® are registered trademarks of IBM Corporation. • ORACLE® is a registered trademark of ORACLE Corporation.
• INFORMIX®-OnLine for SAP and INFORMIX® Dynamic ServerTM are registered trademarks of Informix Software Incorporated.
• UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group. • Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®,
VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc.
• HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.
• JAVA® is a registered trademark of Sun Microsystems, Inc.
• JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.
• SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.com are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other products mentioned are trademarks or registered trademarks of their respective companies.
Disclaimer
THESE MATERIALS ARE PROVIDED BY SAP ON AN "AS IS" BASIS, AND SAP EXPRESSLY DISCLAIMS ANY AND ALL WARRANTIES, EXPRESS OR APPLIED, INCLUDING
WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WITH RESPECT TO THESE MATERIALS AND THE SERVICE, INFORMATION, TEXT, GRAPHICS, LINKS, OR ANY OTHER MATERIALS AND PRODUCTS CONTAINED HEREIN. IN NO EVENT SHALL SAP BE LIABLE FOR ANY DIRECT,
INDIRECT, SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES OF ANY KIND WHATSOEVER, INCLUDING WITHOUT LIMITATION LOST REVENUES OR LOST PROFITS, WHICH MAY RESULT FROM THE USE OF THESE MATERIALS OR INCLUDED SOFTWARE COMPONENTS.
This handbook is intended to complement the instructor-led presentation of this course, and serve as a source of reference. It is not suitable for self-study.
Typographic Conventions
American English is the standard used in this handbook. The following typographic conventions are also used.
Type Style Description
Example text Words or characters that appear on the screen. These include field names, screen titles, pushbuttons as well as menu names, paths, and options.
Also used for cross-references to other documentation both internal (in this documentation) and external (in other locations, such as SAPNet).
Example text Emphasized words or phrases in body text, titles of graphics, and tables
EXAMPLE TEXT Names of elements in the system. These include report names, program names, transaction codes, table names, and individual key words of a programming language, when surrounded by body text, for example SELECT and INCLUDE.
Example text Screen output. This includes file and directory names and their paths, messages, names of variables and parameters, and passages of the source text of a program.
Example text Exact user entry. These are words and characters that you enter in the system exactly as they appear in the documentation.
<Example text> Variable user entry. Pointed brackets indicate that you replace these words and characters with appropriate entries.
Icons in Body Text
The following icons are used in this handbook.
Icon Meaning
For more information, tips, or background Note or further explanation of previous point Exception or caution
Procedures
Indicates that the item is displayed in the instructor's presentation.
Course Overview ... vii
Course Goals ...vii
Course Objectives ...vii
Unit 1: Introduction... 1
Web Dynpro Basics...2
Unit 2: Web Dynpro Programming ... 31
The ABAP Web Dynpro API in Detail ... 33
Dialog Boxes ... 58
Advanced Component Usage ... 86
Personalization ...135
Unit 3: Enhancements ... 177
Enhancements for ABAP Web Dynpro...178
Appendix 1: Tips & Tricks for efficient Programming ... 205
This course is the successor of NET310 - ABAP Web Dynpro. It contains advanced topics related to controller programming, which are not covered by the introduction course. This includes a detailed discussion of important interfaces that are provided by the Web Dynpro framework and an overview of how to enhance Web Dynpro applications.
Target Audience
This course is intended for the following audiences:
• Developers and consultants who would like to create or change complex applications based on the ABAP Web Dynpro programming model.
Course Prerequisites
Required Knowledge
• NET310 - ABAP Web Dynpro
• It is inalienable that you have created some basic ABAP Web Dynpro applications by your own before attending this course.
Course Goals
This course will prepare you to:
• Create complex ABAP Web Dynpro applications.
Course Objectives
After completing this course, you will be able to:
• Understand, how a controller's interface is generated from its meta data. • Explain, what parts of a controller interface are visible to other controllers in
the same component or another component.
• Access the functionality provided statically by the Web Dynpro framework. • Create all kinds of pop-ups.
• Use Web Dynpro component interfaces, clone used components and use components dynamically.
SAP Software Component Information
The information in this course pertains to the following SAP Software Components and releases:
Unit 1
Introduction
Unit Overview
This unit summarizes the basics of ABAP Web Dynpro which are explained in detail in the course NET310.
Unit Objectives
After completing this unit, you will be able to:
• Explain the Web Dynpro architecture and concepts • Know how to use the Web Dynpro controller entities
Unit Contents
Lesson: Web Dynpro Basics ...2 Exercise 1: Create a simple Web Dynpro application ... 21
Lesson: Web Dynpro Basics
Lesson Overview
This lessons summarizes the content of course NET310 in short. This includes the Web Dynpro architecture, Web Dynpro controllers and their constituents and the basics about Web Dynpro component reuse.
Lesson Objectives
After completing this lesson, you will be able to: • Explain the Web Dynpro architecture and concepts • Know how to use the Web Dynpro controller entities
Business Example
You are a project lead. You would like to ensure, that all of your project members understand the basic concepts and terms related to ABAP Web Dynpro.
Web Dynpro Architecture
A Web Dynpro application refers to a Web Dynpro component, which serves as a container for entities which are related to the user interface or which are related to the control flow. The component entities and their dependencies are summed up in the following section.
Internally visible Component Entities
Views are the basic entities from which the user interface (UI) is derived. Views
allow to define a rectangular part of the UI (Layout tab) by means of pre-defined UI elements. UI element properties can be defined statically or they can be bound to the view's context. This allows to influence the element properties from the source code of the view's controller (data binding). In addition, the view controller methods encapsulate the code for checking the user input, to trigger the navigation via firing outbound plugs and to handle a navigation request via inbound plugs. Changing the UI element hierarchy is also possible at runtime.
Views are embedded in windows. Windows allow to define which views may be visible for a certain application connected to this window. If combinations of multiple views are to be displayed, the views are combined in the window (view assembly). Windows are used to define the visual flow by creating navigation links between the outbound plugs and the inbound plugs of embedded views. The control flow of a Web Dynpro component is defined in the component
controller. From the component controller methods, the database of the local
system or the functionality of a back-end system is accessed. This is mainly done by calling methods of a globally defined class (“model”) encapsulating the related
source code. These methods preferably encapsulate open-SQL statements (local DB access), the call of a Web service or the call of a function module in a back-end system. The data interchanged between the controller and the “model” can be stored in the “model” (if this global class is instantiated) or in the component controller's context (if the “model” functionality is provided by static methods). For modularization reasons, custom controllers may be created. These serve as sub controllers of the component controller.
Certain parts of a controller's functionality are potentially visible to other controllers. This is true for all controllers besides the view controller (MVC principle). The controller that needs to access to functionality has to declare the
usage of the controller providing the functionality. Then, the complete context, all
ordinary methods, and all events are visible to the consumer controller. Context
mapping simplifies accessing the context of a used controller by the consumer
controller.
Figure 1: Internally visible component entities
Externally visible Component Entities
From each window a so called interface view is derived. The interface view of a given window may be embedded in a window of a consumer component as if it was just a simple view of the consumer component itself.
Inbound plugs of type startup defined for any interface view of a Web Dynpro component serve as entry points into this Web Dynpro component accessible by the Web Dynpro runtime. To use such an entry point, a Web Dynpro application has to be started having the name of the component, of the interface view and of
Functionality of a Web Dynpro component may be offered to other Web Dynpro components by means of the component's interface controller. This controller is an interface of the component controller. Methods, events and context nodes of the component controller may be declared in a way (flag interface) that they are visible in the components interface controller.
Figure 2: Externally visible component entities
Navigation
Navigation from one view assembly to another view assembly is typically triggered by a client side user action (e.g. clicking a button, selecting a table line). This client side event can be related to the processing of a special method in the related view controller by means of an action.
To define which views will make up the next view assembly, one or more outbound plugs can be fired. A view's outbound plug can only be fired from a method of the corresponding view controller. Plugs allow to pass data via export parameters.
Figure 3: Navigation: Principle
Outbound plugs and inbound plugs of different views are connected in the window via navigation links. One outbound plug can be connected to multiple inbound plugs. This is meaningful if each inbound plug belongs to a different view and all views together belong to the next view assembly. On the other side, multiple outbound plugs may be connected to the same inbound plug.
The following graphics display two different realization of a UI displaying two of four possible views in parallel: A1 and B1, A1 and B2, or A2 and B1. By a single mouse click, the user can switch between any of the allowed view compositions.
A1 and B2 are the default views.
In the first example, two plugs are defined for each of the views A1 and B1. Firing the plugs PX1 or PY1 will result in interchanging one view only. Firing the plugs
PX2 or PY2 will result in interchanging both views, since these outbound plugs are
Figure 4: Example 1: Changing two views by firing a single outbound plug
In the second example, a better implementation is provided. Here the parameters related to the outbound plugs of the views A1 and A2 are used to pass status information to the embedding view View 1 (e.g. which button was pressed by the user). In the inbound plug method of the embedding view this information is analyzed and the next view composition is defined by firing the appropriate combination of outbound plugs related to the embedding view.
Figure 5: Example 2: Define the next state from the outbound plug's parameter values
Controller Methods
Each of the Web Dynpro controller types contains a set of predefined methods which are called by the Web Dynpro runtime. In addition to these so called hook
methods, additional methods can be defined by the developer. These may be
ordinary methods, event handler methods, or supply functions. Ordinary methods are the only methods that can be called from other methods of the same controller or even from other controllers (not valid for view controllers). Supply functions are connected to a context node and are called by the Web Dynpro framework automatically to fill the context.
Figure 6: Controller methods
All controllers contain the hook methods wddoinit() and wddoexit(). These are the first and the last method processed in a controllers lifetime, respectively.
Window controllers contain in addition the two methods wddoonopen() and
wddoonclose(), which are called when opening or closing the window as a dialog
box, respectively.
View controllers contain in addition the methods wddobeforeaction() and
wddomodifyview(). wddobeforeaction() is called before any action handler method
(as a result of a client side event) is processed. This method is used to check the user input. wddomodifyview() is used for dynamic changes of the UI element hierarchy.
Custom controllers do not contain additional hook methods. The component controller contains the additional hook methods
wddobeforenavigation() and wddopostprocessing(). wddobeforenavigation() is
called after the action handler method has been processed and just before the Web Dynpro framework processes the wddomodifyview() methods of all views belonging to the next view assembly. wddopostprocessing() is the last hook method processed before the response is send back to the client.
Figure 7: Standard hook methods: Order of processing
Controller Attributes
Each controller contains the predefined attributes WD_THIS and WD_CONTEXT which are used to access the controller's functionality and its context information, respectively.
If the component controller is defined as a used controller for another controller, the attribute WD_COMP_CONTROLLER will be added to standard attribute list of the controller declaring the usage. This attribute is used to access the functionality of the component controller object at runtime.
If an assistance class is related to a Web Dynpro component, each controller of this component will contain an additional attribute WD_ASSIST, that allows to access the functionality of the assistance class instance at runtime.
In addition to these standard attributes, the developer may define an arbitrary number of attributes. These serve as the controller's globally visible variables. In contrast to the information kept in the controller context, attributes can not be bound to UI element properties, nor they can be mapped between controllers. In addition, there is lot of meta information related to context nodes and context attributes (cardinality, selection cardinality, singleton property, related supply
Figure 8: Controller attributes
Controller Events
Component controller and custom controllers can raise events which may be handled by event handler methods defined in other controllers. Subscribing an event handler method to an event can be performed statically at design time or dynamically at runtime. An event handler method can belong to any controller located in the same component or even in another component. Controller events allow to pass data to the handler method.
Component Reuse
Web Dynpro components are reusable modules. This allows you to build Web Dynpro applications that consist of different components. From within a component, an interface enables you to use the data and functions of another component. Creating generic components is meaningful since they may be used by different developers in different contexts.
Figure 10: Component interface
Preparing Component Reuse
To be able to use any component from another (consumer) component, the consumer component must declare a usage of the component.
Figure 11: Declaring the usage of a component
Next, the component usage has to be instantiated. Technically, this can be done from any method of any controller belonging to the consumer component. As a prerequisite, the name of the used component has to be entered in the list of used components/controllers that can be found on the Properties tab of the controller.
Figure 12: Instantiating a component usage
Embedding Interface Views
Having instantiated the component usage, any interface view of the used component instance may be embedded in a window of the consumer component. Navigation links between inbound and outbound plugs that belong to embedded views or embedded interface views can be created.
Figure 13: Embedding interface views
Accessing the Interface Controller of a Component Usage
To be able to access the functionality of a component usage from a controller of the consumer component, this controller has to declare the usage of the component usage's interface controller. Then, methods, events and context nodes visible in the interface controller of the component usage can be accessed by the controller in the consumer component.
Figure 16: Handling events fired in the interface controller
Cross Component Context Mapping
There are two possibilities to define the mapping between the context node in the interface controller and an appropriate context node in a controller of the consumer component:
Normal context mapping:
If the used component has its data stored in a context node defined in the interface controller, each controller of the consumer component may map this context node. To do so, the controller of the consumer component has to declare the interface controller of the used component as a used controller. The context structure can be copied and the context node can be mapped as if the interface controller was a controller of the same component (drag & drop).
Figure 19: Normal context mapping: Realization
External context mapping:
More often, data stored in the component controller or a custom controller of the consumer component has to be accessed by the used component (e.g. SAP List Viewer component). In this case, the interface controller of the used component instance has to map a context node located in a controller of the consumer component. However, it is not possible to change the functionality of the interface controller of a used component instance. Thus, the context nodes of the used component have to be defined in a very generic manner to allow reusing the component in different contexts (e.g. display arbitrary tables by the SAP List Viewer component). To define the context mapping between the interface controller of a certain component usage and the controller of the consumer component keeping the data, the interface controller of the component usage has to be edited (see drawing below). Next the controller containing the context node to be mapped has to be declared as a used controller for the interface controller usage. Finally the context mapping between the controllers can be established.
Exercise 1: Create a simple Web Dynpro
application
Exercise Objectives
After completing this exercise, you will be able to:
• Proof your basic Web Dynpro knowledge by creating a simple Web Dynpro application.
Business Example
You have to create a complex Web Dynpro application, including the usage of dialog boxes, advanced component reuse, and explicit configuration /
personalization. You know the Web Dynpro basics, since you have taken the class NET310. Thus you begin to create your application implementing the techniques you learned before.
This application allows the user to enter the key of a flight connection. After pressing a button, all related flights are read and displayed on the same screen using a tableView UI element.
Template Component: n/a
Solution Component: NET311_INTR_S
Task 1:
Create a package that will contain all the repository objects you are going to develop.
1. Create the package ZNET311_##. Assign the application component
BC-WD, the software component HOME, and a short description.
A transport request has been created by your trainer.
Task 2:
Create a Web Dynpro component, having one window and a view embedded in this window.
1. Create the Web Dynpro component ZNET311_INTR_## with a main window MAIN_WINDOW.
Task 3:
In the component controller of your component create two context nodes. At runtime, one node will hold the user input (connection key), while the other one will be filled with the flights for the connection key entered by the user.
In addition, create two ordinary methods: The code for reading the user input from the context attributes is to be encapsulated in one method, the code to read the related flights from the data base and save the flight data in the context is to be encapsulated in the second method.
To read the flights, the static method READ_FLIGHTS( ) of class
CL_NET310_FLIGHTMODEL is to be used.
1. In the context of your component controller, create a node CONNECTION, having cardinality (1:1) and type NET311_S_CONNECTION. Add the attributes CARRID and CONNID. Switch on the Input Help Mode (Automatic) and define default values for both attributes.
2. Create another node FLIGHTS, having cardinality (0:n) and type SFLIGHT. Add the attributes CARRID, CONNID, FLDATE, PRICE, CURRENCY, and
PLANETYPE to the node.
3. Now create an ordinary method GET_USER_INPUT( ), having an export parameter ES_CONNECTION of type NET311_S_CONNECTION. Read the user input from the context node CONNECTION and export this connection key via the export parameter.
4. Create the ordinary method GET_FLIGHTS( ). From the source code of this method, call the method GET_USER_INPUT( ). Then pass the connection key to the static method READ_FLIGHTS( ) defined in class
CL_NET310_FLIGHTMODEL. This method will provide the related flights.
Finally store the flights in the context node FLIGHTS.
Task 4:
In the view, create a form to enter the carrier id and the connection number. Create a table to display the flights. Create a button that triggers reading the flights for the connection key entered by the user.
1. Copy and map the context nodes defined in the component controller to the view context.
2. In the view's layout, create a group containing input fields related to the attributes CARRID and CONNID of node CONNECTION.
3. Create a table to display the flights stored in the context node FLIGHTS. 4. Create a button to trigger reading the flights for the connection entered by
the user.
5. Optimize the layout.
Task 5:
Create an application, activate your component and test the application. 1. Create a Web Dynpro application having the name of your component. 2. Test your application.
Solution 1: Create a simple Web Dynpro
application
Task 1:
Create a package that will contain all the repository objects you are going to develop.
1. Create the package ZNET311_##. Assign the application component
BC-WD, the software component HOME, and a short description.
A transport request has been created by your trainer.
a) Perform this step like you (hopefully) have done often before.
Task 2:
Create a Web Dynpro component, having one window and a view embedded in this window.
1. Create the Web Dynpro component ZNET311_INTR_## with a main window MAIN_WINDOW.
a) In the navigation area of the ABAP Workbench, open the context menu for the package and choose Create → WebDynpro → WebDynpro
Component (Interface).
b) In the dialog box, enter the name of the component, a description, and the name of the main window.
2. Create a Web Dynpro view (name: MAIN_VIEW) inside your component. a) In the context menu for the Web Dynpro component choose Create →
View.
b) Enter the name of the view and a short description. 3. Embed the view into the window of your component.
a) Edit the Web Dynpro window and open the Window tab.
b) Drag and drop the view from the object tree of your component to the Window tab.
Task 3:
In the component controller of your component create two context nodes. At runtime, one node will hold the user input (connection key), while the other one will be filled with the flights for the connection key entered by the user.
In addition, create two ordinary methods: The code for reading the user input from the context attributes is to be encapsulated in one method, the code to read the related flights from the data base and save the flight data in the context is to be encapsulated in the second method.
To read the flights, the static method READ_FLIGHTS( ) of class
CL_NET310_FLIGHTMODEL is to be used.
1. In the context of your component controller, create a node CONNECTION, having cardinality (1:1) and type NET311_S_CONNECTION. Add the attributes CARRID and CONNID. Switch on the Input Help Mode (Automatic) and define default values for both attributes.
a) Edit the component controller of your application. Select the Context tab.
b) From the context menu of the root node CONTEXT choose Create
→ Node. Enter name and type. Press the button Add Attribute from Structure. Mark CARRID and CONNID. Finish the dialog.
c) Change the value of property Input Help Mode to Automatic for both attributes.
d) Enter default values for both attributes (property Default Value), e.g.
AA and 0017, respectively.
2. Create another node FLIGHTS, having cardinality (0:n) and type SFLIGHT. Add the attributes CARRID, CONNID, FLDATE, PRICE, CURRENCY, and
PLANETYPE to the node.
a) Proceed as described in last step. In addition you have to change the default cardinality (1:1) to (0:n).
3. Now create an ordinary method GET_USER_INPUT( ), having an export parameter ES_CONNECTION of type NET311_S_CONNECTION. Read the user input from the context node CONNECTION and export this connection key via the export parameter.
a) Select the Methods tab. Enter the name of the method in the column
Method and press Enter. Double click on the method's name to edit
4. Create the ordinary method GET_FLIGHTS( ). From the source code of this method, call the method GET_USER_INPUT( ). Then pass the connection key to the static method READ_FLIGHTS( ) defined in class
CL_NET310_FLIGHTMODEL. This method will provide the related flights.
Finally store the flights in the context node FLIGHTS. a) To create the method, proceed as described in last step. b) Source code see below.
Task 4:
In the view, create a form to enter the carrier id and the connection number. Create a table to display the flights. Create a button that triggers reading the flights for the connection key entered by the user.
1. Copy and map the context nodes defined in the component controller to the view context.
a) Edit the view. Select the Context tab.
b) Drag and drop the nodes CONNECTION and FLIGHTS from the component controller context to the view controller context. 2. In the view's layout, create a group containing input fields related to the
attributes CARRID and CONNID of node CONNECTION. a) Select the Layout tab.
b) Mark the ROOTUIELEMENTCONTAINER. Use the Web Dynpro Code
Wizard to create the group. Enter a text for the group caption.
3. Create a table to display the flights stored in the context node FLIGHTS. a) Mark the ROOTUIELEMENTCONTAINER again. Use the Web Dynpro
Code Wizard to create the table for node FLIGHTS.
4. Create a button to trigger reading the flights for the connection entered by the user.
a) Mark the group embedding the form and press the right mouse button. Use the context menu entry Insert Element to create a button (name:
BUT_FLIGHTS). Assign a text (Display flights) to the button. Use the
button behind the property OnAction to create and assign an action (name: DISP_FLIGHTS).
b) Implement the action handler method for action DISP_FLIGHTS: Call the method GET_FLIGHTS( ) defined in the component controller. c) Source code see below.
5. Optimize the layout.
a) Use an appropriate layout editor for the
ROOTUIELEMENTCON-TAINER and change the Layout Data property of button and table.
b) Change additional layout properties if desired.
Task 5:
Create an application, activate your component and test the application. 1. Create a Web Dynpro application having the name of your component.
a) From the context menu of your application (Create → Web Dynpro
Application) create a Web Dynpro application having the name of your
component. Enter a description and save.
b) Activate your component with all dependent objects. 2. Test your application.
a) Start your application from the context menu of your application.
Result
Comp.
Controller:
GET_USER_INPUT( )
METHOD get_user_input .
DATA: lr_node_connection TYPE REF TO if_wd_context_node, lr_elem_connection TYPE REF TO if_wd_context_element,
ls_connection TYPE if_componentcontroller=>element_connection. * get user input
lr_node_connection = wd_context->get_child_node( name = if_componentcontroller=>wdctx_connection ). lr_elem_connection = lr_node_connection->get_element( ). lr_elem_connection->get_static_attributes( IMPORTING static_attributes = es_connection ). ENDMETHOD.
lr_node_flights TYPE REF TO if_wd_context_node. * get connection key from context
wd_this->get_user_input( IMPORTING es_connection = ls_connection ). * get related flights
CALL METHOD cl_net310_flightmodel=>read_flights EXPORTING
i_carrid = ls_connection-carrid i_connid = ls_connection-connid IMPORTING
e_flights = lt_flights. * store flights in conext
lr_node_flights = wd_context->get_child_node(
name = if_componentcontroller=>wdctx_flights ). lr_node_flights->bind_table( lt_flights ).
ENDMETHOD.
View Controller:
ONACTIONDISP_FLIGHTS( )
METHOD onactiondisp_flights .
* read flights for selected connection wd_comp_controller->get_flights( ). ENDMETHOD.
Lesson Summary
You should now be able to:• Explain the Web Dynpro architecture and concepts • Know how to use the Web Dynpro controller entities
Unit Summary
You should now be able to:• Explain the Web Dynpro architecture and concepts • Know how to use the Web Dynpro controller entities
Related Information
• The following Web Dynpro components are provided in all systems based on SAP NetWeaver Application Server 7.0 and later:
Web Dynpro components having the name WDR_TEST... are applications to test the Web Dynpro concepts.
Web Dynpro components having the name WDR_... (without the addition
TEST) or WD_... are basis utility components.
• The online documentation (component BC-WD-ABA) provides an excellent description of Web Dynpro features, programming techniques, and class references.
• The software developer network (SDN - http://sdn.sap.com) offers a knowledge center and a discussion forum for ABAP Web Dynpro.
• FAQs, HowTos, and other frequently referenced materials can be found in Web Dynpro ABAP WIKI (http://wiki.sdn.sap.com/wiki/display/wdabap).
Unit 2
Web Dynpro Programming
Unit Overview
To exploit the complete functionality offered by the Web Dynpro framework the developer needs to know what classes and interfaces do exist and how these classes and interfaces can be accessed.
The functionality can be divided in two parts: Classes and interfaces that are defined in the repository statically and controller functionality that reflects the meta data entered by the developer in the ABAP Workbench.
The first lesson of this unit describes how the functionality of a certain controller can be accessed from the source code of the same controller or any other controller. The most important interfaces of the Web Dynpro framework are illustrated, inclusive their dependencies and the way of how to access them.
The other lessons focus on sending pop-ups, reusing Web Dynpro components dynamically, and defining / using personalization variants, respectively. In this context the related interfaces are discussed in detail.
Unit Objectives
After completing this unit, you will be able to:
• Explain, how the Web Dynpro controller interface is derived from the controller's entities
• Describe, how a Web Dynpro controller's functionality can be accessed from another controller
• Use the reference variable WD_THIS to access the functionality provided by the Web Dynpro framework
• Create external dialog boxes • Create confirmation dialog boxes
• Use multiple Web Dynpro components having implemented the same Web Dynpro interface
• Use multiple component usages of the same component
• Use component usage groups to manage dynamically created component usages
• Define navigation and event handling for dynamically defined component usages.
• Explain the options for adapting Web Dynpro applications. • Apply implicit adaptation options.
• Prepare the code for explicit adaptations.
• Implement explicit personalization / customizing.
Unit Contents
Lesson: The ABAP Web Dynpro API in Detail ... 33 Exercise 2: Check user input and send messages ... 49 Lesson: Dialog Boxes ... 58 Exercise 3: Dialog boxes ... 75 Lesson: Advanced Component Usage... 86 Exercise 4: Using components with the same component interface 113 Lesson: Personalization ...135 Exercise 5: Configuration, customizing and personalization ...157
Lesson: The ABAP Web Dynpro API in Detail
Lesson Overview
The knowledge of the classes and interfaces provided by the Web Dynpro runtime and the relationship between these classes/interfaces is essential for programming Web Dynpro applications. This lesson explains in detail what classes/interfaces are provided and, how these classes/interfaces can be accessed from the controller's source code.
Lesson Objectives
After completing this lesson, you will be able to:
• Explain, how the Web Dynpro controller interface is derived from the controller's entities
• Describe, how a Web Dynpro controller's functionality can be accessed from another controller
• Use the reference variable WD_THIS to access the functionality provided by the Web Dynpro framework
Business Example
You need to define controller source code not provided by Web Dynpro code wizard, e.g. you need to instantiate component usages dynamically or you need to define an arbitrary number of component usages at runtime. In order to do this, you need to know which classes are to be used to implement your functionality and how these classes can be accessed from the source code of a given controller.
The Controller Interface
A Web Dynpro controller consists of a number of constituents, e.g. the context, attributes, methods, or properties. Depending on the controller type, some of these constituents may be visible to other controllers, while others are private to the controller.
The abstract definition of the constituents is performed using the Web Application Builder. From this definition one or more interfaces are derived per controller. These interfaces allow to access the constituents from the controller itself or from other controllers located in the same Web Dynpro component. For the component controller it is even possible to define methods, events and context nodes in a way, so they can be accessed from controllers that belong to another
Figure 23: Displaying the interface of any Web Dynpro controller
Structure of the Controller Interface
Depending on the controller type (component controller, custom controller, window controller, and view controller), one or two interfaces are generated from the definition of the controller constituents:
• All parts of a controller that are not visible to other controllers are stored in an interface having the name IF_<CONTROLLER>. In the following, this interface is referred to as the controller's private interface.
• All parts of a controller that are potentially visible to other controllers are stored in an interface having the name IG_<CONTROLLER>. The interface IF_<CONTROLLER> is then embedded in the interface
IG_<CONTROLLER>. In the following, this interface is referred to as the
controller's public interface.
• For the component controller, an additional interface is generated (IWCI_<COMPONENT> in the SAP name space or
ZIWCI_<COMPONENT> in the customer name space). This globally
Figure 24: Controller types and related generated component interfaces
The following important interface elements do exist for all controller types: • The method wd_get_api() allows to access the statically defined interfaces of
the Web Dynpro framework.
• For each ordinary method or event handler method, a related method is created in the interface.
• For each attribute defined in the controller, a related attribute is defined in the interface.
• For each context node, a constant WDCTX_<NODE> of type string is created. The value of this node equals the node's name.
In addition , two types are defined, a structure type ELEMENT_<NODE> and a related internal table type ELEMENTS_<NODE>. If the node is typed with a ABAP Dictionary type, the structure type equals the ABAP Dictionary type. If the node is not typed, the structure type is built from the direct attributes of the node.
• For each controller defined as a used controller, a method
(get_<controller>_ctrl()) is created in the interface, which allows to access the public interface (IG_<CONTROLLER>) of the used controller.
According to the Model View Controller (MVC) paradigm, view controllers keep all their functionality private. Thus, only one interface (IF_<VIEW> - not visible to any other controller) is derived from the meta data description of this kind of controller.
Figure 25: Dynamically generated interface for view controllers
In the following, UML diagrams are used to describe the components of the controller interfaces and the dependencies between them.
Figure 26: Generated interface for view controllers
For the window controller, all ordinary methods and all interface component related to context elements are defined in the public interface IG<WINDOW>. For inbound plugs and outbound plugs, the flag public can be checked by the developer. However, this has no effect on the interface in which the related components are defined. All methods related to outbound plugs are always defined in the interface IG<WINDOW>, while the event handler methods related to the inbound plugs are always defined in the interface IF<WINDOW>.
Figure 27: Generated interfaces for window controllers
The generated custom controller interfaces are comparable to the window controller interfaces. However, instead of inbound plugs and outbound plugs, custom controllers have event handlers and events. The methods used to fire the events or to handle an event are always defined in the controller interface
Figure 28: Generated interfaces for custom controllers
The component controller interface consists of the interface
IF_COMPO-NENTCONTROLLER, the interface IG_COMPONENTCONTROLLER and the
globally visible interface (Z)IWCI_<COMPONENT>. Controllers defined in the same component may access the functionality defined in the interfaces
IG_COMPONENTCONTROLLER and (Z)IWCI_<COMPONENT>. Controllers
defined in other components may access the functionality in the global interface
(Z)IWCI_<COMPONENT> using the method wd_cpifc_<component_usage>( ).
The developer can define whether methods, events, and context nodes are visible to other components (flag Interface). However, only ordinary methods having this flag set are defined in the global interface. All other ordinary methods and public attributes are defined in the public interface IG_COMPONENTCONTROLLER. From the source code of the component controller it is also possible to access Web Dynpro framework functionality by means of the embedded static interface
Figure 29: Generated and static interfaces for component controllers
The Web Dynpro API
In the last section the dynamically generated interfaces of Web Dynpro controllers have been discussed. These contain components that result from the developers meta data definition in the Web Application Builder. However, the Web Dynpro framework provides additional functionality that does not depend on the developers input. This includes the possibility to handle messages, to fire portal events, to define new or change existing context elements, to access parameters related to the current action and more.
For each controller, the method wd_get_api( ) is defined in the controller interface. This method returns a reference to an interface giving access to the complete API related to this kind of controller and (via embedded interfaces) to the component's API.
Since wd_get_api( ) is always defined in the public interface of a given controller, this method can be called from any controller that declared the usage of this controller.
Depending on the controller type, the reference returned by the method
wd_get_api( ) is of type IF_WD_COMPONENT (component controller),
IF_WD_VIEW_CONTROLLER (view controller and window controller), or IF_WD_CONTROLLER (custom controller).
Figure 30: Accessing the WD API for the different controller types
IF_WD_CONTROLLER contains the functionality available for all controllers.
Thus, this interface is embedded in the interfaces IF_WD_VIEW_CONTROLLER and IF_WD_COMPONENT.
IF_WD_VIEW_CONTROLLER contains additional functionality only relevant
for view controllers and window controllers. IF_WD_COMPONENT contains functionality not related to a certain controller but to the component.
Figure 31: Web Dynpro API for view / window controllers
Figure 33: Web Dynpro API for component controllers
In the following, the most important methods of the interface
IF_WD_CONTROLLER are summed up: get_action( )
Returns an interface reference of type IF_WD_ACTION. Used to read and redefine action properties.
Hint: This method can only be called from view controller methods.
get_component( )
Returns an interface reference of type IF_WD_COMPONENT. Contained methods are used to access information about the components entities (controllers, used components, window manager, portal manager, application...).
For controllers different from the component controller, the following method calls return the same interface reference:
- WD_COMP_CONTROLLER->wd_get_api()
get_context( )
Returns an interface reference of type IF_WD_CONTEXT. The related object describes the context of the controller (mata data and context data). Contained methods allow to read or change the context structure, to access the content stored at runtime, or to log the context change.
Accessing the controller's root node is possible in two ways: - WD_CONTEXT
- WD_THIS->wd_get_api()->get_context()->ROOT_NODE
get_controller_info()
Returns an interface reference of type IF_WD_RR_CONTROLLER. Allows to access the controller's name.
get_message_manager()
Returns an interface reference of type IF_WD_MESSAGE_MANAGER. Contained methods may be used to report messages, clear the message stack or to check whether any message exists.
get_personalization_manager()
Returns an interface reference of type
IF_WD_PERSONALIZATION_MAN-AGER. This interface contains methods to load, save or delete personalization
variants.
Hint: This functionality is not accessible from view controllers or from window controllers.
In the following, the most important methods of the interface
IF_WD_COMPONENT are summed up: get_id( )
Returns the unique ID (string) of the actual WD component.
get_window_manager( )
Returns an interface reference of type IF_WD_WINDOW_MANAGER. This interface is used to create modal popups or external dialog screens.
get_component_info( )
Returns an interface reference of type IF_WD_RR_COMPONENT. The Interface contains methods to access the meta data description of the component and all included entities.
get_portal_manager()
Returns an interface reference of type IF_WD_PORTAL_INTEGRATION. It allows to access information about the portal type and version embedding the WD application. The interface contains methods which have to be used to access the portal functionality (e.g. portal eventing).
add_event_handler()
This method allows to dynamically register an event handler method defined in one controller for an event defined in another controller of the same component or a used component.
remove_event_handler()
This method allows to delete any dynamically defined registration of an event handler for an event.
get_cmp_usage_group(), has_cmp_usage_group(), create_cmp_usage_group()
Component usage groups are used to manage component usages that are defined dynamically. The methods create_cmp_usage_group() and get_cmp_usage_group() are used to create and access such a component usage group (returning interface reference of type IF_WD_COMPONENT_USAGE_GROUP). The method
has_cmp_usage_group() returns, whether the component usage group has
already been created (returning type boolean).
cancel_navigation()
This method can be used to prevent the navigation for the complete application (or for the window of a used component displayed as a dialog box if cancel_navigation( ) is called from this used component).
wddobeforenavigation( ) is the last hook method processed before the
navigation takes place. Thus, cancel_navigation( ) has to be called before the processing of the hook method wddobeforenavigation( ) is finished.
get_application()
Returns an interface reference of type IF_WD_APPLICATION. Contained methods allow to access the meta data description of the application. Finally, the Web Dynpro runtime allows to access view specific functionality by means of the interface IF_WD_VIEW_CONTROLLER. This interface is returned by the method wd_get_api() for both, view controllers and window controllers. However, some methods may not be used from window controllers as described below:
fire_plug( )
This method allows to fire any plug. The plug's name is to be passed as a
get_embedding_window_ctlr( )
This method checks if the actual view / window is embedded in another window. The reference to the embedding window is returned (interface reference of type IF_WD_WINDOW_CONTROLLER). Contained methods allow to access the meta data description of the window controller (e.g. embedded views, navigation links, name of default view).
Hint: If the actual view / window is not embedded in another window, the returned reference is initial.
If a window is displayed as a modal dialog box, then the method
get_window() called for this window returns a reference to an object of type IF_WD_WINDOW. This object offers functionality related to dialog boxes
(e.g. open dialog box, close dialog box, ...).
Hint: If a window is not displayed as a dialog box, then the reference returned by method get_window( ) is initial.
Example:
View V is embedded in window A. This window is embedded (as an interface view) in window B. Window B is send as a dialog box. Calling method get_embedding_window_ctlr( ) for view V will return a reference to window A. Method get_window() called for this reference will return an initial value. Calling method
get_embedding_window_ctlr( ) a second time for the reference
to window A will return a reference to window B. Method
get_window() called for this reference will now return the reference
to the dialog box functionality of window B.
get_view_info( )
Returns an interface reference of type IF_WD_RR_VIEW. Contained method allow to access the meta data description of the view controller (e.g. view name, life span, description).
request_focus()
Allows to set the focus in the client representation to a certain UI element, if this UI element has it's value property bound to a context attribute.
request_focus_on_action()
Allows to set the focus in the client representation on a certain UI element, if this UI element has the event property on_... bound to an action.
Hint: This method can not be called from a window controller.
get_current_action()
Returns an interface reference of type IF_WD_ACTION. Allows to find out which client side event was fired by the user of the application. Typically used in the method wddobeforeaction() of the related view.
Hint: This method can not be called from a window controller.
prepare_dynamic_navigation(), do_dynamic_navigation()
These two methods are defined in the interface
IF_WD_NAVIGATION_SER-VICES which is embedded in the interface IF_WD_VIEW_CONTROLLER.
These methods allow to define navigation links dynamically. This is necessary, if component usages are defined and instantiated at runtime. Then, the inbound plugs of the related interface views are not existent at design time, which is the prerequisite to define static navigation links.
Exercise 2: Check user input and send
messages
Exercise Objectives
After completing this exercise, you will be able to:
• Define controller attributes and access them from other controllers. • Send messages.
Business Example
In your Web Dynpro application you have to implement the validation of the user input. This may depend on the triggered action.
Template Component: NET311_INTR_S Solution Component: NET311_API_S
Task 1:
If you have finished the previous exercise, you can skip this task. Then, all changes can be implemented in the component you have created in your last exercise. If you have not finished your last exercise, you can start with a copy of the template component. In this case, copy the template component and name the copy ZNET311_API_##. Assign this component to your package ZNET311_##. Create an application having the same name as your component and assign the application to your package, too.
1. Copy the template component.
2. Create an application to access your component.
Task 2:
Create a component controller method that checks if the connection key entered by the user is valid.
To read a single connection for a given connection key, the static method
READ_CONNECTIONS( ) of class CL_NET310_FLIGHTMODEL is to be
used.
If the connection exists, the method should return the value ABAP_TRUE (= 'X'), otherwise the value ABAP_FALSE (= ' ').
2. Define a returning parameter (name: E_CONNECTION_EXISTS) of type
string.
3. Call the method GET_USER_INPUT( ) to get the connection key entered by the user.
4. Call the static method READ_CONNECTIONS( ) of class
CL_NET310_FLIGHTMODEL to read the complete connection data set for
the connection key entered by the user.
5. If the connection data set could be read by the static method, set the returning parameter to ABAP_TRUE, otherwise evaluate the parameter with
ABAP_FALSE.
Task 3:
Define a controller attribute in the component controller to store the reference to the message manager. Make sure that this reference variable is visible to all other controllers of your component.
Get the reference to the message manager in the method WDDOINIT( ) of the component controller.
1. Define a controller attribute in the component controller to store the reference to the message manager. Make sure that this reference variable is visible to all other controllers of your component.
2. Get the reference to the message manager in the method WDDOINIT( ) of the component controller.
Task 4:
All texts displayed as messages have to be translatable. Thus, assign the assistance class CL_NET311_ASSIST to your component.
1. Assign the assistance class to your component.
Task 5:
Now edit the method WDDOBEFOREACTION( ) of the view controller. If the user has triggered the action DISP_FLIGHTS (assigned to the button), then the component controller method CHECK_CONNECTION( ) has to be called. If the connection is not valid, an error message hat to be send. Look for an appropriate message text in the assistance class.
1. Get the reference to the current action by calling the method
GET_CURRENT_ACTION( ) of the view controller API.
2. Check whether the reference to the current action is bound. Stop processing the method, if the reference to the action object is not bound.
Hint: In some situations a round trip can take place without having triggered an action (e.g. selecting a line in a table).
3. If the reference to the current action object is bound, check the value of the public attribute NAME. If this value equals the name of the action assigned to the button with the label Display Flights (DISP_FLIGHTS), call the component controller method CHECK_CONNECTION( ).
4. Check the returning parameter of method CHECK_CONNECTION( ). If the connection does not exist, read the text with id 001 from the text pool of the assistance class by calling its method GET_TEXT( ).
Send this text as an error message. Use the method
REPORT_ER-ROR_MESSAGE( ) defined in the message manager interface.
5. Instead of using the controller attribute WD_COMP_CONTROLLER, what other possibility does exist to access the API of the component controller from a view controller?
Solution 2: Check user input and send
messages
Task 1:
If you have finished the previous exercise, you can skip this task. Then, all changes can be implemented in the component you have created in your last exercise. If you have not finished your last exercise, you can start with a copy of the template component. In this case, copy the template component and name the copy ZNET311_API_##. Assign this component to your package ZNET311_##. Create an application having the same name as your component and assign the application to your package, too.
1. Copy the template component.
a) Display the template component in the object tree. Clicking on the component with the right mouse button will open the component's context menu. Choose Copy.... Enter the name of the component to be created. Press Continue.
b) Adapt the description of the new component. 2. Create an application to access your component.
a) An application having the same name as the component can be created from the context menu of the component.
Task 2:
Create a component controller method that checks if the connection key entered by the user is valid.
To read a single connection for a given connection key, the static method
READ_CONNECTIONS( ) of class CL_NET310_FLIGHTMODEL is to be
used.
If the connection exists, the method should return the value ABAP_TRUE (= 'X'), otherwise the value ABAP_FALSE (= ' ').
1. Create a method (name: CHECK_CONNECTION( )) in the component controller. This method will contain the source code to validate the user input.
a) Edit the component controller of your component. Select the Methods tab. In the column Method enter the method's name and press Enter. Double click on the method's name to edit its source code.
2. Define a returning parameter (name: E_CONNECTION_EXISTS) of type
string.
a) Parameters are defined by entering name, type, and associated type in the corresponding fields above the source code.
3. Call the method GET_USER_INPUT( ) to get the connection key entered by the user.
a) Source code see below.
4. Call the static method READ_CONNECTIONS( ) of class
CL_NET310_FLIGHTMODEL to read the complete connection data set for
the connection key entered by the user. a) Source code see below.
5. If the connection data set could be read by the static method, set the returning parameter to ABAP_TRUE, otherwise evaluate the parameter with
ABAP_FALSE.
a) Source code see below.
Task 3:
Define a controller attribute in the component controller to store the reference to the message manager. Make sure that this reference variable is visible to all other controllers of your component.
Get the reference to the message manager in the method WDDOINIT( ) of the component controller.
1. Define a controller attribute in the component controller to store the reference to the message manager. Make sure that this reference variable is visible to all other controllers of your component.
a) In the component controller, select the tab Attributes. Define a reference variable (name: GR_MESS_MAN) of type
IF_WD_MESSAGE_MANAGER. Check the property PUBLIC.
2. Get the reference to the message manager in the method WDDOINIT( ) of the component controller.
Task 4:
All texts displayed as messages have to be translatable. Thus, assign the assistance class CL_NET311_ASSIST to your component.
1. Assign the assistance class to your component.
a) Double click on your component. Enter the name of the assistance class in the corresponding field. Save.
Task 5:
Now edit the method WDDOBEFOREACTION( ) of the view controller. If the user has triggered the action DISP_FLIGHTS (assigned to the button), then the component controller method CHECK_CONNECTION( ) has to be called. If the connection is not valid, an error message hat to be send. Look for an appropriate message text in the assistance class.
1. Get the reference to the current action by calling the method
GET_CURRENT_ACTION( ) of the view controller API.
a) Source code see below.
2. Check whether the reference to the current action is bound. Stop processing the method, if the reference to the action object is not bound.
Hint: In some situations a round trip can take place without having triggered an action (e.g. selecting a line in a table).
a) Source code see below.
3. If the reference to the current action object is bound, check the value of the public attribute NAME. If this value equals the name of the action assigned to the button with the label Display Flights (DISP_FLIGHTS), call the component controller method CHECK_CONNECTION( ).
a) Source code see below.
4. Check the returning parameter of method CHECK_CONNECTION( ). If the connection does not exist, read the text with id 001 from the text pool of the assistance class by calling its method GET_TEXT( ).
Send this text as an error message. Use the method
REPORT_ER-ROR_MESSAGE( ) defined in the message manager interface.
a) Source code see below.
5. Instead of using the controller attribute WD_COMP_CONTROLLER, what other possibility does exist to access the API of the component controller from a view controller?
Answer: The related code is commented in the source code of method
WDDOBEFOREACTION( ) printed below.
Result
Comp.
Controller:
CHECK_CONNECTION( )
METHOD check_connection .
DATA: ls_connection TYPE net311_s_connection, ls_spfli TYPE spfli.
* get connection key from context
wd_this->get_user_input( IMPORTING es_connection = ls_connection ). * try to read complete connection for connection key
CALL METHOD cl_net310_flightmodel=>read_connections EXPORTING
i_carrid = ls_connection-carrid i_connid = ls_connection-connid IMPORTING
e_connection = ls_spfli. * set returning parameter
IF ls_spfli IS INITIAL. e_connection_exists = abap_false. ELSE. e_connection_exists = abap_true. ENDIF. ENDMETHOD.
Comp.
Controller:
WDDOINIT( )
METHOD wddoinit .
DATA: lr_current_controller TYPE REF TO if_wd_controller. lr_current_controller ?= wd_this->wd_get_api( ).
View Controller:
WDDOBEFOREACTION( )
METHOD wddobeforeaction .
DATA: lr_api_main_view TYPE REF TO if_wd_view_controller, * lr_api_comp_ctlr TYPE REF TO ig_componentcontroller,
lr_current_action TYPE REF TO if_wd_action, lv_result TYPE string, lv_text TYPE string.
CONSTANTS: lc_action_1 TYPE string VALUE 'DISP_FLIGHTS'. * get object for current action
lr_api_main_view = wd_this->wd_get_api( ).
lr_current_action = lr_api_main_view->get_current_action( ). * if action is not accessible
IF NOT lr_current_action IS BOUND. RETURN.
ENDIF.
* check action name
IF lr_current_action->name = lc_action_1. * check if connection key is meaningful
lv_result = wd_comp_controller->check_connection( ).
***************************************************************************** *** alternative approach without using wd_comp_controller ******************* * lr_api_comp_ctlr = wd_this->get_componentcontroller_ctr( ). * * lv_result = lr_api_comp_ctlr->check_connection( ). * *****************************************************************************
IF lv_result = abap_false.
lv_text = wd_assist->get_text( '001' ).
wd_comp_controller->gr_mess_man->report_error_message( message_text = lv_text ). ENDIF.
ENDIF. ENDMETHOD.
Lesson Summary
You should now be able to:• Explain, how the Web Dynpro controller interface is derived from the controller's entities
• Describe, how a Web Dynpro controller's functionality can be accessed from another controller
• Use the reference variable WD_THIS to access the functionality provided by the Web Dynpro framework
Related Information
• A description of the programming interfaces can be found in the section
Reference →Programming Interfaces of the Web Dynpro ABAP online
Lesson: Dialog Boxes
Lesson Overview
ABAP Web Dynpro allows to send windows as dialog boxes. These dialog boxes can be modal (window containing the element that was clicked to open the popup is locked) or external (independent from the window containing the element clicked on). This lesson describes how to define and how to handle dialog boxes.
Lesson Objectives
After completing this lesson, you will be able to: • Create external dialog boxes
• Create confirmation dialog boxes
• Create modal dialog boxes to display windows of the same or another component
• Define and handle buttons on modal dialog boxes and confirmation dialog boxes
Business Example
You are developing a Web Dynpro application. In this context you would like to implement dialog boxes.
Overview
Dialog boxes are used to display concrete information or possible settings in a view popping up on top of the browser window the user clicked on. After the dialog has been exited, either the browser window underneath becomes active again or another screen may appear.
There are two different types of dialog boxes: • External dialog box:
An external dialog box is opened in a separate browser window and can be moved around the screen independently of the original window. External dialog boxes are generally modeless.
• Modal dialog box:
A modal dialog box is opened in the current browser window. The modal dialog box may display a window of the same component, the interface view of a used component, or a confirmation dialog.
Dialog boxes are implemented within a Web Dynpro application via an additional window and are generally called by the event handler of an action. If necessary however, all other controller methods can be used. The component controller contains the interface IF_WD_WINDOW_MANAGER, with which a new window for the content of the dialog box can be created and opened.
