NET311 Advanced ABAP Web Dynpro

NET311Advanced ABAP Web Dynpro

SAP NetWeaver

Date

Training Center

Instructors

Education Website

Participant HandbookCourse Version: 2006 Q2Course Duration: 2 Day(s)Material Number: 50084905

An SAP course - use it to learn, reference it for work

Copyright

Copyright © 2007 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purposewithout the express permission of SAP AG. The information contained herein may be changedwithout prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary softwarecomponents of other software vendors.

Trademarks

� Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® areregistered 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 trademarksof Citrix Systems, Inc.

� HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, WorldWide 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.comare trademarks or registered trademarks of SAP AG in Germany and in several other countriesall over the world. All other products mentioned are trademarks or registered trademarks oftheir respective companies.

Disclaimer

THESE MATERIALS ARE PROVIDED BY SAP ON AN "AS IS" BASIS, AND SAP EXPRESSLYDISCLAIMS ANY AND ALL WARRANTIES, EXPRESS OR APPLIED, INCLUDINGWITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY AND FITNESS FOR APARTICULAR PURPOSE, WITH RESPECT TO THESE MATERIALS AND THE SERVICE,INFORMATION, TEXT, GRAPHICS, LINKS, OR ANY OTHER MATERIALS AND PRODUCTSCONTAINED HEREIN. IN NO EVENT SHALL SAP BE LIABLE FOR ANY DIRECT,INDIRECT, SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES OF ANYKIND WHATSOEVER, INCLUDING WITHOUT LIMITATION LOST REVENUES OR LOSTPROFITS, WHICH MAY RESULT FROM THE USE OF THESE MATERIALS OR INCLUDEDSOFTWARE COMPONENTS.

g2007526112259

About This HandbookThis handbook is intended to complement the instructor-led presentation of thiscourse, and serve as a source of reference. It is not suitable for self-study.

Typographic ConventionsAmerican English is the standard used in this handbook. The followingtypographic conventions are also used.

Type Style Description

Example text Words or characters that appear on the screen. Theseinclude field names, screen titles, pushbuttons as wellas menu names, paths, and options.

Also used for cross-references to other documentationboth internal (in this documentation) and external (inother locations, such as SAPNet).

Example text Emphasized words or phrases in body text, titles ofgraphics, and tables

EXAMPLE TEXT Names of elements in the system. These includereport names, program names, transaction codes, tablenames, and individual key words of a programminglanguage, when surrounded by body text, for exampleSELECT and INCLUDE.

Example text Screen output. This includes file and directory namesand their paths, messages, names of variables andparameters, and passages of the source text of aprogram.

Example text Exact user entry. These are words and characters thatyou enter in the system exactly as they appear in thedocumentation.

<Example text> Variable user entry. Pointed brackets indicate that youreplace these words and characters with appropriateentries.

2007/Q3 © 2007 SAP AG. All rights reserved. iii

About This Handbook NET311

Icons in Body TextThe 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'spresentation.

iv © 2007 SAP AG. All rights reserved. 2007/Q3

ContentsCourse Overview ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Course Goals .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .viiCourse Objectives ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .vii

Unit 1: Introduction..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Web Dynpro Basics.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

Unit 2: Web Dynpro Programming ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31The ABAP Web Dynpro API in Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Dialog Boxes .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Advanced Component Usage .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Personalization .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135

Unit 3: Enhancements ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177Enhancements for ABAP Web Dynpro.. . . . . . . . . . . . . . . . . . . . . . . . . . .178

Appendix 1: Tips & Tricks for efficient Programming ...... . 205

Index ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

2007/Q3 © 2007 SAP AG. All rights reserved. v

Contents NET311

vi © 2007 SAP AG. All rights reserved. 2007/Q3

Course OverviewThis course is the successor of NET310 - ABAP Web Dynpro. It containsadvanced topics related to controller programming, which are not covered by theintroduction course. This includes a detailed discussion of important interfacesthat are provided by the Web Dynpro framework and an overview of how toenhance Web Dynpro applications.

Target AudienceThis course is intended for the following audiences:

� Developers and consultants who would like to create or change complexapplications based on the ABAP Web Dynpro programming model.

Course PrerequisitesRequired 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 GoalsThis course will prepare you to:

� Create complex ABAP Web Dynpro applications.

Course ObjectivesAfter 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.� Define and use configuration, customizing and personalization of Web

Dynpro applications.� Enhance existing Web Dynpro components.

2007/Q3 © 2007 SAP AG. All rights reserved. vii

Course Overview NET311

SAP Software Component InformationThe information in this course pertains to the following SAP Software Componentsand releases:

viii © 2007 SAP AG. All rights reserved. 2007/Q3

Unit 1Introduction

Unit OverviewThis unit summarizes the basics of ABAP Web Dynpro which are explained indetail in the course NET310.

Unit ObjectivesAfter 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 ContentsLesson: Web Dynpro Basics .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

Exercise 1: Create a simple Web Dynpro application .. . . . . . . . . . . . . . . . . 21

2007/Q3 © 2007 SAP AG. All rights reserved. 1

Unit 1: Introduction NET311

Lesson: Web Dynpro Basics

Lesson OverviewThis lessons summarizes the content of course NET310 in short. This includes theWeb Dynpro architecture, Web Dynpro controllers and their constituents and thebasics about Web Dynpro component reuse.

Lesson ObjectivesAfter 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 ExampleYou are a project lead. You would like to ensure, that all of your project membersunderstand the basic concepts and terms related to ABAP Web Dynpro.

Web Dynpro ArchitectureA Web Dynpro application refers to a Web Dynpro component, which serves as acontainer for entities which are related to the user interface or which are related tothe control flow. The component entities and their dependencies are summed up inthe following section.

Internally visible Component EntitiesViews are the basic entities from which the user interface (UI) is derived. Viewsallow to define a rectangular part of the UI (Layout tab) by means of pre-definedUI elements. UI element properties can be defined statically or they can be boundto the view's context. This allows to influence the element properties from thesource code of the view's controller (data binding). In addition, the view controllermethods encapsulate the code for checking the user input, to trigger the navigationvia 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 bevisible for a certain application connected to this window. If combinations ofmultiple views are to be displayed, the views are combined in the window (viewassembly). Windows are used to define the visual flow by creating navigationlinks between the outbound plugs and the inbound plugs of embedded views.

The control flow of a Web Dynpro component is defined in the componentcontroller. From the component controller methods, the database of the localsystem or the functionality of a back-end system is accessed. This is mainly doneby calling methods of a globally defined class (�model�) encapsulating the related

2 © 2007 SAP AG. All rights reserved. 2007/Q3

NET311 Lesson: Web Dynpro Basics

source code. These methods preferably encapsulate open-SQL statements (localDB access), the call of a Web service or the call of a function module in a back-endsystem. The data interchanged between the controller and the �model� can bestored in the �model� (if this global class is instantiated) or in the componentcontroller's context (if the �model� functionality is provided by static methods).

For modularization reasons, custom controllers may be created. These serve assub controllers of the component controller.

Certain parts of a controller's functionality are potentially visible to othercontrollers. This is true for all controllers besides the view controller (MVCprinciple). The controller that needs to access to functionality has to declare theusage of the controller providing the functionality. Then, the complete context, allordinary methods, and all events are visible to the consumer controller. Contextmapping simplifies accessing the context of a used controller by the consumercontroller.

Figure 1: Internally visible component entities

Externally visible Component EntitiesFrom each window a so called interface view is derived. The interface view of agiven window may be embedded in a window of a consumer component as if itwas just a simple view of the consumer component itself.

Inbound plugs of type startup defined for any interface view of a Web Dynprocomponent serve as entry points into this Web Dynpro component accessible bythe Web Dynpro runtime. To use such an entry point, a Web Dynpro applicationhas to be started having the name of the component, of the interface view and ofa startup plug assigned to it.

A URL is assigned to each Web Dynpro application. The related service to call theWD application is defined automatically. This service can be edited and viewedusing transaction SICF.



Functionality of a Web Dynpro component may be offered to other Web Dynprocomponents by means of the component's interface controller. This controller isan interface of the component controller. Methods, events and context nodes ofthe component controller may be declared in a way (flag interface) that they arevisible in the components interface controller.

Figure 2: Externally visible component entities

NavigationNavigation from one view assembly to another view assembly is typicallytriggered 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 therelated view controller by means of an action.

To define which views will make up the next view assembly, one or more outboundplugs can be fired. A view's outbound plug can only be fired from a method of thecorresponding 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 windowvia navigation links. One outbound plug can be connected to multiple inboundplugs. This is meaningful if each inbound plug belongs to a different view andall views together belong to the next view assembly. On the other side, multipleoutbound plugs may be connected to the same inbound plug.

The following graphics display two different realization of a UI displaying two offour possible views in parallel: A1 and B1, A1 and B2, or A2 and B1. By a singlemouse 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. Firingthe plugs PX1 or PY1 will result in interchanging one view only. Firing the plugsPX2 or PY2 will result in interchanging both views, since these outbound plugs areconnected to two inbound plugs of two different views.



Figure 4: Example 1: Changing two views by firing a single outbound plug

In the second example, a better implementation is provided. Here the parametersrelated to the outbound plugs of the views A1 and A2 are used to pass statusinformation to the embedding view View 1 (e.g. which button was pressed bythe user). In the inbound plug method of the embedding view this informationis analyzed and the next view composition is defined by firing the appropriatecombination of outbound plugs related to the embedding view.



Figure 5: Example 2: Define the next state from the outbound plug'sparameter values

Controller MethodsEach of the Web Dynpro controller types contains a set of predefined methodswhich are called by the Web Dynpro runtime. In addition to these so called hookmethods, additional methods can be defined by the developer. These may beordinary methods, event handler methods, or supply functions. Ordinary methodsare the only methods that can be called from other methods of the same controlleror even from other controllers (not valid for view controllers). Supply functionsare connected to a context node and are called by the Web Dynpro frameworkautomatically to fill the context.



Figure 6: Controller methods

All controllers contain the hook methods wddoinit() and wddoexit(). These are thefirst and the last method processed in a controllers lifetime, respectively.

Window controllers contain in addition the two methods wddoonopen() andwddoonclose(), which are called when opening or closing the window as a dialogbox, respectively.

View controllers contain in addition the methods wddobeforeaction() andwddomodifyview(). wddobeforeaction() is called before any action handler method(as a result of a client side event) is processed. This method is used to check theuser input. wddomodifyview() is used for dynamic changes of the UI elementhierarchy.

Custom controllers do not contain additional hook methods.

The component controller contains the additional hook methodswddobeforenavigation() and wddopostprocessing(). wddobeforenavigation() iscalled after the action handler method has been processed and just before theWeb Dynpro framework processes the wddomodifyview() methods of all viewsbelonging to the next view assembly. wddopostprocessing() is the last hookmethod processed before the response is send back to the client.



Figure 7: Standard hook methods: Order of processing

Controller AttributesEach controller contains the predefined attributes WD_THIS and WD_CONTEXTwhich 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 attributeWD_COMP_CONTROLLER will be added to standard attribute list ofthe controller declaring the usage. This attribute is used to access the functionalityof the component controller object at runtime.

If an assistance class is related to a Web Dynpro component, each controller ofthis component will contain an additional attribute WD_ASSIST, that allows toaccess the functionality of the assistance class instance at runtime.

In addition to these standard attributes, the developer may define an arbitrarynumber of attributes. These serve as the controller's globally visible variables. Incontrast to the information kept in the controller context, attributes can not bebound to UI element properties, nor they can be mapped between controllers. Inaddition, there is lot of meta information related to context nodes and contextattributes (cardinality, selection cardinality, singleton property, related supplyfunction ...) not available for controller attributes.



Figure 8: Controller attributes

Controller EventsComponent controller and custom controllers can raise events which may behandled by event handler methods defined in other controllers. Subscribing anevent handler method to an event can be performed statically at design time ordynamically at runtime. An event handler method can belong to any controllerlocated in the same component or even in another component. Controller eventsallow to pass data to the handler method.

Figure 9: Controller events



Component ReuseWeb Dynpro components are reusable modules. This allows you to buildWeb Dynpro applications that consist of different components. From within acomponent, an interface enables you to use the data and functions of anothercomponent. Creating generic components is meaningful since they may be usedby different developers in different contexts.

Figure 10: Component interface

Preparing Component ReuseTo be able to use any component from another (consumer) component, theconsumer 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 donefrom any method of any controller belonging to the consumer component. As aprerequisite, the name of the used component has to be entered in the list of usedcomponents/controllers that can be found on the Properties tab of the controller.



Figure 12: Instantiating a component usage

Embedding Interface ViewsHaving instantiated the component usage, any interface view of the usedcomponent instance may be embedded in a window of the consumer component.Navigation links between inbound and outbound plugs that belong to embeddedviews or embedded interface views can be created.



Figure 13: Embedding interface views

Accessing the Interface Controller of a Component UsageTo be able to access the functionality of a component usage from a controller ofthe consumer component, this controller has to declare the usage of the componentusage's interface controller. Then, methods, events and context nodes visible inthe interface controller of the component usage can be accessed by the controllerin the consumer component.



Figure 14: Calling methods defined in the interface controller

Figure 15: Accessing the interface controller of a used component



Figure 16: Handling events fired in the interface controller

Figure 17: Handling event fired in used Component



Cross Component Context MappingThere are two possibilities to define the mapping between the context node inthe interface controller and an appropriate context node in a controller of theconsumer component:

Normal context mapping:

If the used component has its data stored in a context node defined in the interfacecontroller, each controller of the consumer component may map this context node.To do so, the controller of the consumer component has to declare the interfacecontroller of the used component as a used controller. The context structure canbe copied and the context node can be mapped as if the interface controller wasa controller of the same component (drag & drop).

Figure 18: Normal context mapping: Principle



Figure 19: Normal context mapping: Realization

External context mapping:

More often, data stored in the component controller or a custom controllerof 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 usedcomponent instance has to map a context node located in a controller of theconsumer component. However, it is not possible to change the functionality ofthe interface controller of a used component instance. Thus, the context nodes ofthe used component have to be defined in a very generic manner to allow reusingthe component in different contexts (e.g. display arbitrary tables by the SAPList Viewer component). To define the context mapping between the interfacecontroller of a certain component usage and the controller of the consumercomponent keeping the data, the interface controller of the component usage hasto be edited (see drawing below). Next the controller containing the context nodeto be mapped has to be declared as a used controller for the interface controllerusage. Finally the context mapping between the controllers can be established.



Figure 20: External context mapping: Principle

Figure 21: External context mapping: Realization (1)



Figure 22: External context mapping: Realization (2)



Exercise 1: Create a simple Web Dynproapplication

Exercise ObjectivesAfter completing this exercise, you will be able to:� Proof your basic Web Dynpro knowledge by creating a simple Web Dynpro

application.

Business ExampleYou have to create a complex Web Dynpro application, including the usageof dialog boxes, advanced component reuse, and explicit configuration /personalization. You know the Web Dynpro basics, since you have taken the classNET310. Thus you begin to create your application implementing the techniquesyou learned before.

This application allows the user to enter the key of a flight connection. Afterpressing a button, all related flights are read and displayed on the same screenusing 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 todevelop.

1. Create the package ZNET311_##. Assign the application componentBC-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 inthis window.

1. Create the Web Dynpro component ZNET311_INTR_## with a mainwindow MAIN_WINDOW.

2. Create a Web Dynpro view (name: MAIN_VIEW) inside your component.

3. Embed the view into the window of your component.

Continued on next page



Task 3:In the component controller of your component create two context nodes. Atruntime, one node will hold the user input (connection key), while the other onewill 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 inputfrom the context attributes is to be encapsulated in one method, the code to readthe related flights from the data base and save the flight data in the context is tobe encapsulated in the second method.

To read the flights, the static method READ_FLIGHTS( ) of classCL_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. Addthe 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, andPLANETYPE to the node.

3. Now create an ordinary method GET_USER_INPUT( ), having an exportparameter ES_CONNECTION of type NET311_S_CONNECTION. Read theuser input from the context node CONNECTION and export this connectionkey via the export parameter.

4. Create the ordinary method GET_FLIGHTS( ). From the source codeof this method, call the method GET_USER_INPUT( ). Then pass theconnection key to the static method READ_FLIGHTS( ) defined in classCL_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. Createa table to display the flights. Create a button that triggers reading the flights forthe connection key entered by the user.

1. Copy and map the context nodes defined in the component controller tothe view context.

2. In the view's layout, create a group containing input fields related to theattributes 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 bythe 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 DynproapplicationTask 1:Create a package that will contain all the repository objects you are going todevelop.

1. Create the package ZNET311_##. Assign the application componentBC-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 inthis window.

1. Create the Web Dynpro component ZNET311_INTR_## with a mainwindow MAIN_WINDOW.

a) In the navigation area of the ABAP Workbench, open the context menufor the package and choose Create→ WebDynpro→ WebDynproComponent (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 tothe Window tab.




Task 3:In the component controller of your component create two context nodes. Atruntime, one node will hold the user input (connection key), while the other onewill 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 inputfrom the context attributes is to be encapsulated in one method, the code to readthe related flights from the data base and save the flight data in the context is tobe encapsulated in the second method.

To read the flights, the static method READ_FLIGHTS( ) of classCL_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. Addthe 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 Contexttab.

b) From the context menu of the root node CONTEXT choose Create→ Node. Enter name and type. Press the button Add Attribute fromStructure. Mark CARRID and CONNID. Finish the dialog.

c) Change the value of property Input Help Mode to Automatic for bothattributes.

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, andPLANETYPE to the node.

a) Proceed as described in last step. In addition you have to change thedefault cardinality (1:1) to (0:n).

3. Now create an ordinary method GET_USER_INPUT( ), having an exportparameter ES_CONNECTION of type NET311_S_CONNECTION. Read theuser input from the context node CONNECTION and export this connectionkey via the export parameter.

a) Select the Methods tab. Enter the name of the method in the columnMethod and press Enter. Double click on the method's name to editthe source code.

b) Enter the parameter name in the column Parameter, choose Type =Exporting, and Associated Type = NET311_S_CONNECTION.

c) Source code see below.




4. Create the ordinary method GET_FLIGHTS( ). From the source codeof this method, call the method GET_USER_INPUT( ). Then pass theconnection key to the static method READ_FLIGHTS( ) defined in classCL_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. Createa table to display the flights. Create a button that triggers reading the flights forthe connection key entered by the user.

1. Copy and map the context nodes defined in the component controller tothe view context.

a) Edit the view. Select the Context tab.

b) Drag and drop the nodes CONNECTION and FLIGHTS from thecomponent controller context to the view controller context.

2. In the view's layout, create a group containing input fields related to theattributes CARRID and CONNID of node CONNECTION.

a) Select the Layout tab.

b) Mark the ROOTUIELEMENTCONTAINER. Use the Web Dynpro CodeWizard 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 theWeb DynproCode Wizard to create the table for node FLIGHTS.

4. Create a button to trigger reading the flights for the connection entered bythe 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 thebutton behind the property OnAction to create and assign an action(name: DISP_FLIGHTS).

b) Implement the action handler method for action DISP_FLIGHTS: Callthe 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 DynproApplication) create a Web Dynpro application having the name of yourcomponent. 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.

Comp. Controller: GET_FLIGHTS( )

METHOD get_flights .

DATA: ls_connection TYPE net311_s_connection,

lt_flights TYPE net310_t_sflight,




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 NET311

Unit SummaryYou 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 onSAP NetWeaver Application Server 7.0 and later:

Web Dynpro components having the name WDR_TEST... are applicationsto test the Web Dynpro concepts.

Web Dynpro components having the name WDR_... (without the additionTEST) or WD_... are basis utility components.

� The online documentation (component BC-WD-ABA) provides an excellentdescription of Web Dynpro features, programming techniques, and classreferences.

� The software developer network (SDN - http://sdn.sap.com) offers aknowledge center and a discussion forum for ABAP Web Dynpro.

� FAQs, HowTos, and other frequently referenced materials can be found inWeb Dynpro ABAP WIKI (http://wiki.sdn.sap.com/wiki/display/wdabap).


http://sdn.sap.com

http://wiki.sdn.sap.com/wiki/display/wdabap

Unit 2Web Dynpro Programming

Unit OverviewTo exploit the complete functionality offered by the Web Dynpro frameworkthe developer needs to know what classes and interfaces do exist and how theseclasses and interfaces can be accessed.

The functionality can be divided in two parts: Classes and interfaces that aredefined in the repository statically and controller functionality that reflects themeta data entered by the developer in the ABAP Workbench.

The first lesson of this unit describes how the functionality of a certain controllercan 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 componentsdynamically, and defining / using personalization variants, respectively. In thiscontext the related interfaces are discussed in detail.


� Explain, how the Web Dynpro controller interface is derived from thecontroller's entities

� Describe, how a Web Dynpro controller's functionality can be accessedfrom another controller

� Use the reference variable WD_THIS to access the functionality provided bythe Web Dynpro framework

� 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� Define and implement Web Dynpro component interfaces


Unit 2: Web Dynpro Programming NET311

� Use multiple Web Dynpro components having implemented the same WebDynpro 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 ContentsLesson: The ABAP Web Dynpro API in Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Exercise 2: Check user input and send messages .. . . . . . . . . . . . . . . . . . . . 49Lesson: Dialog Boxes .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Exercise 3: Dialog boxes .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Lesson: Advanced Component Usage.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Exercise 4: Using components with the same component interface 113Lesson: Personalization .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135

Exercise 5: Configuration, customizing and personalization .. . . . . . . .157


NET311 Lesson: The ABAP Web Dynpro API in Detail

Lesson: The ABAP Web Dynpro API in Detail

Lesson OverviewThe knowledge of the classes and interfaces provided by the Web Dynpro runtimeand the relationship between these classes/interfaces is essential for programmingWeb Dynpro applications. This lesson explains in detail what classes/interfaces areprovided and, how these classes/interfaces can be accessed from the controller'ssource code.


� Explain, how the Web Dynpro controller interface is derived from thecontroller's entities

� Describe, how a Web Dynpro controller's functionality can be accessedfrom another controller

� Use the reference variable WD_THIS to access the functionality provided bythe Web Dynpro framework

Business ExampleYou need to define controller source code not provided by Web Dynpro codewizard, e.g. you need to instantiate component usages dynamically or you need todefine 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 functionalityand how these classes can be accessed from the source code of a given controller.

The Controller InterfaceA Web Dynpro controller consists of a number of constituents, e.g. the context,attributes, methods, or properties. Depending on the controller type, some ofthese constituents may be visible to other controllers, while others are privateto the controller.

The abstract definition of the constituents is performed using the Web ApplicationBuilder. From this definition one or more interfaces are derived per controller.These interfaces allow to access the constituents from the controller itself orfrom other controllers located in the same Web Dynpro component. For thecomponent controller it is even possible to define methods, events and contextnodes in a way, so they can be accessed from controllers that belong to anotherWeb Dynpro component.

The functionality defined in the interfaces can be accessed using the standardattributeWD_THIS provided by the Web Dynpro framework.



Figure 23: Displaying the interface of any Web Dynpro controller

Structure of the Controller InterfaceDepending on the controller type (component controller, custom controller,window controller, and view controller), one or two interfaces are generated fromthe definition of the controller constituents:

� All parts of a controller that are not visible to other controllers are stored inan interface having the name IF_<CONTROLLER>. In the following, thisinterface is referred to as the controller's private interface.

� All parts of a controller that are potentially visible to other controllersare stored in an interface having the name IG_<CONTROLLER>.The interface IF_<CONTROLLER> is then embedded in the interfaceIG_<CONTROLLER>. In the following, this interface is referred to as thecontroller's public interface.

� For the component controller, an additional interface isgenerated (IWCI_<COMPONENT> in the SAP name space orZIWCI_<COMPONENT> in the customer name space). This globallyvisible interface is used for cross component communication.



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 ofthe Web Dynpro framework.

� For each ordinary method or event handler method, a related method iscreated in the interface.

� For each attribute defined in the controller, a related attribute is definedin the interface.

� For each context node, a constant WDCTX_<NODE> of type string iscreated. 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 istyped with a ABAP Dictionary type, the structure type equals the ABAPDictionary type. If the node is not typed, the structure type is built from thedirect 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 accessthe public interface (IG_<CONTROLLER>) of the used controller.

� If the interface controller of a component usage is added to the list ofused controllers, related methods for instantiating the component usage(wd_cpuse_...()) and to call it's interface controller (wd_cpifc_...()) aregenerated.



According to the Model View Controller (MVC) paradigm, view controllerskeep all their functionality private. Thus, only one interface (IF_<VIEW> - notvisible to any other controller) is derived from the meta data description of thiskind of controller.

Figure 25: Dynamically generated interface for view controllers

In the following, UML diagrams are used to describe the components of thecontroller interfaces and the dependencies between them.



Figure 26: Generated interface for view controllers

For the window controller, all ordinary methods and all interface componentrelated to context elements are defined in the public interface IG<WINDOW>.For inbound plugs and outbound plugs, the flag public can be checked by thedeveloper. However, this has no effect on the interface in which the relatedcomponents are defined. All methods related to outbound plugs are always definedin the interface IG<WINDOW>, while the event handler methods related to theinbound 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 windowcontroller interfaces. However, instead of inbound plugs and outbound plugs,custom controllers have event handlers and events. The methods used to firethe events or to handle an event are always defined in the controller interfaceIF<CUST_CTRL>.



Figure 28: Generated interfaces for custom controllers

The component controller interface consists of the interface IF_COMPO-NENTCONTROLLER, the interface IG_COMPONENTCONTROLLER and theglobally visible interface (Z)IWCI_<COMPONENT>. Controllers defined inthe same component may access the functionality defined in the interfacesIG_COMPONENTCONTROLLER and (Z)IWCI_<COMPONENT>. Controllersdefined 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 visibleto other components (flag Interface). However, only ordinary methods having thisflag set are defined in the global interface. All other ordinary methods and publicattributes are defined in the public interface IG_COMPONENTCONTROLLER.

From the source code of the component controller it is also possible to accessWeb Dynpro framework functionality by means of the embedded static interfaceIF_WD_CONTROLLER. This will be discussed in detail below.



Figure 29: Generated and static interfaces for component controllers

The Web Dynpro APIIn the last section the dynamically generated interfaces of Web Dynpro controllershave been discussed. These contain components that result from the developersmeta data definition in the Web Application Builder. However, the Web Dynproframework provides additional functionality that does not depend on thedevelopers input. This includes the possibility to handle messages, to fire portalevents, to define new or change existing context elements, to access parametersrelated 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 APIrelated to this kind of controller and (via embedded interfaces) to the component'sAPI.

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 thiscontroller.

Depending on the controller type, the reference returned by the methodwd_get_api( ) is of type IF_WD_COMPONENT (component controller),IF_WD_VIEW_CONTROLLER (view controller and window controller), orIF_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_CONTROLLERand IF_WD_COMPONENT.

IF_WD_VIEW_CONTROLLER contains additional functionality only relevantfor view controllers and window controllers. IF_WD_COMPONENT containsfunctionality not related to a certain controller but to the component.



Figure 31: Web Dynpro API for view / window controllers

Figure 32: Web Dynpro API for custom controllers



Figure 33: Web Dynpro API for component controllers

In the following, the most important methods of the interfaceIF_WD_CONTROLLER are summed up:

get_action( )Returns an interface reference of type IF_WD_ACTION. Used to read andredefine action properties.

Hint: This method can only be called from view controller methods.

get_component( )Returns an interface reference of type IF_WD_COMPONENT. Containedmethods 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 followingmethod calls return the same interface reference:- WD_COMP_CONTROLLER->wd_get_api()- WD_THIS->wd_get_api()->get_component()



get_context( )Returns an interface reference of type IF_WD_CONTEXT. The relatedobject describes the context of the controller (mata data and context data).Contained methods allow to read or change the context structure, to accessthe 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. Allowsto 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 stackor 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 personalizationvariants.

Hint: This functionality is not accessible from view controllers orfrom window controllers.

In the following, the most important methods of the interfaceIF_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. Thisinterface is used to create modal popups or external dialog screens.

get_component_info( )Returns an interface reference of type IF_WD_RR_COMPONENT. TheInterface contains methods to access the meta data description of thecomponent and all included entities.

get_portal_manager()Returns an interface reference of type IF_WD_PORTAL_INTEGRATION. Itallows to access information about the portal type and version embeddingthe WD application. The interface contains methods which have to be usedto access the portal functionality (e.g. portal eventing).



add_event_handler()This method allows to dynamically register an event handler method definedin one controller for an event defined in another controller of the samecomponent or a used component.

remove_event_handler()This method allows to delete any dynamically defined registration of anevent 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 thatare defined dynamically. The methods create_cmp_usage_group()and get_cmp_usage_group() are used to create and access sucha component usage group (returning interface reference oftype IF_WD_COMPONENT_USAGE_GROUP). The methodhas_cmp_usage_group() returns, whether the component usage group hasalready been created (returning type boolean).

cancel_navigation()This method can be used to prevent the navigation for the completeapplication (or for the window of a used component displayed as a dialogbox if cancel_navigation( ) is called from this used component).wddobeforenavigation( ) is the last hook method processed before thenavigation takes place. Thus, cancel_navigation( ) has to be called beforethe processing of the hook method wddobeforenavigation( ) is finished.

get_application()Returns an interface reference of type IF_WD_APPLICATION. Containedmethods allow to access the meta data description of the application.

Finally, the Web Dynpro runtime allows to access view specific functionality bymeans of the interface IF_WD_VIEW_CONTROLLER. This interface is returnedby the method wd_get_api() for both, view controllers and window controllers.However, some methods may not be used from window controllers as describedbelow:

fire_plug( )This method allows to fire any plug. The plug's name is to be passed as astring.



get_embedding_window_ctlr( )This method checks if the actual view / window is embedded in anotherwindow. The reference to the embedding window is returned (interfacereference of type IF_WD_WINDOW_CONTROLLER). Contained methodsallow 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 anotherwindow, the returned reference is initial.

If a window is displayed as a modal dialog box, then the methodget_window() called for this window returns a reference to an object of typeIF_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 referencereturned by method get_window( ) is initial.Example:View V is embedded in window A. This window is embedded (as aninterface view) in window B. Window B is send as a dialog box.Calling method get_embedding_window_ctlr( ) for view V willreturn a reference to window A. Method get_window() calledfor this reference will return an initial value. Calling methodget_embedding_window_ctlr( ) a second time for the referenceto window A will return a reference to window B. Methodget_window() called for this reference will now return the referenceto the dialog box functionality of window B.

get_view_info( )Returns an interface reference of type IF_WD_RR_VIEW. Contained methodallow to access the meta data description of the view controller (e.g. viewname, life span, description).

request_focus()Allows to set the focus in the client representation to a certain UI element, ifthis UI element has it's value property bound to a context attribute.

Hint: This method can not be called from a window controller.



request_focus_on_action()Allows to set the focus in the client representation on a certain UI element, ifthis UI element has the event property on_... bound to an action.


get_current_action()Returns an interface reference of type IF_WD_ACTION. Allows to find outwhich client side event was fired by the user of the application. Typicallyused in the method wddobeforeaction() of the related view.


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 isnecessary, if component usages are defined and instantiated at runtime.Then, the inbound plugs of the related interface views are not existent atdesign time, which is the prerequisite to define static navigation links.



Exercise 2: Check user input and sendmessages

Exercise ObjectivesAfter completing this exercise, you will be able to:� Define controller attributes and access them from other controllers.� Send messages.

Business ExampleIn your Web Dynpro application you have to implement the validation of the userinput. 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 changescan 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 thetemplate component. In this case, copy the template component and name thecopy ZNET311_API_##. Assign this component to your package ZNET311_##.Create an application having the same name as your component and assign theapplication 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 enteredby the user is valid.

To read a single connection for a given connection key, the static methodREAD_CONNECTIONS( ) of class CL_NET310_FLIGHTMODEL is to beused.

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 componentcontroller. This method will contain the source code to validate the userinput.




2. Define a returning parameter (name: E_CONNECTION_EXISTS) of typestring.

3. Call the method GET_USER_INPUT( ) to get the connection key enteredby the user.

4. Call the static method READ_CONNECTIONS( ) of classCL_NET310_FLIGHTMODEL to read the complete connection data set forthe connection key entered by the user.

5. If the connection data set could be read by the static method, set thereturning parameter to ABAP_TRUE, otherwise evaluate the parameter withABAP_FALSE.

Task 3:Define a controller attribute in the component controller to store the referenceto the message manager. Make sure that this reference variable is visible to allother controllers of your component.

Get the reference to the message manager in the methodWDDOINIT( ) of thecomponent controller.

1. Define a controller attribute in the component controller to store the referenceto the message manager. Make sure that this reference variable is visible toall 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 assistanceclass CL_NET311_ASSIST to your component.

1. Assign the assistance class to your component.

Task 5:Now edit the methodWDDOBEFOREACTION( ) of the view controller. If theuser has triggered the action DISP_FLIGHTS (assigned to the button), then thecomponent controller method CHECK_CONNECTION( ) has to be called. If theconnection is not valid, an error message hat to be send. Look for an appropriatemessage text in the assistance class.

1. Get the reference to the current action by calling the methodGET_CURRENT_ACTION( ) of the view controller API.




2. Check whether the reference to the current action is bound. Stop processingthe method, if the reference to the action object is not bound.

Hint: In some situations a round trip can take place without havingtriggered 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 thepublic attribute NAME. If this value equals the name of the action assignedto the button with the label Display Flights (DISP_FLIGHTS), call thecomponent controller method CHECK_CONNECTION( ).

4. Check the returning parameter of method CHECK_CONNECTION( ). If theconnection does not exist, read the text with id 001 from the text pool of theassistance 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 attributeWD_COMP_CONTROLLER, whatother possibility does exist to access the API of the component controllerfrom a view controller?



Solution 2: Check user input and sendmessagesTask 1:If you have finished the previous exercise, you can skip this task. Then, all changescan 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 thetemplate component. In this case, copy the template component and name thecopy ZNET311_API_##. Assign this component to your package ZNET311_##.Create an application having the same name as your component and assign theapplication to your package, too.


a) Display the template component in the object tree. Clicking on thecomponent with the right mouse button will open the component'scontext menu. Choose Copy.... Enter the name of the component to becreated. Press Continue.

b) Adapt the description of the new component.


a) An application having the same name as the component can be createdfrom the context menu of the component.

Task 2:Create a component controller method that checks if the connection key enteredby the user is valid.

To read a single connection for a given connection key, the static methodREAD_CONNECTIONS( ) of class CL_NET310_FLIGHTMODEL is to beused.

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 componentcontroller. This method will contain the source code to validate the userinput.

a) Edit the component controller of your component. Select theMethodstab. 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 typestring.

a) Parameters are defined by entering name, type, and associated type inthe corresponding fields above the source code.

3. Call the method GET_USER_INPUT( ) to get the connection key enteredby the user.

a) Source code see below.

4. Call the static method READ_CONNECTIONS( ) of classCL_NET310_FLIGHTMODEL to read the complete connection data set forthe connection key entered by the user.


5. If the connection data set could be read by the static method, set thereturning parameter to ABAP_TRUE, otherwise evaluate the parameter withABAP_FALSE.


Task 3:Define a controller attribute in the component controller to store the referenceto the message manager. Make sure that this reference variable is visible to allother controllers of your component.

Get the reference to the message manager in the methodWDDOINIT( ) of thecomponent controller.

1. Define a controller attribute in the component controller to store the referenceto the message manager. Make sure that this reference variable is visible toall other controllers of your component.

a) In the component controller, select the tab Attributes. Definea reference variable (name: GR_MESS_MAN) of typeIF_WD_MESSAGE_MANAGER. Check the property PUBLIC.

2. Get the reference to the message manager in the methodWDDOINIT( )of the component controller.





Task 4:All texts displayed as messages have to be translatable. Thus, assign the assistanceclass 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 classin the corresponding field. Save.

Task 5:Now edit the methodWDDOBEFOREACTION( ) of the view controller. If theuser has triggered the action DISP_FLIGHTS (assigned to the button), then thecomponent controller method CHECK_CONNECTION( ) has to be called. If theconnection is not valid, an error message hat to be send. Look for an appropriatemessage text in the assistance class.

1. Get the reference to the current action by calling the methodGET_CURRENT_ACTION( ) of the view controller API.


2. Check whether the reference to the current action is bound. Stop processingthe method, if the reference to the action object is not bound.

Hint: In some situations a round trip can take place without havingtriggered 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 thepublic attribute NAME. If this value equals the name of the action assignedto the button with the label Display Flights (DISP_FLIGHTS), call thecomponent controller method CHECK_CONNECTION( ).


4. Check the returning parameter of method CHECK_CONNECTION( ). If theconnection does not exist, read the text with id 001 from the text pool of theassistance 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 attributeWD_COMP_CONTROLLER, whatother possibility does exist to access the API of the component controllerfrom a view controller?




Answer: The related code is commented in the source code of methodWDDOBEFOREACTION( ) 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( ).

* get message manager

wd_this->gr_mess_man = lr_current_controller->get_message_manager( ).

ENDMETHOD.




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 sectionReference→Programming Interfaces of the Web Dynpro ABAP onlinedocumentation.



Lesson: Dialog Boxes

Lesson OverviewABAP Web Dynpro allows to send windows as dialog boxes. These dialog boxescan be modal (window containing the element that was clicked to open the popupis locked) or external (independent from the window containing the elementclicked on). This lesson describes how to define and how to handle dialog boxes.


� Create external dialog boxes� Create confirmation dialog boxes� Create modal dialog boxes to display windows of the same or another


boxes

Business ExampleYou are developing a Web Dynpro application. In this context you would like toimplement dialog boxes.

OverviewDialog boxes are used to display concrete information or possible settings in aview popping up on top of the browser window the user clicked on. After thedialog has been exited, either the browser window underneath becomes activeagain 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 bemoved around the screen independently of the original window. Externaldialog boxes are generally modeless.

� Modal dialog box:

A modal dialog box is opened in the current browser window. The modaldialog box may display a window of the same component, the interface viewof a used component, or a confirmation dialog.


NET311 Lesson: Dialog Boxes

Dialog boxes are implemented within a Web Dynpro application via an additionalwindow and are generally called by the event handler of an action. If necessaryhowever, all other controller methods can be used. The component controllercontains the interface IF_WD_WINDOW_MANAGER, with which a newwindow for the content of the dialog box can be created and opened.

Figure 34: Accessing the interface IF_WD_WINDOW_MANAGER



Figure 35: Accessing the interface IF_WD_WINDOW_MANAGER (ifcomponent controller is used controller)

The following UML diagram displays the components of interfaceIF_WD_WINDOW_MANAGER. Using the interface methods to generate dialogboxes is explained in the following sections.

Figure 36: Components of the interface IF_WD_WINDOW_MANAGER



Figure 37: Components of the interface IF_WD_WINDOW

External Dialog Box

Figure 38: External dialog box

To create an external dialog box, the method create_external_window( ) of theinterface IF_WD_WINDOW_MANAGER is used. This method's parameter allowto set the window title and the URL of the object to be displayed in the dialog box.



In addition there exist boolean parameters to display or hide the browser's menubar, scroll bars, status bar, tool bar and address bar. Finally, the develop can decidewhether the browser window should be resizable or not.

The method create_external_window( ) returns a reference of typeIF_WD_WINDOW. This reference to the dialog box object allows to open andclose the dialog box, to set its position and size and its title. For modal dialog boxesthere is even more functionality which is described in the related section below.

Figure 39: Creating an external dialog box: Source code



Modal Dialog BoxesThere are three different kinds of modal dialog boxes, that can be implementedwith ABAP Web Dynpro:

1. Confirmation dialog box:

This dialog box is used to display simple texts in a window with astandardized set of buttons to define the next step.

2. Dialog box displaying a window of the same component:

This dialog box can be used to display any window of the same componentas a popup. The content is arbitrary. Buttons to trigger the next step can bechosen from a set of predefined button combinations.

3. Dialog box displaying a window of a used component:

This dialog box can be used to display any interface view of a usedcomponent as a popup.

Confirmation Dialog Box

Figure 40: Confirmation dialog box

A confirmation dialog box is a modal popup displaying an arbitrary text.



In order to generate a confirmation dialog box, the method create_popup_to_con-firm( ) of the interface IF_WD_WINDOW_MANAGER has to be called.Parameters allow to set the text to be displayed by the confirmation dialog box andits title. Optionally, an icon can be displayed on the left side of the text indicatingits significance (e.g. warning).

The buttons to be displayed can by chosen from a predefined set of buttoncombinations, one of these buttons can be defined as the default button. Finally,the popup's close button in the upper right corner can be displayed or hidden.

Figure 41: Confirmation dialog box: Where to put the code



Figure 42: Creating a confirmation dialog box: Source code

To close the confirmation dialog box, any button displayed on the popup can beused (and - if displayed - the popup's close button). To each of the button clicks, acertain action can be assigned. By this mean, coding located in different actionhandler methods can be processed depending on the user action.

To define which action is to be related to which button, the methodwd_comp_controller->gr_window->subscribe_to_event( ) has to be called oncefor each button displayed on the dialog box. Here gr_window is the reference tothe dialog box object, stored as a public attribute in the component controller.

Hint: Trying to register an action to a button not displayed on the dialogbox will lead to a dump.

Hint: The parameter WDEVENT->NAME of the action handler methodcontains the name of the button the user has pressed. This allows to handlemultiple button clicks by a common action handler method.

Hint: The standard button texts (e.g. Cancel, Yes, No...) can be changedby the method subscribe_to_button( ) (parameter BUTTON_TEXT).



Figure 43: Confirmation dialog box: Event handling

Dialog Box displaying a Window of the same Component

Figure 44: Dialog box displaying window of same component



In order to display a window of the same component as a dialog box, the methodcreate_window( ) of the interface IF_WD_WINDOW_MANAGER has to be called.Parameters allow to define, which window of the same component is to bedisplayed as a modal dialog box. The title of the modal dialog box can be set.

The buttons to be displayed can by chosen from a predefined set of buttoncombinations, one of these buttons can be defined as the default button. Thepopup's close button in the upper right corner can be displayed or hidden.

Optionally, an icon can be displayed on the left side of the dialog box indicatingthe significance of the content (e.g. information).

If the parameter CLOSE_IN_ANY_CASE is set to ABAP_FALSE and actionshave been assigned to the buttons displayed in the window, the dialog box is notautomatically closed if the user presses any button. To close the dialog box, themethod wd_comp_controller->gr_window->close( ) has to be used (gr_window isa public component controller attribute that contains the reference to the dialogbox object).

The parameter MESSAGE_DISPLAY_MODE allows to define, which messagesare to be displayed in the dialog box. It is possible to display all message, to hideall messages and to display only messages related to the popup.

Hint: For the last case the Web Dynpro framework has to be able to decidewhich message is related to which view. This is possible if the message isrelated to a context attribute or if the name of the view is passed to themethod that is called to report the message (interface parameter view).



Figure 45: Dialog box displaying window of same component: Where toput the code

Figure 46: Creating a dialog box displaying window of same component:Source code



To each of the buttons displayed by the dialog box a certain action can beassigned. However, the window object does not contain actions and action handlermethods. Thus, a view displayed by this popup window has to care for the eventhandling. Registering an action for a button click is typically performed in thehook method wddoinit( ) of the view that contains the actions. The methodsubscribe_to_button_event( ) is used to register an action to a certain button. Fordetails please refer to the section about confirmation dialog boxes.

Figure 47: Dialog box displaying window of same component: Eventhandling



Dialog Box displaying a Window of a used Component

Figure 48: Dialog box displaying window of used component

In order to display a window of a used component as a dialog box, the methodcreate_window_for_cmp_usage( ) of the interface IF_WD_WINDOW_MANAGERhas to be called.

The name of the used component and the name of its interface view to be displayedas a dialog box has to be defined by setting the related interface parameters of themethod create_window_for_cmp_usage( ).

If the parameter CLOSE_IN_ANY_CASE is set to ABAP_FALSE, the dialog boxis not automatically closed if the user presses any button. To close the dialogbox, the method wd_comp_controller->gr_window->close( ) has to be used(gr_window is a public component controller attribute that contains the referenceto the dialog box object).

The parameter MESSAGE_DISPLAY_MODE allows to define, which messagesare to be displayed in the dialog box. It is possible to display all message, to hideall messages and to display only messages related to the popup.

Hint: For the last case the Web Dynpro framework has to be able to decidewhich message is related to which view. This is possible if the message isrelated to a context attribute or if the name of the view is passed to themethod that is called to report the message (interface parameter view).

Finally, the title of the dialog box can be defined.



Figure 49: Dialog box displaying window of used component: Where toput the code

Figure 50: Creating a dialog box displaying window of used component:Source code



All dialog box settings not mentioned in the last paragraph (buttons to bedisplayed, default button, visibility of popup's close button, ...) have to be definedin appropriate controller methods of the window to be displayed as a dialog box.For this reason, the window controller has two methods that are only processedif the window is displayed as a dialog box: wddoonopen( ) (before opening thedialog box) and wddoonclose( ) (before closing the dialog box).

Hint: The window's inbound plug method can not be used to encapsulatethe code, since opening a window as a dialog box does not involvenavigation requests.

The signature of the window controller methodwddoonopen( ) contains a parameterWINDOW_DESCR (reference type IF_WD_WINDOW_DESCRIPTION). Fromthis parameter, the popup functionality can be accessed using the attributeWINDOW (reference type IF_WD_WINDOW).

Figure 51: Dialog box displaying window of used component: Define popupsettings at WDDOONOPEN()

Registering an action for a button click is performed as described in the lastsection �Dialog Box displaying a Window of the same Component�.

To interchange data between the consumer component and the used componentcontaining the popup window, external context mapping can be used. A secondway of passing data from the consumer component to the used component is to



call a method defined in its interface controller. Passing data back to the consumercomponent can be implemented by raising an event defined in the interfacecontroller using the event parameters. A method defined in any controller of theconsumer component may then be registered for this event.



Exercise 3: Dialog boxes

Exercise ObjectivesAfter completing this exercise, you will be able to:� Send windows defined in same component as modal dialog boxes.� Define buttons in a modal dialog box and handle clicking these buttons.

Business ExampleThe user of your application should be able to display bookings related to aselected flight. The bookings should be displayed in a modal dialog box.

Template Component: NET311_API_S

Solution Component: NET311_WINDOW_S


If you have not finished your last exercise, you can start with a copy of thetemplate component. In this case, copy the template component and name the copyZNET311_WINDOW_##. Assign this component to your package ZNET311_##.Create an application having the same name as your component and assign theapplication to your package, too.



Task 2:The table displaying the flights allows to select a single line. Marking this linetriggers a round trip. The component controller has to be changed in a way,that bookings related to the selected flights are read and stored in the controllercontext, automatically.

1. In the component controller context, define a new node BOOKINGS oftype SBOOK as a sub node of the node FLIGHTS. The node BOOKINGShas to contain the attributes BOOKID, CUSTOMID, CUSTTYPE, SMOKER,CLASS, FORCURAM, FORCURKEY, and ORDER_DATE.

2. Assign a supply function (name: GET_BOOKINGS( )) to the nodeBOOKINGS.




3. Implement the supply function. Bookings for a given flight shouldbe read using the static method READ_BOOKINGS( ) of classCL_NET310_FLIGHTMODEL.

Task 3:The bookings are to be displayed by a separate view embedded in a new window.This window has to be displayed as a modal dialog box.

1. Create a new view (name: POPUP_VIEW). Copy and map the contextnode BOOKINGS defined in the component controller to the context ofthe new view.

2. Use the Web Dynpro Code Wizard to create a table View UI elementdisplaying the bookings. Restrict the number of lines displayed by the tableto 10. Hide the column to select table lines.

3. Create a new window (POPUP_WINDOW). Embed the view POPUP_VIEWin this window.

Task 4:The window POPUP_WINDOW has to be displayed when the user selects aflight. Thus create an action in the view MAIN_VIEW. Assign this action tothe event onLeadSelect of the table displaying the flights. In the related actionhandler method create and open a modal dialog box for displaying the windowPOPUP_WINDOW.

Because the reference to the created popup is accessed in different methods ofdifferent controllers, this reference should be stored as a public attribute of thecomponent controller.

1. Create a public attribute (name: GR_WINDOW) of reference typeIF_WD_WINDOW in the component controller of your component.

2. Create a new action (name: DISP_DETAILS) in view MAIN_VIEW. Assignthis action to the event onLeadSelect of the table displaying the flights.

3. Implement the action handler method ONACTIONDISP_DETAILS( ):

- Get a text displayed as the title of the dialog box from the assistance class.

Get the reference to the window manager.

Call the appropriate method for sending a window of the same component asa modal dialog box.

Store the reference to the created popup in the corresponding attribute of thecomponent controller.

Finally, display the modal dialog box.




The following settings should be used for the dialog box:

- The OK button should be displayed exclusively. This button should bedefined as the default button.

- The Close button of the window (right upper corner) should not be visible.

- Pressing theOK button should not close the modal dialog box automatically.

- An extra image left of the tableView UI element (indicating the severity ofthe information displayed in the popup) is not desired.

- Use constants of the interface IF_WD_WINDOW to evaluate the parametersof this method whenever possible.

Task 5:Up to now, pressing the OK button in the modal dialog box is not related to specialcode. To change this, the following steps are necessary:

In the view POPUP_VIEW a new action has to be defined. This action has to beassigned to the event �pressing the OK button�. Finally, the action handler methodhas to be implemented: If theOK button is pressed, the dialog box has to be closed.

The references to the view controller API of view POPUP_VIEW is accessedmultiple times. Thus it is a good idea to create a controller attribute in the viewPOPUP_VIEW to store this reference. The value of this attribute should bedetermined in the method WDDOINIT( ) of the view controller.

1. Create the action OK_BUTTON_ACTION in the view POPUP_VIEW.

2. Create the method REGISTER_BUTTONS( ) in the view POPUP_VIEW.

3. Create a controller attribute in the view POPUP_VIEW. At runtime, thisattribute (name: GR_VIEW_API) should contain the reference to the viewcontroller API (interface IF_WD_VIEW CONTROLLER).

4. Set the value of the controller attribute GR_VIEW_API in the methodWDDOINIT( ) of view POPUP_VIEW.

5. Call the method REGISTER_BUTTONS( ) from the method WDDOINIT() of view POPUP_VIEW.

6. Implement the method REGISTER_BUTTONS( ):

Register the action OK_BUTTON_ACTION for the event �pressing the OKbutton�.

7. Implement the handler method of action OK_BUTTON_ACTION:

Check the name of the user event by checking the value of the publicattribute WDEVENT->NAME. Close the modal dialog box, if this valuecorresponds to the value expected for the OK button (value: ON_OK).



Solution 3: Dialog boxesTask 1:If you have finished the previous exercise, you can skip this task. Then, all changescan 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 thetemplate component. In this case, copy the template component and name the copyZNET311_WINDOW_##. Assign this component to your package ZNET311_##.Create an application having the same name as your component and assign theapplication to your package, too.






Task 2:The table displaying the flights allows to select a single line. Marking this linetriggers a round trip. The component controller has to be changed in a way,that bookings related to the selected flights are read and stored in the controllercontext, automatically.

1. In the component controller context, define a new node BOOKINGS oftype SBOOK as a sub node of the node FLIGHTS. The node BOOKINGShas to contain the attributes BOOKID, CUSTOMID, CUSTTYPE, SMOKER,CLASS, FORCURAM, FORCURKEY, and ORDER_DATE.

a) Edit the component controller. Select the tab Context. Rightmouse-click on the node FLIGHTS. In the context menu, choose Create→ Node.

b) Enter name and type. Change the Cardinality property to (0:n).

c) Press the button Add Attribute from Structure. Select the structurefields listed above and press Continue.




2. Assign a supply function (name: GET_BOOKINGS( )) to the nodeBOOKINGS.

a) Enter the method's name in the related property field of the contextnode and press Enter.

3. Implement the supply function. Bookings for a given flight shouldbe read using the static method READ_BOOKINGS( ) of classCL_NET310_FLIGHTMODEL.


Task 3:The bookings are to be displayed by a separate view embedded in a new window.This window has to be displayed as a modal dialog box.

1. Create a new view (name: POPUP_VIEW). Copy and map the contextnode BOOKINGS defined in the component controller to the context ofthe new view.

a) Proceed as described in exercises you have solved before. Do not mapthe node FLIGHTS, but only the sub node BOOKINGS.

2. Use the Web Dynpro Code Wizard to create a table View UI elementdisplaying the bookings. Restrict the number of lines displayed by the tableto 10. Hide the column to select table lines.

a) Proceed as described in exercises you have solved before. Thenumber of lines displayed by the table is defined by the propertyvisibleRowCount. Setting the property selectionMode to none willhide the mark column.

3. Create a new window (POPUP_WINDOW). Embed the view POPUP_VIEWin this window.

a) Proceed as described in exercises you have solved before.




Task 4:The window POPUP_WINDOW has to be displayed when the user selects aflight. Thus create an action in the view MAIN_VIEW. Assign this action tothe event onLeadSelect of the table displaying the flights. In the related actionhandler method create and open a modal dialog box for displaying the windowPOPUP_WINDOW.

Because the reference to the created popup is accessed in different methods ofdifferent controllers, this reference should be stored as a public attribute of thecomponent controller.

1. Create a public attribute (name: GR_WINDOW) of reference typeIF_WD_WINDOW in the component controller of your component.

a) Edit the component controller. Select the Attributes tab. Enter nameand type of the attribute in the fields Attribute and Associated Type,respectively. Mark the property RefTo.

2. Create a new action (name: DISP_DETAILS) in view MAIN_VIEW. Assignthis action to the event onLeadSelect of the table displaying the flights.

a) Edit the properties of the tableView UI element of view MAIN_VIEW.Create the action and assign it to the event onLeadSelect of thetableView UI element in one step. This is done by clicking the Createbutton right of the property onLeadSelect. In the dialog that pops up,enter the action name in the field with the label Action.

3. Implement the action handler method ONACTIONDISP_DETAILS( ):

- Get a text displayed as the title of the dialog box from the assistance class.

Get the reference to the window manager.

Call the appropriate method for sending a window of the same component asa modal dialog box.

Store the reference to the created popup in the corresponding attribute of thecomponent controller.

Finally, display the modal dialog box.

The following settings should be used for the dialog box:

- The OK button should be displayed exclusively. This button should bedefined as the default button.

- The Close button of the window (right upper corner) should not be visible.

- Pressing theOK button should not close the modal dialog box automatically.

- An extra image left of the tableView UI element (indicating the severity ofthe information displayed in the popup) is not desired.




- Use constants of the interface IF_WD_WINDOW to evaluate the parametersof this method whenever possible.

a) The text id you should use is 002.

The correct method to create this kind of window isCREATE_WINDOW( ).


Task 5:Up to now, pressing the OK button in the modal dialog box is not related to specialcode. To change this, the following steps are necessary:

In the view POPUP_VIEW a new action has to be defined. This action has to beassigned to the event �pressing the OK button�. Finally, the action handler methodhas to be implemented: If theOK button is pressed, the dialog box has to be closed.

The references to the view controller API of view POPUP_VIEW is accessedmultiple times. Thus it is a good idea to create a controller attribute in the viewPOPUP_VIEW to store this reference. The value of this attribute should bedetermined in the method WDDOINIT( ) of the view controller.

1. Create the action OK_BUTTON_ACTION in the view POPUP_VIEW.

a) Enter the action name in the field Action on tab Actions.

2. Create the method REGISTER_BUTTONS( ) in the view POPUP_VIEW.


3. Create a controller attribute in the view POPUP_VIEW. At runtime, thisattribute (name: GR_VIEW_API) should contain the reference to the viewcontroller API (interface IF_WD_VIEW CONTROLLER).

a) Select the Attributes tab. Enter name and type of the attribute in thefields Attribute and Associated Type, respectively. Mark the propertyRefTo.

4. Set the value of the controller attribute GR_VIEW_API in the methodWDDOINIT( ) of view POPUP_VIEW.


5. Call the method REGISTER_BUTTONS( ) from the method WDDOINIT() of view POPUP_VIEW.











Result

Comp. Controller: GET_BOOKINGS( )

METHOD get_bookings .

DATA: ls_flights TYPE if_componentcontroller=>element_flights,

lt_bookings TYPE net310_t_sbook.

* Key fields for selected flight

parent_element->get_static_attributes(

IMPORTING

static_attributes = ls_flights ).

* Read bookings

CALL METHOD cl_net310_flightmodel=>read_bookings

EXPORTING

i_carrid = ls_flights-carrid

i_connid = ls_flights-connid

i_fldate = ls_flights-fldate

IMPORTING

e_bookings = lt_bookings.

* Store bookings in context

node->bind_table( lt_bookings ).

ENDMETHOD.

MAIN_VIEW Controller: ONACTIONDISP_DE-TAILS( )

method onactiondisp_details.

data: lr_window_manager type ref to if_wd_window_manager,




lr_cmp_api type ref to if_wd_component,

lv_text type string.

* Read text from assistance class


* Create modal dialog box sending window of own component

lr_cmp_api = wd_comp_controller->wd_get_api( ).

lr_window_manager = lr_cmp_api->get_window_manager( ).

wd_comp_controller->gr_window

= lr_window_manager->create_window(

window_name = 'POPUP_WINDOW'

title = lv_text

close_in_any_case = abap_false

message_display_mode = if_wd_window=>co_msg_display_mode_selected

close_button = abap_false

button_kind = if_wd_window=>co_buttons_ok

message_type = if_wd_window=>co_msg_type_none

default_button = if_wd_window=>co_button_ok ).

* Open dialog box

wd_comp_controller->gr_window->open( ).

endmethod.

POPUP_VIEW Controller: WDDOINIT( )

METHOD wddoinit .

* get view api, save reference as controller attribute

wd_this->gr_view_api = wd_this->wd_get_api( ).

wd_this->register_buttons( ).

ENDMETHOD.

POPUP_VIEW Controller: REGISTER_BUTTONS( )

METHOD register_buttons .

* pressing of OK button will trigger action OK_BUTTON_ACTION in same view

wd_comp_controller->gr_window->subscribe_to_button_event(

button = if_wd_window=>co_button_ok

action_name = 'OK_BUTTON_ACTION'




action_view = wd_this->gr_view_api ).

ENDMETHOD.

POPUP_VIEW Controller: ONACTIONOK_BUT-TON_ACTION( )

METHOD onactionok_button_action .

* close window only if OK button was pressed

CASE wdevent->name.

WHEN 'ON_OK'.

wd_comp_controller->gr_window->close( ).

ENDCASE.

ENDMETHOD.



Lesson Summary

You should now be able to:� Create external dialog boxes� Create confirmation dialog boxes� Create modal dialog boxes to display windows of the same or another


boxes



Lesson: Advanced Component Usage

Lesson OverviewIn this lesson, the dynamic reuse of ABAP Web Dynpro components is discussed.This includes reusing components having the same component interface andreusing the same Web Dynpro component multiple times.


� Define and implement Web Dynpro component interfaces� 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.

Business ExampleYou have to develop a big application consisting of a large number of WebDynpro components. However, depending on the user's actions only a subset ofthese components need to be instantiated. While programming you encounteredthe following problems:

1. Some of the components that are to be used alternatively have an identicalcomponent interface. You ask yourself if there is the possibility to defineand implement component interfaces. In addition you are interested if it ispossible to use this interface as the name of a used component, so you donot have to know at design time, which of the component implementing thesame component interface is instantiated at runtime. This is especially usefulif the component to be used should be defined via configuration.

2. For some of the components you do not know, how many componentusages you will need at runtime. So you would like to know how to clonecomponents at runtime and how to define navigation and event handlingfor these component usages.

OverviewWeb Dynpro components are built in a way, so they can be reused by othercomponents. This includes the components functionality (as defined in theinterface controller) and the complete user interface (by means of the component'sinterface views).


NET311 Lesson: Advanced Component Usage

There are two scenarios of how components can be combined:

� Scenario 1: The same functionality is used by multiple main components.� Scenario 2: Depending on configuration, user interaction, or program status,

different components could be reused by a given main component.

Figure 52: Web Dynpro component usage

For scenario 1, a service component is developed which is then reused by anarbitrary number of other consumer components. Examples: SAP List Viewer forABAP Web Dynpro, OVS (object value selector).

For scenario 2, there are different possible ways of how to implement thecomponent usage:

If the number of possible component usages is not too big and all componentnames are known at design time, the consumer component can declare componentusages for all components that may be needed at runtime. At runtime only thecomponent usage that is needed will be instantiated.

If a component is to be reused, the name is not known, but the implementedcomponent interface, the consumer component only has to declare a usage of thecomponent's interface. At runtime, any component implementing this componentinterface can be instantiated.

Finally, it is possible to declare usages of any component at runtime withouthaving to know its name or interface at design time.



Static Component Usage vs. dynamic ComponentUsageComponent usage is referred to as static component usage, if the name of thecomponent (or the component interface) to be used at runtime is known at designtime and this name is added to the list of used components on the properties tabof the consumer component.

Contrary, if neither the name of the component nor the name of the implementedcomponent interface is known at design time, then it is not possible to add a relatedcomponent usage to the list of used components (properties tab of consumercomponent). In this case the component usage has to be defined in the controllermethods dynamically and this type of component usage is referred to as dynamiccomponent usage.

Dynamic component usage should only be used if static component usage is notpossible (e.g. the name of the used component is not known at design time) or thesource code resulting for the static component usage is very complicated (e.g. thenumber of possible used components is large and only few of them are used atruntime). The reasons are as follows:

� It is easier to implement� It is easier to maintain and debug� The performance is significant better compared to reusing components

dynamically

Interfaces of theWeb Dynpro API related to ComponentReuseAs a reference for this lesson, the most important interfaces related to componentreuse and provided by the Web Dynpro framework are summarized below.

Figure 53: Accessing the statically defined component usage and itsinterface controller



Figure 54: The interface IF_WD_COMPONENT_USAGE

Figure 55: Accessing the interface IF_WD_COMPONENT_USAGE_GROUP



Figure 56: The interfaces IF_WD_RR_COMPONENT and IF_WD_COMPO-NENT_USAGE_GROUP

Web Dynpro Component InterfacesThe interface of a Web Dynpro component consists of the interface controller andas many interface views as windows are defined in the component.

The functionality of the interface controller is defined in the component controller.The developer can set the flag INTERFACE for ordinary methods, events, andcontext nodes, so these controller parts appear in the interface controller. For acontext node an additional property (Input Element (ext)) allows to prepare thiscontext node for external context mapping.

The functionality of an interface view is defined in the related window. Only thewindow's plugs can be defined in the interface view (flag INTERFACE). For theconsumer component, embedding an interface view of a used component in aViewUIElementContainer does not differ from embedding a view defined in theown component.



Figure 57: The interface of a Web Dynpro component

The repository object type Web Dynpro component interface allows to definecomponent entities to be contained in a component's interface as a separateobject. A component interface may be implemented by an arbitrary number ofWeb Dynpro components, resulting in a common set of methods, events, contextnodes and interface views existing for all these components. On the other side,any Web Dynpro component can implement an arbitrary number of Web Dynprocomponent interfaces. In this case, the component implementing the componentinterfaces will containing all methods, events, context nodes and interface viewsdefined in any of the component interfaces.

Creating a Web Dynpro Component InterfaceFrom the context menu of a package, a Web Dynpro component interface can becreated via the menu item Create→ Web Dynpro→ Web Dynpro Component(Interface). In the dialog box appearing, the radio button having the descriptionWeb Dynpro Component Interface has to be selected. After having saved thecomponent interface, a new entry appears in node Web Dynpro Comp. Interfacesof the object tree for the related package. After creation, the component interfacecontains an interface controller but no interface views. However, from the contextmenu for the component interface, an arbitrary number of interface views can becreated.



Figure 58: Creating a component interface

Figure 59: Web Dynpro component interface: Creating an interface view



Implementing Web Dynpro Component Interfaces byWeb Dynpro ComponentsTo implement a Web Dynpro component interface by a component, the nameof the component interface has to entered in column Name on tab ImplementedInterfaces of the implementing component. After having pressed Enter, a redlight appears and a button with the label Reimplement. Pressing this button willdo the following:

� Methods, events, and context nodes defined in the interface controller ofthe component interface are copied to the component controller of theimplementing component.

� From the interface view defined in the component interface, a window willbe generated in the implementing component.

Hint: If a component interface is implemented by a component, the flagINTERFACE available for all entities of a component interface is not setautomatically.

Hint: Implementing a component interface means copying the relatedentities. If methods, events, context nodes, or interface views are deletedin the component interface, they are not deleted in the implementingcomponents. However, if the method's signatures are changed or ifentities are added to the component interface the implementation has tobe actualized in all implementing components.

Hint: Deleting the implementation of a component interface does notdelete the entities from the implementing component.



Figure 60: Implementing Web Dynpro component interfaces by Web Dynprocomponents

Instantiating Usages of Components having implementedthe same Component InterfaceIn this section component reuse is discussed under the following boundaryconditions:

� Multiple components that may be reused by a consumer component haveimplemented the same component interface. Only one of these componentsis reused at the same time.

� The consumer component only needs to access functionality defined in theimplemented component interface.

In this case, the consumer component does not need to define a separatecomponent usage for each of the possible sub components, but only one usage ofthe implemented component interface. Which one of the possible sub componentsis to be instantiated can then be decided at runtime.



Figure 61: Reusing components having implemented the same componentinterface (1)

Figure 62: Reusing components having implemented the same componentinterface (2)



Each controller having added the usage of the interface component to its list ofused components / controllers can instantiate the usage of a component, that hasimplemented the component interface. However, since the name of the componentis not fixed, it is necessary to pass the components name to the method used toinstantiate the component usage.

Hint: All entities of a component that are defined in the implementedinterface can be accessed by the consumer component, if the consumercomponent accesses this sub component via a usage of the implementedcomponent interface. It is not necessary to set the flag INTERFACE forthese entities in the implementing component.

Figure 63: Instantiation of a component usage implementing a givencomponent interface

This technique also allows to define the component to be used at runtimedynamically (e.g. via configuration). Thus, components not known at design timecan be reused and the related interface view can be embedded as long as theyimplement a given interface controller. It is also possible to exchange the usedcomponent at runtime by first deleting the existing instance of the componentusage and then instantiate a different component usage using the same referenceto the commonly implemented component interface.



Figure 64: Exchanging used components implementing the samecomponent interface

All entities defined in the component interface are always visible to the consumercomponent having defined the component interface as a used component.This does not depend on having the flag INTERFACE set in the implementingcomponent!

However, if the component implementing the interface is added to the list of usedcomponents, this flag works as expected. Only those entities of the implementedcomponent interface are visible to the consumer component that have the flagINTERFACE set.

Multiple Usage of one ComponentIf multiple usages of the same component are required at runtime, but the numberof usages is not known at design time, then the technique of dynamically cloningstatically defined component usages can be applied.

Example: The user of a Web Dynpro application can mark multiple lines of a tableto display details for each selected data set. The details of one data set is displayedby one usage of a certain component. Thus, the number of component usagesequals the number of marked lines, which is not known at design time.



Figure 65: Multiple usage of one component: Example

The prerequisite for cloning any component usage is, that a single usage of thiscomponent has been defined at design time. Any controller having added thename of the static component usage to the list of used controllers / componentscan then create additional usages of the same component. Each component usagemust have a unique name.



Figure 66: Multiple usage of one component: Cloning a statically definedcomponent usage

To store the references to dynamically created component usages, acontroller attribute may be used. In the ABAP Dictionary, the table typeWD_COMPONENT_USAGE_GROUP has been created for this reason. Theline type is a reference type to the interface IF_WD_COMPONENT_USAGE.Alternatively, the framework supports managing dynamically created componentusages by the concept component usage groups. This will be discussed in thesection Dynamic Usage of different Components.



Figure 67: Prerequisites to create and store the references to a clonedcomponent usage

To clone a statically defined component usage, the following stepsare necessary: First, the reference to the statically defined componentusage (<comp_usage_name>) has to be obtained using the methodWD_THIS->wd_cpuse_<comp_usage_name>( ). This method is definedin the controller interface, since the name of the component usage hasbeen added to its list of used controllers / components. Next, the methodcreate_comp_usage_of_same_type( ) has to be called for the reference to thestatically defined component usage. This will create an additional usage of thesame component. The name of this additional component usage is defined viathe method's parameter NAME.

Accessing the interface of a dynamically created component usage differs fromthe way presented for statically defined component usages. If the name of thecomponent usage is known at design time, then the interface controller of thiscomponent usage can be added to the list of used controllers / components of anycontroller belonging to the consumer component. As a result, an additional methodin the controllers generated interface is created (wd_cpifc_<comp_usage_name>()). Calling this method will return the reference to the component usage'sinterface controller. However, if the name of the component usage is not knownat design time, this method does not exist in any controller. Thus, to accessthe interface controller of a dynamically defined component usage, the methodget_interface_controller( ) has to be called for the reference to the relatedcomponent usage. The receiving parameter of this method is of generic type ref



to object, thus casting this reference to a variable of the correct reference typeis necessary before the functionality defined in the component's interface canbe accessed.

Figure 68: Cloning a static component usage and accessing its interfacecontroller

Embedding and Displaying an Interface View dynamicallyUp to now, embedding interface views have only been discussed for the case thatthe component usage related to the interface view has been defined at design time.The single steps of embedding and displaying an interface view of a staticallydefined component usage are as follows:

� In the consumer component, a view containing a ViewUIElementContaineris embedded in a window.

� In this window, the interface view of the used component is embedded in theViewUIElementContainer of the previously embedded view.

� If the interface view must not be displayed before a certain user action (e.g.clicking a button) takes place, the EmptyView has to be embedded in theViewUIElementContainer, too. In addition, the EmptyView has to be definedas the Default View of the ViewUIElementContainer.

� Then, to display the interface view, a navigation link has to be created. Thisnavigation link connects an outbound plug of any view (e.g. fired as a resultof clicking a button) and an inbound plug of the interface view.



If the component usage is not defined at design time, it is not possible to embed aninterface view of this component usage into a ViewUIElementContainer of anotherview. It is also not possible to define a navigation link connecting any outboundplug of an existing view to an inbound plug of this interface view at design time.In this case methods of the Web Dynpro API have to be applied.

The API for view controllers and window controllers (interfaceIF_WD_VIEW_CONTROLLER) contains the method prepare_dynamic_naviga-tion( ). This method allows to define a navigation link at runtime. In addition,it allows to define the embedding position for the target view (interface view)dynamically. After having called this method, the outbound plug of the sourceview has to be fired, so the navigation to the target view (interface view) isperformed.

The embedding position for the view (interface view) is built up from the view'sname <VIEW> and the name of the ViewUIElementContainer (<CONTAINER>):<VIEW>/<CONTAINER>. For nested views, the further specification is separatedby a period from the specification of the outer view / container combination:<OUTER_VIEW>/<CONTAINER>.<INNER_VIEW>/<CONTAINER>

Hint: Calling the method prepare_dynamic_navigation( ) at runtimecorresponds to creating a navigation link at design time. Thus, calling thismethod several times for the same outbound plug but different inboundplugs will have the same effect as defining multiple navigation linksfor the same outbound plug and different inbound plugs. This is onlymeaningful if each inbound plug belongs to a separate view and all ofthese views may be displayed in parallel (view assembly).

If the navigation could lead from one source view to different targetviews (e.g. depending on the user input) and the navigation link has tobe defined dynamically, then one outbound plug should be created in thesource view for each possible inbound plug in a target view. The correctoutbound plug can be fired using the method fire_plug( <plug_name> )defined in the interface IF_WD_VIEW_CONTROLLER.



Figure 69: Defining navigation link and embedding position dynamically

Handle Events of dynamically created component usagesUp to now, handling events fired in the interface controller of a used componenthas only been discussed for the case that the component usage has been definedat design time. The single steps of registering an event handler method for anevent are as follows:

� First, the controller firing the event has to be added to the list of usedcontrollers / components of the controller that has to handle the event. Forthe case of cross component event handling, the controller to add is theinterface controller of the used component.

� Next, a method of type Event Handler has to be defined in the controller thatshould handle the event (Methods tab).

� Using the value help for the field with the label Event right of the method'sname, an event of the used controller can be assigned to the event handlermethod.

� After having selected the event handler, the signature of the event handlermethod is automatically changed to fit the signature of the event.

If the component usage is not defined at design time, then it is not possible tostatically assign an event of the component usage's interface controller to theevent handler method defined in any controller of the consumer component. The



signature of the event handler method can also not be defined in a way to fit theevent's signature. However, registering an event handler method for an event canbe performed at runtime using methods of the Web Dynpro framework.

Figure 70: Multiple usage of one component: Defining event handlingdynamically

To dynamically register an event handler method of any controller belongingto the consuming component for an event of a component usage instance, thefollowing steps have to be performed:

� First, the reference to the component usage instance has to be determined.This reference is of type IF_WD_COMPONENT_USAGE.

� For this reference, the method add_event_handler( ) has to be called.

Hint: The method remove_event_handler( ) can be used to delete thedynamic registering of an event handler method for an event.



Figure 71: Registering event handler method for event of used componentdynamically

The signature of the event handler method is not modified by dynamicallyregistering this method for the event of the used component. However, thecomplete information send by the event is available from the parameterWDEVENT that is predefined in all event handler methods. This parametercontains an internal table (WDEVENT->PARAMETERS) filled by the WebDynpro runtime. For each parameter provided by the event, a line of this tableis filled. Each line consists of the field NAME (filled with the name of the eventparameter) and the field VALUE (filled with the value of the event parameter).Because the type of each event parameter is arbitrary, the type of the value fieldis generic (type ref to data). Thus, before this value of a certain event parametercan be accessed, it has to be casted to a variable of the correct type. This istypically done by de-referencing the reference variable into a field symbol usingthe addition casting type <type_name>. However, the Web Dynpro runtime typesthe reference variables with dynamically generated types that are not compatibleto the statically available types defined in the class builder. Thus a different wayof de-referencing the variable value into a field symbol has to be used:



Figure 72: Dynamic event handling: Accessing the event parameters (1)

At runtime, the type of a variable can be described by an object using RTTI(run time type information). On the other side, a RTTI type description can beused to type variables using the addition type handle to. This addition can alsobe used when de-referencing a reference variable into a generically typed fieldsymbol (casting type handle to). Thus, accessing the event parameters involvesthe following steps:

� First the dynamically created reference type of an event parameter isobtained by using RTTI ( e.g. the method describe_by_data_ref( ) of classCL_ABAP_TYPEDESCR).

� Next, the parameter value is de-referenced in a field symbol using theaddition casting type handle to <RTTI type object>.

� If the static type of this parameter is known, the field symbol can finally becasted to a reference variable of this static type.



Figure 73: Dynamic event handling: Accessing the event parameters (2)

Dynamic Usage of different ComponentsIn the last sections the following situations for reusing components have beendiscussed:

1. One component is used. The implemented component interface is known,but not the component name.

2. Multiple components of same type are used. The component name is known.The number of component usages is not known at design time.

Another situation will be discussed in this section: Multiple components havingimplemented the same component interface may be used at runtime. So neither thenumber of component usages nor the component name is known at design time.

Example: In an application the component to be used depends on the country codeentered by the user. Multiple component usages are needed at runtime, e.g. foreach data set selected by the user an own component usage has to be instantiated.



Component Usage GroupsTo manage multiple component usages two concepts can be applied:

� After having created a component usage, the reference to this usage can bestored in an internal table of type WD_COMPONENT_USAGE_GROUP.This internal table can be defined as an attribute of a controller, so it can beaccessed during the life time of this controller. This technique allows to storereferences to component usages of any type.

For details please refer to the beginning of section �Multiple Usage of oneComponent�.

� If multiple component usages have to be managed that are usages ofcomponents implementing the same component interface (or usages of thesame component), then a component usage group can be applied. Thismanagement technique is integrated in the Web Dynpro framework, so noextra data object has to be created to store the references to the componentusages. Here, creating a new component usage and adding this component tothe component usage group is performed in one step.

The Interface IF_WD_COMPONENT provides methods to create a newcomponent usage group (create_cmp_usage_group( )), to check whether acomponent usage group has already been created (has_cmp_usage_group( )), andto get the reference to an existing component usage group (get_cmp_usage_group()).

Figure 74: Creating a component usage group (1)



Figure 75: Creating a component usage group (2)

The component usage group is described by the interface IF_WD_COM-PONENT_USAGE_GROUP. This interface contains methods to create anew component usage and add its reference to the component usage group(add_component_usage( )), to get the reference to one / all stored componentusage(s) (get_component_usage( ) / get_component_usages( )) or to deleteone / all stored component usage(s) from the component usage group(remove_component_usage( ) / remove_all_cmp_usage( )).



Figure 76: Creating and adding a component usage to a component usagegroup (1)

Figure 77: Creating and adding a component usage to a component usagegroup (2)



It is possible to work with more than one component usage group simultaneously,since each component usage group has its own name. When creating a componentusage group, not only the name of the component usage group, but also the nameof a component or a component interface has to be provided. All componentusages managed by this component usage group have to be usages of theprovided component or they have to implement the provided component interface,respectively.

The method add_component_usage( ) for adding a component usage to acomponent usage group contains the parameters NAME, USED_COMPONENT,and EMBEDDING_POSITION. NAME is the name of the component usage thathas to be unique in the component usage group. USED_COMPONENT is the nameof the component, the component usage is derived from. This component must becompatible to the usage group definition. Finally, EMBEDDING_POSITION isthe specification of the container in which an interface view of this componentusage has to be embedded. The container specified by this way does not haveto exist at the time the component usage is created. This allows to define thelayout of the embedding view dynamically by reusing the information stored inthe component usage group.

Example: For each component usage the related interface view has to bedisplayed on a separate tab of a tabStrip. This is done by defining dynamically(method wddomodifyview( )) as many tabs as component usages are stored in thecomponent usage group, each tab containing its own viewUIElementContainer.Storing the embedding position with the component usage ensures a consistentnaming of these dynamically created UI elements and parameter values ofmethods used in this context (e.g. dynamic navigation).



Exercise 4: Using components with thesame component interface

Exercise ObjectivesAfter completing this exercise, you will be able to:� Create component interfaces.� Implement component interfaces.� Use multiple components that have the same component interface.

Business ExampleDepending on configuration or authorization, the user of your application shouldsee different kinds of details for the marked flight (related bookings or completeflight data set). The functionality of reading and displaying details should bereusable, so two separate components providing the detail information have to becreated. Both components should have the same component interface. This hasto be accomplished by implementing a common component interface by bothcomponents. This component interface does not exist, so it has to be created first.

By adding the component interface to the list of used components, the maincomponent can instantiate and access the usage of the correct detail componentat runtime. The window defined in the common component interface has to bedisplayed as a modal dialog box.

Template Component: NET311_WINDOW_S

Solution Main Component: NET311_COMP_S

Solution Sub Components: NET311_COMP_C1_S, NET311_COMP_C2_S

Optional Parts:

Solution Main Component: NET311_COMP_OPT_S

Solution Sub Components: NET311_COMP_C1_OPT_S,NET311_COMP_C2_OPT_S




If you have not finished your last exercise, you can start with a copy of thetemplate component. In this case, copy the template component and name the copyZNET311_COMP_##. Assign this component to your package ZNET311_##.Create an application having the same name as your component and assign theapplication to your package, too.

Hint: The component you created in your last exercise (or the componentyou create in this task by copying the template component) will bereferred to as your main component in this exercise.



Task 2:Create a component interface (name: ZNET311_##_IF) in your package. Thisinterface should consist of a method (name: DISPLAY_DETAILS( )) having animport parameter (name: IS_FLIGHT) of type SFLIGHT and an interface view(name: DETAILS_WINDOW). Activate the component interface.

1. Create a component interface (name: ZNET311_##_IF).

2. Create an interface view (name: DETAILS_WINDOW) for the componentinterface you have created before.

3. Create a method (name: DISPLAY_DETAILS( )) in the interface controllerof the component interface. This method should have an import parameter(name: IS_FLIGHT) of type SFLIGHT.

4. Activate the component interface.




Task 3:Create two new components in your package (names: ZNET311_##_C1 andZNET311_##_C2) each having a view (name: DETAILS_VIEW). Implement thecomponent interface ZNET311_##_IF by both components. Embed the viewDETAILS_VIEW in the window DETAILS_WINDOW defined in the componentinterface.

1. Create two new components in your package (names: ZNET311_##_C1 andZNET311_##_C2).

Hint: When creating a component, you also have to create a windowfor this component. However, we do not need this window here.Thus you may delete the windows after the creation process of thecomponents is completed.

2. Implement the component interface ZNET311_##_IF by both components.

3. For each of the components create a view (name: DETAILS_VIEW). Embedthis view in the window provided by the implemented component interface.

Task 4:Implement the functionality of component ZNET311_##_C1:

For the key of a given flight, all related bookings should be read and displayedby the view DETAILS_VIEW.

1. Create a node (name: BOOKINGS, cardinality: (0:n), type: SBOOK) in thecomponent controller context of component ZNET311_##_C1. This nodeshould contain the fields BOOKID, CUSTOMID, CUSTTYPE, SMOKER,CLASS, FORCURAM, FORCURKEY, and ORDER_DATE.

2. Copy and map this node to the context of the view DETAILS_VIEW.

3. Display the content of the node BOOKINGS by a tableView UI element.Display 10 lines in the table. Do not display a mark column.

4. In method DISPLAY_DETAILS( ) read the bookings for the flight keypassed via the import parameter IS_FLIGHT. Use the static methodREAD_BOOKINGS( ) of class CL_NET310_FLIGHTMODEL. Save thebookings in the context node BOOKINGS.





For the key of a given flight, the complete flight data set should be read anddisplayed in the view DETAILS_VIEW.

1. Create a node (name: FLIGHT, cardinality: (1:1), type: SFLIGHT) in thecomponent controller of component ZNET311_##_C2. This node shouldcontain all fields of the transparent table sflight.


3. Display the content of the node FLIGHT by a form containing labels andread-only inputFields. Display all context attributes except the attributeCLIENT.

4. In method DISPLAY_DETAILS( ) read the complete flight data set for theflight key passed via the import parameter IS_FLIGHT. Use the staticmethod READ_FLIGHTS( ) of class CL_NET310_FLIGHTMODEL. Savethe flight in the context node FLIGHT.

Task 6:At runtime, one of the components ZNET311_##_C1 or ZNET311_##_C2 has tobe instantiated and accessed to display the details for the flight selected by the userin a modal dialog box. Only the component interface should be declared as aused component. The name of the sub component implementing this componentinterface should be provided by the value of a context attribute defined in thecomponent controller of your main component.

1. Add the component interface to the list of used components for your maincomponent. Choose DETAILS_COMP as the name of the component usage.

2. In the context of the component controller of your main component, adda context node (name: SUB_COMP_INFO) having an attribute (name:NAME) of type STRING. Set the property Default Value of this contextattribute to ZNET311_##_C1, where ## is your group number.

Caution: The name of the component has to be entered in uppercase letters.

3. Add the interface controller of the used component DETAILS_COMP to thelist of used controllers for the component controller of your main component.

4. Create a method (name: PROCESS_SUB_COMP( )) in the componentcontroller of your main component. Implement the functionality of themethod:

- Read the flight key from the context node FLIGHTS.




- Read the name of the component that should be used to display the detailsfrom the context node SUB_COMP_INFO.

- Instantiate the component usage if necessary.

- Call the interface method DISPLAY_DETAILS( ) of the subcomponent andpass the connection key to this method.

5. Create a new action (name: DISP_DETAILS_SUBCOMP) in viewMAIN_VIEW of your main component. Assign this action to the eventonLeadSelect of the table displaying the flights.

Hint: Up to now, the action DISP_DETAILS has been assignedto the table event onLeadSelect. Thus selecting a line has lead todisplaying the related bookings by a window also defined in themain component. Because we do not want to rewrite this coding, anew action will be used to display the details by a sub component.

6. Implement the action handler method for actionDISP_DETAILS_SUBCOMP:

Call the component controller method PROCESS_SUB_COMP( ).Then, create and open a modal dialog box for the interface viewDETAILS_WINDOW of the sub component.

- Use the method CREATE_WINDOW_FOR_CMP_USAGE( ) of theinterface IF_WD_WINDOW_MANAGER to create the dialog box.

- Store the reference to the popup in the attribute GR_WINDOW of thecomponent controller.

- Set the parameter CLOSE_IN_ANY_CASE to ABAP_FALSE.

- Get the title displayed by the dialog box from the assistance class.

Task 7:Test the functionality of your application.

1. To define which of the components is instantiated at runtime, theproperty Default Value of the component controller's context attributeSUB_COMP_INFO.NAME has to be changed.




Task 8:OPTIONAL:

Add an OK button to the modal dialog box. In the controller of the view that isdisplayed in the modal dialog box, create an action. Assign this action to the event�Pressing the OK button�. Finally, implement the action handler method: Closethe modal dialog box, if the OK button is pressed.

Because the reference to the dialog box is used in several controllers of the subcomponent, it is advantageous to store this reference as a public attribute of thesub component's component controller. If the window DETAILS_WINDOW issend as a modal dialog box, this reference is automatically provided by the WDframework (interface parameter WINDOW_DESCR->WINDOW in methodWDDOONOPEN( )).

These steps have to be implemented in both components that implement thecomponent interface.

1. Create a public attribute (GR_WINDOW type ref to IF_WD_WINDOW) inthe component controller of the sub component.

2. Add the component controller to the list of used controllers for the windowDETAILS_WINDOW. This is necessary to access the public attributeGR_WINDOW defined in the component controller.

3. Check if the window DETAILS_WINDOW of the sub component is sent asa modal dialog box. If this is true, display an OK button in the dialog box.Define this button as the default button and hide the close button of thepopup (right upper corner).

4. Create a new action (name: OK_BUTTON_ACTION) for the viewDETAILS_VIEW that is embedded in the window DETAILS_WINDOW.

5. Create the method REGISTER_BUTTONS( ) in the view DETAILS_VIEW.

6. Create a controller attribute (name: GR_VIEW_API) in the viewDETAILS_VIEW. At runtime, this attribute should contain the reference tothe view controller API (interface IF_WD_VIEW CONTROLLER).

Set the value of the attribute GR_VIEW_API in the method WDDOINIT() of view DETAILS_VIEW.

7. If the window is send as a modal dialog box, call the methodREGISTER_BUTTONS( ) from the method WDDOINIT( ) of viewDETAILS_VIEW.



9. Implement the handler method of action OK_BUTTON_ACTION:Continued on next page



Solution 4: Using components with thesame component interfaceTask 1:If you have finished the previous exercise, you can skip this task. Then, all changescan 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 thetemplate component. In this case, copy the template component and name the copyZNET311_COMP_##. Assign this component to your package ZNET311_##.Create an application having the same name as your component and assign theapplication to your package, too.

Hint: The component you created in your last exercise (or the componentyou create in this task by copying the template component) will bereferred to as your main component in this exercise.






Choose MAIN_WINDOW as the interface view and DEFAULT as thename of the startup plug.




Task 2:Create a component interface (name: ZNET311_##_IF) in your package. Thisinterface should consist of a method (name: DISPLAY_DETAILS( )) having animport parameter (name: IS_FLIGHT) of type SFLIGHT and an interface view(name: DETAILS_WINDOW). Activate the component interface.

1. Create a component interface (name: ZNET311_##_IF).

a) A component interface is created the same way as a component.However, in the popup that appears while creating the component /component interface, you have to select the radio button with the labelWeb Dynpro Component interface.

b) Save. Assign your component interface to your package.

2. Create an interface view (name: DETAILS_WINDOW) for the componentinterface you have created before.

a) From the context menu of the component interface, you can createthe interface view.

3. Create a method (name: DISPLAY_DETAILS( )) in the interface controllerof the component interface. This method should have an import parameter(name: IS_FLIGHT) of type SFLIGHT.

a) In the object tree of the component interface, double-click on the itemINTERFACECONTROLLER.

b) Select the Methods tab. Enter the name of the method in the Methodcolumn.

c) Enter the name of the parameter in the column Parameter. ChooseType = Importing and Associate Type = SFLIGHT.

d) Save.

4. Activate the component interface.

a) Proceed as described in exercises you have done before.




Task 3:Create two new components in your package (names: ZNET311_##_C1 andZNET311_##_C2) each having a view (name: DETAILS_VIEW). Implement thecomponent interface ZNET311_##_IF by both components. Embed the viewDETAILS_VIEW in the window DETAILS_WINDOW defined in the componentinterface.

1. Create two new components in your package (names: ZNET311_##_C1 andZNET311_##_C2).

Hint: When creating a component, you also have to create a windowfor this component. However, we do not need this window here.Thus you may delete the windows after the creation process of thecomponents is completed.


2. Implement the component interface ZNET311_##_IF by both components.

a) The following steps have to be performed for both components,ZNET311_##_C1 and ZNET311_##_C2.

b) In the object tree of your package, double-click on the name of thecomponent. This will display the list of used components. Make surethat you are in the edit mode.

c) Select the tab Implemented Interfaces.

d) Enter the name of your component interface (ZNET311_##_IF) inthe column Name.

e) Press the button with the label Reimplement that is displayed in thecolumn containing the name of the component interface. The light inthe column Implementation State will change from red to green.

f) Activate the component.

3. For each of the components create a view (name: DETAILS_VIEW). Embedthis view in the window provided by the implemented component interface.






For the key of a given flight, all related bookings should be read and displayedby the view DETAILS_VIEW.

1. Create a node (name: BOOKINGS, cardinality: (0:n), type: SBOOK) in thecomponent controller context of component ZNET311_##_C1. This nodeshould contain the fields BOOKID, CUSTOMID, CUSTTYPE, SMOKER,CLASS, FORCURAM, FORCURKEY, and ORDER_DATE.




3. Display the content of the node BOOKINGS by a tableView UI element.Display 10 lines in the table. Do not display a mark column.


Use the Web Dynpro Code Wizard to create the table.

Hint: The number of visible rows can be set via the propertyvisibleRowCount, the mark column can be hidden by settingthe property selectionMode to none.

4. In method DISPLAY_DETAILS( ) read the bookings for the flight keypassed via the import parameter IS_FLIGHT. Use the static methodREAD_BOOKINGS( ) of class CL_NET310_FLIGHTMODEL. Save thebookings in the context node BOOKINGS.



For the key of a given flight, the complete flight data set should be read anddisplayed in the view DETAILS_VIEW.

1. Create a node (name: FLIGHT, cardinality: (1:1), type: SFLIGHT) in thecomponent controller of component ZNET311_##_C2. This node shouldcontain all fields of the transparent table sflight.







3. Display the content of the node FLIGHT by a form containing labels andread-only inputFields. Display all context attributes except the attributeCLIENT.


Use the Web Dynpro Code Wizard to create the form. In the generatedform, mark the check box related to the property readOnly for allinputFields.

4. In method DISPLAY_DETAILS( ) read the complete flight data set for theflight key passed via the import parameter IS_FLIGHT. Use the staticmethod READ_FLIGHTS( ) of class CL_NET310_FLIGHTMODEL. Savethe flight in the context node FLIGHT.


Task 6:At runtime, one of the components ZNET311_##_C1 or ZNET311_##_C2 has tobe instantiated and accessed to display the details for the flight selected by the userin a modal dialog box. Only the component interface should be declared as aused component. The name of the sub component implementing this componentinterface should be provided by the value of a context attribute defined in thecomponent controller of your main component.

1. Add the component interface to the list of used components for your maincomponent. Choose DETAILS_COMP as the name of the component usage.

a) Edit the list of used components for your main component. Select thetab Used Components. Enter the name of your component interfacein the column Component and DETAILS_COMP in the columnComponent Use.

b) Save.

2. In the context of the component controller of your main component, adda context node (name: SUB_COMP_INFO) having an attribute (name:NAME) of type STRING. Set the property Default Value of this contextattribute to ZNET311_##_C1, where ## is your group number.

Caution: The name of the component has to be entered in uppercase letters.





3. Add the interface controller of the used component DETAILS_COMP to thelist of used controllers for the component controller of your main component.

a) Edit the properties of the component controller of your maincomponent.

b) Use the button having the quick info Create Controller Usage to addthe interface controller of component usage DETAILS_COMP to thelist of used controllers / components.

4. Create a method (name: PROCESS_SUB_COMP( )) in the componentcontroller of your main component. Implement the functionality of themethod:

- Read the flight key from the context node FLIGHTS.

- Read the name of the component that should be used to display the detailsfrom the context node SUB_COMP_INFO.

- Instantiate the component usage if necessary.

- Call the interface method DISPLAY_DETAILS( ) of the subcomponent andpass the connection key to this method.

a) In order to instantiate the component usage, the name of the subcomponent implementing the component interface ZNET311_##_IFhas to be passed to the method CREATE_COMPONENT( ).


5. Create a new action (name: DISP_DETAILS_SUBCOMP) in viewMAIN_VIEW of your main component. Assign this action to the eventonLeadSelect of the table displaying the flights.

Hint: Up to now, the action DISP_DETAILS has been assignedto the table event onLeadSelect. Thus selecting a line has lead todisplaying the related bookings by a window also defined in themain component. Because we do not want to rewrite this coding, anew action will be used to display the details by a sub component.


Replace the action DISP_DETAILS actually assigned to the table eventonLeadSelect by the new action DISP_DETAILS_SUBCOMP.

6. Implement the action handler method for actionDISP_DETAILS_SUBCOMP:

Call the component controller method PROCESS_SUB_COMP( ).Then, create and open a modal dialog box for the interface viewDETAILS_WINDOW of the sub component.




- Use the method CREATE_WINDOW_FOR_CMP_USAGE( ) of theinterface IF_WD_WINDOW_MANAGER to create the dialog box.

- Store the reference to the popup in the attribute GR_WINDOW of thecomponent controller.

- Set the parameter CLOSE_IN_ANY_CASE to ABAP_FALSE.

- Get the title displayed by the dialog box from the assistance class.



1. To define which of the components is instantiated at runtime, theproperty Default Value of the component controller's context attributeSUB_COMP_INFO.NAME has to be changed.

a) Edit the component controller context of your main component.

b) Change the values of the property Default Value of the componentcontroller's context attribute SUB_COMP_INFO.NAME.

Hint: Valid values for the property Default Value areZNET311_##_C1 and ZNET311_##_C2, where ## is yourgroup number.

c) Save and activate your main component.

d) Restart your application and display the details of any flight data set.




Task 8:OPTIONAL:

Add an OK button to the modal dialog box. In the controller of the view that isdisplayed in the modal dialog box, create an action. Assign this action to the event�Pressing the OK button�. Finally, implement the action handler method: Closethe modal dialog box, if the OK button is pressed.

Because the reference to the dialog box is used in several controllers of the subcomponent, it is advantageous to store this reference as a public attribute of thesub component's component controller. If the window DETAILS_WINDOW issend as a modal dialog box, this reference is automatically provided by the WDframework (interface parameter WINDOW_DESCR->WINDOW in methodWDDOONOPEN( )).

These steps have to be implemented in both components that implement thecomponent interface.

1. Create a public attribute (GR_WINDOW type ref to IF_WD_WINDOW) inthe component controller of the sub component.


2. Add the component controller to the list of used controllers for the windowDETAILS_WINDOW. This is necessary to access the public attributeGR_WINDOW defined in the component controller.





3. Check if the window DETAILS_WINDOW of the sub component is sent asa modal dialog box. If this is true, display an OK button in the dialog box.Define this button as the default button and hide the close button of thepopup (right upper corner).

a) Edit the method WDDOONOPEN( ) of the windowDETAILS_WINDOW.

b) Check the attribute IS_POPUP of the interface parameterWINDOW_DESCR to find out, if the window is displayed as a popup.

c) If the window is displayed as a popup, use the methodsSET_BUTTON_KIND( ), SET_DEFAULT_BUTTON(), and SET_CLOSE_BUTTON( ) of the attributeWINDOW_DESCR→WINDOW to define the desiredbehavior.

d) Save the reference to the dialog box in the component controllerattribute GR_WINDOW.

Hint: The reference to the dialog box is provided by the WDframework (parameter WINDOW_DESCR->WINDOW).

e) Source code see below.

4. Create a new action (name: OK_BUTTON_ACTION) for the viewDETAILS_VIEW that is embedded in the window DETAILS_WINDOW.


5. Create the method REGISTER_BUTTONS( ) in the view DETAILS_VIEW.


6. Create a controller attribute (name: GR_VIEW_API) in the viewDETAILS_VIEW. At runtime, this attribute should contain the reference tothe view controller API (interface IF_WD_VIEW CONTROLLER).

Set the value of the attribute GR_VIEW_API in the method WDDOINIT() of view DETAILS_VIEW.






7. If the window is send as a modal dialog box, call the methodREGISTER_BUTTONS( ) from the method WDDOINIT( ) of viewDETAILS_VIEW.


Hint: If the window is sent as a dialog box, the attributeGR_WINDOW defined in the component controller is notinitial.








Result

Component ZNET311_##_C1 - Comp.Controller: DISPLAY_DETAILS( )

METHOD display_details .

DATA: lt_bookings TYPE net310_t_sbook,

lr_node_bookings TYPE REF TO if_wd_context_node.

CALL METHOD cl_net310_flightmodel=>read_bookings

EXPORTING

i_carrid = is_flight-carrid

i_connid = is_flight-connid

i_fldate = is_flight-fldate

IMPORTING

e_bookings = lt_bookings.

lr_node_bookings = wd_context->get_child_node(

if_componentcontroller=>wdctx_bookings ).

lr_node_bookings->bind_table( lt_bookings ).




ENDMETHOD.

Component ZNET311_##_C2 - Comp.Controller: DISPLAY_DETAILS( )

METHOD display_details .

DATA: ls_flight TYPE sflight,

lr_node_flight TYPE REF TO if_wd_context_node.

CALL METHOD cl_net310_flightmodel=>read_flights

EXPORTING

i_carrid = is_flight-carrid

i_connid = is_flight-connid

i_fldate = is_flight-fldate

IMPORTING

e_flight = ls_flight.

lr_node_flight = wd_context->get_child_node( if_componentcontroller=>wdctx_flight ).

lr_node_flight->bind_structure( ls_flight ).

ENDMETHOD.

Main Component - Comp. Controller:PROCESS_SUB_COMP( )

METHOD process_sub_comp .

DATA: lr_node_sub_comp_info TYPE REF TO if_wd_context_node,

lr_elem_sub_comp_info TYPE REF TO if_wd_context_element,

ls_sub_comp_info TYPE if_componentcontroller=>element_sub_comp_info,

lv_cmp_name LIKE ls_sub_comp_info-name,

lr_node_flights TYPE REF TO if_wd_context_node,

lr_elem_flights TYPE REF TO if_wd_context_element,

ls_flights TYPE if_componentcontroller=>element_flights,

lr_cmp_usage TYPE REF TO if_wd_component_usage,

lr_interfacecontroller TYPE REF TO iwci_net311_comp_s_if .

* read from context, which component implementing the same comp interface

* has to be instantiated

lr_node_sub_comp_info = wd_context->get_child_node(

name = if_componentcontroller=>wdctx_sub_comp_info ).

lr_elem_sub_comp_info = lr_node_sub_comp_info->get_element( ).

lr_elem_sub_comp_info->get_attribute(




EXPORTING

name = ‘NAME‘

IMPORTING

value = lv_cmp_name ).

* Get key fields of selected flight

lr_node_flights = wd_context->get_child_node(

name = if_componentcontroller=>wdctx_flights ).

lr_elem_flights = lr_node_flights->get_element( ).

lr_elem_flights->get_static_attributes(

IMPORTING

static_attributes = ls_flights ).

* instantiate component usage if necessary

lr_cmp_usage = wd_this->wd_cpuse_details_comp( ).

IF lr_cmp_usage->has_active_component( ) IS INITIAL.

lr_cmp_usage->create_component( component_name = lv_cmp_name ).

ENDIF.

* pass key fields of selected flight to used component instance

lr_interfacecontroller = wd_this->wd_cpifc_details_comp( ).

lr_interfacecontroller->display_details(

is_flight = ls_flights ).

ENDMETHOD.

Main Component - MAIN_VIEW: ONAC-TIONDISP_DETAILS_SUBCOMP( )

METHOD onactiondisp_details_subcomp .

DATA: lr_window_manager TYPE REF TO if_wd_window_manager,

lr_cmp_api TYPE REF TO if_wd_component,


CONSTANTS: lv_if_name TYPE string VALUE 'DETAILS_WINDOW',

lv_cmp_name TYPE string VALUE 'DETAILS_COMP'.

* Instantiate component usage and pass key of selected flight to this comp. usage

wd_comp_controller->process_sub_comp( ).






* Create modal dialog box sending window of used component




= lr_window_manager->create_window_for_cmp_usage(

interface_view_name = lv_if_name

component_usage_name = lv_cmp_name

title = lv_text

close_in_any_case = abap_false ).

* Open dialog box


ENDMETHOD.

OPTIONAL: Component ZNET311_##_C1 /ZNET311_##_C2 - DETAILS_WINDOW: WDDOONOPEN()

METHOD wddoonopen.

* if window is send as modal dialog box: set related properties

IF window_descr->is_popup = abap_true.

window_descr->window->set_button_kind( button_kind = if_wd_window=>co_buttons_ok ).

window_descr->window->set_close_button( close_button = abap_false ).

window_descr->window->set_default_button( button = if_wd_window=>co_button_ok ).

wd_comp_controller->gr_window = window_descr->window.

ENDIF.

ENDMETHOD.

OPTIONAL: Component ZNET311_##_C1 /ZNET311_##_C2 - DETAILS_VIEW: WDDOINIT( )

METHOD wddoinit .



IF wd_comp_controller->gr_window IS NOT INITIAL.


ENDIF.

ENDMETHOD.




OPTIONAL: Component ZNET311_##_C1/ ZNET311_##_C2 - DETAILS_VIEW:REGISTER_BUTTONS( )

METHOD register_buttons .






ENDMETHOD.

OPTIONAL: Component ZNET311_##_C1/ ZNET311_##_C2 - DETAILS_VIEW:ONACTIONOK_BUTTON_ACTION( )



CASE wdevent->name.

WHEN 'ON_OK'.


ENDCASE.

ENDMETHOD.



Lesson Summary

You should now be able to:� Define and implement Web Dynpro component interfaces� Use multiple Web Dynpro components having implemented the same Web



usages.


NET311 Lesson: Personalization

Lesson: Personalization

Lesson OverviewABAPWeb Dynpro applications can be adjusted in different ways and by differenttarget groups. The Web Dynpro framework provides techniques out of the box(implicit adaptation), so no development effort is necessary. However, if theseoptions are not sufficient, the developer of the Web Dynpro component can defineadditional functionality to be adjustable (explicit adaptation).

This lesson covers all techniques for adapting a Web Dynpro application implicitlyand explicitly.


� Explain the options for adapting Web Dynpro applications.� Apply implicit adaptation options.� Prepare the code for explicit adaptations.� Implement explicit personalization / customizing.

Business ExampleYou are a developer of a Web Dynpro application. You know, that yourapplication can be adapted by different techniques: configuration, customizing,and personalization. You would like to know how these concepts work so you canadd the functionality to your components. This is the prerequisite for the plannedadaptation options.

Adaptation OptionsThere are three techniques available to adapt Web Dynpro applications:Configuration, customizing, and personalization. Intrinsically, all concepts allowto change predefined property values of UI elements used in any of the views ofthis component. However, these concepts can be extended to allow all changesthat are guided by changing the values of context attributes.

Configuration is performed by a developer. First, a component configuration iscreated for every Web Dynpro component that has to be adapted.

Next, a configuration of the Web Dynpro application is developed (applicationconfiguration). Here, the developer decides which component configuration isto be used for which component of this application.

Configuration takes place at design time. This kind of application adjustmentis visible for everybody in the system.



In contrast to configuration, personalization is a function that is available tothe user of an application and provides him or her with the option of adjustingthe application to suit his or her own personal requirements or preferences. Theframework for variation options within personalization is less far-reaching thanthat in configuration; personal settings in the UI must never limit the runningability of an application. Personalization of an application is performed directlyby a user from within the current application.

It is possible to maintain application settings in a uniform manner for all usersworking in the same client (customizing). A system administrator can processpersonalization settings on the basis of his or her extended authorization, providedthe respective application runs in so-called configuration mode. Customizingallows to change a lot more settings then personalization does.

Personalization and customizing are always executed at runtime of an application.

Adaptation HierarchyThe concepts of configuration, customizing, and personalization can be combinedto define the final adaptation. Here, the changes defined by personalizationoverwrite the changes defined by customizing, and customizing overwritesthe configuration adaptation. On the other side, the parameters available forconfiguration can be set final so they cannot be changed using customizing orpersonalization. Parameters available for customizing can be set final so theycannot be changed using personalization.



Figure 78: Adaptation possibilities: Configuration, customizing, andpersonalization

Hint: Customizing and personalizing is always related to the usedcomponent configuration. That means, that for each componentconfiguration a separate configuration data set per client and a separatepersonalization data set for every user may exist.

For this technical reason a default configuration data set exists for everycomponent. If customizing or personalization is applied to a componentthat has not been configured yet, then the personalization / customizingdata sets are related to this default component configuration.

Implicit / Explicit AdaptationABAP Web Dynpro offers configuration, customizing, and personalization out ofthe box. This means that adapting a Web Dynpro application is possible withoutany programming effort. This kind of adaptation is called implicit adaptation.

If the possibility provided by the implicit adaptation techniques are not sufficient,these concepts can be extended. This means, that additional adaptationpossibilities can be planned by the developer of the component.



Figure 79: Implicit / explicit adaptation of Web Dynpro components

Technically, the developer has to define a data interface that can be usedto pass adaptable data values to the component when instantiating it. Thisconcept is called explicit adaptation and can be implemented by configuration,customizing and personalization. The data interface is the context of a specialcustom controller (configuration controller) that is instantiated even before thecomponent controller of the related Web Dynpro component is instantiated. TheWeb Dynpro framework reads the adapted data values and fills the context of theconfiguration controller automatically when instantiating the related component.Thus, the adapted data values are loaded before the first hook method of any othercontroller defined in this component is processed. All other controllers can accessthe adaptation data by mapping the corresponding nodes of the configurationcontroller.

The developer has to decide which attributes should be defined in the configurationcontroller and how changing these attributes will influence the functionality andthe UI of this component.



The single steps of creating a configuration controller are as follows:

� First a new custom controller has to be created. The context of the customcontroller has to contain all attributes that should be adaptable by explicitadaptation.

� The related context nodes of the custom controller have to be mapped to allcontrollers that need to access the attribute values at runtime. The sourcecode acting on the attribute values has to be defined or the attributes can bebound directly to properties of UI elements.

� In order to make the custom controller attributes accessible by configuration,customizing, or personalization, the custom controller has to be declared asthe component's configuration controller. This is done from the contextmenu of the custom controller ((Re)Set as Config. Controller).

Hint: Only one configuration controller may exist for each Web Dynprocomponent.

The Personalization InterfaceThe personalization interface (implemented by the personalizationmanager at runtime) allows to load, save, or delete adaptation data setsat runtime. As a reference for this lesson, the personalization interfaceIF_WD_PERSONALIZATION and the way of how to access this interface aresummarized below.

Figure 80: Accessing the personalization interface from any controller



Figure 81: Accessing the personalization interface from a controller havingdeclared the component controller as a used controller

Figure 82: The personalization interface



ConfigurationConfiguration is a concept that lets the developer create configuration data setscontaining values for UI element properties or context attributes (typically boundto UI element properties). This allows to overwrite many of the statically definedUI element properties, resulting in a different look and feel of the application(UI elements may be set to invisible, tables may have an alternating row color,and so on).

Configuration data sets are related to components or they are related toapplications. Component configurations allow you to change properties of UIelements defined in any view of a single component. For each component, anarbitrary number of component configurations can be defined. Applicationconfigurations are bound to Web Dynpro applications. They define whichcomponent configuration is used for which component in this application. Foreach application, an arbitrary number of application configurations can be created.

Application changes related to configuration affect every user of this applicationin every client.

Figure 83: Configuration: Concept

Defining a Component ConfigurationDefining a component configuration is started from the context menuof the related Web Dynpro component (Create/Change Configuration).The configuration tool is implemented by the Web Dynpro applicationconfigure_component.



Figure 84: Creating / changing a component configuration



Figure 85: Explicit component configuration

Hint: Properties that are configured explicitly may be overwritten byimplicit customizing / personalization (if they are not set final).



The single steps of creating a new component configuration are as follows:

1. In the Component Configuration tray, enter the name of the componentconfiguration to be created.

Caution: In a customer system, you may only choose names in thecustomer name space (beginning with Z or Y).

2. In the Functions tray, choose Create. This will open a dialog where youcan change UI element properties.

3. On the Implicit Configuration tab, choose the UI element you want tomanipulate. Change the property values and set the Final flag if you do notwant this property to be changed by customizing or by personalization.

4. On the Explicit Configuration tab, you can change the values of all attributesdefined in the configuration controller. This tab is only selectable, if aconfiguration controller exists.

5. Enter a description in the form field above the tab strip.6. Press the Details button in the Changed Configuration tray. In the form

fields appearing on the right side, you can choose the package name and thetransport request the component configuration will be assigned to.

Hint: For SAP NetWeaver Application Server 7.0 SP12 and later,the Details button does not exist any more. The correspondingdialog is send automatically when the Save button is pressed.

7. Finally, press the Save button in the Changed Configuration tray.8. Close the browser. In the ABAP Workbench, refresh the object list. The

component configuration can be found as a sub-element of the Web Dynprocomponent.

Using the same configuration tool, existing component configurations can bedisplayed or changed.

Hint: Existing component configuration data sets for any componentcan be displayed and deleted using the Web Dynpro applicationWD_ANALYZE_CONFIG_COMP.

Defining an application configuration is started from the context menuof an existing Web Dynpro application (Create/Change Configuration).The configuration tool is also implemented by a Web Dynpro application(configure_application). The single steps of creating an application configurationare as follows:



Figure 86: Creating / changing an application configuration

1. In the Application Configuration tray, enter the name of the applicationconfiguration to be created.

Caution: In a customer system you may only choose names in thecustomer namespace (beginning with Z or Y).

2. In the Functions tray, choose Create. This will open a dialog where you canchoose which configuration will be used for which component.

3. In the Assignment to Component Configuration group, choose a componentusage. In the group below, choose which configuration should be used forthis component usage.

4. Enter a description in the form field on top of the Assignment to ComponentConfiguration group.

5. Press the Details button in the Changed Configuration tray. In the formfields appearing on the right side, you can choose the package name and thetransport request the component configuration will be assigned to.

Hint: For SAP NetWeaver Application Server 7.0 SP12 and later,the Details button does not exist any more. The correspondingdialog is send automatically when the Save button is pressed.

6. Finally, press the Save button in the Changed Configuration tray.7. Close the browser. In the ABAP Workbench, refresh the object list. The

application configuration can be found as a sub-element of the Web Dynproapplication.

Using the same application configuration tool, existing application configurationscan be changed.

Hint: Existing application configuration data sets can bedisplayed, changed, or deleted using the Web Dynpro applicationWD_ANALYZE_CONFIG_APPL.



Using an Application Configuration at RuntimeBefore an application configuration is used at runtime it has to be assigned to therelated Web Dynpro application. There are three ways of doing that:

1. The application configuration can be assigned to the application statically. Inthis case the parameterWDCONFIGURATIONID has to be added to theapplication's parameter list and the name of the application configuration(<appl_config>) has to be defined as the value of this parameter.

2. The application configuration can be assigned dynamically by adding thequery string sap-wd-configID=<appl_config> to the URL used to start theWeb Dynpro application.

3. Using the method load_config_by_key( ) of the interfaceIF_WD_PERSONALIZATION, the component configuration for eachcomponent of the application can be loaded or replaced at runtime.

Hint: A list of available component configurations fora given component can be obtained from the serviceclass CL_WD_CONFIGURATION_UTILITIES, methodget_config_list_4_comp( ).

Implicit Customizing / PersonalizationTo start customizing, the Web Dynpro application has to be started having addedthe query string sap-config-mode=X to the URL. If the right mouse buttonis pressed in the browser display and the authorization of the actual user issufficient (authorization for object S_DEVELOP or at least authorization for objectS_WDR_P13N is assigned to user), then a context menu pops up having the entrySettings. If this menu item is selected, the dialog for implicitly customizing theactual view is started. All UI element that are defined in this view can be selectedin a tree that reflects the UI element hierarchy of this view. For each UI elementthe values of a predefined set of properties can be altered and saved. Elements(or element properties) that are excluded from customizing by the underlyingconfiguration are not available. Selecting the Final check box for any propertyexcludes this property from personalization.

Every user starting the application in the same client and with the same underlyingconfiguration will now see the customized version.

Hint: If a user has changed a customized UI element property viapersonalization and this property is not excluded from personalization viacustomizing (flag final), then the personalized version of this propertyis used at runtime.



Figure 87: Implicit customizing: Dialog

Personalization of a Web Dynpro application is performed by pressing the rightmouse button in the browser display of an application that was started without theaddition of the query string sap-config-mode=X. The context menu that pops uphas an entry Settings. Clicking this entry will bring up a submenu. For most ofthe elements, this submenu has only one entry to hide the UI element the user hasclicked on. For some elements (e.g. table) additional personalization options canbe reached by selecting the additional submenu entry Other Settings. HidingUI elements is saved automatically. The dialog for other settings allows to savethese settings by pressing a Save button. Elements (or element properties) that areexcluded from personalization by customizing or configuration are not available.The personalization data sets are user dependent.

Hint: The visibility of UI elements that have been hidden bypersonalization can be restored by pressing the right mouse buttonanywhere on the browser display. Choosing the menu entries Settings→ Invisible Elements in the context menu will open a submenu with anentry for all invisible elements, respectively. Clicking on an entry willrestore the related UI element.

Hint: Customizing and personalization data sets can bedisplayed and deleted using the Web Dynpro applicationWD_ANALYZE_CONFIG_USER.



Figure 88: Implicit Personalization: Dialog

Explicit Customizing / PersonalizationAttributes defined in the configuration controller of a component are not availableautomatically for customizing and personalization. The developer has to createthe dialog that will be used at runtime to access these attributes. This dialog canbe used for customizing and for personalization. If the application is started incustomizing mode (adding query string sap-config-mode=X to URL) the dataentered by the user will be saved as customizing data. If the application is started innormal mode, the adaptation data will be saved user dependent (personalization).



Typically, the customizing / personalization dialog is implemented as a modaldialog box that is send when the user of the application clicks on a certain UIelement (button, link). Thus, to implement explicit customizing / personalization,the following development steps are necessary:

� Define a UI element, which is used to start the adaptation process.� Define the source code in the related action handler method to display the

adaptation dialog.� Define the adaptation dialog. To alter the values of the context attributes

defined in the configuration controller, UI elements have to be created thatare bound to these context attributes.

� Define the logic to close the adaptation dialog (typically via Save and Cancelbuttons).

� Define the logic to save the adaptation data (if Save was selected by the user).� Define the logic to roll back the context changes defined by the user input

(if Cancel was selected by the user). This is done by reloading the actualconfiguration.

� Define the functional changes in the component arising from the alteredcontext attribute values.

Figure 89: Explicit customizing / personalization

To save the customizing / personalization data entered by the user in thefields of the personalization window, the method save( ) of the interfaceIF_WD_PERSONALIZATION has to be called.



Figure 90: Explicit customizing / personalization: Creating and openingwindow

Figure 91: Explicit customizing / personalization: Saving data set



If a personalization dialog is created explicitly by the application developers, itcan be appropriate to also embed the personalization of the implicit configurationoption � for example, on an additional tab page. In this case, the user wouldhave the advantage of uniform handling. Embedding takes place with the helpof a component interface already provided, whereby further programming of thisimplicit section of the personalization dialog is no longer required.

The prepared Web Dynpro component interface to be used is calledIWD_PERSONALIZATION and provides an interface view that, in turn, must beembedded in the window of the component used. This interface has a methodcalled init_personalization( ), which is called in a method of the main component.The reference to the view controller for the view element to be personalized as wellas the ID of this view element must be passed to the method init_personalization( ).

Figure 92: Explicit customizing / personalization: Embedding implicitadaptation possibilities



Figure 93: Combining implicit / explicit adaptation options: Calling methodINIT_PERSONALIZATION



Figure 94: Combining implicit / explicit adaptation options: Embeddinginterface view IMP_PERSONALIZATION

Hint: All controllers that need to access the interface ofIWD_PERSONALIZATION have to declare the usage of thisinterface. Typically this is the view containing the link to startcustomizing / personalization, the view embedding the interface viewimp_personalization and the component controller.

Caution: It is not allowed to use component WDR_P13N directly. Theinterface of this component may be changed without notice.

Summary of functionality defined in InterfaceIF_WD_PERONALIZATIONThe most important functionality offered by the personalization interfaceIF_WD_PERSONALIZATION is summarized below:

� save( ) / delete( ):

Saving / deleting the customizing / personalization data set forf the activeuser.

� enter_change_mode( ):



Should be called before changing the customizing / personalization data setto recognize locks. However, save( ) automatically checks for existing lockson data set. If a lock is recognized by this method, a catchable runtimeexception is thrown.

� get_state( ):

Get information about the loaded configuration: The configuration's name,its type (e.g. application, default, or generated), its description and the scope(personalization range) of the actual user (e.g. scope=1 in personalizationmode, scope=4 in customizing mode).

� load_config_by_key( ):

Loading a component configuration by providing its name. If available, thecustomizing or personalization data set for this configuration is loaded.

� get_valid_personal_scope( ):

Get information about the scope (personalization range) of the actualuser. This scope defines if adaptations saved by the user are stored aspersonalization data (scope=1) or as customizing data (scope=4).

� Methods containing the fragment variant (e.g. save_new_variant( )):

These methods have been created to handle customizing variants andpersonalization variants in SAP List Viewer for ABAP Web Dynpro. Thesemethods are not intended to be used in another context.

� get_context_change_assistant( ):

The object returned by this method can be used to find out and handle allcontext changes related to external configuration / personalization. Changesof attributes not defined in the configuration controller can also be recordedif required.

� support_delta_handling( ):

As a result of calling this method only delta changes of the attribute valuesdefined in the configuration controller are saved. In contrast to working withthe context change assistant, only attributes defined in the configurationcontroller are handled.

� undo_context_changes( ):

The list of context changes recorded by the context change assistant isdeleted. However, this does not mean that the context changes are rolledback. This has to be done by reloading the actual configuration (first callget_state( ) to find out the name of the actual configuration, then reload thisconfiguration by calling the method load_config_by_key( )).

� transport_allowed( ):



Returns, if transporting of adaptation data set is allowed. This shouldbe checked before saving the data sets using the method save( ) orsave_new_variant( ).



Exercise 5: Configuration, customizingand personalization

Exercise ObjectivesAfter completing this exercise, you will be able to:� Create a configuration controller.� Enable the personalization of the configuration controller context attributes

(external personalization).

Business ExampleYour application is built in a way that different components implementing thesame component interface may be used at runtime. However, the name of the subcomponent is defined by the default value of a context attribute, so replacing thesub component requires overwriting the default value.

You have to change your application so everyone can choose his preferred detailcomponent at runtime without having to change the repository objects. This canbe achieved by external configuration and external personalization.

Template Component: NET311_COMP_OPT_S

Template Sub Components: NET311_COMP_C1_OPT_S,NET311_COMP_C2_OPT_S

Solution Main Component: NET311_P13N_S

Solution Sub Components: NET311_P13N_C1_S, NET311_P13N_C2_S

Task 1:If you have finished the previous exercise, you can skip this task. Then, all changescan be implemented in the components you have created in your last exercise.

If you have not finished your last exercise, you can start with a copy of thetemplate components. In this case, copy the template components listed aboveand name the copies ZNET311_P13N_##, ZNET311_P13N_##_C1, andZNET311_P13N_##_C2, respectively. Assign these components to your packageZNET311_##. Create an application for component ZNET311_P13N_## havingthe same name as this component and assign the application to your package, too.

Adapt the value of the property Default Value for the context attributeSUB_COMP_INFO.NAME. This attribute is defined in the component controllerof your main component.

1. Copy the template components.

2. Create an application to access your main component.Continued on next page



3. Adapt the value of the property Default Value for the context attributeSUB_COMP_INFO.NAME defined in the component controller of the maincomponent.

Task 2:Create a configuration controller in your main component. Copy the nodeSUB_COMP_INFO from the component controller context to the configurationcontroller context. Map the component controller node to the configurationcontroller node (the configuration controller node has to be the mapping origin).

1. Create a configuration controller (name: CONFIG_CTLR) in your maincomponent.

2. Copy the node SUB_COMP_INFO from the component controller context tothe configuration controller context.

3. Map the component controller node SUB_COMP_INFO to the configurationcontroller node SUB_COMP_INFO (origin).

Task 3:Create a component configuration for the main component of your application.Change some UI element properties. In addition, change the name of the subcomponent that is used by default for the main component (external configuration).Create an application configuration for your application. Start your applicationwith and without assigning the application configuration.

1. Create a component configuration for the main component of yourapplication. Change some UI element properties. In addition, change thename of the sub component that is used by default for the main component(external configuration).

2. After having created a component configuration for the main component,create an application configuration for your application.

3. Start your application with and without assigning the applicationconfiguration.

Task 4:The name of the sub component used at runtime should also be adaptable viacustomizing and personalization. Thus you have to create a dialog that allows tochoose the name of the sub component to be used at runtime.

1. Create a new window (name: PERS_WINDOW) in the main component.This window will be send as a modal dialog box if external customizing orexternal personalization is started.




2. Create a new view (name: PERS_VIEW). Embed this view in the windowPERS_WINDOW.

3. Copy and map the context node SUB_COMP_INFO from the componentcontroller context to the context of view PERS_VIEW.

4. Define the layout of view PERS_VIEW. Create a DropDownByKeyUI element and bind the property selectedKey to the context attributeSUB_COMP_INFO.NAME. Create a label for the DropDownByKey UIelement. Give the property text of the label UI element a meaningful value.

5. Create a method (name: SET_VALUE_SET( )) in the controller of viewPERS_VIEW. This method will encapsulate the code used to build up thevalue list displayed by the DropDownByKey UI element. Call this methodfrom the method WDDOINIT( ) of this view.

6. Implement the method SET_VALUE_SET( ). Create an internal tablewith line type WDR_CONTEXT_ATTR_VALUE. This line type has twofields: TEXT and VALUE. Add two lines to this internal table: The fieldVALUE has to contain the name of a sub component that can be used todisplay the details (in upper case letters), while TEXT can contain anytext describing this sub component. Define the attribute value set relatedto the context attribute SUB_COMP_INFO.NAME: Call the methodSET_ATTRIBUTE_VALUE_SET( ) for the meta data description of theattribute NAME and pass the internal table to this method via the parameterVALUE_SET.

7. Define a link in the view MAIN_VIEW. This link (ToolBarLinkToAction UIelement - that will be used to open the personalization dialog) should belocated in a toolbar that has to be defined as a sub element of the flight table.

8. Define a new action in view MAIN_VIEW (name: PERSONALIZE). Assignthis action to the ToolBarLinkToAction UI element.

9. Implement the handler method for the action PERSONALIZE. Create andopen a modal dialog box for the window PERS_WINDOW.

- The text displayed as the window title can be read from the assistance class.

- The window should not be closed in any case.

- Messages created by the popup should be displayed in the popup.

- The Close button of the window should not be displayed.

- The OK button should be displayed. This button should be the defaultbutton.

- An extra image indicating the severity of the information displayed by thepopup is not desired.




- Store the reference to the dialog box in the component controller attributeGR_WINDOW.

Task 5:The OK button can be used to close the personalization dialog. However, thepersonalization data is not stored yet. Thus, the following changes have to beimplemented:

The OK button should be renamed (preferred name: Save). After closing thedialog via Save, the personalization data should be stored.

1. The references to the view controller API of view PERS_VIEW is accessedmultiple times. Thus create a controller attribute in the view PERS_VIEW(type IF_WD_VIEW_CONTROLLER) to store this reference. The valueof this attribute should be determined in the method WDDOINIT( ) of theview controller.

2. Create the action OK_BUTTON_ACTION in the view PERS_VIEW.

3. Create the method REGISTER_BUTTONS( ) in the view PERS_VIEW. Callthis method from the hook method WDDOINIT( ).


Register the action OK_BUTTON_ACTION for the event �pressing the OKbutton�. Rename the button by providing the new text (Save) via parameterBUTTON_TEXT.


- Check if the name of the user event (WDEVENT->NAME) equals thevalue expected for the Save button (value: ON_OK).

- If this is true, try to save the personalization data set. Here the methodSAVE( ) of the personalization manager has to be called.

Hint: For convenience, the reference to the personalization managershould be obtained in the method WDDOINIT( ) of the componentcontroller and stored in a globally visible component controllerattribute (name: GR_P13N_MAN).

- If the personalization data set could not be saved (exception), report theexception. Use method REPORT_EXCEPTION( ).

- Finally, close the modal dialog box.





1. Start your application having assigned the application configuration.

2. Append the query string sap-config-mode=X to the URL created in step 1.Restart the application. This will start external customizing for the configuredversion of your application. Click the link to open the customizing dialog.Change the sub component used to display the details and press Save. Startyour application again having assigned the application configuration but nowin normal mode. You should see the customized version.

3. Restart your application again in normal mode (having assigned theapplication configuration but without having added the query stringsap-config-mode=X). Start the external personalization dialog by clickingthe related link. Change the sub component used to display the details andpress Save. Restart your application again in normal mode (having assignedthe application configuration but without having added the query stringsap-config-mode=X). You should now see the personalized version.

4. Customizing and Personalization is bound to the underlying configuration.Thus, if you start the application without assigning the applicationconfiguration, you will see the original version of the main component.



Solution 5: Configuration, customizingand personalizationTask 1:If you have finished the previous exercise, you can skip this task. Then, all changescan be implemented in the components you have created in your last exercise.

If you have not finished your last exercise, you can start with a copy of thetemplate components. In this case, copy the template components listed aboveand name the copies ZNET311_P13N_##, ZNET311_P13N_##_C1, andZNET311_P13N_##_C2, respectively. Assign these components to your packageZNET311_##. Create an application for component ZNET311_P13N_## havingthe same name as this component and assign the application to your package, too.

Adapt the value of the property Default Value for the context attributeSUB_COMP_INFO.NAME. This attribute is defined in the component controllerof your main component.


a) Display the template components in the object tree. Clicking on anycomponent with the right mouse button will open the component'scontext menu. Choose Copy.... Enter the name of the component to becreated. Press Continue.

b) Adapt the descriptions of the new components.

2. Create an application to access your main component.

a) An application having the same name as the component can be createdfrom the context menu of the main component.


3. Adapt the value of the property Default Value for the context attributeSUB_COMP_INFO.NAME defined in the component controller of the maincomponent.

a) Edit the component controller context of the main component. Opennode SUB_COMP_INFO and mark the attribute NAME. Change thevalue of the property Default Value to the name of one of your subcomponents you have copied in this task. The name has to be written inupper case letters.




Task 2:Create a configuration controller in your main component. Copy the nodeSUB_COMP_INFO from the component controller context to the configurationcontroller context. Map the component controller node to the configurationcontroller node (the configuration controller node has to be the mapping origin).

1. Create a configuration controller (name: CONFIG_CTLR) in your maincomponent.

a) From the context menu of your main component, choose Create→Custom Controller. Enter the controller's name and a description. Save.

b) Right mouse-click on the custom controller CONFIG_CTLR to openthe context menu. Choose (Re)Set as Config. Controller to make it thecomponent's configuration controller.

2. Copy the node SUB_COMP_INFO from the component controller context tothe configuration controller context.

a) Right mouse-click on the root node of the configuration controllercontext. From the context menu choose Create Using the Wizard→Copy Nodes of Different Context. A popup appears.

b) Make sure that the name of your main component is entered in the fieldwith the label Component Name. Enter COMPONENTCONTROLLERin the field with the label View/Controller Names. Press Enter.

c) The complete context of the component controller is displayed in apopup. Mark the node SUB_COMP_INFO and press Enter.

3. Map the component controller node SUB_COMP_INFO to the configurationcontroller node SUB_COMP_INFO (origin).

a) Edit the component controller. Add the configuration controller to thelist of used controllers/components for the component controller.

b) Select the tab Context. On the left side the context of the componentcontroller is displayed. On the right side a button is displayed for eachused controller. Press the button for the configuration controller.

c) Drag the node SUB_COMP_INFO from the component controllercontext and drop it on the node having the same name in theconfiguration controller context.




Task 3:Create a component configuration for the main component of your application.Change some UI element properties. In addition, change the name of the subcomponent that is used by default for the main component (external configuration).Create an application configuration for your application. Start your applicationwith and without assigning the application configuration.

1. Create a component configuration for the main component of yourapplication. Change some UI element properties. In addition, change thename of the sub component that is used by default for the main component(external configuration).

a) In order to create a component configuration, right mouse-click on thecomponent and choose the menu entry Create/Change Configuration.The configuration editor is opened in the browser.

b) Enter a name in the field Configuration (customer name space). Clickon the link Create.

c) Select the tab Implicit and change some settings for each view.

d) Because the main component contains a configuration controller, the tabExplicit can also be selected. Here the context nodes are displayed onthe left side. Select the node SUB_COMP_INFO. On the right side, theattributes NAME with its default value is displayed. Change this valueto use the other sub component of your main component at runtime.

e) Before you save the component configuration, add a description (fieldwith label description) and assign the component configuration toyour package and a transport request (button Details). Then pressbutton Save.




2. After having created a component configuration for the main component,create an application configuration for your application.

a) In order to create an application configuration, right mouse-click on theapplication and choose the menu entry Create/Change Configuration.The configuration editor is opened in the browser.

b) Enter a name in the field Configuration (customer name space). Clickon the link Create.

c) Mark the main component in the group wit the header Assignment ofComponent Configurations.

d) Assign the component configuration you have created before tothe main component. This is done in the group with the headerConfiguration of Root Component by entering the componentconfiguration name in the field with label Configuration.

e) Before you save the application configuration, add a description (fieldwith label description) and assign the application configuration toyour package and a transport request (button Details). Then pressbutton Save.

3. Start your application with and without assigning the applicationconfiguration.

a) To test your application without assigning the application configuration,right mouse-click on the application name in the object tree. ChooseTest from the context menu. The application looks as designed bythe developer.

Note, which sub component is used to display the details of the selectedflight.

b) To test your application having assigned the application configuration,open the element list for your application in the object tree. Rightmouse-click on the name of the application configuration. ChooseTest from the context menu. You will now see the configured versionof your application.

Note, which sub component is used now to display the details of theselected flight.




Task 4:The name of the sub component used at runtime should also be adaptable viacustomizing and personalization. Thus you have to create a dialog that allows tochoose the name of the sub component to be used at runtime.

1. Create a new window (name: PERS_WINDOW) in the main component.This window will be send as a modal dialog box if external customizing orexternal personalization is started.


2. Create a new view (name: PERS_VIEW). Embed this view in the windowPERS_WINDOW.


3. Copy and map the context node SUB_COMP_INFO from the componentcontroller context to the context of view PERS_VIEW.


4. Define the layout of view PERS_VIEW. Create a DropDownByKeyUI element and bind the property selectedKey to the context attributeSUB_COMP_INFO.NAME. Create a label for the DropDownByKey UIelement. Give the property text of the label UI element a meaningful value.

a) Proceed as described in exercises you have solved before. Best way tocreate both elements in one step is to create a container form from thecontext menu of the ROOTUIELEMENTCONTAINER.

5. Create a method (name: SET_VALUE_SET( )) in the controller of viewPERS_VIEW. This method will encapsulate the code used to build up thevalue list displayed by the DropDownByKey UI element. Call this methodfrom the method WDDOINIT( ) of this view.



6. Implement the method SET_VALUE_SET( ). Create an internal tablewith line type WDR_CONTEXT_ATTR_VALUE. This line type has twofields: TEXT and VALUE. Add two lines to this internal table: The fieldVALUE has to contain the name of a sub component that can be used todisplay the details (in upper case letters), while TEXT can contain anytext describing this sub component. Define the attribute value set relatedto the context attribute SUB_COMP_INFO.NAME: Call the methodSET_ATTRIBUTE_VALUE_SET( ) for the meta data description of theattribute NAME and pass the internal table to this method via the parameterVALUE_SET.





7. Define a link in the view MAIN_VIEW. This link (ToolBarLinkToAction UIelement - that will be used to open the personalization dialog) should belocated in a toolbar that has to be defined as a sub element of the flight table.

a) From the context menu for the flight table, create a ToolBar UI element.

b) From the context menu of the ToolBar UI element create a right-alignedToolBarLinkToAction UI element.

c) Set the property text of the ToolBarLinkToAction UI element.

8. Define a new action in view MAIN_VIEW (name: PERSONALIZE). Assignthis action to the ToolBarLinkToAction UI element.


9. Implement the handler method for the action PERSONALIZE. Create andopen a modal dialog box for the window PERS_WINDOW.

- The text displayed as the window title can be read from the assistance class.

- The window should not be closed in any case.

- Messages created by the popup should be displayed in the popup.

- The Close button of the window should not be displayed.

- The OK button should be displayed. This button should be the defaultbutton.

- An extra image indicating the severity of the information displayed by thepopup is not desired.

- Store the reference to the dialog box in the component controller attributeGR_WINDOW.





Task 5:The OK button can be used to close the personalization dialog. However, thepersonalization data is not stored yet. Thus, the following changes have to beimplemented:

The OK button should be renamed (preferred name: Save). After closing thedialog via Save, the personalization data should be stored.

1. The references to the view controller API of view PERS_VIEW is accessedmultiple times. Thus create a controller attribute in the view PERS_VIEW(type IF_WD_VIEW_CONTROLLER) to store this reference. The valueof this attribute should be determined in the method WDDOINIT( ) of theview controller.



2. Create the action OK_BUTTON_ACTION in the view PERS_VIEW.

a) Enter the action name in the field Action on tab Actions.

3. Create the method REGISTER_BUTTONS( ) in the view PERS_VIEW. Callthis method from the hook method WDDOINIT( ).




Register the action OK_BUTTON_ACTION for the event �pressing the OKbutton�. Rename the button by providing the new text (Save) via parameterBUTTON_TEXT.



- Check if the name of the user event (WDEVENT->NAME) equals thevalue expected for the Save button (value: ON_OK).

- If this is true, try to save the personalization data set. Here the methodSAVE( ) of the personalization manager has to be called.

Hint: For convenience, the reference to the personalization managershould be obtained in the method WDDOINIT( ) of the componentcontroller and stored in a globally visible component controllerattribute (name: GR_P13N_MAN).




- If the personalization data set could not be saved (exception), report theexception. Use method REPORT_EXCEPTION( ).

- Finally, close the modal dialog box.



1. Start your application having assigned the application configuration.

a) To test your application having assigned the application configuration,open the element list for your application in the object tree. Rightmouse-click on the name of the application configuration. ChooseTest from the context menu. You will now see the configured versionof your application.

2. Append the query string sap-config-mode=X to the URL created in step 1.Restart the application. This will start external customizing for the configuredversion of your application. Click the link to open the customizing dialog.Change the sub component used to display the details and press Save. Startyour application again having assigned the application configuration but nowin normal mode. You should see the customized version.

a) You can ask another student to start your application (having assignedthe application configuration). He/she should also see the customizedversion.

b) If you have a user in another client of the training system, restart theapplication (having assigned the application configuration) in thisclient. You will see the version without customizing.

3. Restart your application again in normal mode (having assigned theapplication configuration but without having added the query stringsap-config-mode=X). Start the external personalization dialog by clickingthe related link. Change the sub component used to display the details andpress Save. Restart your application again in normal mode (having assignedthe application configuration but without having added the query stringsap-config-mode=X). You should now see the personalized version.

a) You can ask another student to start your application again (havingassigned the application configuration). He/she should still see thecustomized version.

b) If you have a user in another client of the training system, restartthe application in normal mode (having assigned the applicationconfiguration) in this client. You will see the configured versionwithout customizing.




4. Customizing and Personalization is bound to the underlying configuration.Thus, if you start the application without assigning the applicationconfiguration, you will see the original version of the main component.

Result

PERS_VIEW Controller: WDDOINIT( )

METHOD wddoinit .




wd_this->set_value_set( ).

ENDMETHOD.

PERS_VIEW Controller: SET_VALUE_SET( )

METHOD set_value_set.

DATA: lr_root_node_info TYPE REF TO if_wd_context_node_info,

lr_sub_node_info TYPE REF TO if_wd_context_node_info,

lt_value_set TYPE wdr_context_attr_value_list,

ls_value_set TYPE wdr_context_attr_value.

* Navigate to meta info of node SUN_COMP_INFO

lr_root_node_info = wd_context->get_node_info( ).

lr_sub_node_info = lr_root_node_info->get_child_node(

NAME = if_pers_view=>wdctx_sub_comp_info ).

* Define value set -> Texts will be displayed

ls_value_set-text = 'Bookings for marked flight'.

ls_value_set-value = 'NET311_P13N_C1_S'.

INSERT ls_value_set INTO TABLE lt_value_set.

ls_value_set-text = 'Complete flight data set'.

ls_value_set-value = 'NET311_P13N_C2_S'.

INSERT ls_value_set INTO TABLE lt_value_set.

* set value set for attribute NAME

lr_sub_node_info->set_attribute_value_set(

NAME = 'NAME'

VALUE_SET = lt_value_set ).




ENDMETHOD.

MAIN_VIEW Controller: ONACTIONPERSONALIZE()

METHOD onactionpersonalize.

DATA: lr_window_manager TYPE REF TO if_wd_window_manager,

lr_cmp_api TYPE REF TO if_wd_component,




* Create modal dialog box sending personalization window of own component




= lr_window_manager->create_window(

window_name = 'PERS_WINDOW'

title = lv_text

close_in_any_case = abap_false

message_display_mode = if_wd_window=>co_msg_display_mode_selected

close_button = abap_false

button_kind = if_wd_window=>co_buttons_ok

message_type = if_wd_window=>co_msg_type_none

default_button = if_wd_window=>co_button_ok ).

* Open dialog box


ENDMETHOD.

PERS_VIEW Controller: REGISTER_BUTTONS( )

METHOD register_buttons.


* Label of OK button is renamed to SAVE



button_text = 'SAVE'






ENDMETHOD.

Comp. Controller: WDDOINIT( )

METHOD wddoinit.

DATA: lr_current_controller TYPE REF TO if_wd_controller.

lr_current_controller ?= wd_this->wd_get_api( ).

* get message manager

wd_this->gr_mess_man = lr_current_controller->get_message_manager( ).

* get personalization manager

wd_this->gr_p13n_man = lr_current_controller->get_personalization_manager( ).

ENDMETHOD.

PERS_VIEW Controller: ONACTIONOK_BUT-TON_ACTION( )


DATA: lr_ex TYPE REF TO cx_wd_personalization.


CASE wdevent->name.

WHEN 'ON_OK'.

* try to save peronalization data set

TRY.

wd_comp_controller->gr_p13n_man->save( ).

CATCH cx_wd_personalization INTO lr_ex.

wd_comp_controller->gr_mess_man->report_exception( message_object = lr_ex ).

ENDTRY.


ENDCASE.

ENDMETHOD.



Lesson Summary

You should now be able to:� Explain the options for adapting Web Dynpro applications.� Apply implicit adaptation options.� Prepare the code for explicit adaptations.� Implement explicit personalization / customizing.

Related Information

� In the online documentation, details about Personalization and Configurationcan be found in the help portal (http://help.sap.com) for the SAP NetWeaver7.0 by entering the terms in the search field.

Or you can navigate in the documentation for ABAP Web Dynprovia the menu entries Development in Detail→ Advanced Concepts→Personalization and Configuration to the same section.

� The system demo WDR_TEST_P13N is available in all SAP systems basedon SAP NetWaever 7.0.


http://help.sap.com

Unit Summary NET311

Unit SummaryYou 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� Create external dialog boxes� Create confirmation dialog boxes� Create modal dialog boxes to display windows of the same or another


boxes� Define and implement Web Dynpro component interfaces� Use multiple Web Dynpro components having implemented the same Web



usages.� Explain the options for adapting Web Dynpro applications.� Apply implicit adaptation options.� Prepare the code for explicit adaptations.� Implement explicit personalization / customizing.


NET311 Unit Summary

Related Information

� The following Web Dynpro components are provided in all systems based onSAP NetWeaver Application Server 7.0 and later:

Web Dynpro components having the name WDR_TEST... are applicationsto test the Web Dynpro concepts.

Web Dynpro components having the name WDR_... (without the additionTEST) or WD_... are basis utility components.

� The online documentation (component BC-WD-ABA) provides an excellentdescription of Web Dynpro features, programming techniques, and classreferences.




http://sdn.sap.com


Unit Summary NET311


Unit 3Enhancements

Unit OverviewEnhancements are used to change the functional and the visual behavior of ABAPapplications. The new enhancement framework introduced with SAP NetWeaver7.0 can be used to implement enhancements for ABAP Web Dynpro basedapplications. This includes changes in respect to the user interface, to the contextelements, to actions, plugs and navigation, and to method's source code.

This unit explains how to implement enhancements for ABAP Web Dynprocomponents.


� Know all possible enhancement possibilities for ABAP Web Dynpro.� Enhance ABAP Web Dynpro applications modification-free.

Unit ContentsLesson: Enhancements for ABAP Web Dynpro .. . . . . . . . . . . . . . . . . . . . . . . . . . .178

Exercise 6: Enhancements for ABAP Web Dynpro (optionalexercise) .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193


Unit 3: Enhancements NET311

Lesson: Enhancements for ABAP Web Dynpro

Lesson OverviewThe new enhancement concept of the ABAP Workbench enables the integrationof different concepts for modifying and enhancing development objects. Theenhancement concept is supported by the Enhancement Builder tool and ABAPlanguage elements. The overall goal of the enhancement framework is to providea technology to create modification-free enhancements and to unify all possibleways of modifying or enhancing Repository objects.


� Know all possible enhancement possibilities for ABAP Web Dynpro.� Enhance ABAP Web Dynpro applications modification-free.

Business ExampleYou have to adopt an ABAP Web Dynpro application that has not been developedin your company. You know about the possibilities to change the look and feel ofWeb Dynpro applications via configuration and personalization. However, thesetechniques are not sufficient since not only the UI element properties have to bechanged. In addition you know that SAP offers enhancement techniques to changerepository objects modification-free. Thus you would like to know, whethermodification-free enhancement possibilities do also exist for ABAP Web Dynproand what kind of changes are supported.

Enhancement ConceptIn many cases, it will be necessary to change or enhance applications delivered bySAP or ones that already exist. Unstructured changes to the source code or layoutof an application are called modifications. Modifications can cause conflicts whena new release of the application programs is to be imported.

The new enhancement concept of the ABAP Workbench (EnhancementFramework - as of SAP NetWeaver 7.0) enables the integration of differentconcepts for modifying and enhancing development objects. The enhancementconcept is supported by the Enhancement Builder tool, which is integrated in theABAP Workbench and ABAP language elements (ABAP language elements arenot yet supported by ABAP Web Dynpro).

The aim of the new enhancement concept is to unify all possible ways ofmodifying or enhancing SAP products (more precisely, Repository objects ofthe SAP NetWeaver Application Server ABAP), which go beyond the scope ofCustomizing.


NET311 Lesson: Enhancements for ABAP Web Dynpro

In the context of the new enhancement concept, the following can be handledas enhancements:

� Modifying a Repository object.� Replacing a Repository object with an identically-named object.� Enhancing a Repository object at a predefined position.� Using a foreign object.

Hint: For the current release, the enhancement concept only incorporatesenhancements of Repository objects at predefined positions calledenhancement options.

The enhancements of the enhancement concept can be switched using the SwitchFramework. This means that an enhancement takes effect when the package inwhich the above enhancement components are defined is assigned to a switch ofthe Switch Framework and this switch is not deactivated.

Enhancements for ABAP Web DynproYou can create enhancement implementations for existing applications that wereimplemented using Web Dynpro for ABAP. These enhancement implementationsare independent development objects that are managed separately from therespective original object. They are part of the enhancement concept that wasintegrated into the ABAP Workbench in the SAP NetWeaver ApplicationServer 7.0. The original objects they are based on are not changed by such anenhancement and can therefore be updated whenever there is a release change.

Hint: Conflicts related to software updates can be solved using transactionSPAU_ENH.

ABAP source texts in a Web Dynpro application can be enhanced using BAdIs.For this purpose, explicit anchor points (called enhancement options) areimplemented in the source code at suitable points during the development of theapplication. Using these options, you can insert a separately developed BAdI lateron into the flow of the program. Each BAdI is therefore an explicit enhancement.

An implicit enhancement, on the other hand, does not need any advanceimplementation through the application development department.

In addition to the source code enhancements described above, you can alsoperform enhancements to individual sections of a Web Dynpro component. Forexample, you can insert UI elements into a view or suppress them, or you caninsert new nodes in a controller context.

In this lesson, implementing implicit enhancements is discussed in detail. BesidesBAdIs, explicit enhancement options are not available for ABAP Web Dynpro yet.



Figure 95: Enhancements: Web Dynpro Application without enhancements

Figure 96: Enhancements: Same Web Dynpro application withenhancements



Enhancements in DetailThe following Web Dynpro entities can be enhanced modification-free using thenew enhancement framework. The first list contains the enhancement options forall kinds of Web Dynpro controllers.

� At the beginning and at the end of each method, pre-exit and post-exitmethods can be created that are called at the beginning of this method or atthe end of this method, respectively.

� New ordinary methods can be created.� New supply functions can be created.� New event handler methods can be created.� New attributes can be created.� New context attributes can be added to an existing context node.� New context nodes can be created.� The list of used components/controllers can be extended statically (as of

SAP NetWeaver 7.0, SP13 and later).

Additional enhancement options exist for view controllers:

� New inbound plugs and outbound plugs can be added.� New actions can be created.� Existing UI elements can be removed, new UI elements can be added to the

UI element hierarchy.� New views can be created (as of SAP NetWeaver 7.0, SP13 and later).

For window controllers, the following additional enhancement options do exist:

� New inbound plugs and outbound plugs can be added.� Existing navigation links can be removed, new navigation links can be

defined.� New windows can be created (as of SAP NetWeaver 7.0, SP13 and later).

For Web Dynpro components, the list of used components can be extendedstatically (as of SAP NetWeaver 7.0, SP13 and later).

The following enhancement options do not exist for SAP NetWeaver 7.0:

� Create new custom controllers� Create new events in existing controllers� Enhance component interfaces



Creating an Enhancement ImplementationIn order to use a predefined enhancement option, an enhancement implementationhas to be created and activated.

Hint: Enhancing of Web Dynpro controllers is only possible, if the relatedWeb Dynpro components belong to a software component having thecorrect system change settings (Transaction SE06).

Figure 97: Prerequisite for enhancing repository objects: Adequate systemchange settings

Hint: Deactivating enhancement implementations is only possiblevia the switch framework. To use this functionality, the enhancementimplementations have to be stored in a package that is assigned to aswitch (Transaction SFW1). In addition, this switch has to be assigned toa business function (Transaction SFW2). Then, activating / deactivatingthe enhancement implementations can be realized by switching on therelated business function using transaction SFW5.

To create an enhancement implementation for any Web Dynpro controller, thecontroller object has to be displayed (not edited) in the ABAP Workbench. Next,for switching to the enhancement implementation mode, the related icon in thebutton bar has to be pressed (or menu entry <left menu>→Enhance, or key



combination Ctrl + F4). A dialog box will pop up asking for the name of theenhancement implementation to use. You can either create a new enhancementimplementation or you can select an existing one if available.

To switch back to the display mode of the controller, the button to toggle betweenthe display mode and the change mode has to be pressed once (or menu entry <leftmenu>→Display <-> Change, or key combination Ctrl + F1).

Figure 98: Creating / extending an enhancement implementation

Enhancements for all Controller TypesOn the tab Methods, the hook methods, ordinary methods, supply functions, andevent handler methods are displayed. Having switched to the enhancement mode,additional user defined methods can be added to this list and the source code canbe entered as if these methods were defined in the edit mode.

For existing methods, the source code can not be modified, but coding blocks thatare processed before the method's source code (pre-exits) and after the method'ssource code (post-exit) can be defined. To do this, two buttons are available inthe line displaying the method's name. These buttons are located in columns withthe title Pre-Exit and Post-Exit, respectively. Pressing such a button will open therelated coding block in the edit mode.



Figure 99: Enhancements: Creating new methods, pre-exits and post-exits

For the pre-exit method, all importing and changing parameters of thecorresponding controller method are automatically provided. Export parametersand returning parameters are not accessible.

For the post-exit methods, all import and changing parameters of the relatedcontroller method are provided. Export parameters and returning parameters ofthe controller method are provided as changing parameters.



Figure 100: Pre-exits and post-exits: Processing flow

To delete pre-exit methods or post-exit methods, the related buttons on theMethods tab (above the table displaying the methods) have to be pressed. Thesame enhancement implementation has to be used for the creation and the deletionof these methods.

In the enhancement mode arbitrary attributes can be added to all kinds ofcontrollers. Existing attributes can not be changed. Deleting attributes definedby enhancements is possible, if the deletion is stored in the same enhancementimplementation that has been used before to create the attributes.



Figure 101: Enhancements: Defining new controller attributes

Context nodes can be added to the context of all controller types. This is not onlytrue for independent nodes but also for dependent nodes. There are no differencesbetween defining a node in the enhancement mode and in the edit mode. It is evenpossible to map context nodes defined by enhancement to other controllers.

Context attributes can be added to all context nodes. However, if the context nodeis typed with an ABAP Dictionary structure, only attributes related to the fields ofthis structure may be added. This is done via the context menu entry Create usingthe Wizard→ Attributes from Components of Structure.

Context nodes and context attributes defined by enhancement can be changed anddeleted again. However, the same enhancement implementation has to be used forthe creation and the deletion.

Context elements created in the edit mode can not be deleted by enhancementand their properties can not be changed.

Finally, for new context nodes supply functions can be created. Again, this doesnot differ from the way it is done in the edit mode.



Figure 102: Enhancements: Defining new context elements and map contextnodes

Additional Enhancements for View Controllers andWindow ControllersFor view controllers and for window controllers, additional outbound plugs andinbound plugs can be created in the enhancement mode. The single steps ofdefining plugs, outbound plug parameters and for inbound plugs the method'ssource code and signature do not differ from creating these entities in the editmode. Creating, changing, or deleting plugs is only possible in one and the sameenhancement implementation.



Figure 103: Enhancements: Defining new plugs

New actions can be defined in view controllers. The single steps of definingactions, the method's source code, and its signature do not differ from creatingthese entities in the edit mode. Creating, changing, or deleting actions is onlypossible in one and the same enhancement implementation.



Figure 104: Enhancements: Defining new actions

For window controllers, navigation links can be deleted (suppressed) viaenhancement. New navigation links, connecting plugs that are defined staticallyor via enhancement, can be created. Navigation links deleted by enhancementsare still displayed in the window. However, in the property list for these links anadditional line appears indicating by which enhancement implementation thislink is hidden. For the new links defined by enhancement a corresponding lineis added indicating, by which enhancement implementation the new link wascreated. Creating new navigation links and deleting them again has to be stored inthe same enhancement implementation. The same rule applies for suppressing anddisplaying again statically defined navigation links.

By combining the enhancement options to create new actions, new plugs, andto change the navigation, the sequence of the view assemblies and the reactionon user input can be changed without having to modify the Web Dynprocomponent. However, creating new views and embedding these views in existingviewUIElementContainers is not possible before SAP NetWeaver 7.0 SP13. Forsystems without SP13, the possibility to dynamically change the UI elementhierarchy of each view (from the pre-exit or from the post-exit method of thehook method wddomodifyview()) in combination with the possibility to define andtrigger the navigation dynamically serves as a replacement.

Hint: Changing navigation links using enhancement implementations cancause inconsistencies. Steps that are technically required for the businesslogic can be suppressed in the navigation sequence. Thus, data required ata later point of time may not be set.



Figure 105: Enhancements: Change navigation between views

The last modification-free changes provided by enhancement options are changesof the UI element hierarchy related to a view's layout. Existing UI elements can beremoved and new UI elements can be attached to each container UI element.

Removing an existing UI element does not mean that it is deleted from the UIelement hierarchy. It is still visible at design time. However, at runtime thiselement will not be processed at all, so it will not leave its marks in the generatedUI. This is different from an UI element having the property visible = none, sincesuch an element still occupies space in the rendered UI.

Hint: UI elements removed by enhancement are not accessible at runtime.This has to be taken into account - especially when accessing the UIelements dynamically (method wddomodifyview()).

Creating new UI elements and deleting them again has to be stored in the sameenhancement implementation. The same rule applies for suppressing existing UIelements and displaying them again.



Figure 106: Enhancements: Changing the view's layout

Additional informationIn this section additional information in respect to enhancing Web Dynproapplications is summarized.

Displaying Enhancement ImplementationsThe enhancement implementations created to adopt Web Dynpro applicationshave been assigned to a package. The object tree of this package contains a nodelabeled Enhancements with a sub node Enhancement Implementations. From thecontext menu of an enhancement implementation located in this node, the relatedchanges stored in this enhancement implementation can be displayed.

Depending on the type of implemented enhancement option, the changes can befound in one of the tabs with the labels Layout, Context, Navigation, Methods,Attributes, or Plugs/Actions. On all of these tabs, a button is displayed labeledwith the name of the Web Dynpro component that is enhanced by the enhancementimplementation displayed. Pressing this button allows to navigate to this WebDynpro component.

The tab Technical Details contains the information which controllers of theenhanced Web Dynpro component have been changed. The tab History containsthe log of all changes stored in this enhancement implementation. Finally,information about the last person changing the enhancement implementation andthe related date, the description visible in the object tree, and so on are displayedon the tab Properties.



From the context menu of an enhancement implementation displayed in the objecttree, it is also possible to select the entry Change. However, only the descriptionof the enhancement implementation can be changed this way.

Figure 107: Displaying enhancement implementations

Name Space: RecommendationsThere is no general customer name space (e.g. Z*) for objects that can be createdinside an enhancement within Web Dynpro. Therefore naming conflicts can occur.

To avoid naming conflicts (e.g. during upgrade) it is highly recommended to usean own customer name space for the enhancement implementation object and allembedded objects (e.g. controller attributes, plugs, actions, context nodes ...).

Hint: See OSS note 84282 (�Development name space for customers andpartners�) for registering a customer name space.



Exercise 6: Enhancements for ABAP WebDynpro (optional exercise)

Exercise ObjectivesAfter completing this exercise, you will be able to:� Enhance the controller context.� Enhance the view layout.� Assign a supply function to a context node by enhancement.

Business ExampleUsing personalization you can hide information displayed by the components.However, you want to display additional data on the MAIN_VIEW of your maincomponent and on the DETAILS_VIEW of your sub component displaying thecomplete flight data set. This can be achieved by enhancing these two components.

Template Component: NET311_P13N_S

Template Sub Components: NET311_P13N_C1_S, NET311_P13N_C2_S

Solution Main Component: NET311_ENH_S

Solution Sub Components: NET311_ENH_C1_S, NET311_ENH_C2_S

Task 1:If you have finished the previous exercise, you can skip this task. Then, all changescan be implemented in the components you have created in your last exercise.

If you have not finished your last exercise, you can start with a copy ofthe template components. In this case, copy the template components listedabove and name the copies ZNET311_ENH_##, ZNET311_ENH_##_C1, andZNET311_ENH_##_C2, respectively. Assign these components to your packageZNET311_##. Create an application for component ZNET311_P13N_## havingthe same name as this component and assign the application to your package, too.

Adapt the value of the property Default Value for the context attributeSUB_COMP_INFO.NAME. This attribute is defined in the configurationcontroller of your main component.

Adapt the source code of method SET_VALUE_SET( ) defined in the viewPERS_VIEW of your main component. Make sure that the names of your own subcomponents are stored in the internal table LT_VALUE SET.






3. Adapt the value of the property Default Value for the context attributeSUB_COMP_INFO.NAME defined in the configuration controller of themain component.

4. Adapt the source code of method SET_VALUE_SET( ) defined in the viewPERS_VIEW of your main component. Make sure that the names of yourown sub components are stored in the internal table LT_VALUE SET.

Task 2:Enhance your main component. Display additional columns (SEATSMAX,SEATSOCC, and PAYMENTSUM) in the flight table of view MAIN_VIEW.

1. Display the component controller context of your main component. Open thenode FLIGHTS. Switch to the enhancement mode. Create the enhancementimplementation ZNET311_##_ENH to save your changes.

2. Add the attributes SEATSMAX, SEATSOCC, and PAYMENTSUM to thecontext node FLIGHTS.

3. Enhance the context of view MAIN_VIEW: Update the mapping of nodeFLIGHTS.

4. Add columns to the flight table to display the attributes you have addedin step 2 of this task.

5. Activate the enhancement implementation and test the result.

Task 3:Enhance your sub component used to display the complete flight data set forthe selected flight.

In addition to the flight data set, the details of the plane used for this flight shouldbe displayed. The plane information has not been read yet. Thus, a method has tobe created in the component controller to read the flight information. In addition,a new context node has to be defined in the component controller context to storethe data. The flight information should be displayed by a form that is located rightof the form displaying the flight data set.

1. Display the component controller of the sub component used to displaythe complete flight data set. Switch to the enhancement mode. Create anew enhancement implementation (name: ZNET311_##_C2_ENH) to saveyour changes.

2. Create a new node (name: PLANE, type: NET311_S_SAPLANE,cardinality: (1:1)) being a sub node of node FLIGHTS. Add an attribute tothe context node for each field of the structure except for the field CLIENT.

3. Create a supply function (name: GET_PLANE_DETAILS( )) and assignthis method to the node PLANE.




4. Implement the supply function. Read the plane information for the selectedflight and store the data in the context node PLANE. To read the planeinformation, call the static method READ_PLANE( ) defined in classCL_NET310_FLIGHTMODEL.

5. Update the mapping of node FLIGHT in the context of viewDETAILS_VIEW.

6. Enhance the layout of view DETAILS_VIEW. Create a group as a new childelement of the ROOTUIELEMENTCONTAINER. Inside this group create acontainer form for all fields of node PLANE. Choose TextView UI elementsto display the attribute values.

7. Activate your enhancement and test the result.



Solution 6: Enhancements for ABAP WebDynpro (optional exercise)Task 1:If you have finished the previous exercise, you can skip this task. Then, all changescan be implemented in the components you have created in your last exercise.

If you have not finished your last exercise, you can start with a copy ofthe template components. In this case, copy the template components listedabove and name the copies ZNET311_ENH_##, ZNET311_ENH_##_C1, andZNET311_ENH_##_C2, respectively. Assign these components to your packageZNET311_##. Create an application for component ZNET311_P13N_## havingthe same name as this component and assign the application to your package, too.

Adapt the value of the property Default Value for the context attributeSUB_COMP_INFO.NAME. This attribute is defined in the configurationcontroller of your main component.

Adapt the source code of method SET_VALUE_SET( ) defined in the viewPERS_VIEW of your main component. Make sure that the names of your own subcomponents are stored in the internal table LT_VALUE SET.


a) Display the template components in the object tree. Clicking on anycomponent with the right mouse button will open the component'scontext menu. Choose Copy.... Enter the name of the component to becreated. Press Continue.

b) Adapt the descriptions of the new components.


a) An application having the same name as the component can be createdfrom the context menu of the main component.





3. Adapt the value of the property Default Value for the context attributeSUB_COMP_INFO.NAME defined in the configuration controller of themain component.

a) Edit the configuration controller context of the main component.

b) Open node SUB_COMP_INFO and mark the attribute NAME.

c) Change the value of the property Default Value to the name of one ofyour sub components you have copied in this task.

Hint: The name of the sub component has to be written inupper case letters.

4. Adapt the source code of method SET_VALUE_SET( ) defined in the viewPERS_VIEW of your main component. Make sure that the names of yourown sub components are stored in the internal table LT_VALUE SET.

a) In the source code the name of the template sub components are storedin the variable LS_VALUE_SET-VALUE. Replace the names of thetemplate sub components by the names of your own sub components.

Hint: The names of your sub components have to be writtenin upper case letters.

Task 2:Enhance your main component. Display additional columns (SEATSMAX,SEATSOCC, and PAYMENTSUM) in the flight table of view MAIN_VIEW.

1. Display the component controller context of your main component. Open thenode FLIGHTS. Switch to the enhancement mode. Create the enhancementimplementation ZNET311_##_ENH to save your changes.

a) Choose the menu entry Controller→ Enhance to switch to theenhancement mode.

b) In the dialog box that pops up, enter ZNET311_##_ENH in the namewith label Enhancement Implementation and a short text in the fieldbelow. Press Enter.

c) Assign the enhancement implementation to your package.




2. Add the attributes SEATSMAX, SEATSOCC, and PAYMENTSUM to thecontext node FLIGHTS.

a) Use the menu entry Create Using the Wizard→ Attributes fromComponents of Structure from the context menu of node FLIGHT toselect the additional attributes.

b) Save.

3. Enhance the context of view MAIN_VIEW: Update the mapping of nodeFLIGHTS.

a) Display the view MAIN_VIEW. Switch to the enhancement mode.When being asked for the enhancement implementation, choose theone you have created in step 1 of this task.

b) Select the Context tab. Select the node FLIGHTS. From the contextmenu of this node, choose the entry Update Mapping.

c) Save.

4. Add columns to the flight table to display the attributes you have addedin step 2 of this task.

a) From the context menu of the Table UI element displayed in viewMAIN_VIEWchoose Insert Table Column to create a new column.Repeat this step two times.

b) Adopt the names of the new columns and the names of the columnheaders that have been created with the columns. Choose the namesaccording to the pattern used for the existing columns and columnheaders.

c) For each of the new columns insert a table cell editor (choose InsertTable Cell Editor from the context menu of the TableColumn UIelement). Use TextView UI elements as table cell editors for allcolumns. Choose the names according to the pattern used for theexisting table cell editors.

d) Bind the property text of the table cell editor UI elements to thecorresponding attributes of the view controller context.

e) Save.

5. Activate the enhancement implementation and test the result.

a) Activate as usual. Start your application. The flight table should nowdisplay three additional columns.




Task 3:Enhance your sub component used to display the complete flight data set forthe selected flight.

In addition to the flight data set, the details of the plane used for this flight shouldbe displayed. The plane information has not been read yet. Thus, a method has tobe created in the component controller to read the flight information. In addition,a new context node has to be defined in the component controller context to storethe data. The flight information should be displayed by a form that is located rightof the form displaying the flight data set.

1. Display the component controller of the sub component used to displaythe complete flight data set. Switch to the enhancement mode. Create anew enhancement implementation (name: ZNET311_##_C2_ENH) to saveyour changes.

a) Proceed as described in the step 1 of the last task.

2. Create a new node (name: PLANE, type: NET311_S_SAPLANE,cardinality: (1:1)) being a sub node of node FLIGHTS. Add an attribute tothe context node for each field of the structure except for the field CLIENT.

a) The creation of the sub node PLANE in the enhancement mode is notdifferent from the creation in the edit mode.

3. Create a supply function (name: GET_PLANE_DETAILS( )) and assignthis method to the node PLANE.

a) Mark the node PLANE. Enter the name of the supply function in theinput field related to the node property Supply Function. PressingEnter will create the method.

4. Implement the supply function. Read the plane information for the selectedflight and store the data in the context node PLANE. To read the planeinformation, call the static method READ_PLANE( ) defined in classCL_NET310_FLIGHTMODEL.

a) The reference to the element at lead selection of node FLIGHTis provided by the interface parameter PARENT_ELEMENT. Thereference to the collection for node PLANE is provided by the interfaceparameter NODE.





5. Update the mapping of node FLIGHT in the context of viewDETAILS_VIEW.

a) Display the view DETAILS_VIEW and switch to the enhancementmode. Save your changes in the enhancement implementationZNET311_##_ENH created in step 1 of this task.

b) Update the mapping of node FLIGHT. This does not differ from theprocedure in the edit mode.

6. Enhance the layout of view DETAILS_VIEW. Create a group as a new childelement of the ROOTUIELEMENTCONTAINER. Inside this group create acontainer form for all fields of node PLANE. Choose TextView UI elementsto display the attribute values.

a) From the context menu of the ROOTUIELEMENTCONTAINER,choose Insert Element. Create a Group UI element. Set the propertiesLayout to MatrixLayout and height to 100%.

b) Set the text for the group caption.

c) From the context menu of the group created in this step, choose CreateContainer Form. Choose TextView as the standard cell editor. Create afrom field for all attributes of node PLANE.

d) Optimize the design by setting the property LayoutData toMatrixHeadData for all labels. This allows to define a line break for alllabel UI elements. You could also place the units behind the physicalquantities.




7. Activate your enhancement and test the result.

a) Your sub component does not only display the complete flight data set,but also the complete information of the plane used for this flight.

Result

Component ZNET311_##_C2 - Comp.Controller: GET_PLANE_DETAILS( )

METHOD get_plane_details .

DATA: ls_flight TYPE if_componentcontroller=>element_flight,

lv_planetype LIKE ls_flight-planetype,

ls_plane_info TYPE saplane.

* Get planetype from selected flight

parent_element->get_attribute(

EXPORTING

name = ‘PLANETYPE‘

IMPORTING

value = lv_planetype ).

* read complete plane data set

CALL METHOD cl_net310_flightmodel=>read_plane

EXPORTING

i_planetype = lv_planetype

IMPORTING

e_plane_info = ls_plane_info.

* store plane data set in context

node->bind_structure( ls_plane_info ).

ENDMETHOD.



Lesson Summary

You should now be able to:� Know all possible enhancement possibilities for ABAP Web Dynpro.� Enhance ABAP Web Dynpro applications modification-free.

Related Information

� General information about the concept of the new enhancementframework and the switch framework can be found in the help portal(http://help.sap.com) for the SAP NetWeaver 7.0 by entering the terms inthe search field.

� The enhancement of ABAP Web Dynpro components is described in the helpportal as a subtopic of Development in Detail→ Advanced Concepts .

� The system demo WDR_TEST_ENHANCEMENTS is availablein all SAP systems based on SAP NetWaever 7.0. Here, theenhancement implementations WDR_TEST_ENHANCEMENTS andWDR_TEST_ENHANCEMENTS_2 have been used to change the layout ofviews, to add a context attribute to a context node, to change the navigation,to add actions, inbound plugs, and outbound plugs.


http://help.sap.com

NET311 Unit Summary

Unit SummaryYou should now be able to:� Know all possible enhancement possibilities for ABAP Web Dynpro.� Enhance ABAP Web Dynpro applications modification-free.

Related Information




http://sdn.sap.com


Course Summary NET311

Course SummaryYou should now 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.� Define and use configuration, customizing and personalization of Web

Dynpro applications.� Enhance existing Web Dynpro components.


Appendix 1Tips & Tricks for efficient Programming

Number, Size, and Genericness of ComponentsThe Ideal Design of a ComponentCommunication between components requires work and makes the performanceof the application suffer. Despite this, you should not make each componenttoo big. You need to balance these requirements, while making sure that eachcomponent is a self-contained logical unit. You must always prevent differentdevelopment groups from working on the same component. We have put togetherthe following guideline for the optimum number of views in a component:

Hint: Whenever possible, restrict your components to a maximum of 15views.

Make sure that the number of controllers used by each controller doesnot exceed 8.

Remember, at runtime you create a load from your components. The size of thisload depends to a great extend on the number of views, UI elements, controllers,controller usages, and the size of the context nodes. If this load is too big, thesystem produces a warning telling you that limited resources are available atruntime for the WDA application. Performance drops.


Appendix 1: Tips & Tricks for efficient Programming NET311

View or ComponentA component is a reusable unit in the Web Dynpro Framework. A view canbe displayed only once within a component; a component, however, can beinstantiated multiple times. This means that, if you want a view to appear morethan once in a window, you must make it a separate component and reuse itmultiple times in a different component.

Hint: A component is a visual unit. For this reason, we recommendthat you embed only one interface view on the window of the "using"component for each declared component usage.

Model ComponentsWe no longer recommend that you create special model components, since theydo not offer any benefits over model classes. One alternative is to use a sharedassistance class to provide a model (see Context).

The Genericness of Web Dynpro ComponentsGeneric components are more difficult to maintain than explicitly programmedcomponents, which is why we recommend that you make all your componentsonly as generic as they absolutely need to be. This requirement needs to bebalanced with the demands of distributed application development groups. Thesegroups need to provide generic components that are then, for example, given auniform layout at a later time or by a different group.

Hint: As a guideline, we recommend that you make your applicationsgeneric to the extent that, when the resulting component is configured,around 80% of all applications are covered. Do not try to make yourcomponent more generic just to cover the remaining 20% of thepossibilities.

ContextA context in Web Dynpro ABAP is a complex construct that gives you greatfreedom when you design your applications. The way an application handlesquantities of data is usually of great significance for its performance; as adeveloper, you have an opportunity here to control the time needed by yourapplication, but there are also risks to consider. Today, performance optimizationis important for many applications, particularly more complex applications, and


NET311 Appendix 1: Tips & Tricks for efficient Programming

must be considered in the design of every new application or application group.The following sections offer you a range of useful information about how best touse various context properties and context features.

Hint: If you want to use an element in multiple contexts, but intend tomodify it only rarely if at all, it is best to create a copy of the elementin the appropriate context.

You must, however, ensure that the data always remains consistent. Anotheroption is to store the content of the context node as an internal table initially, andto store it as an actual context node only within the relevant view.

Caution: Define a mapping to context nodes of used components onlyin exceptional cases.

This can cause a drop in performance, and any changes within the used componentcan cause errors in the main component.

Hint: An alternative to this is the shared usage of an assistance classinstance.

Handling Context MappingsA context mapping is a mechanism that enables you to make static connectionsbetween different contexts in different controllers. If, for example, you require aset of data in exactly the same structure but in two different views, it is a goodidea to configure a suitable context node in the component controller. In a singleaction, you can then create a copy of the component controller node for eachview controller in the Workbench's View Editor; at the same time, a mapping tothe original node is created. This procedure is both easy to implement and verysecure. It does, however, encourage you to start designing contexts in a componentby designing the component controller context first, and then only defining therequired mappings for the view contexts. Depending of the size of the contextnode (number and structure of the subnodes, and the absolute size of the data), thiscan have a significant effect on the performance of the application. To avoid usingsuperfluous mappings in your component, consider carefully which context nodesyou actually require in multiple contexts, and which nodes you only require locally.

A context node is not filled until the corresponding context is called for the firsttime. Unlike a context node mapped to a central node, a context node createdlocally is empty, until the corresponding view is accessed. To avoid errors indialogs, it is a good idea to provide the data for the context of the follow-on viewbefore the actual navigation step is triggered. Since an instance of the follow-onview has not yet been created, you must now decide whether to configure acomponent controller context with an appropriate mapping, or whether to fetchand check the data in an auxiliary class first and only pass it to the context of the



follow-on view after navigation is completed. An application developer would,of course, prefer to use the context mapping method; using an auxiliary class,however, improves performance significantly.

Dynamically Created Attributes or Dynamically Created NodesBoth context nodes and context attributes can be created dynamically in the WebDynpro ABAP framework. The dynamic creation of these features is relevantfrom a performance perspective, but is not particularly significant if only oneattribute is being created.

Hint: If you want to create multiple attributes for a context nodedynamically and in parallel, it is a much better idea to first create astructure. The whole of the new node is then created in a single step.

For an example of the dynamic creation of a node from a structure, refer to the WebDynpro application DEMODYNAMIC in the package SWDP_DEMO in yoursystem. The method WDDOINIT in the view DYNAMIC_NODE_TYPE creates astructure first and then the required node information is created from this structure.

Singleton NodeThe "Singleton" property of a context node is described in the architecture manualfor Web Dynpro in the chapter Context Node: Properties. When you create acontext node below the root node, the "Singleton" checkbox is selected by default.If you have deep data structures with large amounts of data, we recommendthat you consider only loading the data for the selected element of the mainnode into the memory. The other factor that you need to consider, however, isthe performance loss connected to the required invalidation and refilling of thecorresponding context node or nodes. You need to decide whether to minimize thememory load created by large amounts of data or minimize the runtime caused byinvalidation and filling actions.

Hint: Use singleton nodes only if the data in the memory will reach acritical amount if you take no action. If not, you may prefer to work withnon-singleton nodes and delete any data that you do not yet need, or willnever need, from the memory explicitly.

Filling the Context: The Supply FunctionThe "Supply" function lets you supply a node with data only when required. Thesupply function is not called until the content of the node is actually neededat runtime (and only then). Since runtime controls when the supply function iscalled (and not the code created by the application developer), it is especiallyimportant that no errors occur when the data is retrieved. For this reason, use thesupply function only if you know that the data is available and correct in the back



end. Supply functions are especially suited for filling subnodes, whether they aresingleton nodes or non-singleton nodes. However, you must note the following:The required content of a subnode can be dependent only on one element of thecorresponding superordinate node. This is the only way of ensuring that instancesof all required nodes are created and that the values exist.

Caution: A cascading call of two or more supply functions is invalidand causes a runtime error.

Hint: Therefore, if you need to access the data of a superordinate nodeother than the direct superordinate node to fill a context node, do not usethe supply function.

Instead, program the required data retrieval function in an appropriate eventhandler method. If this is really not possible, at least ensure that any runtimeerrors are caught and handled correctly. If you want to trigger the call of a supplyfunction explicitly before the content of the node is used for the first time, youcan use the method get_element (). A supply function always recognizes theparameters PARENT_ELEMENT and NODE automatically. The parameterPARENT_ELEMENT is a reference to the element of the superordinate node,whose value must be read to retrieve the data; the parameter NODE, however, is areference to the node that is filled by the supply function. You must use these twoparameters. It is much more difficult to use a generic method involving genericcontext methods. There are no real benefits and it is also more prone to errors.

Caution: Make sure that you never modify the CONTEXT_NODE_INFOof a context node within a supply function. A supply function must alsonever modify the ValueSet of a node.

This causes complications since the order of the steps performed at runtime mayno longer match the values.

Context Change LogUse the Context Change Log functions to detect user input. This has particularperformance benefits while a user of the application modifies only a small amountof data in a view while displaying a large amount of mixed data.

Data Types in a Context Node: Internal and External Data TypesWhen an editable field is filled with values in the user interface of a businessapplication, these characters are initially in an external format for the Web DynproABAP application. Only when processed are these characters checked andtransformed to an appropriate internal format.



The context attribute for the value of the input and the context attribute for thecurrency must share a node (here the node input_node). Otherwise the valuecannot be assigned to the data type. If, for example, you use a wizard to generatethe node from an existing ABAP Dictionary structure, the required referenceof the value attribute to the data type attribute is created automatically, sincethe reference structure is usually the same as the ABAP Dictionary structure.In very rare exceptions, however, the reference structure can be taken froma different ABAP Dictionary structure. In this case, the reference structurecannot be located in the node created by the wizard and the reference type isunknown at runtime. You must configure the reference manually. To enablethis, the interface IF_WD_CONTEXT_NODE_INFO includes the methodSET_ATTRIBUTE_REFERENCE_FIELD. If a reference fields does not exist atruntime or is not recognized, a default format applies (with two decimal places)The value of a price or quantity field must always be a packed number (in BCDformat).

Hint: Since the application may at some point be required to handlecurrencies that do not use two decimal places (such the Japanese Yen),you must run comprehensive tests on the application programs.

Data Input

� All data input is checked and transformed in accordance with the referenceddata type. Corrections may be made, such as when the year in a date wasentered as two digits and the two missing digits are obvious and can be added.

� Conversion exits are called automatically. Any conversion errors aredisplayed.

� For prices and quantities, the system first finds the reference field and thenconverts the input accordingly.

� If a ValueSet exists for the attribute whose values is entered by the user, theconversion checks whether the input value is actually part of the ValueSet.

� Conversions from external formats to internal formats retain any spacecharacters in string and character input. This is not the case for other datatypes, unless the format has been modified explicitly by the applicationdeveloper. A developer can do this by dynamic manipulation ofCONTEXT_NODE_INFO.



Data Output

� Internal data formats are also converted to external data formatsautomatically. The conversion includes any local user settings, such as localoutput formats or dates and times.

� Any conversion exits declared in the data element are called.� Digits are displayed with or without a leading zero, depending on the data

type.� You can change some formatting properties of context attributes, depending

on the data type. CONTEXT_NODE_INFO is modified dynamically toenable this.

� If the output consists of packed numbers, the sign is placed to the right of thenumber by default. All other data types place the sign on the left.

ControllerHandling Controller MethodsAs well as contexts, a controller also includes methods for handling the valuesof the context attributes, and for triggering and handling events. Importantinformation about this is available in the Programming Manual for Web Dynprofor ABAP. Alongside these predefined method structures, you can create yourown methods and call them from your application. The greater the size of aWeb Dynpro application, the more effective it becomes to move its logic intoseparate auxiliary classes. This makes the methods much more flexible, sinceyou can use these auxiliary classes in other application. Web Dynpro Frameworkitself implements an assistance class. The inherited type of this class gives itspecial properties that can be used as appropriate by Web Dynpro Framework. Inaddition, you can create your own auxiliary classes and structure them to matchyour application landscape. Independent auxiliary classes have the additionalbenefit of optional parameters.

Hint: Remember that the methods from auxiliary and assistance classescan be called directly from view controllers as well.

Handling Method AttributesWe also recommend that you create method attributes in separate auxiliary classes,and reference them from the Web Dynpro methods.

Events

Caution: Events and event handling in Web Dynpro for ABAP are notidentical to the similar concepts in ABAP.



In particular, events can be caught and handled only if a controller usage is enteredfor both controllers involved.

Notes on Assistance ClassesAssistance classes are instantiated with their component.

Hint: From SAP NetWeaver 7.0 SP10, you can, in principle, useassistance classes outside of their component. This is particularly usefulwith reference to model interfaces.

If a particular assistance class is accessed from various components in acomponent chain, it makes sense to create the class in the main component andthen pass it to the subcomponents.

User InterfaceYou have many different UI elements at your disposal when designing the userinterface of a Web Dynpro ABAP application, and you can combine and nest theseelements in many different ways. The latter aspect of UI design can, however,cause overly complex views to be created that not only tax the user but are alsobad for the application's performance. For these reasons, always avoid making thestructures in your views overly complex if at all possible.

The Matrix LayoutIn a view layout with a regular level of complexity, always use the matrix layouteven if the default setting of the View Editor is a flow layout. A matrix layoutbenefits you by providing several formatting utilities that are otherwise verydifficult to design. A matrix layout is not, however, suitable if you want your viewto have a very simple layout. In this case, use a flow layout or grid layout forperformance reasons. In a matrix layout, the properties strechedHorizontally andstrechedVertically are set by default.

Hint: Disable the strechedVertically property, since it can often causebrowser errors at runtime.

For UI elements embedded in matrix layout, you can define vales for height andwidth under LayoutData. The values you enter here are defined as pixel values("px") by default. You can change this unit from "px" to "em" or "ex" (see theCSS Standards).



Dynamic ProgrammingWeb Dynpro ABAP enables you to manipulate the view layout dynamically, whichmeans you can create, modify, or remove specific UI elements at runtime. Theuser of the application can personalize some properties of UI elements though,making the application developer unaware of the values of these properties.

Example:

The property visibleRowCount of the table element of a view was set to 10 atdesign time. At runtime, however, a user sets a personalized value of 15. Thisproduces two aspects that need to be handled by dynamic manipulation:

� You cannot program a dynamic modification of the table element forwhich the personalized value of the visibleRowCount property is required,since runtime cannot access this value. If you retrieve the value ofvisibleRowCount here, runtime always produces the initial value 10 and notthe personalized value 15.

Hint: To avoid errors, you must never base the dynamicmanipulation of a UI element on a value that can be personalized.

� If you modify an element property, the modification is valid only if the userdoes not personalize the property. In our example, it is possible that thevisibleRowCount property is raised dynamically to 12. All users that have notpersonalized this property are given a table with 12 visible rows. Any userwho have personalized this property are given a table with their number ofrows, 15 in our example. The personalized values are always given priority.

Hint: If you use dynamic methods to create a UI element, make sure thatyou give each element an element ID.

Technically, this is an optional property, but it is a great help when the elementis processed. Implicit personalization can work only if an ID is set, since stableassignments of values can only be made to the same UI element. If you do notdefine an element ID, the elements are given new random IDs each time they arecalled and the personalized values cannot be assigned.

You often do not know how many elements need to be created at design time. Forexample, if you want to create a form dynamically, and you do not know its contextnodes at design time, you must assign element IDs generically. In this case,ensure that your chosen algorithm provides unique results. Simply numberingthe elements sequentially is not enough to ensure that each dynamic UI elementappears in the right position in the view. For example, a "Price" attribute mayappear as the third attribute in node A, but as the fifth attribute in the structure innode B. In this case, it is more effective to use the attribute name as the element ID.



The ALV ComponentThe ALV component offers application developers a range of integrated servicesthat they can use directly without any additional programming work. Theseservices include functions such as filters, sort functions, and total functions.However, each additional ALV component you use increases runtime significantly;the table UI control is quicker for displaying simple tables.

Hint: Use the ALV component only if you are sure you need its extrafunctions. Always choose a simple Web Dynpro table if sufficient foryour application.

When you use an ALV component, you can pass the data for display using either aregular cross-component mapping or an external context mapping.

Configuration OptionsMake use of the personalization and configuration options when you developyour applications. When you create generic components, however, rememberthat subsequent application developers may themselves want to add dynamicUI elements. It is not a good idea to define a maximum set of UI elements atthe beginning and assume that many of these elements will be deactivated later.Restrict yourself only to those elements that you actually need when you createyour components.

Multiple Parallel ApplicationsSeparate Roll AreasEach Web Dynpro application runs in its own role area. Multiple applications canrun in parallel or communicate with each other only if one of the following is used:

� The database� Shared objects/shared memory� Portal events

For this reason, it is not possible to close an application by closing anotherapplication (that is, closing a browser window).

Hint: You must therefore make sure that a self-contained task createsonly one application.

This reduces both programming work and the number of browser windows forthe user.



Dialog BoxDialog boxes (often called popups) are special display elements that openalongside a running application. Dialog boxes always start a separate phase modelinstance, which means that their source window cannot be refreshed or editedwhile the dialog box is open (while the phase model instance still exists).

You can avoid dialog boxes in many cases by displaying content in an additionalwindow view.

This removes the source of many errors and improves performance. Modelessdialog boxes are not supported.

Using Components and Component InterfacesComponents and Interface DefinitionsThe Web Dynpro Framework enables you to use functions and data from onecomponent in another by using a component in another component. A prerequisitefor this is that a usage declaration is created in the "using" component at designtime. This itself requires the used component to exist and be recognized by itsname. This is not always the case, however. To help you in cases when theused component cannot be identified, Web Dynpro Framework offers a lessrigid technology: Component interface definitions. In this case, you first enterthe usage of a separately defined component interface. All components thatimplement precisely this interface definition can now be used by means of theusage declaration from the main component. The concrete implementation of thismethod is passed as a parameter at runtime.

Example:

If a component wants to embed two components that are not yet known atdesign time, all components that are able to be embedded must implement acommon interface definition. The calling component creates two usages for theinterface. At runtime, the implementation is passed as a parameter when the usedcomponents or interfaces are created.

General Information About Handling Interfaces

� A component can implement multiple interfaces.� Interfaces cannot be inherited.� You can implement interfaces in the Application Configuration or by calling

them as URL parameters.

Caution: Interfaces do not implement their own name spaces. Werecommend strongly that you use prefixes when you name your interfaces.



Implementation of Interfaces for Customer DevelopmentsUsing interfaces in a Web Dynpro component benefits customers by givingthem a clean basis for their own further developments. When creating a localdevelopment, you can implement a used interface in a separate component andadd your own aspects to an application delivered by SAP.

Component Usage GroupsIn certain circumstances, you may want a main component to use an individualcomponent more than once. To enable this, you can create multiple usages for thesame component. The same applies to the usage of interface definitions. As longas the number of used components is reasonable and known already at designtime, we recommend that you use a component usage group instead of a staticlist of individual usages. Component usage groups organize the dynamicallyprogrammed use of components or interface definitions.

Hint: Before you decide to use a solution that involves dynamiccomponent usages, remember that you also need to program navigationto any components whose use is implemented using component usagegroups. This makes navigation more complicated and also means that theapplication is more difficult to maintain.


IndexAadaptation, 135configuration, 141configuration controller,139customizing, 147hierarchy, 136implicit / explicit, 137options, 135personalization, 147personalization interface,139

adaptation hierarchy, 136Ccomponent interface, 90definition, 91implementation, 93

component reuse, 86clone components, 97components with sameinterface, 94dynamic componentusage, 107dynamic event handling,103dynamic navigation, 101interfaces of WD API, 88multiple usage of samecomponent, 97static usage / dynamicusage, 88

component usage groups, 108configuration, 141configuration controller, 139confirmation dialog box, 63controller interface, 33structure, 34WD_THIS, 33

customizing, 147explicit, 149

Ddialog box, 58confirmation dialog box,63display window of samecomponent, 67display window of usedcomponent, 70external, 61modal, 63types of dialog boxes, 58

Eenhancements, 178options, 179

external dialog box, 61IIF_<CONTROLLER>, 34IF_<CUST_CTRL>, 38IF_<VIEW>, 36IF_<WINDOW>, 37IF_COMPONENTCON-TROLLER, 39

IF_WD_COMPONENT, 40,44

IF_WD_COMPONENT_US-AGE, 88

IF_WD_COMPONENT_US-AGE_GROUP, 88

IF_WD_CONTROLLER, 40,43

IF_WD_PERSONALIZA-TION, 139

IF_WD_RR_COMPONENT,88


Index NET311

IF_WD_VIEW_CON-TROLLER, 40, 45

IF_WD_WINDOW, 59IF_WD_WINDOW_MAN-AGER, 59

IG_<CONTROLLER>, 34IG_<CUST_CTRL>, 38IG_<WINDOW>, 37IG_COMPONENTCON-TROLLER, 39

interface viewembed dynamically, 101

IWCI_<COMPONENT>, 34Mmodal dialog box, 63Ppersonalization, 147explicit, 149

personalization interface, 139popup (see dialog box), 58Ttips & tricks for efficientprogramming, 205

WWD_THIS, 33web dynpro API, 40WD_GET_API(), 40

Web Dynpro basicsaction, 4application, 3architecture, 2component, 2component controller, 2component interface, 11

component reuse, 11component reuse - callmethods, 14component reuse - contextmapping, 17component reuse -declaration, 11component reuse - embedinterface view, 13component reuse - handleevents, 15component reuse -instantiation, 12context mapping, 3controller attributes, 9controller events, 10controller methods, 7controller methods - orderof processing, 8controller usage, 3custom controller, 3data binding, 2interface controller, 4interface view, 3navigation, 4navigation link, 5navigation scheme, 5plugs, 4startup plug, 3used controller, 3user interface (UI), 2view, 2window, 2

Z(Z)IWCI_<COMPONENT>,34, 39


FeedbackSAP AG has made every effort in the preparation of this course to ensure theaccuracy and completeness of the materials. If you have any corrections orsuggestions for improvement, please record them in the appropriate place in thecourse evaluation.


NET311 Advanced ABAP Web Dynpro

Documents

Transcript of NET311 Advanced ABAP Web Dynpro