NET310
Fundamentals of Web Dynpro for
ABAP
SAP NetWeaver
Date
Training Center
Instructors
Education Website
Instructor Handbook
Course Version: 91
Course Duration: 5 Day(s)
Material Number: 50092901
Owner: Stefan Ehret (D025626)
An SAP Compass course - use it to learn, reference it for work
Copyright
Copyright © 2008 SAP AG. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any purpose without the
express permission of SAP AG. The information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software
components of other software vendors.
Trademarks
•
Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are
registered trademarks of Microsoft Corporation.
•
IBM®, DB2®, OS/2®, DB2/6000®, Parallel Sysplex®, MVS/ESA®, RS/6000®, AIX®, S/390®,
AS/400®, OS/390®, and OS/400® are registered trademarks of IBM Corporation.
•
ORACLE® is a registered trademark of ORACLE Corporation.
•
INFORMIX®-OnLine for SAP and INFORMIX® Dynamic ServerTM are registered trademarks
of Informix Software Incorporated.
•
UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group.
•
Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®,
VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarks of
Citrix Systems, Inc.
•
HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide
Web Consortium, Massachusetts Institute of Technology.
•
JAVA® is a registered trademark of Sun Microsystems, Inc.
•
JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used under license for
technology invented and implemented by Netscape.
•
SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP
EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.com are
trademarks or registered trademarks of SAP AG in Germany and in several other countries all
over the world. All other products mentioned are trademarks or registered trademarks of their
respective companies.
Disclaimer
THESE MATERIALS ARE PROVIDED BY SAP ON AN "AS IS" BASIS, AND SAP EXPRESSLY
DISCLAIMS ANY AND ALL WARRANTIES, EXPRESS OR APPLIED, INCLUDING WITHOUT
LIMITATION WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE, WITH RESPECT TO THESE MATERIALS AND THE SERVICE, INFORMATION, TEXT,
GRAPHICS, LINKS, OR ANY OTHER MATERIALS AND PRODUCTS CONTAINED HEREIN. IN
NO EVENT SHALL SAP BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL,
CONSEQUENTIAL, OR PUNITIVE DAMAGES OF ANY KIND WHATSOEVER, INCLUDING
WITHOUT LIMITATION LOST REVENUES OR LOST PROFITS, WHICH MAY RESULT FROM
THE USE OF THESE MATERIALS OR INCLUDED SOFTWARE COMPONENTS.
g200905473
About This Handbook
This handbook is intended to complement the instructor-led presentation of this
course, and serve as a source of reference. It is not suitable for self-study.
Typographic Conventions
American English is the standard used in this handbook. The following typographic
conventions are also used.
Type Style
Description
Example text
Words or characters that appear on the screen. These
include field names, screen titles, pushbuttons as well as
menu names, paths, and options.
Also used for cross-references to other documentation
both internal (in this documentation) and external (in
other locations, such as SAPNet).
2009
Example text
Emphasized words or phrases in body text, titles of
graphics, and tables
EXAMPLE TEXT
Names of elements in the system. These include report
names, program names, transaction codes, table names,
and individual key words of a programming language,
when surrounded by body text, for example SELECT
and INCLUDE.
Example text
Screen output. This includes file and directory names
and their paths, messages, names of variables and
parameters, and passages of the source text of a program.
Example text
Exact user entry. These are words and characters that
you enter in the system exactly as they appear in the
documentation.
<Example text>
Variable user entry. Pointed brackets indicate that you
replace these words and characters with appropriate
entries.
© 2008 SAP AG. All rights reserved.
iii
About This Handbook
NET310
Icons in Body Text
The following icons are used in this handbook.
Icon
Meaning
For more information, tips, or background
Note or further explanation of previous point
Exception or caution
Procedures
Indicates that the item is displayed in the instructor’s
presentation.
iv
© 2008 SAP AG. All rights reserved.
2009
Contents
Course Overview ............ ............... ............... ............... ............... ..... vii
Course Goals.................................................................................vii
Course Objectives ........................................................................... ix
Unit 1: Web Dynpro Introduction ....... ............... ............... ............... ....... 1
Web Dynpro Introduction .................................................................... 3
Unit 2: Web Dynpro Controllers......... ............... ............... ............... ..... 47
Web Dynpro Controllers ................................................................... 48
Unit 3: The Context ......... ............... ............... ............... ............... ..... 61
The Context ................................................................................. 63
Unit 4: Defining the User Interface ..... ............... ............... ............... ..... 89
Defining the User Interface ................................................................ 90
Unit 5: Controller and Context Programming ....... ............... ............... ....141
Controller and Context Programming ................................................... 143
Unit 6: Internationalization and Messages .......... ............... ............... ....195
Internationalization ........................................................................ 196
Messages ................................................................................... 208
Unit 7: Value Help, Semantic Help, and Keyboard Access ..... ............... ....235
Value Help .................................................................................. 237
Semantic Help.............................................................................. 255
Keyboard Access .......................................................................... 267
Unit 8: Component Reuse . ............... ............... ............... ............... ....275
Component Reuse......................................................................... 276
Unit 9: Dialog Boxes (Popups) .......... ............... ............... ............... ....305
Dialog Boxes (Popups) ................................................................... 306
2009
© 2008 SAP AG. All rights reserved.
v
Contents
NET310
Unit 10: Adaptation Techniques.............. ............... ............... ..............325
Configuration and Personalization ...................................................... 327
Enhancements for Web Dynpro ABAP ................................................. 352
Dynamic Modifications at Runtime ...................................................... 362
Unit 11: Additional Topics ...... ............... ............... ............... ..............401
SAP List Viewer for Web Dynpro ABAP ................................................ 403
Portal Integration........................................................................... 417
Integrating SAP Interactive Forms by Adobe .......................................... 429
Appendix 1: Phase Model
.... ............... ............... ............... ..............441
Appendix 2: Dynamic Programming - Advanced Topics
Appendix 3: Input Help - Advanced Topics
.......... ..............443
............ ............... ..............447
Appendix 4: Adapting Web Dynpro Applications - Advanced Topics
Appendix 5: Portal Integration
........453
............. ............... ............... ..............457
Index ... ............... ............... ............... ............... ............... ..............467
vi
© 2008 SAP AG. All rights reserved.
2009
Course Overview
Web Dynpro is SAP’s state-of-the-art technology for creating application user
interfaces (UIs). This course explains the fundamental concepts of how to develop
applications based on Web Dynpro for ABAP.
Target Audience
This course is intended for the following audiences:
•
•
Developers and consultants who would like to create or change applications
based on the Web Dynpro ABAP programming model
Technically experienced project leads who want to get an overview over the
functionality of Web Dynpro for ABAP
Course Prerequisites
Required Knowledge
•
•
•
Well-founded ABAP programming knowledge
BC400 – ABAP Workbench Foundations
BC401 – ABAP Objects
Course Duration Details
Unit 1: Web Dynpro Introduction
Web Dynpro Introduction
Exercise 1: Introduction
Exercise 2: Navigation
Exercise 3: View Assemblies (OPTIONAL)
120 Minutes
20 Minutes
30 Minutes
20 Minutes
Unit 2: Web Dynpro Controllers
Web Dynpro Controllers
40 Minutes
Unit 3: The Context
The Context
Exercise 4: Context Definition, Context Mapping,
and Data Binding
Unit 4: Defining the User Interface
Defining the User Interface
2009
© 2008 SAP AG. All rights reserved.
70 Minutes
30 Minutes
160 Minutes
vii
Course Overview
NET310
Exercise 5: Using Layout Managers to arrange
UI elements
Exercise 6: Displaying Tables
20 Minutes
35 Minutes
Unit 5: Controller and Context Programming
Controller and Context Programming
Exercise 7: Accessing the Context at Runtime
Exercise 8: Displaying mass data using tables
Exercise 9: Using Supply Functions
130 Minutes
15 Minutes
30 Minutes
30 Minutes
Unit 6: Internationalization and Messages
Internationalization
Exercise 10: Internationalization (optional)
Messages
Exercise 11: Value Checks and Messages
70
10
60
40
Minutes
Minutes
Minutes
Minutes
Unit 7: Value Help, Semantic Help, and Keyboard Access
70 Minutes
Value Help
Exercise 12: Display allowed Field Values by Drop
Down Box
30 Minutes
30 Minutes
Semantic Help
Keyboard Access
15 Minutes
Unit 8: Component Reuse
Component Reuse
Exercise 13: Component Reuse
Unit 9: Dialog Boxes (Popups)
Dialog Boxes (Popups)
Exercise 14: Displaying Interface View of
Component Usage as Popup
viii
120 Minutes
70 Minutes
45 Minutes
15 Minutes
Unit 10: Adaptation Techniques
Configuration and Personalization
Exercise 15: Adaptation via Configuration
Enhancements for Web Dynpro ABAP
Dynamic Modifications at Runtime
Exercise 16: Dynamic Modifications at Runtime
90
30
20
80
50
Minutes
Minutes
Minutes
Minutes
Minutes
Unit 11: Additional Topics
SAP List Viewer for Web Dynpro ABAP
Exercise 17: Using the SAP List Viewer
Portal Integration
Integrating SAP Interactive Forms by Adobe
30
30
45
20
Minutes
Minutes
Minutes
Minutes
© 2008 SAP AG. All rights reserved.
2009
NET310
Course Overview
Course Goals
This course will prepare you to:
•
Understand the role and application of Web Dynpro for ABAP in SAP’s UI
strategy
Develop Web Dynpro ABAP-based applications
•
Course Objectives
After completing this course, you will be able to:
•
•
•
•
Explain the architecture of a Web Dynpro component.
Describe the parts of a Web Dynpro controller.
Create context elements in Web Dynpro controllers.
Explain how navigation and data transfer in and between Web Dynpro
components can be realized.
Define the UI of a Web Dynpro component.
Internationalize a Web Dynpro application.
Define and send messages.
Define input help and semantic help related to UI elements.
Display dialog boxes.
Embed Web Dynpro components in other Web Dynpro components.
Manipulate the context and the UI element hierarchy at runtime.
Use the ABAP List Viewer (ALV) in the Web Dynpro UI.
Configure and personalize Web Dynpro components.
Integrate Web Dynpro applications into the SAP NetWeaver Portal.
•
•
•
•
•
•
•
•
•
•
SAP Software Component Information
The information in this course pertains to the following SAP Software Components
and releases:
•
•
SAP NetWeaver 7.0
SAP NetWeaver 7.0EhP 1
This is the third upgrade of this course. Changes in respect to the last course are
restricted on details.
All exercises have been adapted to the new master.
2009
© 2008 SAP AG. All rights reserved.
ix
Course Overview
NET310
The naming of the plugs has been updated, since plugs should be named according to
their usage and not according to the next view (that may differ).
The chapter about value help and semantic help has been extended to cover
accessibility. Hotkeys and access keys are added. In addition, default buttons are
introduced.
The topics “Internationalization” and “Messages” are now separated in two lessons.
Messages related to multiple attributed belonging to the same context element are used.
Personalization, Enhancements (new!), and dynamic programming has been combined
to a new unit (Adaptation Techniques)
At the time this course was finished using statically defined context menus did not
work. Thus I did not include this topic here.
Demos about context menus (dynamically assigned to UI elements), drag & drop,
enhancements, SAP interactive forms by Adobe, and flash islands can be found in
course NET312.
System Requirements:
This course is based on SAP NetWeaver Application Server 7.01. When using a
different release, functionality may differ. When teaching on SAP’s training systems,
an appropriate system will be assigned to this class automatically. In this system you
will find demos, templates, and solutions in the package NET310.
System Preparation:
The preparation for this course is easy. For each student, you have to create a user
in the system / client that has been assigned to your training event. In addition,
you have to create a transport request for all users. In order to do this, please use
transaction ZUSR. The template user is NETALL, available in all clients of the SAP
training system. This user has the authorization profiles SAP_ALL and SAP_NEW.
After having created the users, create a common transport request by clicking the
corresponding button in the button row of transaction ZUSR.
You will find the existing demos and all the demos I will add in the future in the
package NET310. This package can be found on each standard training system that is
copied from the master system for this class.
CATTs/eCATTs:
There is no CATT/eCATT needed for this course.
Other process steps not explicitly mentioned:
Preparation steps not explicitly listed in this trainer guide are not needed to run this
course.
x
© 2008 SAP AG. All rights reserved.
2009
NET310
Course Overview
Training System
Your training system will be available and accessible on Sunday evening (CET time
zone) in the week the training takes place. Do not use the system or prepare your
course before that time. The system can still be in use by another course or in the
refresh procedures of the IT preparation for your course! If you need a test/prep.
system before your course takes place, see details under Training System
Test/Prep.
System.
→
Test-/Prep. System
The system id of the preparation system is ZTE, client 800. Please log on with the user
training and the monthly changed password given from your education department
in the training information email/documentation. Make clear that test/prep. systems
should not be used in a training by participants without the permission of KPS. An
access violation fee might be charged.
Training WTS farm
Training at SAP training centers/Internal SAP training
The internal connectivity to the training WTS farms can only be used inside
of SAP network infrastructure. To connect to the training WTS farm use
http://wts.wdf.sap.corp:1080. Choose your home region (US, EMEA or APJ). Select
the Training-Zone menu. Connect to ‘Common Training, if no other WTS farm is
named for the training.
Customer Onsite training / Third party training center
Customer Onsite training can only connect to SAP training WTS farm via the SAP
Citrix Secure Gateway (SAP CSG). Therefore you need a CSG-User ID. The User ID
has to be already created by the education department for the time of the training. The
data (User ID and password) are delivered to you by the education department. Trainer
and participants using the same dedicated CSG-User-ID and password for the training.
To connect to the training WTS farm use http://mywts.sap.com. Enter the CSG-User
ID and password. Choose your home region (US, EMEA or APJ). Select the Training
icon. Connect to Common Training, if no other WTS farm is named for the training.
User ID and Passwords for the Course
Training with Reference User IDs
To create the participants users and your trainer user, please log into the system with
user ‘Training’. The monthly changed password should be delivered to you by your
education department in the training information email/documentation.
Additional information:
2009
© 2008 SAP AG. All rights reserved.
xi
Course Overview
NET310
Check out http://service.sap.com/curr-net to find additional information for this course
(time schedule, hints, error list ... ).
For the portal demos, you can use the test and demo portal for training available at
http://twdf0336.wdf.sap.corp:50100/irj/portal, user portalsetup, password trainer.
This portal is not refreshed automatically. So be sure to delete all objects you created
when the demo session is over. The URL of the portal and the user/password may
change in the future. Please check for changes at http://service.sap.com/curr-net.
A time schedule for this class is available at http://service.sap.com/curr-net.
xii
© 2008 SAP AG. All rights reserved.
2009
Unit 1
Web Dynpro Introduction
1
The first task is to explain why SAP is rolling out another UI technology. In this unit,
compare this technology with the classical Dynpro screen, SAP ITS and BSP. This
should lead to the following conclusion:
Web Dynpro is the successor to the classical Dynpro technology. It is not a direct
competitor of BSPs.
SAP ITS is a mapping tool that allows you to translate existing Dynpro-based
applications to a standard interpretable by a browser. SAP ITS is the only technology
which enables the mapping of existing programs based on Dynpros to HTML and thus
to a browser-based UI.
Web Dynpro is a programming model which allows you to design standard UIs very
quickly. Everything that can be designed without coding is designed without coding.
On the other hand, the user’s freedom in designing the UI is restricted. For example, it
is not possible to include client-side JavaScript in the generated pages. The generated
code is not restricted to HTML.
Finally, the BSP programming model offers the option of including all
browser-supported techniques in the generated HTML pages. However, constructing a
BSP UI takes a lot more time than developing a WD UI, since there is no declarative
approach. So BSP should be used for “freestyle” programming.
Unit Overview
Web Dynpro is a programming model provided by SAP. Web Dynpro is implemented
in Java and ABAP. It is suited to generating standardized user interfaces (UIs) using a
declarative approach, minimizing the time needed to realize Web applications.
This unit will describe the advantages of using the Web Dynpro programming model
as compared to other established Web programming models. It will provide a
summary of the basic architecture and functionality of Web Dynpro.
2009
© 2008 SAP AG. All rights reserved.
1
Unit 1: Web Dynpro Introduction
NET310
Unit Objectives
After completing this unit, you will be able to:
•
•
•
Describe the declarative programming approach used to create Web Dynpro
applications.
Explain the benefits resulting from this metadata approach.
List the most important elements that are part of a Web Dynpro application
and that can be defined declaratively.
Unit Contents
Lesson: Web Dynpro Introduction ................................................... 3
Exercise 1: Introduction ........................................................ 27
Exercise 2: Navigation .......................................................... 33
Exercise 3: View Assemblies (OPTIONAL) .................................. 39
2
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson:
2
Lesson: Web Dynpro Introduction
Web Dynpro Introduction
Lesson Duration: 120 Minutes
Lesson Overview
This lesson contains a brief overview of the functionality of Web Dynpro. The main
benefits of using Web Dynpro for designing Web applications are discussed.
Lesson Objectives
After completing this lesson, you will be able to:
•
•
•
Describe the declarative programming approach used to create Web Dynpro
applications.
Explain the benefits resulting from this metadata approach.
List the most important elements that are part of a Web Dynpro application
and that can be defined declaratively.
It is helpful if the trainer knows other Web-UI programming models in order to be
able to list the benefits (and the restrictions!) of Web Dynpro ABAP. In the ABAP
area there are two other programming models, SAP ITS and BSPs, which are still
supported. The trainer should be prepared for questions related to the pros and cons of
these three technologies. Here are some hints:
SAP ITS will be used in future to map existing Dynpro-based transactions
to HTML pages. This is a necessity since it is impossible to convert all
Dynpro-based transactions to Web Dynpro in an acceptable amount of time.
SAP ITS is the only Web-enabling technology. For all other technologies, the
application has to be completely rewritten! Cons: long response times, since
additional time is necessary for the mapping between HTML pages and Dynpros
(in both directions).
Web Dynpro is the technology SAP uses for developing future applications.
Existing Dynpro-based transactions may be converted. Web Dynpro will replace
the old Dynpro step-by-step. Cons: Web Dynpro does allow fast development of
standardized UIs, but it is not the right choice for developing fancy Web-UIs.
This is because the UI is rendered from meta data, so the developer can not
place his/her own JavaScript code in the rendered HTML page! Web Dynpro
applications may be embedded in the portal environment, they may be displayed
by the SAP NetWeaver Business Client, or they may be displayed by a browser.
Finally, BSP is the ABAP technology for “freestyle” programming. Everything
is possible. BSP can be compared to JSP on the Java side. Cons: Standardized
UIs are not supported and everything has to be coded (navigation, UI...).
2009
© 2008 SAP AG. All rights reserved.
3
Unit 1: Web Dynpro Introduction
NET310
Thus the development of a BSP-based UI is much slower than Web Dynpro
development. Because SAP develops standard applications that need to have a
standardized and consistent UI, BSP will not be used by SAP. However, BSP is
the only one of these three technologies that allows you to design sophisticated
Internet applications based on ABAP. This technology will continue to be
interesting for customers well into the future.
Business Example
You want to find the technology that is best suited to developing ABAP-based
Web applications. The requirements for your projects are high speed, low cost and
standardized UIs. You’ve heard that Web Dynpro ABAP is a good candidate. So you
want to get an initial overview of Web Dynpro functionality.
What is Web Dynpro?
From a technical standpoint, SAP’s Web Dynpro for Java and ABAP is a revolutionary
step in the development of Web-based user interfaces. It is completely unlike any
design paradigm previously used by SAP and represents a quantum leap in the
development of Web-based enterprise resource planning (ERP) applications.
Web Dynpro applications are built using declarative programming techniques based
on the Model View Controller (MVC) paradigm. That is, you specify which user
interface elements you wish to have on the client and where those elements will get
their data from. You also define the possible navigation paths declaratively in your
application. All the code to create the user interface is then generated automatically
within a standard runtime framework. This relieves you of the repetitive coding tasks
involved in writing HTML and making it interactive with JavaScript.
Web Dynpro ABAP has been available since SAP NetWeaver 7.0 (SAP NetWeaver
Application Server 7.0). For developing the entities of a Web Dynpro application, the
Object Navigator (transaction code SE80) has been enhanced.
Web Dynpro is designed to support structured development. The software
modularization units are Web Dynpro components, which can be combined to build
up complex applications.
Meta Model Declaration vs. Custom Coding
A Web Dynpro application is developed using a declarative programming approach.
Within the ABAP Workbench, there are special tools that allow you to build an
abstract representation of your application in the form of a Web Dynpro meta model.
The necessary source code is then generated automatically and conforms to a standard
architecture known as the Web Dynpro framework.
4
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Web Dynpro Introduction
The Web Dynpro framework allows you to place the custom source code at predefined
positions within the generated code.
All Web Dynpro applications are constructed from the same basic units. However,
through the use of custom coding, the standard framework can be extended to supply
any required business functionality.
Not all implementation decisions need to be made at design time. It is possible to
implement a Web Dynpro application in which the appearance of the user interface is
decided at runtime. This allows a highly flexible application to be written without the
need to directly write any HTML or JavaScript.
Figure 1: Meta model declarations vs. custom coding
2009
© 2008 SAP AG. All rights reserved.
5
Unit 1: Web Dynpro Introduction
NET310
Application Scenarios with Web Dynpro
Figure 2: Application Scenarios with Web Dynpro
Web Dynpro applications can access different kinds of data sources:
•
•
From a Web Dynpro ABAP application, all kinds of reuse components can
be addressed directly:
1. Methods of classes defined in own system.
2. Function modules defined in own system or (via RFC) in back-end system.
3. Web Services via a Web Service client object.
Do NOT place a SELECT statement in your controller methods directly, since
this leads to a mixing between flow logic and business logic.
Model objects are not yet supported in Web Dynpro ABAP. The best way to have
reusable entities encapsulating business logic is to create global ABAP classes
containing the source code. It is also possible to develop UI-free (faceless) Web
Dynpro components, which only offer reusable functionality. These components can
then be accessed by other Web Dynpro components by way of component reuse.
6
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Web Dynpro Introduction
Benefits of Web Dynpro
Web Dynpro’s main goal is to enable application developers to create powerful Web
applications with minimal effort using descriptive tools in a structured design process.
One guiding principle in the Web Dynpro philosophy is: The fewer lines of
hand-written code, the better. Web Dynpro pursues this goal in two ways.
•
•
•
Web Dynpro uses a declarative meta model for defining user interfaces. The
development environment generates the required source code from this abstract
definition. However, the UI can also be manipulated from the source code which
is necessary to implement dynamic changes not known at design time.
Web Dynpro provides technical features such as support for internationalization,
flicker-free interaction and a clean separation of the business logic and the user
interface. This separation is achieved through a modified implementation of the
Model View Controller (MVC) design paradigm.
Wizards support the definition of forms and tables in the UI and source code in
the controller methods. This reduces the development effort significantly.
Since the repetitive tasks of UI coding have been eliminated, the developer can focus
his attention on the flow of business data through the application.
Web Dynpro applications may be embedded in the portal environment, they may be
displayed by the SAP NetWeaver Business Client, or they may be displayed by a
browser.
2009
© 2008 SAP AG. All rights reserved.
7
Unit 1: Web Dynpro Introduction
NET310
Figure 3: Web Dynpro Benefits
Web Dynpro Architecture: Entities and Concepts
Figure 4: Web Dynpro component
8
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Web Dynpro Introduction
Web Dynpro components allow you to structure complex Web applications and
develop reusable, interacting entities. This enables the nesting of large application
sections.
Web Dynpro components are containers for other entities related to the UI and the
Web Dynpro program.
Entities related to the UI are windows and views. The layout of a view is the
rectangular part of a page displayed by the client (for example, a browser). The view
contains UI elements such as input fields and buttons. The complete page sent to the
client can be set up by only one view, but can also be a combination of multiple views.
The possible combinations of views and the flow between the views is defined in a
window. A window can contain any number of views. A view can be embedded in
any number of windows.
The Web Dynpro source code is located in Web Dynpro controllers. Global variables
of controllers are defined as controller attributes. Global data related to the UI
(displayed by elements on the UI or used to manipulate UI element properties) has to
be stored in a hierarchical storage called the context.
Now log on to the system, start transaction SE80 and display package NET310. Open
any Web Dynpro component (e.g. NET310_UI_S2) and display the entities in the
object tree. Do not elaborate further.
Web Dynpro components can be addressed in three different ways:
•
•
•
Using a Web Dynpro application, a Web Dynpro component can be linked to a
URL, which can be called from a Web browser or another Web Dynpro client.
When reusing a Web Dynpro component as a subcomponent, the visual interface
of a Web Dynpro component can be combined with the visual entities of the
main component to form the UI.
When reusing a Web Dynpro component as a subcomponent, all methods
and data defined in the programming interface can be accessed by the main
component.
At the end of this section, create your first WD component. Start by creating a
package. Save this package in the transport request created prior to the course. Create
a WD component with a window and a view in your package. Create an application to
access the component. Finally, add a TextView UI element to your view and enter
some text. Activate the component with all entities and start the application.
2009
© 2008 SAP AG. All rights reserved.
9
Unit 1: Web Dynpro Introduction
NET310
Exercise “Web Dynpro Introduction”
Context Mapping and Data Binding
Figure 5: Context and Data Transport
The values of UI elements that allow user input have to be connected to the context
attributes of the corresponding controller. This is called data binding. Through
data binding, an automatic data transport between the UI elements and the context
attributes is established.
The variables defined in a Web Dynpro controller context can be referenced from
other Web Dynpro controllers. This is called context mapping. Context mapping
allows you to share common attributes between different controllers, so copying these
attributes between the controller contexts is not necessary.
Combining these two concepts, data transport between UI elements located in different
views can be defined in a purely declarative way.
10
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Web Dynpro Introduction
In the Web Dynpro component you displayed before (e.g. NET310_UI_S2), show the
context of views and component controllers. Show context mapping. Open views.
Show UI elements that are bound to context attributes.
Figure 6: Context mapping
Now you can go to the property tab of a view and show the entry for controller
usage. The component controller usage is generated automatically when a new view
is created.
Context mapping allows a context node in one controller to be supplied automatically
with data from a corresponding context node in another controller. This is the primary
mechanism for sharing data between controllers.
2009
© 2008 SAP AG. All rights reserved.
11
Unit 1: Web Dynpro Introduction
NET310
For a mapping relationship to be established, the following steps must first be
performed:
•
•
•
A node must exist in the context of the controller acting as the mapping origin.
This node need not have any declared child nodes or attributes.
The mapping origin controller must not be a view controller.
The controller containing the mapped node must declare the use of the mapping
origin controller as a used controller.
Figure 7: Putting data on the screen: data binding
Data binding is the means by which data is automatically transported from a view
controller’s context to a UI element in its layout, and vice versa.
You may not bind UI elements to context nodes or attributes defined in another
controller. UI elements are private to the view controller in which they are declared.
The data binding process decouples the UI element object from the application code
in the view controller. Therefore, in order to manipulate UI element properties, the
application code in the view controller needs only to manipulate the values of context
nodes and attributes to which the UI elements are bound. The Web Dynpro framework
then performs the following two tasks:
12
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Web Dynpro Introduction
Open component NET310_UI_S2 to show the data binding of a TABLE UI element to
a context node. Or open a view of component NET310_COND_S to show the data
binding between an input field and a context attribute.
•
•
The transport of data from the context attribute to the UI element during the
screen rendering process.
Repopulation of the context attribute from the UI element after data has been
entered by the user and the next server round trip is initiated. The values entered
by the user are automatically converted and checked for type conformity. If an
error occurs, a message is displayed.
Data binding is a powerful instrument since not only the value of a UI element can be
bound to a context attribute, but also other UI properties like visibility. This means
that UI element properties can be manipulated from the view controller by acting on
context attributes.
Navigation Between Views
Figure 8: Navigation between views
2009
© 2008 SAP AG. All rights reserved.
13
Unit 1: Web Dynpro Introduction
NET310
Navigation between views is triggered by firing outbound plugs. Firing an
outbound plug causes a navigation event to be raised. Navigation events are special
asynchronous events that are placed into a navigation queue. Multiple outbound plugs
can be fired from one view. This can be used to define the next UI, consisting of
multiple views. The navigation queue is processed at a certain point in time in the
Web Dynpro processing phase. Up to this point of time, the navigation stack can be
extended by firing additional outbound plugs, or the complete navigation stack can
be deleted. Outbound plugs should be named according to the action that caused
navigation away from the current view.
Inbound plugs are special event handler methods that subscribe to navigation events
raised when outbound plugs are fired. Inbound plug methods are called only when
the navigation queue is processed. This only takes place once the views in the
current view assembly have fired their outbound plugs and no validation errors have
occurred that would cause navigation to be cancelled. Inbound plugs should be named
according to the reason for which the view being displayed.
Outbound and inbound plugs are joined together using navigation links. Technically,
linking an inbound plug to an outbound plug means registering the inbound plug event
handler method to the navigation event called by firing an outbound plug.
Outbound plugs and event handler methods related to the inbound plug can have
parameters, allowing you to pass data between the views.
An Action is used to link a client side event to an event handler method (automatically
defined with the action) in the corresponding view controller.
14
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Web Dynpro Introduction
Figure 9: Navigation: Principle
Open any view of component NET310_UI_S2 and show the plugs.
Your application: Create a second view and embed it in your window. Add an
outbound plug and an inbound plug to each of the views (no plug parameters). Go
back to the window and add navigation links in order to enable navigation back and
forth between the views. Add a button to each of the views to trigger the navigation.
For each of the views: Create the action and the fire_plug statement by entering the
action’s name in the onAction property of the button. Test the application.
Exercise “Navigation”
2009
© 2008 SAP AG. All rights reserved.
15
Unit 1: Web Dynpro Introduction
NET310
Windows and Nested Views
Figure 10: Windows and nested views
A window defines which views are displayed in what combination and how the
view combination may be changed by firing outbound plugs. So when you create a
window, you define three things:
16
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Web Dynpro Introduction
Open window D1_WIND of component NET310_NAVI_D1 and show how
plugs are linked via navigation links. Open window D2_WIND of component
NET310_NAVI_D1 and show how a view can be embedded in a view container.
Explain view assembly.
•
•
•
All the possible views that could exist in the component’s visual interface must
be embedded in the window.
If multiple views need to be displayed in parallel, the layout and position of
these views is defined by a special view containing ViewContainerUIElements
in its layout. This container view is embedded in the window and, inside
each area defined by a ViewContainerUIElement, all possible views for
this view container area are embedded (nested embedding). For each
ViewContainerUIElement, there is one default view displayed at startup.
The navigation links between the different views must be defined.
Only one view can be displayed in the view container area at one time. Navigation
links must be defined between views in order for the contents of a view container
area to be replaced.
View container areas can be blanked out by embedding the view EMPTYVIEW
(automatically created with the component) whose inbound plug responds to an
appropriate navigation event.
Figure 11: View assembly
2009
© 2008 SAP AG. All rights reserved.
17
Unit 1: Web Dynpro Introduction
NET310
Outbound plugs are the triggers that cause a view container area to contain a particular
view.
For a given window definition in which multiple views are embedded in view
container areas, many permutations of views could be visible. The permutation that is
visible depends on which navigation links the user follows.
The subset of views visible at any time is known as a view assembly.
Your component: Create a second window. Create a new view consisting of two
view containers, VC1 and VC2. Embed this view in the new window and make it
the default view. Embed the existing start view in VC1 and the existing result view
in VC2. Also include an empty view in VC2 and make it the default view in this
view container. Define the navigation such that clicking on the button of the start
view in VC1 will replace the empty view in VC2 with the result view. Clicking back
on the result view in VC2 will display the empty view in VC2 again. Create a new
application to access your second window.
Having discussed that, you should then be sure to mention the applications
NET310_NAVI_D1 and NET310_NAVI_D1_, NET310_NAVI_D1A (using window
plugs for navigation) and NET310_NAVI_D1B (using main view plugs for navigation,
passing state information via plugs).
Optional exercise “View Assemblies”
18
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Web Dynpro Introduction
Web Dynpro Architecture: Relation Between Web Dynpro
Entities
Figure 12: Model View Controller (MVC)
SAP’s Web Dynpro is built on the foundation of the Model View Controller (MVC)
design paradigm. MVC was originally invented by the Norwegian software designer
Trygve Reenskaug while working at Xerox PARC in the late 1970s. The first
implementation of this design paradigm was with the release of the Smalltalk-80
programming language.
MVC was a revolutionary design paradigm because it was the first to describe
software components in terms of:
•
•
The functional responsibilities each should fulfill
The message protocols to which each component should respond
SAP has modified and extended the original MVC specification to create the Web
Dynpro toolset.
2009
© 2008 SAP AG. All rights reserved.
19
Unit 1: Web Dynpro Introduction
NET310
Web Dynpro Component Architecture
Figure 13: Internally-visible Web Dynpro entities (1)
A view can be embedded in different windows. The first view that is embedded in a
window will be the default view.
The architecture of a Web Dynpro component can be divided into two parts: external
and internal visibility. The horizontal dashed line in the above figure separates the
entities that are visible from outside the component from those that are only visible
within the component.
The internally-visible parts can be further divided into visual entities and programming
entities. Visual entities are those related to the UI, generated by the Web Dynpro
framework and passed to the client. The internally-visible entities consist of windows
and views.
A view consists of a view layout and the corresponding view controller. The view
controller can contain navigation plugs, methods and a context.
A window embeds one or more views and has a corresponding window controller. A
window controller can contain navigation plugs, methods, and a context. Each view
can be embedded in multiple windows.
20
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Web Dynpro Introduction
The outbound plug of a window can be connected to any inbound plug of embedded
views and the outbound plug of a view can be connected to any inbound plug of the
embedding window. However, navigation between windows of the same component
is not possible.
Figure 14: Internally-visible Web Dynpro entities (2)
Multiple windows may exist (e.g. NET310_NAVI_D1). Sometimes it is useful
to access business logic from a view (input check: Is there a data set that fits the
user’s input?).
The component controller acts as a component-wide controller. Program logic related
only to a certain view - checking user input, for example - should be coded in the
related view controller. Usage declarations between the controllers allow you to
access the context data, the public attributes, and methods of the declared controller
(used controller). A view controller cannot be declared as a used controller for other
controllers as this would violate good programming practice (MVC programming
paradigm).
Business logic should not be part of the Web Dynpro component, but should be
defined outside of the component to have high reusability. It is preferable that global
ABAP classes be used to encapsulate the related source code.
2009
© 2008 SAP AG. All rights reserved.
21
Unit 1: Web Dynpro Introduction
NET310
Figure 15: Internally-visible Web Dynpro entities (3)
In your component: Create a custom controller. Create a usage declaration in the
custom controller for the component controller and vice versa.
Custom controllers are optional controllers that have to be defined by the developer.
These controllers can be used to modularize component content. For example,
custom controllers can act as local controllers for some views, or they can be used to
encapsulate the logic related to a certain model class (business logic). This allows you
to reduce the content of the component controller by populating subfunctions.
22
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Web Dynpro Introduction
Figure 16: Externally-visible Web Dynpro entities
If one Web Dynpro component (parent component) needs access to another Web
Dynpro component (child component), the parent component can declare the use of
the child component. A specific component usage instance is then created and the
parent component accesses the functionality of the child component via its component
interface controller.
The only parts of a Web Dynpro component that are visible to the user are the
interface controller and the interface view(s).
2009
© 2008 SAP AG. All rights reserved.
23
Unit 1: Web Dynpro Introduction
NET310
In your component: Display the component interface. For each window, an interface
view has been created. An interface controller has also been created automatically.
•
•
•
All Web Dynpro components have only one interface controller. Via the
interface controller, data, methods and event handlers can be made accessible
to other components.
Interface views represent the visual interface of a Web Dynpro component.
There is a one-to-one relationship between a window and an interface view. Each
time a window is defined, a related interface view is automatically generated
which makes the window accessible from outside the component. The interface
view only exposes those inbound and outbound plugs to the component user that
have the interface property checked. Methods and context data of the window
are not accessible via the related interface view.
If the component has no views, there is no need to have windows. In this case,
the component does not implement an interface view. Components without any
visual interface are called faceless components.
Figure 17: Web Dynpro application
A Web Dynpro application is an entry point into a Web Dynpro component and is
the only Web Dynpro entity that can be addressed via a URL.
24
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Web Dynpro Introduction
There is often (but not always) a one-to-one relationship between an interface view
and an application.
In the same way that the functionality in an ABAP module pool can be accessed
by defining multiple transaction codes, the functionality of a single Web Dynpro
component can be accessed by defining multiple applications, each addressing a
different interface view and/or a different inbound plug of the interface view.
In order to define a Web Dynpro application, you must specify:
•
•
•
2009
The component to be invoked; this component is then known as the root
component.
Which interface view of the root component will be used; the default view(s) in
this interface view define(s) the default view assembly.
Which inbound plug will act as the entry point for the nominated interface view
(this inbound plug must be of type Startup).
© 2008 SAP AG. All rights reserved.
25
Unit 1: Web Dynpro Introduction
26
© 2008 SAP AG. All rights reserved.
NET310
2009
NET310
21
Lesson: Web Dynpro Introduction
Exercise 1: Introduction
Exercise Duration: 20 Minutes
Exercise Objectives
After completing this exercise, you will be able to:
•
Create a Web Dynpro component with a window embedding a single view
•
Define a simple UI element on the view layout and edit its properties
•
Create a Web Dynpro application to allow accessing the application via URL
Business Example
You would like to develop a Web Dynpro application. You will start by creating
the Web Dynpro entities that are mandatory for an application that displays a page
with a simple text field.
Template: n/a
Solution: NET310_INTR_S
Task 1:
Create a package that will contain all the repository objects you are going to develop.
1.
Create the package ZNET310_##. Assign the application component BC-WD
and the software component HOME to your package.
Task 2:
Create a Web Dynpro component with a window embedding a single view.
1.
Create a Web Dynpro component ZNET310_INTR_## with a window
MAIN_WINDOW that is embedding a single view MAIN_VIEW.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
27
Unit 1: Web Dynpro Introduction
2.
NET310
What other Web Dynpro entities are now displayed in the object tree of the
ABAP Workbench?
Task 3:
Create a simple TEXTVIEW UI element in the layout of the view MAIN_VIEW. This
UI element should display an arbitrary text.
1.
Create a simple UI element of type TEXTVIEW (suggested name:
TEXT_VIEW) on the view layout and edit its properties.
2.
Maintain the text to be displayed in the TEXTVIEW UI element. You may
want to change some other properties of the element and see the result on the
layout preview.
Task 4:
Create a Web Dynpro application to access your Web Dynpro component. Start the
application.
28
1.
Create a Web Dynpro application (suggested name: ZNET310_INTR_##) that
accesses the only existing window of your Web Dynpro component.
2.
Activate the Web Dynpro component and test the Web Dynpro application.
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Web Dynpro Introduction
Solution 1: Introduction
Task 1:
Create a package that will contain all the repository objects you are going to develop.
1.
Create the package ZNET310_##. Assign the application component BC-WD
and the software component HOME to your package.
a)
This is basic ABAP knowledge!
Task 2:
Create a Web Dynpro component with a window embedding a single view.
1.
2.
Create a Web Dynpro component ZNET310_INTR_## with a window
MAIN_WINDOW that is embedding a single view MAIN_VIEW.
a)
In the navigation area, open the context menu for the package and choose
Create
WebDynpro
WebDynpro Component (Interface).
b)
In the dialog box, enter the name of the component, a description, the name
of the window, and the name of the view.
c)
Finish the dialog by pressing Enter.
→
→
What other Web Dynpro entities are now displayed in the object tree of the
ABAP Workbench?
Answer:
A component controller
An interface controller
An interface view for the window
A global interface ZIWCI_NET310_INTR_##
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
29
Unit 1: Web Dynpro Introduction
NET310
Task 3:
Create a simple TEXTVIEW UI element in the layout of the view MAIN_VIEW. This
UI element should display an arbitrary text.
1.
2.
Create a simple UI element of type TEXTVIEW (suggested name:
TEXT_VIEW) on the view layout and edit its properties.
a)
Edit your Web Dynpro view MAIN_VIEW and open the Layout tab.
b)
In the display of the UI element hierarchy (upper-right corner), open the
context menu for ROOTUIELEMENTCONTAINER and choose Insert
Element.
c)
Enter the name of the element (TEXT_VIEW) and the element type
(TEXTVIEW).
Maintain the text to be displayed in the TEXTVIEW UI element. You may
want to change some other properties of the element and see the result on the
layout preview.
a)
Click on the TEXTVIEW UI element in the UI element hierarchy.
b)
In the properties list (below the UI element hierarchy) maintain the text
in the text field.
c)
Change additional properties if desired.
Task 4:
Create a Web Dynpro application to access your Web Dynpro component. Start the
application.
1.
Create a Web Dynpro application (suggested name: ZNET310_INTR_##) that
accesses the only existing window of your Web Dynpro component.
→
a)
In the navigation area, open the context menu for your Web Dynpro
component and choose Create
WebDynpro Application.
b)
In the dialog box, check the name of the application (same as component)
and enter a description.
c)
Finish the dialog by selecting Enter.
Continued on next page
30
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Web Dynpro Introduction
2.
2009
Activate the Web Dynpro component and test the Web Dynpro application.
a)
From the context menu of your Web Dynpro Component choose the item
Activate. In the next dialog box all parts of your component that have not
been activated yet will be selected automatically. Start activating these
objects by finishing the dialog
b)
From the context menu of your Web Dynpro Application choose Test to
open a browser window and start your application.
© 2008 SAP AG. All rights reserved.
31
Unit 1: Web Dynpro Introduction
32
© 2008 SAP AG. All rights reserved.
NET310
2009
NET310
27
Lesson: Web Dynpro Introduction
Exercise 2: Navigation
Exercise Duration: 30 Minutes
Exercise Objectives
After completing this exercise, you will be able to:
•
Define buttons on Web Dynpro views
•
Handle that a button is clicked by the user
•
Implement navigation between Web Dynpro views
Business Example
You want to develop a Web Dynpro application with more than one view. Thus
you would like to define buttons on the view’s layouts to allow the user to initiate
navigation between the views.
Template: n/a
Solution: NET310_CTRL_S
Task 1:
Create a Web Dynpro component containing a window and two views.
1.
Create Web Dynpro component ZNET310_CTRL_## with a window
MAIN_WINDOW and a view INPUT_VIEW.
2.
Create an additional view (name: OUTPUT_VIEW) inside your component
and embed this view into the window MAIN_WINDOW.
Task 2:
Create an outbound plug and an inbound plug for each view. Define two navigation
links between the two views – each going from the outbound plug of one view to the
inbound plug of the other view.
1.
For your first view (INPUT_VIEW), create an outbound plug (name:
OUT_DETAILS) and an inbound plug (name: IN_DEFAULT).
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
33
Unit 1: Web Dynpro Introduction
NET310
2.
What new parts have been created in the view controller by completing the
previous step (refer to the various tabs of the view)?
3.
Repeat step 1 for the view OUTPUT_VIEW. Define the outbound plug
OUT_BACK and the inbound plug IN_DEFAULT.
4.
Define a navigation link from the outbound plug (OUT_DETAILS) of view
INPUT_VIEW to the inbound plug (IN_DEFAULT) of view OUTPUT_VIEW.
5.
Define a navigation link from the outbound plug (OUT_BACK) of view
OUTPUT_VIEW to the inbound plug (IN_DEFAULT) of view INPUT_VIEW.
Task 3:
Define a button on each of the two views and make sure the outbound plug of the
respective view is fired when the button is pressed by the user.
1.
Create a simple UI element of type BUTTON having the name BUT_DETAILS
on the layout of view INPUT_VIEW and maintain the text to be displayed on the
button.
2.
Create an action for the button having the name DISPLAY_DETAILS. Assign
this action to the button BUT_DETAILS. If the user clicks this button, the
outbound plug OUT_DETAILS has to be fired.
3.
What new parts have been created in the view controller by the previous step
(refer to the various tabs of the view)?
4.
Create a button on the view OUTPUT_VIEW having the name BUT_BACK.
Set the text to be displayed on the button and assign an action having the name
BACK to the property ONACTION. Make sure the outbound plug OUT_BACK
is fired if the user clicks the button.
Continued on next page
34
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Web Dynpro Introduction
Task 4:
Activate your component. Create an application to access your component and start
the application.
2009
1.
Activate your component and all contained component entities.
2.
Create a Web Dynpro application for your component. Start the application.
© 2008 SAP AG. All rights reserved.
35
Unit 1: Web Dynpro Introduction
NET310
Solution 2: Navigation
Task 1:
Create a Web Dynpro component containing a window and two views.
1.
Create Web Dynpro component ZNET310_CTRL_## with a window
MAIN_WINDOW and a view INPUT_VIEW.
a)
2.
Perform this step as in the previous exercise.
Create an additional view (name: OUTPUT_VIEW) inside your component
and embed this view into the window MAIN_WINDOW.
→ View.
a)
From the context menu of your component, choose Create
b)
Enter the view’s name and a short description in the corresponding fields of
the popup.
c)
Finish the dialog. Save the view.
d)
Edit the window MAIN_WINDOW. Open the tab labeled Window.
e)
Left mouse-click the view in the object tree for your component. Drag it
from the object area of the Web Dynpro Builder and drop it on the root
node (MAIN_WINDOW) displayed on tab Window. Save.
Task 2:
Create an outbound plug and an inbound plug for each view. Define two navigation
links between the two views – each going from the outbound plug of one view to the
inbound plug of the other view.
1.
For your first view (INPUT_VIEW), create an outbound plug (name:
OUT_DETAILS) and an inbound plug (name: IN_DEFAULT).
a)
Edit Web Dynpro view INPUT_VIEW.
b)
Select the Outbound plugs tab and enter the outbound plug name and a
description in the topmost table.
c)
Select the Inbound plugs tab and enter the inbound plug name and a
description.
Continued on next page
36
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Web Dynpro Introduction
2.
What new parts have been created in the view controller by completing the
previous step (refer to the various tabs of the view)?
Answer:
Event handler method “HANDLEIN_DEFAULT” (empty).
3.
Repeat step 1 for the view OUTPUT_VIEW. Define the outbound plug
OUT_BACK and the inbound plug IN_DEFAULT.
a)
4.
5.
Perform this step as before.
Define a navigation link from the outbound plug (OUT_DETAILS) of view
INPUT_VIEW to the inbound plug (IN_DEFAULT) of view OUTPUT_VIEW.
a)
To edit the window, choose the Window tab and expand all nodes of the
window structure.
b)
Drag the outbound plug of view INPUT_VIEW and drop it on the inbound
plug of view OUTPUT_VIEW. Confirm the data in the dialog box.
Define a navigation link from the outbound plug (OUT_BACK) of view
OUTPUT_VIEW to the inbound plug (IN_DEFAULT) of view INPUT_VIEW.
a)
Perform this step as before.
Task 3:
Define a button on each of the two views and make sure the outbound plug of the
respective view is fired when the button is pressed by the user.
1.
Create a simple UI element of type BUTTON having the name BUT_DETAILS
on the layout of view INPUT_VIEW and maintain the text to be displayed on the
button.
a)
Edit the view and choose the Layout tab.
b)
Open the context menu for ROOTUIELEMENTCONTAINER and choose
Insert Element.
c)
Choose element type BUTTON and enter the name of the button.
d)
Go to property text and maintain the text to be displayed in the Value
column.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
37
Unit 1: Web Dynpro Introduction
2.
3.
NET310
Create an action for the button having the name DISPLAY_DETAILS. Assign
this action to the button BUT_DETAILS. If the user clicks this button, the
outbound plug OUT_DETAILS has to be fired.
in the Binding
a)
Go to property OnAction of the button. Choose Create
column.
b)
In the dialog box, enter the name of the action, a description, and the name
of the outbound plug.
What new parts have been created in the view controller by the previous step
(refer to the various tabs of the view)?
Answer:
Action “DISPLAY_DETAILS”
Event handler method “ONACTIONDISPLAY_DETAILS” (with coding
to fire the outbound plug)
4.
Create a button on the view OUTPUT_VIEW having the name BUT_BACK.
Set the text to be displayed on the button and assign an action having the name
BACK to the property ONACTION. Make sure the outbound plug OUT_BACK
is fired if the user clicks the button.
a)
Perform this step as before.
Task 4:
Activate your component. Create an application to access your component and start
the application.
1.
Activate your component and all contained component entities.
a)
2.
Create a Web Dynpro application for your component. Start the application.
a)
38
Perform this step as in the previous exercise.
Perform this step as in the previous exercise.
© 2008 SAP AG. All rights reserved.
2009
NET310
33
Lesson: Web Dynpro Introduction
Exercise 3: View Assemblies (OPTIONAL)
Exercise Duration: 20 Minutes
Exercise Objectives
After completing this exercise, you will be able to:
•
Display more than one view in parallel
Business Example
You would like to develop a single screen Web Dynpro application. Thus, multiple
views have to be combined to define the page displayed to the user. In addition, firing
outbound plugs should replace one or multiple views being part of the view assembly.
Template: NET310_CTRL_S
Solution: NET310_CTRL_S_OPT
Task 1:
Copy your solution from the previous exercise or the template component.
1.
Copy your solution from the previous exercise (ZNET310_CTRL_##) or
the Web Dynpro component NET310_CTRL_S to the new component,
ZNET310_CTRL_##_OPT.
Task 2:
Define a container area in the layout of view INPUT_VIEW.
1.
Define a UI element of type VIEWCONTAINERUIELEMENT (name: VC)
in the layout of view INPUT_VIEW.
Task 3:
Define a new window. Embed the view INPUT_VIEW in the window. Next embed
the views EMPTYVIEW and OUTPUT_VIEW in the container area of view
INPUT_VIEW. View EMPTYVIEW has to be the default view for the container area.
Define the navigation: If the user clicks the button on view INPUT_VIEW, the
second view should appear in the container area. If the user clicks the button on view
OUTPUT_VIEW, the OUTPUT_VIEW should be replaced by view EMPTYVIEW.
1.
Define a new window having the name SECOND_WINDOW.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
39
Unit 1: Web Dynpro Introduction
2.
Embed the view INPUT_VIEW in the new window.
3.
Embed the view EMPTYVIEW in the container area.
4.
Embed the view OUTPUT_VIEW in the container area VC.
5.
Define the navigation.
NET310
Task 4:
Activate the component. Define a new Web Dynpro application to access the new
window of your application. Start the new application.
40
1.
Activate your component and all contained component entities.
2.
Create a Web Dynpro application for your component.
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Web Dynpro Introduction
Solution 3: View Assemblies (OPTIONAL)
Task 1:
Copy your solution from the previous exercise or the template component.
1.
Copy your solution from the previous exercise (ZNET310_CTRL_##) or
the Web Dynpro component NET310_CTRL_S to the new component,
ZNET310_CTRL_##_OPT.
a)
One possible solution: In the object navigator, choose Other object and
select the Web Objects tab page.
b)
Enter the name of the Web Dynpro component to copy and choose Copy .
c)
Enter a name for the new Web Dynpro component.
Task 2:
Define a container area in the layout of view INPUT_VIEW.
1.
Define a UI element of type VIEWCONTAINERUIELEMENT (name: VC)
in the layout of view INPUT_VIEW.
a)
Edit the layout of view INPUT_VIEW.
b)
Open the context menu for ROOTUIELEMENTCONTAINER and choose
Insert Element.
c)
Choose element type VIEWCONTAINERUIELEMENT and enter the name
(VC).
d)
Save.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
41
Unit 1: Web Dynpro Introduction
NET310
Task 3:
Define a new window. Embed the view INPUT_VIEW in the window. Next embed
the views EMPTYVIEW and OUTPUT_VIEW in the container area of view
INPUT_VIEW. View EMPTYVIEW has to be the default view for the container area.
Define the navigation: If the user clicks the button on view INPUT_VIEW, the
second view should appear in the container area. If the user clicks the button on view
OUTPUT_VIEW, the OUTPUT_VIEW should be replaced by view EMPTYVIEW.
1.
2.
3.
4.
Define a new window having the name SECOND_WINDOW.
→ Window.
a)
From the context menu of your component, choose Create
b)
Enter the window’s name and a short description in the corresponding
fields of the popup.
c)
Finish the dialog.
Embed the view INPUT_VIEW in the new window.
a)
Edit the window SECOND_WINDOW. Open the tab labeled Window.
b)
Left mouse-click the view INPUT_VIEW in the object tree for your
component. Drag it to the object area of the Web Dynpro Builder and drop
it on the root node (SECOND_WINDOW) displayed on tab Window.
c)
Save.
Embed the view EMPTYVIEW in the container area.
a)
Go on editing the window SECOND_WINDOW.
b)
Click on the icon left of the node SECOND_WINDOW to display the
embedded views. Locate the view INPUT_VIEW.
c)
Click on the icon left of the node INPUT_VIEW to display the container
areas related to this view. Locate the view container area VC.
d)
Right mouse-click on the view container area VC. Choose Insert View. In
the popup displayed next choose the view EMPTYVIEW and finish the
dialog.
Embed the view OUTPUT_VIEW in the container area VC.
a)
Right mouse-click on the view container area VC. Choose Insert View. In
the popup displayed next choose the view OUTPUT_VIEW and finish
the dialog.
Continued on next page
42
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Web Dynpro Introduction
5.
Define the navigation.
a)
Drag the outbound plug of view INPUT_VIEW and drop it on the inbound
plug of view OUTPUT_VIEW. Confirm the data in the dialog box.
b)
Drag the outbound plug of view OUTPUT_VIEW and drop it on the
inbound plug of view EMPTYVIEW. Confirm the data in the dialog box.
c)
Save.
Task 4:
Activate the component. Define a new Web Dynpro application to access the new
window of your application. Start the new application.
1.
Activate your component and all contained component entities.
a)
2.
Perform this step as in the previous exercise.
Create a Web Dynpro application for your component.
a)
→
From the context menu of your application choose Create
Web Dynpro
Application. Enter a name in the customer name space and a description.
Click Enter.
Hint: This time you have to enter the application name since an
application having the name of the component has already been
defined.
2009
b)
Define the application properties. Use the corresponding drop down box to
enter the name of the new window in the field Interface View and the value
DEFAULT in the field Plug Name.
c)
Save your application.
d)
Start the application.
© 2008 SAP AG. All rights reserved.
43
Unit 1: Web Dynpro Introduction
NET310
Lesson Summary
You should now be able to:
•
Describe the declarative programming approach used to create Web Dynpro
applications.
•
Explain the benefits resulting from this metadata approach.
•
List the most important elements that are part of a Web Dynpro application
and that can be defined declaratively.
44
© 2008 SAP AG. All rights reserved.
2009
NET310
Unit Summary
Unit Summary
You should now be able to:
•
Describe the declarative programming approach used to create Web Dynpro
applications.
•
Explain the benefits resulting from this metadata approach.
•
List the most important elements that are part of a Web Dynpro application
and that can be defined declaratively.
2009
© 2008 SAP AG. All rights reserved.
45
Unit Summary
46
NET310
© 2008 SAP AG. All rights reserved.
2009
Unit 2
Web Dynpro Controllers
41
This unit does not discuss every detail concerning Web Dynpro controllers. Some
topics, like hook methods available only for view controllers or component controllers
will be discussed in the corresponding units (“Controller and Context Programming”,
“Dynamic Modifications at Runtime” ... ). So focus on giving an overview of the
constituent parts of a controller and describe what they are used for.
Unit Overview
Controllers contain the source code of a Web Dynpro application. They contain all
data - stored as controller attributes or as attributes belonging to context elements.
In addition they control event handling and navigation. Any programming of flow
logic requires knowledge of how controllers are defined and what kind of elements
they offer.
This unit gives a brief introduction to Web Dynpro controllers. Special attention
will be given to the differences between the different controller types that can exist
in a Web Dynpro component.
Unit Objectives
After completing this unit, you will be able to:
•
•
•
Name the contents of a Web Dynpro controller.
Describe the function of each controller entity.
List the differences between the component controller, custom controllers, view
controllers and window controllers.
Unit Contents
Lesson: Web Dynpro Controllers .................................................. 48
2009
© 2008 SAP AG. All rights reserved.
47
Unit 2: Web Dynpro Controllers
Lesson:
42
NET310
Web Dynpro Controllers
Lesson Duration: 40 Minutes
Lesson Overview
As the place where program logic and data are defined, controllers are the heart of
Web Dynpro components. This lesson gives an overview of the entities that make
up a controller.
Lesson Objectives
After completing this lesson, you will be able to:
•
•
•
Name the contents of a Web Dynpro controller.
Describe the function of each controller entity.
List the differences between the component controller, custom controllers, view
controllers and window controllers.
Do not go into detail concerning the order of hook methods, special hook methods,
etc., as these details can be explained in the corresponding chapters later in course
NET310.
For the demos, you should be familiar with the creation of WD components, including
the embedding of a view in a window, custom controllers, and WD applications.
It’s a good idea to compare the abstract component entities with entities the students
know from OO programming:
•
•
•
•
The complete component will be stored as a global class.
Each controller will end up as a local class in the global component class.
Defining a controller usage means that this controller may ask the WD
framework for the reference to the used controller object at runtime. If this
reference is not known, the controller object can not be accessed.
Controller attributes, events, methods are stored as public attributes, public
events and public methods in the related controller class.
Business Example
You are familiar with the windows, views, and controllers that make up a Web Dynpro
program. However, to implement the flow logic, which comprises event handling,
inbound plug method implementation reaction on client side events and so on, it is
necessary to know the inner structure of controllers.
48
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Web Dynpro Controllers
Controller Types
There are four types of controllers in a Web Dynpro component. These different
controller types differ in the entities of which they are composed:
•
Component controller
There is only one component controller per Web Dynpro component. This is a
global controller, visible to all other controllers. The component controller drives
the functionality of the entire component. This controller has no visual interface.
•
Custom controllers
Custom controllers are optional. They have to be defined at design time and
can be used to encapsulate subfunctions of the component controller. Multiple
custom controllers can be defined in a component. Custom controllers are
instantiated automatically by the Web Dynpro framework and the instantiation
order is undefined; therefore, the coding in a custom controller should not
depend on the existence of any other custom controller.
•
Configuration controllers
This is a special custom controller. It is only necessary if the corresponding
component implements special configuration and personalization functions.
Only one configuration controller may exist in any component. Any controller
can access the configuration controller, but the configuration controller cannot
access any other controller.
•
View controllers
Each view consists of the layout part and exactly one view controller. This
controller handles the view-specific flow logic, like checking user input and
handling user actions.
•
Window controllers
Each window has exactly one window controller. This controller can be used
to handle the data passed via the inbound plugs when being reused as a child
controller. Methods of this controller can be called from the inbound plug
methods of the window.
At runtime, all controller instances are singletons with respect to their parent
components. This is also true for view controllers; thus, embedding a view in a view
assembly more than once is not allowed.
2009
© 2008 SAP AG. All rights reserved.
49
Unit 2: Web Dynpro Controllers
NET310
The context and the methods defined in a controller are private unless another
controller explicitly declares the usage of this controller. However, a view controller
cannot be declared as a used controller, so the context data and the methods of a view
controller are always private.
Web Dynpro is a stateful implemented technology, meaning that the lifetime of
controller instances is not limited to the time used to process the program code and
to process the UI. Depending on the controller type, the controller instance lifetime
is as follows:
Component controller
The lifetime of the component controller is the lifetime of the component. When
you start a Web Dynpro application, the component controller is instantiated
by the Web Dynpro runtime.
Custom controllers
The instantiation of a custom controller is delayed until the first method of the
controller is called. Custom controller instances cannot be deleted explicitly.
Configuration controllers
This controller is instantiated as the first controller of the component. It lives as
long as the component lives.
View controllers
The instantiation of a view controller is delayed until the first method of the
controller is called. The lifetime of a view controller can be controlled via the
view properties:
If framework controlled is selected, the view instance will be deleted with
the component.
If when visible is selected, the view instance is deleted as soon as the view
no longer belongs to the view assembly.
Window controllers
The instantiation of a window controller is delayed until the first method of
this controller is called. This is done by starting a Web Dynpro application, by
embedding the related interface view in the parent component’s window, or
by displaying the window as a popup. Window controller instances cannot
be deleted explicitly.
Common Controller Entities
Each controller has its own context. The context root node already exists. All other
nodes and attributes have to be defined statically or by source code.
50
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Web Dynpro Controllers
Figure 18: Constituents of all controllers
Display the component controller of the component NET310_EVEN_D1. Click the
single tabs to display the common controller entities. Open a view controller and
the window controller of this component in order to demonstrate which entities are
found in all of these controllers.
Add an attribute and a method to any of the controllers located in your demo
component. Demonstrate how to add a used controller statement to one of the
controllers.
For all controllers, methods are called by the Web Dynpro framework in a predefined
order. These are called hook methods. Depending on the controller type, there are
different hook methods available. At least two hook methods are contained in all
controller types. These methods are processed only once during the lifetime of a
controller instance: once when a controller instance is created (wddoinit( )) and once
when a controller instance is deleted (wddoexit( )).
Additional methods can be defined using the Methods tab.
Attributes not bound to any UI element property should be declared using the
Attributes tab. These attributes are then visible in all methods of this controller.
There are two predefined attributes, which are used to access the functionality of the
controller (WD_THIS) and of the context (WD_CONTEXT).
2009
© 2008 SAP AG. All rights reserved.
51
Unit 2: Web Dynpro Controllers
NET310
To share information between different controllers, one controller must declare the use
of another controller. This is done on the Properties tab of the controller that needs to
access another controller. This type of data sharing is most often used when you wish
to create a mapped context node or when you wish to access another controller’s user
defined methods and public attributes.
You may not specify the name of a view controller as a used controller, as this would
violate good MVC design principles. A view controller should be written such that
it is responsible for nothing more than the display of data and user interaction. A
view controller is not responsible for generating the data it displays; that is the role
of a custom controller.
Business logic, such as function modules, BAPIs or methods in helper classes, can be
accessed from the methods of all controllers.
Special Entities of Component / Custom Controllers
Figure 19: Component / custom controllers: special entities
Create an event in the custom controller of your component. Define a controller usage
of the custom controller in the component controller. Define an event handler method
in the component controller and register this method to the custom controller event.
52
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Web Dynpro Controllers
For both component controller and custom controllers, events can be defined with
the parameters of your choice. Any method of any other controller, including view
and window controllers, can register to these events if this method is defined as an
event handler method. A typical use of such events is the invocation of processing in a
view controller after processing in the component controller has been completed. This
can be done when a method in the view controller subscribes to an event raised by
the component controller.
Using your design-phase declarations, the Web Dynpro framework automatically
performs the definition, triggering, and handling subscription to such events for you.
You also have the additional option of dynamic event subscription at runtime.
Caution: If two or more methods subscribe to the same event, the order in
which they will be executed is undefined.
The component controller has three additional hook methods:
wddobeforenavigation( ), wddopostprocessing( ), and wddoapplicationstatechange( ).
For details please refer to the lesson “Controller an Context Programming”.
Methods, context elements, and events can be marked as interface elements. These
elements are then exposed to other components by means of the interface controller.
Special Entities of View Controllers
Figure 20: View controllers: special entities
2009
© 2008 SAP AG. All rights reserved.
53
Unit 2: Web Dynpro Controllers
NET310
A view controller is a visual building block of a Web Dynpro component and it is
designed to handle all aspects of data display and user interaction.
To enable navigation between different Web Dynpro view controllers, special
navigation events and navigation event handlers have been created. These are called
navigation plugs.
A navigation event is raised when an outbound plug is fired.
Using the generic name <Outbound plug> for an outbound plug, its declaration
causes a method named FIRE_<Outbound plug>_PLG to be generated in the view’s
component controller.
An inbound plug is a navigation event handler that can be registered to a navigation
request. Using the generic name <Inbound plug> for an inbound plug, its declaration
causes a method named HANDLE<Inbound plug>_PLG to be generated in the view’s
component controller.
A static registration of an inbound plug to the navigation event raised by an outbound
plug is called a navigation link. Navigation links are not part of a view but are
defined in a window embedding the view. Thus the event registration can be defined
differently in different windows.
An action links a client-side event (for example, clicking a button in a browser) to an
event handler method defined in the corresponding view controller. When defining an
action with the name <Action>, an event handler method (ONACTION<Action>) is
automatically generated. If a view has to be replaced as a result of a client event, the
related outbound plug can be fired in this action event handler method.
There are four special hook methods found in view controllers: wddobeforeaction( ),
wddoafteraction( ), wddomodifyview( ), and wddooncontextmenu( ). For details please
refer to the lesson “Controller an Context Programming”.
In addition to the standard attributes of all controllers, a view controller has a reference
to the component controller of its component: WD_COMP_CONTROLLER. This
reference can be used to access functions related to the component controller. It is
used when accessing messages or when calling a method declared in the component
controller.
Hint: The attribute WD_COMP_CONTROLLER does only exist, if the usage
of the component controller is declared.
54
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Web Dynpro Controllers
Start demo NET310_EVEN_D1. Discuss the order in which the events are processed.
Repeat the discussion with demo NET310_EVEN_D2
Here you could also demonstrate the influence of the view’s lifetime property
on the lifetime of the view. Start WD applications NET310_CONF_D2 and
NET310_CONF_D2A. The related components are identical; only the lifetime of the
views is different. The layout displays how often the WDDOINIT hook method is
processed. If the view survives a navigation request, the method will not be processed
again. WDDOEXIT is only processed if the view is deleted.
Special Entities of Window Controllers
Window controllers are very similar to view controllers. Technically, it is like a
view controller without a UI (view layout). All views that are to be displayed when
using a Web application have to be embedded in the window that is referred to by
the application or the calling component.
Figure 21: Window controller architecture
2009
© 2008 SAP AG. All rights reserved.
55
Unit 2: Web Dynpro Controllers
NET310
The Web Dynpro window embeds all views to be displayed and - if statically defined the navigation links defining the possible view assemblies.
Each Web Dynpro window contains outbound plugs and inbound plugs, just like
views. You can use the plugs to set up cross-component navigation. To expose the
plugs to the component interface, select the property Interface for each plug. These
plugs will then be part of the related interface view.
If the usage of the component controller is declared, the window controller will also
have the additional attribute WD_COMP_CONTROLLER allowing to access the
component controller functionality.
There are two special hook methods found in window controllers: wddoonopen( )
and wddoonclose( ). For details please refer to the lesson “Controller an Context
Programming”.
56
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Web Dynpro Controllers
Facilitated Discussion
Discuss on open questions.
Discussion Questions
Use the following questions to engage the participants in the discussion. Feel free to
use your own additional questions.
•
•
•
2009
When are the controller objects instantiated and when are the controller objects
deleted?
What kind of data should be stored in the context and which data objects should
be stored in controller attributes?
Which hook methods belong to a the view controller and which ones belong to a
component controller?
© 2008 SAP AG. All rights reserved.
57
Unit 2: Web Dynpro Controllers
NET310
Lesson Summary
You should now be able to:
•
Name the contents of a Web Dynpro controller.
•
Describe the function of each controller entity.
•
List the differences between the component controller, custom controllers, view
controllers and window controllers.
58
© 2008 SAP AG. All rights reserved.
2009
NET310
Unit Summary
Unit Summary
You
•
•
•
2009
should now be able to:
Name the contents of a Web Dynpro controller.
Describe the function of each controller entity.
List the differences between the component controller, custom controllers, view
controllers and window controllers.
© 2008 SAP AG. All rights reserved.
59
Unit Summary
60
NET310
© 2008 SAP AG. All rights reserved.
2009
Unit 3
The Context
53
In the mean time I explain context nodes, context elements, and context attributes be
sketching the real objects with their main attributes and their dependencies to other
parts of the context. This means:
Each data set is stored as an element. An element is an object containing the important
attributes STATIC_ATTRIBUTES and CHILD_NODES.
The reference to these elements are stored in an internal table being an attribute
(COLLECTION) of a node.
Beginning with WD_CONTEXT, you can explore the context without having to
define any source code. Take your time to get familiar with debugging the context.
Take into account the following situations:
A mapped node does not store the element collection. This is stored in the mapping
origin. The reference to the mapping origin is provided by the node’s attribute
MAPEE. On the other side, MAPPERS is a table containing the references to all
mapped nodes.
Storing elements in the context node is performance optimized and thus delayed. This
makes debugging nasty, especially when defining the context at run time!
Unit Overview
Data used to control the UI has to be stored in the controller context. The context is a
hierarchical structure, which can be defined statically or at runtime. Understanding
the context structure consisting of context nodes and context elements is a prerequisite
to working in this context. In this unit, we will explain how to define the context
structure statically.
Unit Objectives
After completing this unit, you will be able to:
2009
© 2008 SAP AG. All rights reserved.
61
Unit 3: The Context
•
•
•
NET310
Define nodes and attributes in a controller’s context.
Explain how the node properties cardinality and singleton influence memory
allocation at runtime.
Define the mapping between contexts of different controllers located in the
same Web Dynpro component.
Unit Contents
Lesson: The Context ................................................................ 63
Exercise 4: Context Definition, Context Mapping, and Data Binding ..... 81
62
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson:
54
Lesson: The Context
The Context
Lesson Duration: 70 Minutes
Lesson Overview
At design time, the developer can statically define the context structure of any
controller. Context nodes and context attributes have to be added to the structure
hierarchy and properties have to be set for each context node and attribute,
respectively. At runtime, these properties govern memory allocation, for example,
the type of the content and the dimension of data arrays to be stored. It is therefore
essential to understand the static definitions and the runtime properties related to the
context. This lesson presents a basic introduction to the context.
Lesson Objectives
After completing this lesson, you will be able to:
•
•
•
Define nodes and attributes in a controller’s context.
Explain how the node properties cardinality and singleton influence memory
allocation at runtime.
Define the mapping between contexts of different controllers located in the
same Web Dynpro component.
Depending on how much was covered in the Web Dynpro Introduction unit, some
topics can be skipped (context mapping).
In this lesson, continue developing your WD component. Create a context node in the
component controller (with some attributes), copy this node to both views and map the
context nodes of both views to the component controller context node. Create forms
that allow you to enter data in one view and display it in the other view.
Business Example
You have created your first Web Dynpro component with views and windows
embedding the views. You have created a Web Dynpro application to access your Web
Dynpro component from the browser. However, you do not want your application to
display static data only, but also data from a back-end system. So you need to define
variables that can be bound to UI elements and that can be easily exchanged between
different controllers. These variables must be defined in the controller context, so you
want to learn about how to define this hierarchical data storage structure.
2009
© 2008 SAP AG. All rights reserved.
63
Unit 3: The Context
NET310
Defining the Context Structure
Every Web Dynpro controller has exactly one hierarchical data storage structure,
known as a context. The data held in the context exists only for the life span of the
controller. Once the controller instance has been terminated, all data held within
its context is lost.
Figure 22: The context
The structure (that is, the meta data) of a context is typically defined at design time.
However, at runtime you can not only modify the contents of the context, but also
modify the structure itself.
64
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: The Context
Figure 23: Changing the context (1)
Figure 24: Changing the context (2)
Unless declared differently, all runtime data in a controller’s context is private to
that component.
2009
© 2008 SAP AG. All rights reserved.
65
Unit 3: The Context
NET310
Information held in the context of the component controller or of a custom controller
can be made easily accessible to the context of another controller (view or custom) by
a technique known as context mapping. Using this technique, two or more controllers
can access the same runtime data. This is the primary mechanism for sharing data
between controllers within a single component.
It is not possible for a view controller to share its context data.
Figure 25: Creating new context elements
Demo step 1: Create a context node with attributes in the component controller.
Show how to define a node without attributes and add the attributes one by one. Also
show how a node related to a DDIC structure and some attributes related to structure
fields can be defined in one step. Show how to add or delete some of the attributes
after creating the node (choose Change in the context menu of the node). Show how
to copy a node from another controller (choose Create Using the Wizard
Copy
Nodes of Different Context).
→
All controller contexts are constructed from a hierarchical arrangement of entities
known as nodes and attributes. A context always has a parent node known as the
context root node. The root node is created automatically when the controller is
initialized and always has fixed properties. The context root node cannot be deleted
or modified in any way.
66
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: The Context
A context node is the main abstraction class used for runtime data storage within the
Web Dynpro framework. Context nodes are arranged hierarchically. The node may
have attributes or other nodes as children.
All the child entities of a node are aggregated into a unit known as an element. A
node can be thought of as a collection of such elements in the same way that a table
is a collection of rows.
Caution: The name of a context node must be unique within the complete
structure of a controller’s context.
A context attribute is an entity within the context that is not permitted to have
children. A context attribute cannot exist without being the child of some parent node,
be it the context root node itself or some other node.
If a collection of structured data objects should be stored in a controller context
at runtime, a context node must be defined to store the collection itself. Context
attributes or other context nodes must be defined as subelements, storing the elements
of each structured data object.
Figure 26: Context nodes an context attributes at runtime (1)
2009
© 2008 SAP AG. All rights reserved.
67
Unit 3: The Context
NET310
Figure 27: Context nodes an context attributes at runtime (2)
68
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: The Context
Figure 28: Context nodes an context attributes at runtime (3)
Context Node Properties
A lot of node properties set at design time govern memory allocation (for example, the
dimension of data array to be stored) at runtime. It is therefore essential to understand
the node’s properties.
Collection Cardinality
At design time, you create the meta data structure within which the runtime data will
be stored. All context nodes are collections, so there could potentially be multiple
element references stored by a context node at runtime.
Every context node has a property known as cardinality. This property is composed
of two values that, taken together, describe the maximum and minimum number of
elements the node collection may hold at runtime:
Cardinality minimum: 0 or 1
Cardinality maximum: 1 or n
2009
© 2008 SAP AG. All rights reserved.
69
Unit 3: The Context
NET310
There are therefore four possible cardinality values (specified as <Min>..<Max>):
•
•
•
•
0..1:
0..n:
1..1:
1..n:
Zero or one element permitted
Zero or more elements permitted
Exactly one element permitted
One or more elements permitted
If the node’s cardinality is 0..1 or 0..n and no element is created and explicitly added
to the collection, the node will have an empty collection. A view containing form
fields which are bound to attributes of this node can then not be displayed, since the
corresponding data storage does not exist. The application will dump.
All nodes contain an element collection, even if the maximum number of elements
within the collection is limited to one.
Figure 29: Context structure at runtime: cardinality property (1)
The context root node always contains exactly one element (note that the cardinality is
1..1). This is known as the default element and cannot be deleted! This also implies
that any node collection that is a direct child of the context root node exists at runtime
70
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: The Context
as an empty collection (cardinality = 0..<something>) or with one default element
(cardinality = 1..<something>). These child nodes of the context root node are
therefore called independent nodes. All other node collections exist only if their
parent collections contain at least one element. The existence of these node collections
at runtime is therefore not guaranteed. Thus, these nodes are called dependent nodes.
If you attempt to perform any action on a node collection that would violate its
cardinality, you will get a runtime error from the Web Dynpro framework. Such
actions include:
•
•
Trying to delete the default element of a node with cardinality 1..1 or 1..n
Trying to add a second element to a node with cardinality 0..1 or 1..1
Figure 30: Context structure at runtime: cardinality property (2)
You can now see that the structure of the context at runtime is not the flat,
two-dimensional hierarchy seen at design time. At runtime, the context consists of
multiple dependent objects.
This can be compared to an internal table in ABAP at design time and runtime. At
design time, the meta data of the internal table comprises the structure given by the
line type. The dimension of the internal table (how many lines the data object holds at
runtime) is not part of the definition. At runtime, multiple lines can be appended to the
2009
© 2008 SAP AG. All rights reserved.
71
Unit 3: The Context
NET310
internal table data object, just as multiple elements can be appended to a collection
originating from a context node at runtime. However, since there are no restrictions on
the minimum and maximum number of lines an internal table can hold, there is no
counterpart for the cardinality property. Internal tables always have zero lines after the
declaration of the object, and they can hold an unrestricted number of lines at runtime.
The Lead Selection
A node’s element collection can be accessed using an index value. The lead selection
of a context node either points to a single selected node element (lead selection value
= index of the selected node element) or, if no element is selected, has the value of
the constant IF_WD_CONTEXT_NODE=>NO_SELECTION. The lead selection can
be set automatically by the Web Dynpro framework if the context node property
Initialize Lead Selection is set to true. In this case, the first element in a collection
is automatically marked as the element when the lead selection is made. The lead
selection can also be set by program source code or it can be set by user actions related
to UI elements (e.g. by selecting a line in Table UI element bound to the node).
Figure 31: Lead selection index
72
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: The Context
Your component: Open one of the views, navigate to the context and show the
property of the previously created context node (Cardinality, Initialize Lead Selection,
...). Show that these properties can only be manipulated for the mapping origin, not
for the mapped nodes.
If the lead selection is set, the following is true:
•
•
In the controller code, special methods can be used to access the lead selection of
a node, as well as its position.
UI elements such as input fields can be bound to the attributes of this element.
The Singleton Property
Figure 32: Context structure at runtime: singleton property (1)
Note that the context node N1 has a child node called N2. The N2 node is a distinct
node with its own element collection.
The boolean property Singleton critically affects the relationship between a dependent
node and its parent node!
2009
© 2008 SAP AG. All rights reserved.
73
Unit 3: The Context
NET310
If the N2 node has its singleton property set to false (node N2 at runtime will be
a non-singleton - which is the default), then for every element in the parent node
collection N1 there will be a distinct instance of the child node N2.
The most important thing to understand here is that each instance of the N2 node is
related to the respective element in the parent node collection. Note that the arrows
pointing to each of the N2 node collections originate in the elements of the parent node.
Therefore, if there are n elements in the parent node, then there will be n distinct
instances of a non-singleton child node.
Figure 33: Context structure at runtime: singleton property (2)
If the node N2 now has its Singleton property set to true, it does not matter how many
elements are present in the parent node collection N1. There will only ever be one
instance of the child node N2, so the N2 node will be a singleton at runtime.
Supply Function
In the above example, there could be many different elements in the N1 node
collection. We need to ensure that when the child node N2 is accessed, it contains the
correct data for the selected element in the parent node.
74
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: The Context
Figure 34: Repopulating a dependent node (here singleton node): supply
function
Supply functions are a mechanism for repopulating child nodes. A supply function can
be assigned to each context node of a controller. This supply function is automatically
called by the Web Dynpro runtime under the following conditions:
•
•
•
If the node’s collection is initial.
If the lead selection index of the parent node is changed.
If the node’s collection is invalidated programmatically.
Hint: For all of these situation, the supply function is only called when
necessary: If the child node N2 is neither accessed programmatically nor it
is bound to any UI element on the next view assembly, the supply function
will not be called.
Hint: Supply functions may not be called from the source code of a controller
method. Only the WD runtime can access such a method.
2009
© 2008 SAP AG. All rights reserved.
75
Unit 3: The Context
NET310
A supply function can be assigned to a node by setting the value of property Supply
Function accordingly. As a result, an additional controller method is generated with
a given signature:
•
•
A reference to the element at lead selection in the parent node (name:
PARENT_ELEMENT) allows access to the attributes of this element.
A reference to the node to which the supply function is related to (name: NODE)
allows you to store the dependent data in the child nodes collection.
Your component: Edit the component controller context. You have previously created
a node with attributes. Now add a subnode to this node. Edit the node’s properties.
Enter any name in the input field for the property Supply Function. Press Enter.
Open the Methods tab and display the generated supply function with its interface
parameters.
When a typical business transaction is being used, information will often be presented
in the form of a list of header records of some sort (sales order headers, for example).
From this list, the user typically selects one order header and then looks at its line
items. It makes much more sense to read the line item information only when it is
needed rather than reading all line items for all sale orders on the assumption that
it might be relevant for someone! This would be a highly inefficient application
architecture both in terms of processing requirements and memory usage.
Web Dynpro follows the principle of lazy data instantiation. This means that data is
only created when it is actually needed. When this principle is applied to the context
architecture, it means that unless the program actually needs to look at the data in a
child node, the child node will remain unprocessed.
Lazy data instantiation also means that dependent collections are not automatically
created for all elements of the parent node. The creation of a collection of the
dependent node is delayed till the point at which the related element of the parent
collection gets the lead selection.
76
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: The Context
Context Mapping
Figure 35: Context mapping
Context mapping allows a controller (typically a view controller) to access data that
was preprocessed by some other controller. Since a mapping relationship allows a
direct reference to be made to data in another controller, there is no need for this data
to be copied or moved.
2009
© 2008 SAP AG. All rights reserved.
77
Unit 3: The Context
NET310
The context node that acts as the data source is known as the mapping origin node,
and the context node that is mapped is known as the mapped node.
Note: A mapped node ceases to maintain its own element collection! Instead,
it references the element collection of the mapping origin node. A view
controller cannot act as a data source for a mapping relationship because this
would violate the principles of MVC program design.
Hint: In programs designed according to the MVC principle, a view
controller should be written in such a way that it takes no part in the
generation of the data it displays. Instead, the view controller should only be
concerned with displaying pre-generated data and then handling the resulting
user interaction (validation, error handling and so on). It is the component
controller’s (or custom controller’s) job to interact with back-end logic to
generate the required data.
Once the data has been generated, the component controller (custom
controller) then supplies it to a view controller for display. If a view controller
were allowed to act as the data source (origin) for a mapping relationship, a
situation could arise in which the component controller (a custom controller)
is dependent upon functionality found in a view controller. This would be bad
design and is therefore not permitted.
To establish context mapping between two controllers, the target controller has to
declare the source controller as a used controller in its properties. If the Context tab is
chosen in edit mode of the target controller, the contexts of all used controllers are
displayed on the right side. A node of a source context can then be referenced as
follows:
Your component: Now edit your views.
You can create the context structures by dragging the node from the component
controller context and dropping it on the context root nodes of your views. This also
establishes the context mapping.
You can also copy the context node first and create the mapping afterwards by
dragging the view node and dropping it on the node acting as the mapping origin.
Finally, demonstrate how input fields can be created automatically (using the WD
Code Wizard will create a transparent container containing the form elements.
However, only input fields can be created this way. Using the Create Container Form
78
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: The Context
function from the context menu of the ROOTUIELEMENTCONTAINER will not
create a transparent container that embeds the form fields. However, the developer
can decide which context attribute will be bound to what kind of UI element).
You should also show how changes in the context structure of the mapping origin can
be taken into account by the mapping (choose Update Mapping, Delete Mapping).
•
•
If an independent node to be mapped is not yet defined in the target controller’s
context, the complete structure related to the source node is copied by dragging
it from the source controller context and dropping in on the root node of the
target controller context. In addition, the copied node will be mapped to the
source node.
If the structure related to a node is already defined in the context of the target
controller, the mapping can be established by dragging one of the nodes and
dropping it on the other node. However, the mapping origin is always the node
contained in the used controller (displayed on the right side), the mapping target
is always displayed on the left side.
Hint: If the node to be mapped contains attributes that are not contained
in the mapping origin, then these attributes will be deleted when
mapping the node.
Hint: Mapping origin and mapped node may have different names.
Hint: After executing the mapping between the two nodes, all of their
elements are mapped – both attributes and child nodes.
If the node structure of the mapping origin changes - elements added, deleted
or modified - the mapping can be updated (synchronized) using the context
menu of the mapped node.
2009
© 2008 SAP AG. All rights reserved.
79
Unit 3: The Context
NET310
Figure 36: Context mapping: internal mapping
Internal mapping is the name given to a mapping relationship in which both
the mapped node and the mapping origin node lie within the boundaries of one
component. This means that the mapping relationship can be fully established when
writing the current component.
There is, however, one special case in which a mapping relationship can only be
partially established when writing the current component. This is known as external
mapping. As the name implies, this is a situation in which the mapping origin node
lies outside the boundaries of, or is external to, the current component. External
mapping will be discussed in the lesson dealing with reusing Web Dynpro components.
Exercise “Context Definition, Context Mapping, and Data Binding”
80
© 2008 SAP AG. All rights reserved.
2009
NET310
73
Lesson: The Context
Exercise 4: Context Definition, Context
Mapping, and Data Binding
Exercise Duration: 30 Minutes
Exercise Objectives
After completing this exercise, you will be able to:
•
Create nodes in contexts of components and views
•
Map view context nodes to component context nodes
•
Create input/output fields on Web Dynpro views
•
Bind UI elements to view context nodes
Business Example
You want to develop a Web Dynpro application allowing to enter data into input fields
on the first view. The user input should be displayed on the following view.
Template: NET310_CTRL_S
Solution: NET310_COND_S
Task 1:
Copy your solution from the previous exercise or the template component.
1.
Copy your solution from the previous exercise (ZNET310_CTRL_##) or
the Web Dynpro component NET310_CTRL_S to the new component,
ZNET310_COND_##.
Task 2:
In the context of the component controller, create a context node containing attributes
to store a carrier ID and a connection ID. Create the same context node in each of the
two views and map the nodes defined in the view controller contexts to the node
defined in the component controller context.
1.
In the context of the component controller, create a context node having he name
FLIGHTINFO. This node should be based on dictionary type SFLIGHT and it
should have cardinality 1..1. Add two attributes from the structure components
CARRID and CONNID.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
81
Unit 3: The Context
2.
NET310
Create the same node in the context of each view controller and map the context
node of the view controllers to the context node FLIGHTINFO of the component
controller.
Task 3:
For both views, create a form displaying a label and an input fields for each context
attribute of the node FLIGHTINFO. Use the Web Dynpro Code Wizard to perform
this step.
82
1.
On the layout of the view INPUT_VIEW, create a form with references to the
context attributes CARRID and CONNID. Use the Web Dynpro Code Wizard to
create the form.
2.
Correct the value of property LayoutData for the TEXTVIEW UI element
serving as the form’s caption. Set LayoutData = MatrixHeadData. Assign a
text to this UI element.
3.
Repeat the previous steps for the view OUTPUT_VIEW.
4.
Activate your component. Create a Web Dynpro application for your component.
Test the application.
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: The Context
Solution 4: Context Definition, Context
Mapping, and Data Binding
Task 1:
Copy your solution from the previous exercise or the template component.
1.
Copy your solution from the previous exercise (ZNET310_CTRL_##) or
the Web Dynpro component NET310_CTRL_S to the new component,
ZNET310_COND_##.
and
a)
One possible solution: In the object navigator, choose Other object
select the Web Objects tab page.
b)
Enter the name of the Web Dynpro component to copy and choose Copy
c)
Enter a name for the new Web Dynpro component.
.
Task 2:
In the context of the component controller, create a context node containing attributes
to store a carrier ID and a connection ID. Create the same context node in each of the
two views and map the nodes defined in the view controller contexts to the node
defined in the component controller context.
1.
In the context of the component controller, create a context node having he name
FLIGHTINFO. This node should be based on dictionary type SFLIGHT and it
should have cardinality 1..1. Add two attributes from the structure components
CARRID and CONNID.
a)
Edit the component controller and choose the Context tab page.
b)
Open the context menu of the root context node and choose Create
c)
Enter the node name, the name of the dictionary type (structure) and the
cardinality.
d)
Choose Add Attribute from Structure, mark the structure components
CARRID and CONNID and choose Enter to finish the dialog.
e)
Save.
→ Node.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
83
Unit 3: The Context
2.
NET310
Create the same node in the context of each view controller and map the context
node of the view controllers to the context node FLIGHTINFO of the component
controller.
a)
Edit one of the Web Dynpro views and choose the Context tab page.
b)
Drag the context node FLIGHTINFO from the component controller
context (at right) and drop it on the root node of the view controller context
(at left).
c)
Save.
d)
Repeat these steps for the second view.
Task 3:
For both views, create a form displaying a label and an input fields for each context
attribute of the node FLIGHTINFO. Use the Web Dynpro Code Wizard to perform
this step.
1.
On the layout of the view INPUT_VIEW, create a form with references to the
context attributes CARRID and CONNID. Use the Web Dynpro Code Wizard to
create the form.
a)
Edit the Web Dynpro view and choose the Layout tab.
b)
Mark the ROOTUIELEMENTCONTAINER UI element in the UI element
hierarchy.
c)
Start the Web Dynpro Code Wizard by clicking the button in the Web
Dynpro Explorer bar. Select the template for generating forms by
double-clicking on the related item.
d)
Click the Context button, then double-click the context node
(FLIGHTINFO) in the dialog box.
e)
Confirm the entries (Enter).
Continued on next page
84
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: The Context
2.
Correct the value of property LayoutData for the TEXTVIEW UI element
serving as the form’s caption. Set LayoutData = MatrixHeadData. Assign a
text to this UI element.
a)
Below the ROOTUIELEMENTCONTAINER a transparent container has
been created encapsulating the form fields. Click on the first element in
this container being of type TEXTVIEW. This element serves as a caption
for the form.
b)
Use the drop down box for property LayoutData to change the property’s
value.
c)
Enter any text in the field right of property text.
Hint: You can rearrange the UI elements as follows:
•
•
3.
4.
Repeat the previous steps for the view OUTPUT_VIEW.
a)
Perform this step as before.
b)
Change the read-only property of the input fields of this view by toggling
the readOnly check box for each input field.
Activate your component. Create a Web Dynpro application for your component.
Test the application.
a)
2009
Dragging and dropping the button on the transparent
container will make it the last element in the container.
Setting the button’s property LayoutData to MatrixHeadData
will move the button to a new line in the container.
Perform this step as in previous exercises.
© 2008 SAP AG. All rights reserved.
85
Unit 3: The Context
NET310
Lesson Summary
You should now be able to:
•
Define nodes and attributes in a controller’s context.
•
Explain how the node properties cardinality and singleton influence memory
allocation at runtime.
•
Define the mapping between contexts of different controllers located in the
same Web Dynpro component.
86
© 2008 SAP AG. All rights reserved.
2009
NET310
Unit Summary
Unit Summary
You should now be able to:
•
Define nodes and attributes in a controller’s context.
•
Explain how the node properties cardinality and singleton influence memory
allocation at runtime.
•
Define the mapping between contexts of different controllers located in the
same Web Dynpro component.
2009
© 2008 SAP AG. All rights reserved.
87
Unit Summary
88
NET310
© 2008 SAP AG. All rights reserved.
2009
Unit 4
Defining the User Interface
81
The focus of this chapter is NOT to discuss all UI elements and their properties this is the content of course NET312. This lesson focusses on the concepts of data
binding, changing UI element properties at runtime and the basics of the element
Table. Comprehensive documentation is available for each UI element via the context
menu in the UI element hierarchy.
Unit Overview
One of the strengths of Web Dynpro is the easy definition of user interfaces. Just as
with the classical Dynpro, a WYSIWYG tool is used to design the view layout. At
runtime, the layout is generated from the meta data description of the UI. The result
depends on the client class and on the protocol. This unit addresses all aspects of
user interface definition.
Unit Objectives
After completing this unit, you will be able to:
•
•
•
Define the view layout by arranging UI elements and setting their properties.
Bind UI element properties to context attributes.
Use the table UI element as an example of using composite UI elements.
Unit Contents
Lesson: Defining the User Interface ............................................... 90
Exercise 5: Using Layout Managers to arrange UI elements............. 121
Exercise 6: Displaying Tables................................................. 129
2009
© 2008 SAP AG. All rights reserved.
89
Unit 4: Defining the User Interface
Lesson:
82
NET310
Defining the User Interface
Lesson Duration: 160 Minutes
Lesson Overview
Defining the user interface involves defining the UI elements and their arrangement in
the view layout as well as binding the UI element properties to context attributes. The
UI element properties can then be controlled via the controller source code by acting
on the attributes, guaranteeing the best separation between UI and program logic.
This lesson explains how to arrange the various UI elements to form the layout of a
view. Not only standard UI elements are discussed, but also complex elements, i.e.
nested UI elements (for example Table or Tree). We will also discuss how to define
data binding between UI element properties and context attributes.
Lesson Objectives
After completing this lesson, you will be able to:
•
•
•
Define the view layout by arranging UI elements and setting their properties.
Bind UI element properties to context attributes.
Use the table UI element as an example of using composite UI elements.
Only the simple elements and the container elements are discussed here. Some
students may also ask about Trees, Business Graphics, Tab Strips, or details about
Tables. These students should attend NET312. In this class nearly all UI elements are
discussed or at least demos for nearly all UI elements exist in Package NET312. A
standard SAP Web Dynpro application (WDR_TEST_UI_ELEMENTS) can also be
used to explore the functionality of elements not covered in this training material.
Business Example
You want to create a Web Dynpro application that has an optimized user interface
(for example, you want to arrange the elements on the screen in groups or trays).
Mass data should be displayed in tables, which allows you to mark one or more rows
and filter or sort the data. In addition, certain properties of the UI elements (such as
visibility) should be controlled from the application source code. So you want to
learn more about UI elements.
90
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Defining the User Interface
Defining a View Layout
Figure 37: UI elements
A UI element is any graphical entity that occupies a position within a view
layout. However, that does not mean that all UI elements are visible on the screen.
There are certain UI elements that are not visible on the screen, such as the
TransparentContainer, the ViewContainerUIElement, or the InvisibleElement. These
elements are used to structure the UI without being visible, but they occupy a position
in the UI element hierarchy just like any other visible UI element. In addition, all
UI elements can be set to invisible at runtime without freeing the space they would
occupy as visible UI elements. For example, hiding the Label UI element located to
the left of an InputField UI element does not automatically mean that the InputField
UI elements moves left and appears at the position where the Label UI element was
previously displayed!
Web Dynpro has been designed to operate with any form-based user interface. This
implies that any UI element is only an abstract description of the source code to be
rendered at runtime, and not just an HTML or WML representation of this element.
2009
© 2008 SAP AG. All rights reserved.
91
Unit 4: Defining the User Interface
NET310
Figure 38: UI element categories
There are numerous elements available for designing the user interface of a Web
Dynpro application. All available user interface elements are divided into categories,
which are displayed in the view designer, if the layout preview is visible.
The Text category contains elements that are used to display texts or to enter literals.
The Action category contains simple elements the user can click on to trigger
navigation or just a round trip.
The Selection category contains simple elements displaying multiple values.
Depending on the element type, the user may select one or multiple values.
The Complex category contains elements that need to have sub elements to define a
valid, renderable UI element.
UI elements defined in the Layout category are used to structure the layout. A special
sub set (container elements) consists of the UI elements TransparentContainer,
Group, ScrollContainer, and Tray. These elements define rectangular areas in which
sub elements are ordered according to rules defined by the container.
The Graphics category contains elements to render graphical members of the page.
92
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Defining the User Interface
Finally the Integration category contains elements to embed all kinds of non-ABAP
technologies in Web Dynpro.
Figure 39: Arrangement of UI elements
Show documentation available for each UI element (right-click any element defined
in the UI element hierarchy).
All view layouts are composed of a hierarchy of UI elements. The root node is always
of type TransparentContainer and is always called RootUIElementContainer. You
cannot change this. It is hard-coded. All subsequent UI elements added to a view
layout are hierarchically subordinate to RootUIElementContainer.
A second item displayed above the RootUIElementContainer has the name
Context_Menus. This so called context menu provider allows to define context
menus at design time. At run time, these context menus may be instantiated and
assigned to UI elements. Right mouse clicking on such a UI element will then display
the related context menu items together with the standard context menu.
2009
© 2008 SAP AG. All rights reserved.
93
Unit 4: Defining the User Interface
NET310
Container Elements and Layout Managers
Container elements are UI elements that may have arbitrary child elements. These
UI elements are:
•
•
•
•
Group
TransparentContainer
Tray
ScrollContainer (deprecated - use TransparentContainer instead)
They occupy a rectangular area in a view’s layout. All UI elements that are children of
a container element are located in this rectangular area. All container elements define
how their children will be arranged. This is done by evaluating the Layout property,
which assigns a layout manager to the container UI element. All child elements of
a container UI element inherit a set of properties that are related to layout manager
assigned to the container UI element. The Layout property may have four values:
•
•
•
•
FlowLayout
RowLayout
MatrixLayout
GridLayout (instead, use MatrixLayout whenever possible)
To demonstrate the differences between the layout managers, start demo
NET310_UI_D1. Resize your browser window.
94
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Defining the User Interface
Figure 40: Layout managers: FlowLayout
The default layout manager is the FlowLayout layout manager. All child attributes of
this container are displayed in a row, as long as the container is wide enough. If the
container UI element is too narrow for all child elements to be displayed in one row (if
the browser window is too narrow, for example), they are automatically wrapped to
the next line(s). This wrapping cannot be forced at design time. However, wrapping
can be switched off completely by setting the property wrapping to false. Elements
in different lines are not related to each other. This kind of container can be used to
arrange sub containers.
2009
© 2008 SAP AG. All rights reserved.
95
Unit 4: Defining the User Interface
NET310
Figure 41: Layout managers: RowLayout
If the RowLayout layout manager is used with the container UI element, all
children inherit the property LayoutData, which can have the values RowData and
RowHeadData. If you set this property to RowHeadData, a line break is forced. If
you set the property to RowData, the child element appears on the same line as the
previous element, even if the right-hand margin has been reached. UI elements located
in different rows are not related to each other and thus are not aligned in columns.
The width of each cell can be set with the width attribute of each child element.
96
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Defining the User Interface
Figure 42: Layout managers: MatrixLayout
If the MatrixLayout layout manager is used with the container UI element, all
children inherit the property LayoutData, which can have the values MatrixData and
MatrixHeadData. If you set this property to MatrixHeadData, a line break is forced.
If you set the property to MatrixData, the child elements appear on the same line as the
previous element, even if the right-hand margin has been reached. The child elements
in this container are arranged in columns. Using this layout manager, the number of
columns is not defined statically, but it is defined by the maximum number of child
elements in any row. The number of elements in different rows do not have to match.
UI elements arranged in a MatrixLayout can occupy multiple cells (colSpan property).
2009
© 2008 SAP AG. All rights reserved.
97
Unit 4: Defining the User Interface
NET310
Figure 43: Layout managers: GridLayout
Like the MatrixLayout, the GridLayout layout manager can be used if a vertical
alignment of the elements is desired. However, in this case the number of columns
is defined via the colCount property of the container element. Thus, the single child
element does not determine whether it is the first element of a new row. A line break
takes place when all cells of a row are occupied. If an element is removed from the
hierarchy, the entire arrangement changes as all subsequent elements in the hierarchy
move as many cells to the left as were occupied by the removed element.
This kind of layout manager should be used if all rows have the same number
of columns and if only complete rows are inserted or deleted. When using this
layout manager, UI elements should not be removed completely but replaced by an
InvisibleElement in order to retain the original element arrangement.
Your component: Change the layout manager of the ROOTUIELEMENTCONTAINER in one of the views. Rearrange the UI elements.
98
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Defining the User Interface
Adding UI Elements to the Layout
The View Editor is a Web Dynpro-specific tool that allows you to edit a view layout.
The View Editor is only available when you are editing a view controller. It does not
appear when you edit a custom controller because these controllers have no visual
interface.
Figure 44: Using the view editor
The view editor can be used with or without the layout preview. The following
description assumes that you are familiar with the layout preview.
2009
© 2008 SAP AG. All rights reserved.
99
Unit 4: Defining the User Interface
NET310
Figure 45: View editor
To add any UI element to the UI element hierarchy, you can drag it from the toolbar
on the left-hand side of the View Editor and drop it on the layout preview. Adding a
new UI element in the hierarchical representation is also possible. This can be done
from the context menu of any element in the hierarchy that can have child elements
(for example, a TransparentContainer element or a Group element).
To change the position of a UI element in the element hierarchy, you can move it
up or down using the related functionality from the element’s context menu. The
element can also be moved by dragging it and dropping it on the new position in the
hierarchical representation or in the layout preview.
Hint: If an element is dragged and dropped on another element that may
serve as its superordinate element, then the dropped element will end up
as a sub element.
100
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Defining the User Interface
The Properties tab displays all properties of a selected UI element. If a UI element
supports events, the supported client-side events are listed in the Events properties
section. Properties related to client-side events begin with the prefix on (for example,
onFilter, onSort, or onAction). To handle these client-side events, actions have to
be associated with each of the events.
Hint: Client-side events are events related to UI elements that are predefined
by the Web Dynpro framework. It is not possible to handle additional events
on the client side (for example, by using JavaScript).
Here you should ask the students if they know the MIME Repository. If this is
not the case, give a brief introduction. This should include the following:
Explain that the path visible in the MIME Repository (e.g.
sap/bc/webdynpro/sap/public/NET310/explosion.gif) is the URL path to
access the MIME object. Demonstrate this by using this path as part of the
URL in the browser.
Use existing MIME objects in Web Dynpro (e.g. drag and drop an image
from the MIME Repository to an Image UI element in the UI element
hierarchy).
Add a MIME object to your component using the context menu for your
component. After importing the MIME object, switch to the MIME
Repository and locate the object (sap/bc/webdynpro/sap/z....).
Exercise “Using Layout Managers to arrange UI Elements”
Data Binding
Once a UI element property is bound to a context node or attribute, the context data is
used to supply a value to the UI element property. If the UI element property is one
that the user can update (such as the value property of an InputField UI element), the
context is automatically updated with the new value during the next round trip.
2009
© 2008 SAP AG. All rights reserved.
101
Unit 4: Defining the User Interface
NET310
Almost all of the properties of a UI element can be bound either to a context node or
to a context attribute with the correct data type.
Note: A binding relationship can only exist between the context and UI
elements of the same view controller.
The Web Dynpro view controller has been constructed in such a way that it is usually
possible to have full control over the appearance of the screen layout without ever
needing direct access the UI element objects. Any property over which you wish to
have programmatic control should be bound to an appropriate context node or attribute.
Figure 46: Data binding
Defining Data Binding
The following steps are the minimum requirement for putting data on the screen:
1.
2.
3.
102
Create a node or attribute in the view controller’s context that will contain the
data.
Create the UI element in your view layout.
For all properties that require context binding, a button with a yellow icon and
an empty circle is displayed on the right hand-side of the property. Define
the required binding by clicking this button. A dialog box displays the view
controller’s context. All nodes or attributes which have the correct type for
binding to the UI element property are displayed. Select an appropriate node
or attribute.
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Defining the User Interface
The context path to the node or attribute is displayed as the property’s value. In
addition, the empty circle is replaced by a green check mark icon. The UI element on
the layout preview also displays the context path of the node or attribute to which it
is bound.
The establishment of a binding relationship instructs the Web Dynpro screen renderer
to obtain the value for a UI element property from the context node or attribute to
which it is bound.
Context binding is not limited to simply supplying an InputField, for example, with a
value. A UI element’s value property is just one of the many properties that can be
supplied with data through a binding relationship.
This is the mechanism by which a view controller can adjust the appearance and
behavior of its view layout without ever needing to access the UI element objects
themselves.
It is to early to explain how UI element properties can be changed from the controller
source code. However, binding the properties to context attributes can be shown.
You can use demo NET310_UI_D2 to show how changing the UI element properties
can be realized.
Your component: In this context, explain that depending on the property, the context
attribute has to have a certain type. Show how to type a context attribute accordingly
(property visible of a Label or / and an InputField). Add a context node containing
such attributes and bind the corresponding UI element properties.
2009
© 2008 SAP AG. All rights reserved.
103
Unit 4: Defining the User Interface
NET310
Figure 47: Putting data on the screen (1)
Data binding is a two-way relationship.
Once a binding relationship has been declared, the data in the bound nodes and
attributes are transported automatically to the corresponding UI elements. After the
user has interacted with the screen and initiated an HTTP round trip, the new or
modified data in the UI elements is transported back to the same nodes and attributes
in the view controller’s context. By the time the Web Dynpro framework hands over
control to your action handler, the context already holds the updated information.
This two-way transport process is entirely automatic and requires no action on the part
of the application developer. All you need to do is declare a binding relationship.
Hint: Data entered by the user is automatically converted to the internal
format. Then the Web Dynpro runtime checks if the data type matches the
type of the bound attribute (including domain fixed values). If a validation
error occurs, the data is not transported to the context attribute.
However, the Web Dynpro runtime stores the user input so it can be displayed
again (in conjunction with a validation error message displayed on the next
view assembly).
104
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Defining the User Interface
Controlling UI Element Behavior
Figure 48: Defining UI element properties statically
The value of a UI element property can either be hard coded or it can be bound
to a context attribute of a suitable data type. If a property value is hard coded at
design time, it can only be changed at runtime by accessing the UI element directly
from the view controller’s source code. This can only be done via the hook method
wddomodifyview( ) as only this method provides a reference to the UI element
hierarchy. However, accessing the UI element hierarchy directly from a controller’s
method is considered poor design because the separation between flow logic and UI is
no longer retained. This technique should be avoided.
2009
© 2008 SAP AG. All rights reserved.
105
Unit 4: Defining the User Interface
NET310
Figure 49: Controlling UI element properties (1)
In order to programmatically control the behavior of a UI element, you should create a
context attribute with a data type that matches the property you wish to control. This
allows you to control the behavior of the UI element by modifying the related attribute
value in any method of any controller that has access to this context attribute. Directly
accessing the UI element object from the controller source code is no longer necessary.
106
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Defining the User Interface
Figure 50: Controlling UI element properties (2)
Once the context attribute has been created, it must be bound to the appropriate UI
element property. In case displayed above, the readOnly property of an InputField UI
element has been bound to a Boolean context attribute.
The value of the context attribute can now be manipulated via any controller hook
method, or via your additionally defined methods.
This technique is applicable to most of the UI element properties. Appropriate data
types can be found using the Types of the Web Dynpro Runtime tab in the dialog box
displayed when typing a context attribute.
Properties that are typically bound to context attributes are the UI element’s key
property (e.g. the property value for the InputField), and the properties enabled,
readOnly, state, and visible.
Beginning with SAP NetWeaver 7.0 SAP_ABA support package stack 12, each
context attribute does allow to bind not only the UI element’s key property to it, but
also the properties enabled, visible, readOnly, and state.
To allow this kind of data binding, the dialog box popping up in the data binding
process contains an additional radio button group consisting of two radio buttons.
If the upper radio button is selected, a direct data binding as described above, is
2009
© 2008 SAP AG. All rights reserved.
107
Unit 4: Defining the User Interface
NET310
established. However, by selecting the lower radio button, the properties enabled,
visible, readOnly, and state can be bound to the corresponding context attribute
properties, respectively.
Two demos do exist in package NET310: NET310_UI_D2A and NET310_UI_D2B.
In demo NET310_UI_D2A, the methods GET_ATTRIBUTE_PROPS_FOR_ELEM( )
and SET_ATTRIBUTE_PROPS_FOR_ELEM( ) are used to get and set the properties
for all attributes of a given context element.
In demo NET310_UI_D2B, the methods GET_ATTRIBUTE_PROPERTIES( ) and
SET_ATTRIBUTE_PROPERTY( ) are used to get and set the properties for a specific
attribute of a given context element.
Figure 51: Context binding for SAP NW 7.0 (ABAP SPS ≥ 12)
108
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Defining the User Interface
Texts from the ABAP Dictionary
Many UI elements (TextViews, Labels, Captions, and so on) display texts in the
rendered UI. These texts can be obtained from the ABAP Dictionary in two ways:
•
•
The property related to the text is explicitly bound to a data element, a structure
field, or a field of a transparent table. This will be explained in the lesson
dealing with internationalization.
The UI element is related to a second UI element, and the primary property of
this second element is bound to a context element typed with a data element.
In this case, the property related to the text must be left blank in order to use
the dictionary text.
Example: A Label is related to an InputField and the Text property of the Label
is left blank. The label text originates from the data element related to property
value of the InputField.
This will be explained in lesson “Internationalization” in detail.
Composite UI Elements
Certain UI elements are displayed on the screen as aggregations of simpler, more
basic, UI elements. The Table UI element is a good example.
2009
© 2008 SAP AG. All rights reserved.
109
Unit 4: Defining the User Interface
NET310
Figure 52: Composite UI elements (1)
Without the subordinate (or child) UI elements, a composite UI element is not capable
of displaying any information. Composite UI elements such as Group and Tray have
a mandatory Caption child UI element, but beyond that, their structure is entirely
user-defined. Composite UI elements such as Table and Tree, however, require a
more complex mandatory child structure.
110
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Defining the User Interface
Figure 53: Composite UI elements (2)
The Table UI Element
The Table UI element acts as a parent of several TableColumn UI elements; each of
which acts as the parent for a header (implemented by a Caption UI element) and a
cell editor. cell editor is an abstract expression for all kinds of UI elements that can
serve as cell elements in a given column. The default for the cell editor is the TextView
UI element. However, depending on the cell value and whether or not a cell value
needs to be changeable, other UI elements can be used as cell editors (for example,
InputField, DropDownByKey, Checkbox, or Button).
Show Demo NET310_UI_D3 here. Focus on: UI element hierarchy in a view layout.
2009
© 2008 SAP AG. All rights reserved.
111
Unit 4: Defining the User Interface
NET310
Figure 54: The Table UI element
Binding a Table to the Context
The Table UI element allows two-dimensional display of data in cells arranged in rows
and columns. The UI element consists of an optional header area, zero or more rows
and a footer area. The Table UI element must be bound to a context node of cardinality
0..n or 1..n. The element at the lead selection in the context node becomes the
highlighted row when displayed on the screen (only if a selection column is displayed).
The Table UI element with its child elements can be created using the Web Dynpro
Code Wizard. In this case, defining the complete context binding is part of the
wizard process. However, if the Table UI element has been added to the element
hierarchy manually, the context menu entry Create Binding should be used to create
the complete binding.
Show Demo NET310_UI_D3 here. Focus on: Data binding of the TABLE UI element.
112
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Defining the User Interface
Figure 55: Binding a Table UI element to the context
TableColumn UI Elements
The Table UI element must contain at least one TableColumn UI element.
TableColumn UI elements are composite UI elements! This means that they must
have child UI elements in order to function correctly.
The column header is created using a Caption element. The text displayed in the
column header can be obtained from the ABAP Dictionary if the text property of the
Caption UI element is left blank and if the primary property of the context attribute
displayed in this column is typed with an ABAP Dictionary data element.
2009
© 2008 SAP AG. All rights reserved.
113
Unit 4: Defining the User Interface
NET310
Figure 56: TableColumn UI elements
Child UI Elements of a TableColumn
To present information to the user, a TableColumn UI element must have a child UI
element that will act as the cell editor. In order to decide which UI element to use, the
kind of interaction between the user and the data in each column has to be clarified.
Despite the word “editor” in the name of this role, the user cannot necessarily change
the data. If you select a display-only UI element such as TextView, the user will not
be able to modify the data; the UI element does not allow it. If you choose a Button,
then the cell value is displayed as the button’s text. In this case the user cannot input
data, but he can fire a client event. If, on the other hand, you chose an InputField to
be the table cell editor, then all the cells appearing in that column would, by default,
be open for input.
The caption that appears as the column header is optional, but if defined will always
be of type Caption.
Show demo NET310_UI_D3 here. Focus on: Data binding of cell editors.
114
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Defining the User Interface
Your component: Now show how to create a table. Gather data by creating a service
call in the component controller (this has to be explained anyway before the related
exercise can be solved - be sure you know which BAPI you want to call). Copy the
generated context node containing the mass data to the start view and map the nodes.
Use the WD Code Wizard to create the table display. Call the WDDOINIT service
method of the view. If necessary, provide data statically.
Figure 57: Defining child UI elements for a TableColumn
Selecting a Table Row and the Effect on the Node’s Lead Selection
Any time you click on the selection button of a table row on the rendered screen, a
round trip is initiated. This round trip will cause the lead selection of the context node
to which this table is bound to be adjusted.
In the figure below, the node collection contains two elements and the user has clicked
on the second table row. This corresponds to element 2 of node FLIGHTS, and the
lead selection of this node is altered to reflect the user’s selection.
There will be as many rows in the table as there are elements in the node collection.
2009
© 2008 SAP AG. All rights reserved.
115
Unit 4: Defining the User Interface
NET310
You can also define a Web Dynpro action and associate it with the table’s onLeadSelect
event. Then, not only is the node collection’s lead selection element adjusted when the
user clicks on a table, but the hook method wddobeforeaction( ), the corresponding
action handler method, and the hook method wddoafteraction( ) of the view containing
the TableView UI element are processed.
Show demo NET310_UI_D3 here. Focus on: Selecting a row is setting the lead
selection (displayed in the view in the input field).
Figure 58: Table row selection
Multiple Selection of Rows from a Table
Before a user is permitted to select multiple rows from a table (by holding down
SHIFT or CTRL and clicking on the required rows), the context node to which the
Table UI element is bound must have a selection cardinality of either 0..n or 1..n.
The default selection cardinality setting for any context node is 0..1, meaning that zero
or one element may be selected at any one time.
116
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Defining the User Interface
Show demo NET310_UI_D3 here. Focus on: Selecting multiple rows (this is allowed,
since the selection cardinality is set to 0..n for this demo). Press CTRL and mark
some lines. Fire the request using the button above the table. The lead selection
does not change!
Figure 59: Selecting multiple rows from a table
The Table UI Element Property SelectionMode
The topics discussed in the two sections above are only true for the default value of
the Table property selectionMode (auto). However, this property can have six values,
which influence your ability to mark rows and set the lead selection as follows:
Show demo NET310_UI_D3 here. Focus on: Choose different settings for Selection
Mode and verify the influence on marking rows and setting lead selection as described
below.
2009
© 2008 SAP AG. All rights reserved.
117
Unit 4: Defining the User Interface
NET310
Other interesting demos:
NET310_UI_D4 shows how selecting a row leads to an HTTP round trip. However,
there is no client-side event handling involved, so the related hook methods in the
view controller are not processed (table at bottom). If the client event “Selecting a
row” (property OnLeadSelect) is bound to an action, the related hook methods and
the action handler method are processed (table at top).
The Property selectionMode
value
minimum
selected rows
maximum
selected rows
selecting
table row
triggers
round
trip
selecting
table row
sets lead
selection
auto
selection
cardinality
selection
cardinality
X
X
single
selection
cardinality
1
X
X
multi
selection
cardinality
selection
cardinality
X
X
none
0
0
-
-
singleNoLead selection
cardinality
1
X
-
multiNoLead
selection
cardinality
X
-
selection
cardinality
Exercise “Displaying Tables”
Test Page for UI Elements
Web Dynpro application WDR_TEST_UI_ELEMENTS is delivered in every system
based on SAP NetWeaver 7.0. You can use it to check each UI element’s functionality.
118
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Defining the User Interface
Figure 60: Test page for UI elements
2009
© 2008 SAP AG. All rights reserved.
119
Unit 4: Defining the User Interface
120
© 2008 SAP AG. All rights reserved.
NET310
2009
NET310
109
Lesson: Defining the User Interface
Exercise 5: Using Layout Managers to
arrange UI elements
Exercise Duration: 20 Minutes
Exercise Objectives
After completing this exercise, you will be able to:
•
Arrange UI elements
•
Display graphic files stored in the MIME Repository
Business Example
You want to develop a Web Dynpro application with an image displayed by the first
view. In addition, the UI elements should be arranged in a predefined way.
Template: NET310_COND_S
Solution: NET310_UI_S1
Task 1:
Copy your solution from the previous exercise or the template component.
1.
Copy your solution from the previous exercise (ZNET310_COND_##) or
the Web Dynpro component NET310_COND_S to the new component,
ZNET310_UI1_##.
Task 2:
Add an IMAGE UI element to the layout of view INPUT_VIEW. The IMAGE UI
element should display the file reisen_1.jpg located in the MIME Repository folder
SAP
BC
WebDynpro
SAP
PUBLIC
NET310.
→ →
1.
→
→
→
In the layout of view INPUT_VIEW, create a UI element of type IMAGE (name:
IMG_PLANE). Maintain the source of the IMAGE UI element. The source
should be file reisen_1.jpg, located in the MIME Repository folder SAP
BC
WebDynpro
SAP
PUBLIC
NET310.
→
→
→
→
→
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
121
Unit 4: Defining the User Interface
NET310
Task 3:
Arrange the UI elements of view INPUT_VIEW. The transparent containing
embedding the input fields and the image should be displayed in one row. Both
elements together should occupy the complete page width. Transparent container and
image should occupy the same height. The labels, the input fields and the button
should be located in the left upper corner of the transparent container (not stretched
across container).
In order to visualize the space occupied by the transparent container, the background
color should be altered.
1.
Assign the layout manager Matrix Layout to the ROOTUIELEMENTCONTAINER.
2.
Change the properties of the transparent container (embedding the form
elements) and of the image so that they are arranged in one row.
3.
Change the background color of the form. The area occupied by the surrounding
transparent container should be displayed in light blue.
4.
Change the properties of the UI elements so that transparent container and image
occupy 100% of the page width. The width of the image should not differ from
its original width.
5.
Change the properties of the UI elements so that transparent container and
image occupy the same height. The height of the image should not differ from
its original height.
6.
Make sure that the form elements are not stretched across the surrounding
transparent container, neither vertically, nor horizontally.
Task 4:
Arrange the UI elements of view OUTPUT_VIEW. The transparent container
containing the form fields should occupy 100% of the page width. The area occupied
by this container should be displayed in light blue.
1.
Change the background color of the form. The area occupied by the surrounding
transparent container should be displayed in light blue.
2.
Arrange the UI elements of the view using the Matrix Layout manager.
3.
Change the properties of the UI elements so that the transparent container
embedding the form occupies 100% of the page width.
Continued on next page
122
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Defining the User Interface
Task 5:
Activate and test your Web Dynpro component.
1.
2009
Activate your component. Create a Web Dynpro application with the same name
as your component. Start the Web Dynpro application.
© 2008 SAP AG. All rights reserved.
123
Unit 4: Defining the User Interface
NET310
Solution 5: Using Layout Managers to
arrange UI elements
Task 1:
Copy your solution from the previous exercise or the template component.
1.
Copy your solution from the previous exercise (ZNET310_COND_##) or
the Web Dynpro component NET310_COND_S to the new component,
ZNET310_UI1_##.
a)
One possible solution: In the object navigator, choose Other object and
select the Web Objects tab page.
b)
Enter the name of the Web Dynpro component to copy and choose Copy.
c)
Enter a name for the new Web Dynpro component.
Task 2:
Add an IMAGE UI element to the layout of view INPUT_VIEW. The IMAGE UI
element should display the file reisen_1.jpg located in the MIME Repository folder
SAP
BC
WebDynpro
SAP
PUBLIC
NET310.
→ →
1.
→
→
→
In the layout of view INPUT_VIEW, create a UI element of type IMAGE (name:
IMG_PLANE). Maintain the source of the IMAGE UI element. The source
should be file reisen_1.jpg, located in the MIME Repository folder SAP
BC
WebDynpro
SAP
PUBLIC
NET310.
→
→
→
→
→
a)
In the context menu of the ROOTUIELEMENTCONTAINER, choose the
item Insert Element.
b)
Choose element type IMAGE and enter the name in the appropriate field.
c)
Open the MIME Repository (choose the MIME Repository button at the top
of the navigation area of the ABAP Workbench).
d)
Open the specified folder. Drag reisen_1.jpg and drop it on the IMAGE UI
element in the UI element hierarchy.
Continued on next page
124
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Defining the User Interface
Task 3:
Arrange the UI elements of view INPUT_VIEW. The transparent containing
embedding the input fields and the image should be displayed in one row. Both
elements together should occupy the complete page width. Transparent container and
image should occupy the same height. The labels, the input fields and the button
should be located in the left upper corner of the transparent container (not stretched
across container).
In order to visualize the space occupied by the transparent container, the background
color should be altered.
1.
Assign the layout manager Matrix Layout to the ROOTUIELEMENTCONTAINER.
a)
2.
3.
Change the properties of the transparent container (embedding the form
elements) and of the image so that they are arranged in one row.
a)
For the transparent container, choose LayoutData = MatrixHeadData; for
the image choose LayoutData = MatrixData.
b)
For both UI elements set vAlign = top.
Change the background color of the form. The area occupied by the surrounding
transparent container should be displayed in light blue.
a)
4.
Set the property Layout to MatrixLayout.
Edit the properties of the transparent container embedding the form fields.
Set cellBackgroundDesign = fill1.
Change the properties of the UI elements so that transparent container and image
occupy 100% of the page width. The width of the image should not differ from
its original width.
a)
For the ROOTUIELEMENTCONTAINER, choose width = 100%. In
addition check the check box related to the property stretchHorizontally.
b)
For the cell surrounding the image, set width (LayoutData (MatrixData))
= 1px. This will force the cell width fitting exactly the width of the
embedded image.
c)
For the transparent container embedding the form fields, set width = 100%.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
125
Unit 4: Defining the User Interface
5.
6.
NET310
Change the properties of the UI elements so that transparent container and
image occupy the same height. The height of the image should not differ from
its original height.
a)
For the cell surrounding the image, set height (LayoutData (MatrixData))
= 1px. This will force the cell height fitting exactly the height of the
embedded image.
b)
For the transparent container embedding the form fields, set height = 100%.
Make sure that the form elements are not stretched across the surrounding
transparent container, neither vertically, nor horizontally.
a)
For the transparent container embedding the form, make sure that the check
boxes related to the properties stretchVertically and stretchHorizontally
are not checked.
Task 4:
Arrange the UI elements of view OUTPUT_VIEW. The transparent container
containing the form fields should occupy 100% of the page width. The area occupied
by this container should be displayed in light blue.
1.
Change the background color of the form. The area occupied by the surrounding
transparent container should be displayed in light blue.
a)
2.
3.
Edit the properties of the transparent container embedding the form fields.
Set cellBackgroundDesign = fill1.
Arrange the UI elements of the view using the Matrix Layout manager.
a)
For the ROOTUIELEMENTCONTAINER, set the property Layout to
MatrixLayout.
b)
For the transparent container embedding the form fields, choose
LayoutData = MatrixHeadData.
Change the properties of the UI elements so that the transparent container
embedding the form occupies 100% of the page width.
a)
For the ROOTUIELEMENTCONTAINER, choose width = 100%. In
addition, check the check box related to property stretchHorizontally.
b)
For the transparent container embedding the form fields, set width to 100%.
In addition set the cell width width (LayoutData (MatrixHeadData)) to
100%.
Continued on next page
126
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Defining the User Interface
Task 5:
Activate and test your Web Dynpro component.
1.
Activate your component. Create a Web Dynpro application with the same name
as your component. Start the Web Dynpro application.
a)
2009
Perform this step as in previous exercises.
© 2008 SAP AG. All rights reserved.
127
Unit 4: Defining the User Interface
128
© 2008 SAP AG. All rights reserved.
NET310
2009
NET310
117
Lesson: Defining the User Interface
Exercise 6: Displaying Tables
Exercise Duration: 35 Minutes
Exercise Objectives
After completing this exercise, you will be able to:
•
Use a wizard that creates a method encapsulating a function module call and the
related context nodes and context attributes
•
Create a UI element of type TABLE to display mass data
Business Example
Template: n/a
Solution: NET310_UI_S2
Task 1:
Create a Web Dynpro component with one view embedded in a window.
1.
Create the Web Dynpro component ZNET310_UI2_## containing one
view (name: DISPLAY_VIEW) which is embedded in a window (name:
MAIN_WINDOW).
Task 2:
Create a service call of function module BAPI_FLIGHT_GETLIST in the component
controller. This will create a method encapsulating the BAPI call. In addition, the
BAPI’s interface parameters are related to component controller context nodes and
attributes.
1.
Create a service call for the function module BAPI_FLIGHT_GETLIST:
The service method and the related context nodes and attributes are to be defined
in the component controller.
In the Adapt Context dialog, choose Object Type = Context for the parameters
DESTINATION_FROM, DESTINATION_TO, and FLIGHT_LIST.
When being asked for the name of the service method, accept the default name
(EXECUTE_BAPI_FLIGHT_GETLIST).
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
129
Unit 4: Defining the User Interface
NET310
2.
What entities of the component have been created?
3.
What are the cardinalities of nodes DESTINATION_FROM and FLIGHT_LIST?
Why are they different?
Task 3:
Copy the node BAPI_FLIGHT_GETLIST defined in the component controller context
to the context of the view and define the context mapping.
1.
Copy the node BAPI_FLIGHT_GETLIST defined in the component controller
context to the context of the view and define the context mapping.
Task 4:
In the view’s layout, create a form containing input fields to enter departure city and
departure country. This form should occupy 50% of the page width. The remaining
page width should be occupied by a form containing input fields to enter destination
city and destination country.
1.
Edit the view’s layout. Mark the ROOTUIELEMENTCONTAINER. Use the
Web Dynpro Code Wizard to create a form containing input fields to enter
departure city and departure country.
2.
Repeat the last step to create a form containing input fields to enter destination
city and destination country.
3.
Adjust the properties of the UI elements.
Continued on next page
130
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Defining the User Interface
Task 5:
Below these two forms, a table displaying the related flights should be defined. The
table has to occupy the complete page width and it has to display 10 lines. Suppress
the selection column.
1.
Use the Web Dynpro Code Wizard to create a table displaying the flights stored
in node FLIGHT_LIST. The table should display all information but the carrier
ID and the ISO code of the currency.
2.
Adjust the properties of the UI element.
Task 6:
Define a button to call the service method defined in the component controller. Locate
the button in a new line between the forms and the table.
1.
Define the button.
2.
Move the button so it is displayed in a new line between the forms and the table.
3.
Adjust the properties of the button. Make the button the first element in a new
row and define a text to be displayed. Assign an action to the button (name:
DISPLAY_DETAILS).
4.
Implement the source code of the action handler method: Call the service
method.
Task 7:
Activate your component. Create an application to access your component. Test
your application
1.
2009
Activate your component. Create an application to access your component.
Test your application
© 2008 SAP AG. All rights reserved.
131
Unit 4: Defining the User Interface
NET310
Solution 6: Displaying Tables
Task 1:
Create a Web Dynpro component with one view embedded in a window.
1.
Create the Web Dynpro component ZNET310_UI2_## containing one
view (name: DISPLAY_VIEW) which is embedded in a window (name:
MAIN_WINDOW).
a)
Perform this step as in previous exercises.
Task 2:
Create a service call of function module BAPI_FLIGHT_GETLIST in the component
controller. This will create a method encapsulating the BAPI call. In addition, the
BAPI’s interface parameters are related to component controller context nodes and
attributes.
1.
Create a service call for the function module BAPI_FLIGHT_GETLIST:
The service method and the related context nodes and attributes are to be defined
in the component controller.
In the Adapt Context dialog, choose Object Type = Context for the parameters
DESTINATION_FROM, DESTINATION_TO, and FLIGHT_LIST.
Continued on next page
132
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Defining the User Interface
When being asked for the name of the service method, accept the default name
(EXECUTE_BAPI_FLIGHT_GETLIST).
a)
Open the context menu for the Web Dynpro component in the navigation
area of the ABAP Workbench (left-hand side). Select the menu item Create
Service Call.
→
2.
b)
Choose Continue to confirm the first window of the wizard.
c)
Select Use Existing Controller, select the component controller of your
component and choose Continue.
d)
Select Function Module and choose Continue.
e)
On the next screen, enter the name of the function module in the Function
Module field and choose Continue.
f)
For the parameters to be stored in the controller’s context
(DESTINATION_FROM, DESTINATION_TO, and FLIGHT_LIST)
select Object Type = Context. Choose Continue.
g)
Accept the name of the service method and the description as defined
by the wizard. Choose Continue.
What entities of the component have been created?
Answer:
•
•
•
3.
Context node BAPI_FLIGHT_GETLIST with several sub-nodes for the
selected IMPORTING and TABLES parameters of the function module
Method EXECUTE_BAPI_FLIGHT_GETLIST( ) in the component
controller, which encapsulates the call of the function module
Controller attributes for the function module parameters AIRLINE and
MAX_ROWS
What are the cardinalities of nodes DESTINATION_FROM and FLIGHT_LIST?
Why are they different?
Answer:
•
DESTINATION_FROM: 1..1
•
FLIGHTLIST: 0..n
The parameter DESTINATION_FROM is a structure. The parameter
FLIGHT_LIST is an internal table.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
133
Unit 4: Defining the User Interface
NET310
Task 3:
Copy the node BAPI_FLIGHT_GETLIST defined in the component controller context
to the context of the view and define the context mapping.
1.
Copy the node BAPI_FLIGHT_GETLIST defined in the component controller
context to the context of the view and define the context mapping.
a)
Perform this step as in previous exercises.
Task 4:
In the view’s layout, create a form containing input fields to enter departure city and
departure country. This form should occupy 50% of the page width. The remaining
page width should be occupied by a form containing input fields to enter destination
city and destination country.
1.
2.
Edit the view’s layout. Mark the ROOTUIELEMENTCONTAINER. Use the
Web Dynpro Code Wizard to create a form containing input fields to enter
departure city and departure country.
a)
Perform this step as in previous exercises. The node
DESTINATION_FROM contains the departure information.
b)
Toggle the check box in column Binding for the attributes AIRPORTID
and COUNTR_ISO.
Repeat the last step to create a form containing input fields to enter destination
city and destination country.
a)
Perform this step as in previous exercises. The node DESTINATION_TO
contains the destination information.
Continued on next page
134
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Defining the User Interface
3.
Adjust the properties of the UI elements.
a)
For the ROOTUIELEMENTCONTAINER, set Layout = MatrixLayout,
width = 100% and check the check box related to property
stretchHorizontally.
b)
For the transparent container displaying the departure information, set
LayoutData = MatrixHeadData, width = 100%, and width (LayoutData
(MatrixHeadData)) = 50%.
c)
For the transparent container displaying the destination information, set
width = 100%, and width (LayoutData (MatrixData)) = 50%.
d)
For the TEXTVIEW UI element used as a caption for the departure
information, set LayoutData = MatrixHeadData. In addition set text =
“Departure information”.
e)
For the TEXTVIEW UI element used as a caption for the destination
information, set LayoutData = MatrixHeadData. In addition, set text =
“Destination information”.
Task 5:
Below these two forms, a table displaying the related flights should be defined. The
table has to occupy the complete page width and it has to display 10 lines. Suppress
the selection column.
1.
Use the Web Dynpro Code Wizard to create a table displaying the flights stored
in node FLIGHT_LIST. The table should display all information but the carrier
ID and the ISO code of the currency.
a)
Mark the ROOTUIELEMENTCONTAINER and start the Web Dynpro
Code Wizard.
b)
Double-click on the entry Table.
c)
Click on the Context button.
d)
Double-click on node FLIGHT_LIST.
e)
Toggle the check box in column Binding for the attributes AIRLINEID
and CURR_ISO.
f)
Finish the dialog by pressing Enter.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
135
Unit 4: Defining the User Interface
2.
NET310
Adjust the properties of the UI element.
a)
For the table, set LayoutData = MatrixHeadData, width = 100%, and
colSpan = 2.
b)
To hide the mark column, set selectionMode = none.
c)
To display 10 lines, set visibleRowCount = 10.
Task 6:
Define a button to call the service method defined in the component controller. Locate
the button in a new line between the forms and the table.
1.
2.
Define the button.
a)
Edit the view’s layout. From the context menu of the
ROOTUIELEMENTCONTAINER, choose the item Insert Element.
b)
Select Type = Button and enter the button’s name.
c)
Finish the dialog.
Move the button so it is displayed in a new line between the forms and the table.
a)
3.
In the UI element hierarchy, drag the button and drop it on the table. This
will interchange the positions of theses two elements.
Adjust the properties of the button. Make the button the first element in a new
row and define a text to be displayed. Assign an action to the button (name:
DISPLAY_DETAILS).
a)
Set LayoutData = MatrixHeadData.
b)
Set text = “Display flights”.
c)
Use the button right of the property onAction in order to create the action
DISPLAY_DETAILS and assign it to the button’s click event.
Continued on next page
136
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Defining the User Interface
4.
Implement the source code of the action handler method: Call the service
method.
a)
Open the Actions tab. Double-click on the method’s name displayed in
column Event Handler. This will display the method’s source code.
b)
Edit the method’s source code. Start the Web Dynpro Code Wizard. Open
the General tab and select Method Call In Used Controller.
c)
Select the component controller and the method to be called
(EXECUTE_BAPI_FLIGHT_GETLIST( ) ) from the input help.
d)
Finish the dialog and save your changes.
Task 7:
Activate your component. Create an application to access your component. Test
your application
1.
Activate your component. Create an application to access your component.
Test your application
a)
2009
Perform this step as in previous exercises.
© 2008 SAP AG. All rights reserved.
137
Unit 4: Defining the User Interface
NET310
Lesson Summary
You should now be able to:
•
Define the view layout by arranging UI elements and setting their properties.
•
Bind UI element properties to context attributes.
•
Use the table UI element as an example of using composite UI elements.
138
© 2008 SAP AG. All rights reserved.
2009
NET310
Unit Summary
Unit Summary
You
•
•
•
2009
should now be able to:
Define the view layout by arranging UI elements and setting their properties.
Bind UI element properties to context attributes.
Use the table UI element as an example of using composite UI elements.
© 2008 SAP AG. All rights reserved.
139
Unit Summary
140
NET310
© 2008 SAP AG. All rights reserved.
2009
Unit 5
Controller and Context Programming
129
This is the first unit dealing with the source code of controller methods. For the typical
ABAP programmer, this is unusual; ABAP programmers are not used to working with
frameworks and having to adhere to the framework’s methods. In particular, accessing
data stored in the controller context is new, since in the classical ABAP programming
context all data objects are defined using the data statement.
The data stored in the controller context cannot be accessed if the API methods for
context accesses are not known to the developer. Thus, point out the advantages
of such an approach: Code wizards can be used to define the coding; data binding
between UI properties and context fields requires a standard way of storing data;
data sharing (context mapping) between controllers requires standard data storage
and so on.
Unit Overview
One of the strengths of Web Dynpro is the declarative meta data approach. This
approach allows you to define the complete static UI and navigation between the
different view assemblies without having to program code. However, defining
the programming logic and the back-end access requires ABAP source code
programming. The source code is defined in the methods of the component controller,
custom controllers, view controllers, or window controllers.
The first part of this unit discusses the different hook methods and the order of
processing these methods (phase model). The second part focusses on how to access
the controller’s context.
Unit Objectives
After completing this unit, you will be able to:
•
•
2009
List the hook methods that exist for the different controller types.
Explain in which order these hook methods are processed.
© 2008 SAP AG. All rights reserved.
141
Unit 5: Controller and Context Programming
•
•
•
•
NET310
Create and call your own controller methods.
Use the standard controller attributes to access the controller functionality, in
particular the controller context.
Define your own controller attributes and use them in the controller methods.
Access the controller context and read, delete, change or add node elements.
Unit Contents
Lesson: Controller and Context Programming .................................. 143
Exercise 7: Accessing the Context at Runtime ............................. 175
Exercise 8: Displaying mass data using tables............................. 181
Exercise 9: Using Supply Functions ......................................... 187
142
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson:
130
Lesson: Controller and Context Programming
Controller and Context Programming
Lesson Duration: 130 Minutes
Lesson Overview
Defining the source code of controllers requires understanding the proper use of
predefined methods (hook methods), when and in which order they are processed
(phase model), how additional user-defined methods can be created and how these
methods can be accessed from the same or from another controller. You should also be
familiar with how to define events, raise events and register the corresponding event
handler for such events. Finally, to implement controllers, you require access to the
controller context (reading, changing and deleting data stored in the controller). In
this lesson, all of these aspects will be discussed in detail.
Lesson Objectives
After completing this lesson, you will be able to:
•
•
•
•
•
•
List the hook methods that exist for the different controller types.
Explain in which order these hook methods are processed.
Create and call your own controller methods.
Use the standard controller attributes to access the controller functionality, in
particular the controller context.
Define your own controller attributes and use them in the controller methods.
Access the controller context and read, delete, change or add node elements.
References to demos can be found in this lesson.
Business Example
You have created a Web Dynpro component. To this point, you have worked
exclusively on entities that can be defined in a declarative manner. However, the flow
logic (including access to the back-end logic) needs to be implemented by defining
ABAP source code in controller methods. You want to know how to work with
controller methods and controller attributes.
2009
© 2008 SAP AG. All rights reserved.
143
Unit 5: Controller and Context Programming
NET310
Controller Methods
Every Web Dynpro controller is a separate local ABAP class defined in the global
ABAP class related to the Web Dynpro component. The definition of these classes is
generated automatically when a new component or controller is declared. The source
code that implements these controllers is generated automatically. Each controller
provides a number of predefined methods, which are called by the Web Dynpro
runtime in a predefined order. These methods are called hook methods. At the time
of controller creation, these methods are empty and can hold any coding the developer
wishes to place in them. In addition to these hook methods, the developer can define
additional methods: ordinary methods, event handler methods or supply functions.
Figure 61: Controller methods
The controller class is generated from all controller methods - hook methods and
user-defined methods - every time the controller is activated. The ABAP Workbench
allows you to enter source code in the controller methods only; the generated
controller class is not accessible.
144
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Controller and Context Programming
Hook Methods
There are two hook methods that exist for all controller types:
•
wddoinit( ):
wddoinit( ) is the first method processed in the controller’s lifetime. It is only
called once in the controller’s lifecycle. All your initialization code should
go here since this method is called immediately after the controller has been
instantiated.
•
wddoexit( ):
wddoexit( ) is the last method processed at the end of a controller’s lifecycle.
All your cleanup code should go here.
Figure 62: Standard hook methods for all controllers
2009
© 2008 SAP AG. All rights reserved.
145
Unit 5: Controller and Context Programming
NET310
Depending on the controller type, additional hook methods are available. For the
component controller, there are three additional standard methods:
•
wddobeforenavigation( )
Whenever a client event is raised, the corresponding action method in the view
controller is processed. The method wddobeforenavigation( ) is called after the
action method has been processed and just before the Web Dynpro framework
processes the events in the navigation queue.
In complex Web Dynpro applications, it may be necessary to validate the data
from multiple components before the next step in the business process can be
taken. This method has been implemented so that cross-component validation
can take place.
•
wddopostprocessing( )
It is the last controller method that is processed before the UI is sent to the client.
•
wddoapplicationstatechange( )
This method is processed each time the application is suspended or resumed.
Suspending a Web Dynpro application happens if a suspend plug of the window
is fired. This can be used to start a new application without exiting the current
Web Dynpro application. Resuming the temporarily disabled Web Dynpro
application takes place automatically if the second application is ended. The
suspended Web Dynpro application is then resumed by entering the window via
a resume plug. If at least one suspend plug is created for a window, one resume
plug must also be created too.
146
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Controller and Context Programming
Figure 63: Standard hook methods: component controller
2009
© 2008 SAP AG. All rights reserved.
147
Unit 5: Controller and Context Programming
NET310
For view controllers, there are four additional hook methods:
•
wddobeforeaction( )
After the user has raised a client event bound to an action, the first methods
processed in the Web Dynpro application are the wddobeforeaction( ) methods
of all view controllers of the previous rendered view assembly. This happens
even before the action handler method related to the client event is processed.
This method typically contains the source code related to input checks.
•
wddoafteraction( )
After an action handler method has been processed, the wddoafteraction( )
methods of all view controllers of the previous rendered view assembly are
processed.
This method can be used to modularize the source code related to action handling.
•
wddomodifyview( )
The only method that allows to access the UI element hierarchy is the view’s
wddomodifyview( ) method. The interface parameter VIEW is a reference to the
UI element hierarchy; the FIRST_TIME parameter can be used to find out if this
method has been previously processed in the view controller’s lifecycle. This
method can be used to manipulate the UI element hierarchy dynamically.
•
wddomodifyview( )
This method is processed each time the user right-mouse clicks on any UI
element defined in the related view layout.
From the source code of this method, statically defined context menus can be
instantiated and new context menus can be defined. These context menus can be
assigned to any UI element defined in the view hierarchy. This allows to extend
the standard right-mouse menu by application defined functionality.
148
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Controller and Context Programming
Figure 64: Standard hook methods: view controller
For window controllers, there are two special hook methods:
•
•
wddoonopen( ) is processed if the window is send as a popup, just before the
popup is opened.
wddoonclose( ) is processed if the window is send as a popup, just before the
popup is closed.
In these two methods code can be stored that should only be processed if the window
is displayed as a popup (e.g. defining buttons displayed in the frame of the popup).
Here you can visualize the phase model for controller processing. Now show the
following demos:
NET310_EVEN_D1: Order of hook methods for one view in one window.
NET310_EVEN_D2: Order of hook methods for two views in one window.
NET310_EVEN_D2A: Order of hook methods for two views in one window. The
view’s lifetime is restricted.
2009
© 2008 SAP AG. All rights reserved.
149
Unit 5: Controller and Context Programming
NET310
NET310_EVEN_D3: Order of hook methods for three views in one window. One
view contains two view containers. The other views are embedded in these view
containers, so they are displayed in parallel.
Additional Controller Methods
For all controllers, you can create additional methods by declaring the method name
and its parameters on the Methods tab of the controller editor window. To define an
ordinary method, choose Method Type = Method. If you choose Method Type =
Event Handler, an event handler method is created. It can be registered statically
(in the Event column) to any event fired in a controller which is defined as a Used
Controller on the Properties tab. Finally, Method Type = Supply Function can be set
to define methods that can be bound to context nodes (Supply Function property).
These methods are automatically called from the Web Dynpro framework if the node
is accessed and it is marked as invalid.
Hint: Supply functions can not be called from the source code of the controller
methods. Only the Web Dynpro runtime may call this type of method.
After double-clicking the method name, the signature and source code of the method
can be defined.
All methods are public and can be used by any other controller of the same component.
As a prerequisite, the controller that calls the method has to define a usage relation to
the controller that owns the methods. The ABAP source code to call a method in the
used controller can be generated using the Web Dynpro Code Wizard.
If the Interface flag is set for a user-defined method, this method will appear in the
component interface. So the method is also visible to other components.
150
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Controller and Context Programming
Figure 65: Additional controller methods
Your component: Create a new ordinary method in the custom controller. Define
this controller as a used controller for one of your view controllers. Call the custom
controller method from this view controller. Look at the source code.
Controller Attributes
Each controller is a separate ABAP class, having not only predefined and user-defined
methods, but also attributes, which are visible for each method of the controller.
2009
© 2008 SAP AG. All rights reserved.
151
Unit 5: Controller and Context Programming
NET310
Standard Attributes
After defining a controller, at least two attributes are predefined. The visibility of
attributes is restricted to the controller methods. The standard attributes are:
•
WD_THIS
WD_THIS is a self-reference to the local controller interface. This attribute must
be distinguished from the standard ABAP self-reference ME, which should not
be used in the source code of any controller. WD_THIS is a reference to the
current controller’s interface, IF_<controller name>, and represents all the
functionality implemented in the generated class. It also gives you access to
standard Web Dynpro functionality, such as validation.
•
WD_CONTEXT
WD_CONTEXT is a reference to the controller’s context root node, and thus
to the entire context. Any access to the controller’s context starts with this
reference.
Figure 66: Standard controller attributes
152
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Controller and Context Programming
If the component controller is declared as a used controller on the Properties tab of
any other controller, an additional attribute is automatically created for the controller
that declared the usage:
•
WD_COMP_CONTROLLER
WD_COMP_CONTROLLER is a reference to the component controller. Using
this reference, all methods and all public attributes of the component controller
can be accessed (wd_comp_controller-><meth>, where <meth> is a
placeholder for the methods name).
Create an ordinary method in the component controller and call this method from the
view controller. Look at the source code. The attribute WD_COMP_CONTROLLER
is not used any more by the wizard. However, you can now delete the local variable
and the line for determining the component controller reference and use the attribute
WD_COMP_CONTROLLER instead.
For all other controllers, even if declared as used controllers, such a reference is
not available. However, this does not mean that user-defined methods and public
attributes are not available, but that the reference must be evaluated first. To have the
reference to the <ctrl> controller defined as a used controller, the following statement
must be used:
DATA: lo_ctrl TYPE REF TO ig_<ctrl> .
lo_ctrl = wd_this->get_<ctrl>_ctr( ).
User-Defined Attributes
On the Attributes tab, additional attributes can be defined for the related controller. If
the Public flag is set, these attributes are also visible for other controllers of the same
Web Dynpro component. Attributes cannot be exposed to the component’s interface.
In order to access public controller attributes in one of the controller’s methods, the
reference variable WD_THIS has to be used. Accessing public attributes defined
in other controllers of the same component is implemented similarly to the access
to methods defined in other controllers.
2009
© 2008 SAP AG. All rights reserved.
153
Unit 5: Controller and Context Programming
NET310
Figure 67: User-defined controller attributes and controller methods
Your component: In the component controller, create two attributes (one
public, one private). Access these attributes from any method of the component
controller. Try to access these attributes from any method of the view controller
(WD_COMP_CONTROLLER-><attribute>). Result: Only the public attribute can
be used from another controller.
Accessing the Context Nodes and Node Elements at
Runtime
In the last section, we saw that we can use controller attributes to provide data objects
that are visible throughout the controller. However, it is not possible to bind UI
element properties to these controller attributes. UI element properties can only be
bound to variables defined in the controller context. This hierarchical data storage is
also preferable if information has to be shared between controllers.
Accessing the controller context at runtime requires knowledge of the appropriate
Web Dynpro methods. This section deals with how to read, change, add or delete
information stored in the controller context.
154
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Controller and Context Programming
Accessing a Context Node
To access a context element or a context attribute, first you need a reference to the
related context node.
Figure 68: Accessing a context node
The following information is important:
•
•
For each controller (<ctrl>), a local interface is generated with the name
IF_<ctrl>.
For each node <node> of a controller context, a constant (WDCTX_<node>) is
generated in this interface; it has the name of the node (in uppercase letters) as
its value. This constant can be used to access the context node.
The context root node can be accessed by the standard attribute WD_CONTEXT.
Child nodes of the context root node can be identified using the get_child_node(
) method. This method returns a reference to the node instance of type
IF_WD_CONTEXT_NODE.
2009
© 2008 SAP AG. All rights reserved.
155
Unit 5: Controller and Context Programming
NET310
The get_child_node( ) method requires the name of the node and, optionally, the index
of the element in the parent node to which the desired node instance belongs. If the
index is not provided, the lead selection index is used implicitly.
Hint: For independent nodes, the index can always be omitted since the
context root node only ever has one element being the element at lead
selection.
Hint: A special ways to access the reference to a dependent node is
given by the method path_get_node( path = ’<path>’ ). As a parameter,
the complete path to the desired node is passed to the method. The
path is constructed from the node names and the element indices (e.g.
<node>.<el_index>.<sub_node>.). If the element index <el_index> is
omitted (here: <node>.<sub_node>), the sub node instance <sub_node>
is determined for the element at lead selection of the superordinate node
<node>.
Accessing a Node Element
After accessing a context node, the reference to the element at lead selection of this
node can be obtained by calling the method get_element( ). This method returns a
reference to the element instance of type IF_WD_CONTEXT_ELEMENT.
156
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Controller and Context Programming
Figure 69: Accessing the node element at lead selection
The element with index n can be accessed using the method get_element( index
= n ). The number of elements in a collection can be obtained from the method
get_element_count( ).
2009
© 2008 SAP AG. All rights reserved.
157
Unit 5: Controller and Context Programming
NET310
Summary
Summary: Accessing Context Nodes and Node Elements
Action
Method
Reference to
context node
<node>
lo_nd_<node> =
wd_context->get_child_node(
name = wd_this->wdctx_<node> ).
Reference to
element at lead
selection
lo_el_<node> =
lo_nd_<node>->get_element( ).
Reference to
element with
index n
lo_el_<node> =
lo_nd_<node>->get_element(
index = n ).
Get number
of elements in
collection
n = lo_nd_<node>->get_element_count( ).
Your component: In your component controller, method DOINIT, access the element
at lead selection of any of your nodes. Use the code wizard to access attributes,
but only show the coding discussed up to now. Check what happens if the node’s
cardinality is 0..<something> and no elements have been added to the collection yet
(result: get_element( ) leaves the element reference initial, which requires attention).
Reading and Changing Attribute Values
The Web Dynpro framework offers a variety of methods to access the attributes of one
node element or to access the attributes of all elements of a context node.
158
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Controller and Context Programming
Accessing Attributes of a Single Node Element
Once you have obtained the reference to a node element, there are two ways to obtain
the attribute values of this element:
1.
2.
Any attribute of a node element can be accessed using the method get_attribute(
). The name of the attribute must be exported and the attribute value is returned
in an import parameter.
Statically-defined attributes can be obtained by calling the method
get_static_attributes( ). A structure is returned in an import parameter. The
target structure can be different from the node structure. This is possible because
structure elements are copied individually to the target structure .
Figure 70: Accessing a single attribute of a node element
2009
© 2008 SAP AG. All rights reserved.
159
Unit 5: Controller and Context Programming
NET310
Figure 71: Accessing all statically defined attributes of a node element
Your component: Use the code wizard to generate code for reading a single attribute
or all static attributes of a node element at lead selection.
The following information is important in this context:
•
•
160
For each node <node> of a controller context, a structure type element_<node>
is implicitly generated in the interface IF_<ctrl>. If the node is typed,
element_<node> will be typed identically. If the node is not typed, the structure
fields correspond to the attributes that comprise the node element. This constant
can be used to type a variable, which is filled by the methods listed above.
In addition, for each node <node> of a controller context, a standard table type
elements_<node> is implicitly generated in the interface IF_<ctrl>. The line
type of this table is element_<node>. This constant can be used to type an
internal table that can hold the attributes of multiple node elements.
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Controller and Context Programming
Accessing the Attributes of all Node Elements
Figure 72: Access to the static attributes of all node elements
With the method get_static_attributes_table( ), the attributes of all elements can be
retrieved as an internal table.
Your component: You have created a service call which binds mass data to a related
context node. After calling the service method, you can read the mass data from the
context using the get_static_attributes_table() method.
2009
© 2008 SAP AG. All rights reserved.
161
Unit 5: Controller and Context Programming
NET310
To access the data sets related to multiple table lines selected by the user, the node’s
method get_selected_elements( ) has to be called. This method returns all selected
elements in an internal table (type WDR_CONTEXT_ELEMENT_SET). Each line of
this internal table contains the reference to one selected element.
Note: To select a context element, the user has to mark the corresponding
table line. Although the element at lead selection is always displayed dark
orange, the related context element is not automatically selected.
Thus, when calling the method get_selected_elements( ) the application
has to define whether the element at lead selection has to be returned even
if was not selected explicitly. This is guided by the value of parameter
INCLUDING_LEAD_SELECTION.
Changing the Attribute Values of a Node Element
Once the reference to a certain node element has been determined, you can not only
read the attribute values using the appropriate getter methods, but also change existing
attribute values by calling related setter methods.
The method set_attribute( ) can be used to change the value of any attribute of the
node element. Multiple attributes can be changed if they are statically defined using
the method set_static_attributes( ).
162
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Controller and Context Programming
Figure 73: Changing a single attribute of a node element
2009
© 2008 SAP AG. All rights reserved.
163
Unit 5: Controller and Context Programming
NET310
Figure 74: Changing multiple attributes of a node element
164
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Controller and Context Programming
Summary
Summary: Accessing and Changing Attributes in Node <node> of
Controller <ctrl>
Action
Read value of
attribute <attr>
Method
DATA:
lv_<attr> TYPE
wd_this->element_<node>-<attr>.
lo_el_<node>->get_attribute(
EXPORTING
name = ’<attr>’
IMPORTING
value = lv_<attr> ).
Read value of
multiple static
attributes
DATA:
ls_<node> TYPE
wd_this->element_<node>.
lo_el_<node>->get_static_attributes(
IMPORTING
static_attributes = ls_<node> ).
2009
© 2008 SAP AG. All rights reserved.
165
Unit 5: Controller and Context Programming
Action
NET310
Method
Read static
attribute values
for all node
elements
DATA:
lt_<node> TYPE wd_this->elements_<node>.
Change value
lv_<attr> of a
single attribute
<attr>
DATA:
lv_<attr> TYPE
wd_this->element_<node>-<attr>.
lo_nd_<node>->get_static_attributes_table(
IMPORTING
table = lt_<node> ).
lv_<attr> = ...
lo_el_<node>->set_attribute(
EXPORTING
name = ’<attr>’
value = lv_<attr> ).
Change multiple
attributes of a
node element
DATA:
ls_<node> TYPE wd_this->element_<node>.
ls_<node>-<attr1> = ...
...
lo_el_<node>->set_static_attributes(
EXPORTING
static_attributes = ls_<node> ).
Exercise “Accessing the Context at Runtime”
Adding new Elements to a Context Node
To this point, we have discussed the reading and changing of data already stored in the
controller context. Now we will learn how to add new elements to a context node.
Adding a new element to a node is performed in two steps. The first step is to create
an element that can be added to a certain context node later. After the attribute values
have been defined, the new element can be added to the context node. This is like
166
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Controller and Context Programming
the process of adding a new line to an internal table. The first step is to define the
cell values of a work area that has the correct line type, and the second step is to
insert the work area into the internal table.
Creating a New Node Element
In order to create an element that can be added to a certain context node, the reference
to this node has to be determined first. This is done by using the get_child_node( )
method of the standard attribute WD_CONTEXT, pointing to the context root node.
Figure 75: Getting the reference to a context node
Once you have obtained this reference, the method create_element( ) is used to create
the new element. Initial values for the static attributes can be submitted using the
static_attribute_values parameter or the attribute values can be defined using the
setter methods set_attribute( ) or set_static_attributes( ).
Caution: The new element is not yet part of the context node!
2009
© 2008 SAP AG. All rights reserved.
167
Unit 5: Controller and Context Programming
NET310
Figure 76: Creating a new node element
168
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Controller and Context Programming
Figure 77: Setting the attribute values of the new element
Adding Elements to a Context Node
Finally, an element,which is not yet part of the context node can be added to the node
using the method bind_element( ) related to the node reference. This method has
two import parameters:
•
•
2009
The element reference is submitted via the parameter new_item.
The parameter set_initial_elements defines whether the new element is simply
added to the element collection (value = abap_false) or replaces all existing
elements in the collection (value = abap_true).
© 2008 SAP AG. All rights reserved.
169
Unit 5: Controller and Context Programming
NET310
Figure 78: Binding an element to a context node
Your component: In your first view, you have some input fields bound to context
attributes. Change the cardinality of the related context node to 0..1. Start the
application -> the application dumps.
In the WDDOINIT method of this view, create a context element, set the context
attributes displayed in the layout and add the element to the collection. Start the
application again -> input fields are ready for input and attribute values are displayed.
Binding a Structure to a Context Node
In ABAP programs, datasets are handled as structures. However, to display the
structure elements in the UI, the structure content must be copied to a context element.
This means that a new element must be defined, the attribute values must be set and
the element must be bound to the appropriate context node.
There is an easier way to copy the structure content as a new element to the context
node. Instead of using method bind_element( ) and submitting the element reference,
you can use method bind_structure( ) with parameter new_item to submit the structure.
As for the bind_element( ) method, the existing collection can be extended or replaced
(parameter set_initial_elements).
170
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Controller and Context Programming
Figure 79: Binding a structure to a context node
Binding an Internal Table to a Context Node
Multiple datasets with identical structures are handled as internal tables in ABAP
programs. However, to be able to display the datasets in the UI, the internal table
content has to be copied to as many context elements as there are lines in the internal
table.
The best way to do this is to use the method bind_table( ). The internal table is
submitted via the parameter new_items. The existing collection can be extended or
replaced (parameter set_initial_elements).
2009
© 2008 SAP AG. All rights reserved.
171
Unit 5: Controller and Context Programming
NET310
Figure 80: Binding an internal table to a context node
Show demo NET310_UI_D5. The source code of the supply function is of interest.
The reference to the node to be altered by the supply function is available from the
interface parameter NODE, and the reference to the element at lead selection in the
parent collection is provided by the interface parameter PARENT_ELEMENT. Only
the data collection has to be implemented. You can also implement a supply function
for any node of your component controller context.
Deleting Elements from a Context Node
To remove an element from a collection, the method remove_element( ) has to be
called. The reference to the element must be submitted using the parameter element.
Two demos can be shown:
NET310_CONR_D1: The following method calls, which debug the source code
of this demo, can be discussed:
172
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Controller and Context Programming
node->get_element(), node->create_element(), node->bind_element(),
node->get_lead_selection(), node->get_element_count(), node->bind_structure(),
element->set_static_attributes() and element->set_attribute().
NET310_CONR_D2: In addition, method call node->remove_element() is used in
this demo.
Summary
Summary: Adding Elements to / Deleting Elements from a Context Node
Action
Method
Create a new
element
lo_el_<node> =
lo_nd_<node>->create_element( ).
Add element to
collection
lo_nd_<node>->bind_element(
new_item
= lo_el_<node>
set_initial_elements = abap_false ).
Bind structure
ls_<node> to
collection
DATA:
ls_<node> TYPE wd_this->element_<node>.
...
lo_nd_<node>->bind_structure(
new_item
= ls_<node>
set_initial_elements = abap_false ).
Bind internal
table lt_<node>
to collection
DATA:
lt_<node> TYPE wd_this->elements_<node>.
...
lo_nd_<node>->bind_table(
new_items
= lt_<node>
set_initial_elements = abap_false ).
Remove element
from collection
lo_nd_<node>->remove_element(
element = lo_el_<node> ).
Exercises “Binding Internal Tables to Context Nodes” and “Lead Selection and
Supply Functions”
2009
© 2008 SAP AG. All rights reserved.
173
Unit 5: Controller and Context Programming
174
© 2008 SAP AG. All rights reserved.
NET310
2009
NET310
159
Lesson: Controller and Context Programming
Exercise 7: Accessing the Context at
Runtime
Exercise Duration: 15 Minutes
Exercise Objectives
After completing this exercise, you will be able to:
•
Set the value of context node attributes dynamically
•
Set default values for input fields dynamically
Business Example
You want to develop a Web Dynpro application having default values displayed the
input fields of the first view at runtime.
Template: NET310_UI_S1
Solution: NET310_CONR_S1
Task 1:
Copy your Web Dynpro component ZNET310_UI1_## or the template
NET310_UI_S1 to Web Dynpro component ZNET310_CONR1_##. Create an
application to access this component.
1.
Copy the template.
2.
Create a Web Dynpro application to access the new component.
Task 2:
Make AA the default value of the field displaying the carrier ID on view
INPUT_VIEW.
1.
Implement the method WDDOINIT of the view controller: Use the Web Dynpro
Code Wizard to set the default value of context attribute FLIGHTINFO.CARRID.
2.
Activate your changes and test your application.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
175
Unit 5: Controller and Context Programming
NET310
Task 3:
Now set default values for all input fields before the view is displayed. Make LH the
default value of the field displaying the carrier ID and 0400 the default value of the
field displaying the connection number.
1.
Turn the last method call into a comment. Replace it as follows:
Fill the structure LS_FLIGHTINFO with the default values and call a method
of the context element to set all attributes in one step.
176
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Controller and Context Programming
Solution 7: Accessing the Context at
Runtime
Task 1:
Copy your Web Dynpro component ZNET310_UI1_## or the template
NET310_UI_S1 to Web Dynpro component ZNET310_CONR1_##. Create an
application to access this component.
1.
Copy the template.
a)
2.
Perform this step as in previous exercises.
Create a Web Dynpro application to access the new component.
a)
Perform this step as in previous exercises.
Task 2:
Make AA the default value of the field displaying the carrier ID on view
INPUT_VIEW.
1.
2.
Implement the method WDDOINIT of the view controller: Use the Web Dynpro
Code Wizard to set the default value of context attribute FLIGHTINFO.CARRID.
a)
Click the Web Dynpro Code Wizard button.
b)
Open the tab Context. Select the radio button labeled Set. Use the input
help to choose the context attribute FLIGHTINFO.CARRID.
c)
Finish the dialog.
d)
Replace the parameter LV_CARRID passed to the method
SET_ATTRIBUTES( ) by the literal “AA”
e)
Source code see below.
Activate your changes and test your application.
a)
Perform this step as in previous exercises. The form field displaying the
carrier should display the value “AA”.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
177
Unit 5: Controller and Context Programming
NET310
Task 3:
Now set default values for all input fields before the view is displayed. Make LH the
default value of the field displaying the carrier ID and 0400 the default value of the
field displaying the connection number.
1.
Turn the last method call into a comment. Replace it as follows:
Fill the structure LS_FLIGHTINFO with the default values and call a method
of the context element to set all attributes in one step.
a)
Use the Pattern function of the ABAP Workbench to create the method call.
b)
Source code see below.
Result
View INPUT_VIEW, Methode WDDOINIT, Task 1
METHOD wddoinit .
DATA lo_nd_flightinfo TYPE REF TO if_wd_context_node.
DATA lo_el_flightinfo TYPE REF TO if_wd_context_element.
DATA ls_flightinfo
TYPE
wd_this->element_flightinfo.
DATA lv_carrid
TYPE
wd_this->element_flightinfo-carrid.
* navigate from CONTEXT to FLIGHTINFO via lead selection
lo_nd_flightinfo = wd_context->get_child_node( name = wd_this->wdctx_flightinfo ).
* get element via lead selection
lo_el_flightinfo = lo_nd_flightinfo->get_element( ).
* set single attribute
lo_el_flightinfo->set_attribute(
name =
‘CARRID‘
value = ‘AA‘ ).
ENDMETHOD.
Continued on next page
178
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Controller and Context Programming
View INPUT_VIEW, Methode WDDOINIT, Task 2
METHOD wddoinit .
DATA lo_nd_flightinfo TYPE REF TO if_wd_context_node.
DATA lo_el_flightinfo TYPE REF TO if_wd_context_element.
DATA ls_flightinfo
TYPE
wd_this->element_flightinfo.
DATA lv_carrid
TYPE
wd_this->element_flightinfo-carrid.
* navigate from CONTEXT to FLIGHTINFO via lead selection
lo_nd_flightinfo = wd_context->get_child_node( name = wd_this->wdctx_flightinfo ).
* get element via lead selection
lo_el_flightinfo = lo_nd_flightinfo->get_element( ).
** set single attribute
*
lo_el_flightinfo->set_attribute(
*
name =
‘CARRID‘
*
value = ‘AA‘ ).
ls_flightinfo-carrid = ’LH’.
ls_flightinfo-connid = ’0400’.
* set all declared attributes
lo_el_flightinfo->set_static_attributes(
static_attributes = ls_flightinfo ).
ENDMETHOD.
2009
© 2008 SAP AG. All rights reserved.
179
Unit 5: Controller and Context Programming
180
© 2008 SAP AG. All rights reserved.
NET310
2009
NET310
165
Lesson: Controller and Context Programming
Exercise 8: Displaying mass data using
tables
Exercise Duration: 30 Minutes
Exercise Objectives
After completing this exercise, you will be able to:
•
Display mass data using internal tables
Business Example
You want to develop a Web Dynpro application where the user can enter selection
criteria in the first view. After the user clicks a button, data is selected and the system
navigates to a second view, in which the selected data is displayed as a table.
Template: NET310_CONR_S1
Solution: NET310_CONR_S2
Task 1:
Copy your Web Dynpro component ZNET310_CONR1_## or the template
NET310_CONR_S1 to Web Dynpro component ZNET310_CONR2_##. Create a
new application to access this component.
1.
Copy the template.
2.
Create a new application to access your component.
Task 2:
In the component controller context, create a new context node to store data sets for
flights read from database table SFLIGHT. Copy this context node to the context of
the view OUTPUT_VIEW and map the context nodes.
1.
In the component controller context, create a new context node (suggested name:
FLIGHTTAB) with reference to ABAP Dictionary structure SFLIGHT and
having cardinality 0..n.
The node should contain the following attributes: CARRID, CONNID,
FLDATE, PLANETYPE, SEATSMAX, and SEATSOCC.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
181
Unit 5: Controller and Context Programming
2.
NET310
Copy the new context node to the context of the view OUTPUT_VIEW. Map
the context node defined in the context of view OUTPUT_VIEW on the node
defined in the context of the component controller.
Task 3:
Extend the layout of the view OUTPUT_VIEW to display the flight data in a table.
1.
Use the Web Dynpro Code Wizard to create a table with binding to the context
node FLIGHTTAB.
Task 4:
Create a method in the component controller in which you select flights from
database table SFLIGHT and store them in an internal table. Use the static method
CL_NET310_FLIGHTMODEL=>READ_FLIGHTS( ) to collect the data. Store
the result in context node FLIGHTTAB.
1.
Create a new method in the component controller (name: FLIGHTTAB_FILL).
2.
Use the Web Dynpro Code Wizard to read the user input from the element at
lead selection of node FLIGHTINFO.
3.
Create an internal table (name: LT_FLIGHTTAB) of table type
NET310_T_SFLIGHT. Use the static method CL_NET310_FLIGHTMODEL=>READ_FLIGHTS( ) to fill the internal table (export parameter
ET_FLIGHTS). Use CARRID and CONNID entered by the user to restrict
the data selection.
4.
Use the code wizard to store the content of the internal table in the context
node FLIGHTTAB.
Task 5:
Make sure your new component controller method is executed after the navigation,
immediately before the view OUTPUT_VIEW is displayed.
1.
182
Edit method HANDLEIN_DEFAULT( ) of the view OUTPUT_VIEW and use
the Web Dynpro Code Wizard to implement a call of the component controller
method FLIGHTTAB_FILL( ).
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Controller and Context Programming
Solution 8: Displaying mass data using
tables
Task 1:
Copy your Web Dynpro component ZNET310_CONR1_## or the template
NET310_CONR_S1 to Web Dynpro component ZNET310_CONR2_##. Create a
new application to access this component.
1.
Copy the template.
a)
2.
Perform this step as in previous exercises.
Create a new application to access your component.
a)
Perform this step as in previous exercises.
Task 2:
In the component controller context, create a new context node to store data sets for
flights read from database table SFLIGHT. Copy this context node to the context of
the view OUTPUT_VIEW and map the context nodes.
1.
In the component controller context, create a new context node (suggested name:
FLIGHTTAB) with reference to ABAP Dictionary structure SFLIGHT and
having cardinality 0..n.
The node should contain the following attributes: CARRID, CONNID,
FLDATE, PLANETYPE, SEATSMAX, and SEATSOCC.
a)
2.
Perform this step as in previous exercises.
Copy the new context node to the context of the view OUTPUT_VIEW. Map
the context node defined in the context of view OUTPUT_VIEW on the node
defined in the context of the component controller.
a)
Perform this step as in previous exercises.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
183
Unit 5: Controller and Context Programming
NET310
Task 3:
Extend the layout of the view OUTPUT_VIEW to display the flight data in a table.
1.
Use the Web Dynpro Code Wizard to create a table with binding to the context
node FLIGHTTAB.
a)
Perform this step as in previous exercises.
b)
In order to make the table the first element of a new line, set LayoutData
= MatrixHeadData. Set width = 100% to stretch the table horizontally
across the page.
Task 4:
Create a method in the component controller in which you select flights from
database table SFLIGHT and store them in an internal table. Use the static method
CL_NET310_FLIGHTMODEL=>READ_FLIGHTS( ) to collect the data. Store
the result in context node FLIGHTTAB.
1.
Create a new method in the component controller (name: FLIGHTTAB_FILL).
a)
2.
3.
In the component controller, choose the Methods tab, enter the name of
the method and double-click the method’s name.
Use the Web Dynpro Code Wizard to read the user input from the element at
lead selection of node FLIGHTINFO.
a)
On the tab Context, select the radio button labeled Read.
b)
Using the value help select the node FLIGHTINFO.
c)
Finish the dialog.
Create an internal table (name: LT_FLIGHTTAB) of table type
NET310_T_SFLIGHT. Use the static method CL_NET310_FLIGHTMODEL=>READ_FLIGHTS( ) to fill the internal table (export parameter
ET_FLIGHTS). Use CARRID and CONNID entered by the user to restrict
the data selection.
a)
Source code see below.
Continued on next page
184
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Controller and Context Programming
4.
Use the code wizard to store the content of the internal table in the context
node FLIGHTTAB.
a)
On the tab Context, select the radio button labeled Set. in addition check
the check box labeled As table operation.
b)
Using the value help to select the node FLIGHTTAB.
c)
Finish the dialog.
d)
Correct the generated source code: Pass the internal table LT_FLIGHTTAB
to the method BIND_TABLE( ).
e)
Source code see below.
Task 5:
Make sure your new component controller method is executed after the navigation,
immediately before the view OUTPUT_VIEW is displayed.
1.
Edit method HANDLEIN_DEFAULT( ) of the view OUTPUT_VIEW and use
the Web Dynpro Code Wizard to implement a call of the component controller
method FLIGHTTAB_FILL( ).
a)
Edit method HANDLEIN_DEFAULT( ).
b)
Choose Web Dynpro Code Wizard.
c)
Select Method Call in Used Controller.
d)
Select the component controller and enter the name of the method.
e)
Source code see below.
Result
Comp.
Controller, Method FLIGTHTAB_FILL
METHOD flighttab_fill .
DATA lo_nd_flightinfo TYPE REF TO if_wd_context_node.
DATA lo_el_flightinfo TYPE REF TO if_wd_context_element.
DATA ls_flightinfo
TYPE
wd_this->element_flightinfo.
DATA lt_flighttab
TYPE
net310_t_sflight.
DATA lo_nd_flighttab
TYPE REF TO if_wd_context_node.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
185
Unit 5: Controller and Context Programming
NET310
* navigate from CONTEXT to FLIGHTINFO via lead selection
lo_nd_flightinfo = wd_context->get_child_node( name = wd_this->wdctx_flightinfo ).
* get element via lead selection
lo_el_flightinfo = lo_nd_flightinfo->get_element( ).
* get all declared attributes
lo_el_flightinfo->get_static_attributes(
IMPORTING
static_attributes = ls_flightinfo ).
* read all flights related to CARRID and CONNID entered by user
cl_net310_flightmodel=>read_flights(
EXPORTING
iv_carrid
= ls_flightinfo-carrid
iv_connid
= ls_flightinfo-connid
IMPORTING
et_flights = lt_flighttab ).
* navigate from CONTEXT to FLIGHTTAB via lead selection
lo_nd_flighttab = wd_context->get_child_node( name = wd_this->wdctx_flighttab ).
* bind table to context node FLIGHTTAB
lo_nd_flighttab->bind_table( new_items
= lt_flighttab
set_initial_elements = abap_true ).
ENDMETHOD.
View OUTPUT_VIEW, Method HANDLEIN_DEFAULT
METHOD handlein_default .
DATA lo_componentcontroller TYPE REF TO ig_componentcontroller .
lo_componentcontroller = wd_this->get_componentcontroller_ctr( ).
lo_componentcontroller->flighttab_fill( ).
ENDMETHOD.
186
© 2008 SAP AG. All rights reserved.
2009
NET310
171
Lesson: Controller and Context Programming
Exercise 9: Using Supply Functions
Exercise Duration: 30 Minutes
Exercise Objectives
After completing this exercise, you will be able to:
•
Use supply functions to populate context nodes
Business Example
You want to develop a Web Dynpro application with a view that displays two tables: a
list of flights and a list of bookings. The data displayed in the second table should
depend on the selected row in the first table. You want to use a supply function to
make sure that the data in the second table is changed whenever the user selects a
different row in the first table.
Template: NET310_CONR_S2
Solution: NET310_CONR_S3
Task 1:
Copy your Web Dynpro component ZNET310_CONR2_## or the template
NET310_CONR_S2 to Web Dynpro component ZNET310_CONR3_##. Create a
new application to access your component.
1.
Copy the template.
2.
Create a new application to access your component.
Task 2:
In the component context, create a new context node being a subnode of node
FLIGHTTAB. This new context node has to store bookings read from the database
table SBOOK.
Update the mapping of context node FLIGHTTAB defined in view OUTPUT_VIEW.
1.
In the component controller context, create a new context node (name:
BOOKINGTAB) being a subnode of node FLIGHTTAB. Set Dictionary
structure = SBOOK and Cardinality = 0..n.
The node should contain the following attributes: BOOKID, CUSTOMID,
CUSTTYPE, LUGGWEIGHT, WUNIT, CLASS, and PASSNAME.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
187
Unit 5: Controller and Context Programming
2.
NET310
Update the mapping for context node FLIGHTTAB in the context of view
OUTPUT_VIEW.
Task 3:
Display the bookings in a second table positioned below the flights table.
1.
Use the Web Dynpro Code Wizard to create a table with binding to the context
node BOOKINGTAB.
Task 4:
Create and implement a supply function to fill the subnode BOOKINGTAB according
to the element at lead selection in node FLIGHTTAB.
1.
In the component controller context, assign a supply function (name:
BOOKINGS_READ) to the node BOOKINGTAB.
2.
The supply method contains commented source code. Remove the comments
for the following statements:
- The declaration of the structure LS_PARENT_ATTRIBUTES.
- The call of method GET_STATIC_ATTRIBUTES( ) for the parent element.
- The declaration of internal table LT_BOOKINGTAB.
- The call of method BIND_TABLE( ) used to bind the table LT_BOOKINGTAB
to the context node.
The rest of the commented lines can be deleted.
3.
188
Call the static method CL_NET310_FLIGHTMODEL=>READ_BOOKINGS( ) to read all bookings for the selected flight. Use the attributes CARRID,
CONNID and FLDATE of the parent element to restrict the data selection.
Change the type of the internal table LT_BOOKINGTAB to the type of the
parameter RT_BOOKINGS returned by the method READ_BOOKINGS( ).
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Controller and Context Programming
Solution 9: Using Supply Functions
Task 1:
Copy your Web Dynpro component ZNET310_CONR2_## or the template
NET310_CONR_S2 to Web Dynpro component ZNET310_CONR3_##. Create a
new application to access your component.
1.
Copy the template.
a)
2.
Perform this step as in previous exercises.
Create a new application to access your component.
a)
Perform this step as in previous exercises.
Task 2:
In the component context, create a new context node being a subnode of node
FLIGHTTAB. This new context node has to store bookings read from the database
table SBOOK.
Update the mapping of context node FLIGHTTAB defined in view OUTPUT_VIEW.
1.
In the component controller context, create a new context node (name:
BOOKINGTAB) being a subnode of node FLIGHTTAB. Set Dictionary
structure = SBOOK and Cardinality = 0..n.
The node should contain the following attributes: BOOKID, CUSTOMID,
CUSTTYPE, LUGGWEIGHT, WUNIT, CLASS, and PASSNAME.
a)
2.
Perform this step as in previous exercises.
Update the mapping for context node FLIGHTTAB in the context of view
OUTPUT_VIEW.
a)
Open the context menu of context node FLIGHTTAB and choose Update
Mapping.
b)
Confirm the following question in the dialog box by choosing Yes.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
189
Unit 5: Controller and Context Programming
NET310
Task 3:
Display the bookings in a second table positioned below the flights table.
1.
Use the Web Dynpro Code Wizard to create a table with binding to the context
node BOOKINGTAB.
a)
Perform this step as in previous exercises.
b)
In order to make the table the first element of a new line, set LayoutData
= MatrixHeadData. Set width = 100% to stretch the table horizontally
across the page.
Task 4:
Create and implement a supply function to fill the subnode BOOKINGTAB according
to the element at lead selection in node FLIGHTTAB.
1.
2.
In the component controller context, assign a supply function (name:
BOOKINGS_READ) to the node BOOKINGTAB.
a)
Edit the component controller context. Click on the node BOOKINGTAB
to display the node’s properties.
b)
Assign the name of the supply function to the property Supply Function.
Double-click the name.
The supply method contains commented source code. Remove the comments
for the following statements:
- The declaration of the structure LS_PARENT_ATTRIBUTES.
- The call of method GET_STATIC_ATTRIBUTES( ) for the parent element.
- The declaration of internal table LT_BOOKINGTAB.
- The call of method BIND_TABLE( ) used to bind the table LT_BOOKINGTAB
to the context node.
The rest of the commented lines can be deleted.
a)
Source code see below.
Continued on next page
190
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Controller and Context Programming
3.
Call the static method CL_NET310_FLIGHTMODEL=>READ_BOOKINGS( ) to read all bookings for the selected flight. Use the attributes CARRID,
CONNID and FLDATE of the parent element to restrict the data selection.
Change the type of the internal table LT_BOOKINGTAB to the type of the
parameter RT_BOOKINGS returned by the method READ_BOOKINGS( ).
a)
Source code see below.
Result
Comp.
Controller, Method BOOKINGS_READ
METHOD bookings_read .
DATA ls_parent_attributes TYPE wd_this->element_flighttab.
DATA lt_bookingtab
TYPE net310_t_sbook.
* get all static attributes of parent element
parent_element->get_static_attributes(
IMPORTING
static_attributes = ls_parent_attributes ).
* read related bookings
lt_bookingtab = cl_net310_flightmodel=>read_bookings(
iv_carrid
= ls_parent_attributes-carrid
iv_connid
= ls_parent_attributes-connid
iv_fldate
= ls_parent_attributes-fldate ).
* bind all the elements
node->bind_table(
new_items
=
lt_bookingtab
set_initial_elements = abap_true ).
ENDMETHOD.
2009
© 2008 SAP AG. All rights reserved.
191
Unit 5: Controller and Context Programming
NET310
Lesson Summary
You should now be able to:
•
List the hook methods that exist for the different controller types.
•
Explain in which order these hook methods are processed.
•
Create and call your own controller methods.
•
Use the standard controller attributes to access the controller functionality, in
particular the controller context.
•
Define your own controller attributes and use them in the controller methods.
•
Access the controller context and read, delete, change or add node elements.
192
© 2008 SAP AG. All rights reserved.
2009
NET310
Unit Summary
Unit Summary
You
•
•
•
•
•
•
2009
should now be able to:
List the hook methods that exist for the different controller types.
Explain in which order these hook methods are processed.
Create and call your own controller methods.
Use the standard controller attributes to access the controller functionality, in
particular the controller context.
Define your own controller attributes and use them in the controller methods.
Access the controller context and read, delete, change or add node elements.
© 2008 SAP AG. All rights reserved.
193
Unit Summary
194
NET310
© 2008 SAP AG. All rights reserved.
2009
Unit 6
Internationalization and Messages
179
Demos are available for all applications described in this unit.
Unit Overview
Internationalizing Web Dynpro applications makes it possible to offer them in different
target languages. Each text - defined as a UI element property or text literal in the
source code, for example - can be defined to be translatable. This is also true for texts
that are used as messages on the client’s screen. This unit focuses on how to define
translatable texts and translatable messages as well as how to send the messages.
Unit Objectives
After completing this unit, you will be able to:
•
•
•
•
•
Define translatable texts in the OTR or as text symbols in an ABAP class.
Use OTR alias texts, text elements from ABAP classes, and data element texts to
define translatable literals in the Web Dynpro environment.
Report messages based on T100 texts, OTR texts, and text elements from ABAP
classes.
Report messages with and without connections to UI elements.
Define where messages are to be displayed on the screen.
Unit Contents
Lesson: Internationalization ....................................................... 196
Exercise 10: Internationalization (optional) ................................. 205
Lesson: Messages.................................................................. 208
Exercise 11: Value Checks and Messages ................................. 223
2009
© 2008 SAP AG. All rights reserved.
195
Unit 6: Internationalization and Messages
Lesson:
180
NET310
Internationalization
Lesson Duration: 70 Minutes
Lesson Overview
Offering a Web Dynpro application in different languages requires defining all literals
used in the application so that they are translatable. At runtime, the literal can then be
loaded in accordance the logon language.
There are several ways to make literals translatable. Text can be defined in the
Online Text Repository (OTR), as a text symbol in an ABAP class, or in the ABAP
Dictionary. All techniques will be discussed in this lesson.
Lesson Objectives
After completing this lesson, you will be able to:
•
•
Define translatable texts in the OTR or as text symbols in an ABAP class.
Use OTR alias texts, text elements from ABAP classes, and data element texts to
define translatable literals in the Web Dynpro environment.
Please use the demos from package NET310 to explain the content. Demos begin
with literal NET310_I18N_.
Business Example
All texts displayed to the user should be translatable since your application has to be
offered in multiple languages.
You can use demo NET310_I18N_D1 for all the techniques for define translatable
texts. Analyze the coding of the DOINIT method of the view to find out how
assistance class texts can be accessed.
However, it’s more instructive if you create and use your own OTR texts in your
component. It’s also better to define your own assistance class, text symbols,
constants, and a public alias for the interface method get_text( ). Using texts from the
ABAP Dictionary should be demonstrated, too.
196
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Internationalization
Internationalization
Internationalization means that all language-dependent parts of applications have to be
defined so that a language-specific version of the entity can be defined and the correct
version - the logon language - is used at runtime.
Figure 81: Internationalization
Note: Because internationalization is such a long word, it is often
abbreviated to I18N. That is, the first letter I, the last letter N, and don’t worry
about the 18 other letters in between.
Language-dependent entities include label texts, tool tips, button texts and message
texts, but also images and so on.
2009
© 2008 SAP AG. All rights reserved.
197
Unit 6: Internationalization and Messages
NET310
Using Texts Defined in the ABAP Dictionary
Figure 82: Referring to ABAP dictionary texts
The field labels stored with data elements can be assigned to UI element properties
easily:
•
The UI element Label is related to a UI element that allows user input (for
example InputField). The primary property of this related UI element, in turn,
must be bound to a context attribute of the property holding the field value. If
the context attribute is typed with an ABAP Dictionary type, the corresponding
data element field label (middle text) is automatically used as the label text.
The same mechanism applies to the captions of table columns.
•
•
198
Each data element field label can also be referenced directly. This is done by
pressing the button to the right of a properties value field. On the popup that
appears, press the button DDIC binding on/off to choose a DDIC type and the
kind of text (short, middle, long...).
From the source code, the function module DDIF_FIELDINFO_GET can be
called to read data element field labels in an arbitrary language.
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Internationalization
Your component: Bind some dictionary texts to text properties of UI elements in
your views (e.g. Label texts).
Defining and Using Online Text Repository (OTR) Texts
The Online Text Repository (OTR) is a central storage area for texts which can be
used not only in a Web Dynpro context but also in BSPs and all kinds of ABAP
programs (e.g. type 1, type M, type K). Different kinds of texts can be defined in the
OTR: OTR long texts, OTR short texts without aliases or OTR short texts with aliases.
OTR long texts are not subject to length restrictions. However, the disadvantage
is that they can only be used once. If you want to use the same long text a second
time, it has to be rewritten in the original language again and - even worse - it has
to be translated again.
OTR short texts are limited to 255 characters. An alias can be assigned to these texts.
OTR short texts with an alias (OTR alias texts) can be reused easily, and they only need
to be translated once. In the Web Dynpro context, only OTR alias texts should be used.
Hint: Texts entered in a value field of a UI element’s property are stored
as OTR short texts without an alias.
The OTR provides services for accessing these texts at runtime and it supports the
entry and translation of texts. To create a new OTR alias text, the Online Text
Repository browser can be used. This tool can be found in the Goto menu when
editing a view. The alias of an OTR short text consists of the package name followed
by a slash and an arbitrary identifier (<package>/<alias>).
In this context, the transaction SOTR_EDIT should be mentioned having the following
important functionality:
•
•
•
2009
Create, change, delete OTR texts in original language.
Check where OTR texts are used (statically).
Display and change existing translations of OTR texts.
© 2008 SAP AG. All rights reserved.
199
Unit 6: Internationalization and Messages
NET310
To use an OTR alias text as the value of a UI element property, perform the following
steps:
•
•
•
Press the input help button in the Properties value field. The OTR
browser appears, displaying all OTR alias texts of your package and of the
SOTR_VOCABULARY_BASIC package, which contains standard texts.
Select a text from the list and choose Enter.
The OTR directive for using this text is automatically entered in the Properties
value field.
The OTR directive is a combination of the text’s alias name and the prefix OTR written in capital letters: $OTR:<package>/<alias>.
Figure 83: Using OTR alias texts as UI element property values
OTR short texts having an alias can also be accessed from a controller’s source code.
The class CL_WD_UTILITIES provides appropriate service methods. The method
get_otr_text_by_alias( ) allows you to access the value of an OTR short text on a
language-dependent basis by providing the alias. The value returned is of type string.
200
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Internationalization
Figure 84: Accessing OTR alias texts from the controller source code
Hint: If a Web Dynpro component or a Web Dynpro application is translated
(using transaction SE63), all OTR short text without an alias related to this
component are also offered for translation.
OTR alias texts have to be translated in a separate step.
Hint: OTR texts are buffered by the application server. Thus, altered texts
defined locally or imported by a transport request will not be displayed before
the OTR buffer is resetted. Resetting the OTR buffer can be initiated by
entering /$OTR in the OK code field of the SAP GUI.
Your component: First, create some OTR texts using the OTR Browser in the menu.
Finally, use the input help for value fields to assign your OTR texts to UI element
properties.
Using Texts Defined in an ABAP Class
Texts from the ABAP Dictionary and OTR short texts are mainly used to provide
translatable texts that are assigned to UI element properties. However, there is a third
way to define translatable texts which is mainly used if you want to access a text from
the controller source code (e.g. the text to be displayed as a message).
2009
© 2008 SAP AG. All rights reserved.
201
Unit 6: Internationalization and Messages
NET310
Translatable texts can be defined as text symbols in an ABAP class. To access a text
symbol, a method has to be defined. If the visibility of this getter class is public, the
texts defined in the text pool can also be accessed from other ABAP programs.
A class offering such a method is already available in each SAP NetWeaver AS
7.0. Its name is CL_WD_COMPONENT_ASSISTANCE. Each class inheriting from
this parent class will have the instance method get_text( ), defined in the interface
IF_WD_COMPONENT_ASSISTANCE. Passing the identifier of the text symbol to the
method get_text( ) returns the text in the language sy-langu.
To use this class in a Web Dynpro component, it has to be instantiated in each
controller. However, an easier and more consistent way is to let the Web Dynpro
runtime create the instance only once. This is done by writing the class name in the
Assistance Class field, which can be found on the Properties tab for the Web Dynpro
component. The single steps are:
•
•
•
Edit the Web Dynpro component. Navigate to the Properties tab of the
component.
Enter a class name in the Assistance Class field.
Double-click the class name. If the class does not exist, it will be created. The
class is derived from the parent class CL_WD_COMPONENT_ASSISTANCE.
The life time of an assistance object defined this way equals the life time of related the
Web Dynpro component.
Figure 85: Using the component assistance class
202
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Internationalization
→
Text symbols can be added to the class by choosing Goto
Text Symbols. Be sure
that the length of the text symbols is long enough to support different languages.
•
•
Optionally, you can define a public alias for the interface method get_text( )
(just for convenience).
If you want to refer to the text elements using arbitrary identifiers, you can
define constants of type WDR_TEXT_KEY for each text element. The constant
value equals the text element identifier in apostrophes.
Once you have assigned the assistance class to the component, an attribute WD_ASSIST - is added to the attribute list of each controller. At runtime, this variable
will contain the reference to the assistance object. Using WD_ASSIST, a text can
be accessed as follows:
•
Using the text symbol identifier CAR:
DATA: lv_text TYPE string.
lv_text = wd_assist->if_wd_component_assistance~get_text(
key = ’CAR’ ).
•
Using a constant CARRID with the text symbol identifier CAR as its value:
DATA: lv_text TYPE string.
lv_text = wd_assist->if_wd_component_assistance~get_text(
key = wd_assist->carrid ).
•
Using the text symbol identifier CAR and having defined a public alias
GET_TEXT for the interface method:
DATA: lv_text TYPE string.
lv_text = wd_assist->get_text( key = ’CAR’ ).
Your component: Create an assistance class. Define a text symbol without any
placeholders and another text symbol having one or more placeholders (names:
&PARA1&, ...). Define class constants with better names. Define an alias get_text for
the interface method if_wd_component_assistance~get_text().
From any method of any controller of your component: Use the ABAP Code Wizard
to generate the method call of the get_text() method. Use the text symbol’s identifier
(literal) or the class constant to access the text symbol. Use an alias or complete
interface method name. For the method with placeholders, hand over literals to
replace the placeholders. Debug.
Texts defined in the assistance class can also have placeholders. These are defined by
using an ampersand (&), followed by the placeholder’s name.
2009
© 2008 SAP AG. All rights reserved.
203
Unit 6: Internationalization and Messages
NET310
The method get_text( ) allows you to export values for the placeholders. It returns
the corresponding text in the logon language, with the placeholder substituted by
the provided values.
Caution: Only a maximum of four placeholders with the names (including
the starting ampersand) &PARA1& ... &PARA4& are replaced by the method
get_text( ). Here, the placeholder names must be defined in capital letters.
If the text is obtained without providing values for the placeholders, the text is returned
as defined. The placeholders can then later be substituted by another algorithm (for
example, if the text is used as the text of a message).
Optional exercise “Internationalization”
204
© 2008 SAP AG. All rights reserved.
2009
NET310
189
Lesson: Internationalization
Exercise 10: Internationalization (optional)
Exercise Duration: 10 Minutes
Exercise Objectives
After completing this exercise, you will be able to:
•
Create OTR texts
•
Use OTR texts for UI elements
Business Example
You would like to develop a Web Dynpro application that can be translated as follows:
All literals assigned to UI element properties should be reusable and translatable. For
those texts that are not retrieved from the ABAP Dictionary, you want to use OTR
alias texts.
Template: NET310_CONR_S3
Solution: NET310_I18N_S1
Task 1:
Copy your Web Dynpro component ZNET310_CONR3_## or the template
NET310_CONR_S3 to Web Dynpro component ZNET310_I18N_##. Create a new
application to access your component.
1.
Copy the template.
2.
Create a new application to access your component.
Task 2:
Replace all literals assigned to UI element properties by references to OTR alias texts.
2009
1.
Create the required OTR texts in your package (identifiers starting with
ZNET310_##/).
2.
For all UI elements of type CAPTION, TEXTVIEW or BUTTON, assign the
reference to an appropriate OTR alias text to property text.
© 2008 SAP AG. All rights reserved.
205
Unit 6: Internationalization and Messages
NET310
Solution 10: Internationalization (optional)
Task 1:
Copy your Web Dynpro component ZNET310_CONR3_## or the template
NET310_CONR_S3 to Web Dynpro component ZNET310_I18N_##. Create a new
application to access your component.
1.
Copy the template.
a)
2.
Perform this step as in previous exercises.
Create a new application to access your component.
a)
Perform this step as in previous exercises.
Task 2:
Replace all literals assigned to UI element properties by references to OTR alias texts.
1.
2.
206
Create the required OTR texts in your package (identifiers starting with
ZNET310_##/).
→ Online Text Repository Browser.
a)
Choose Goto
b)
Choose Create
c)
Enter identifier (starting with ZNET310_##/), length, and text. Choose
Save .
.
For all UI elements of type CAPTION, TEXTVIEW or BUTTON, assign the
reference to an appropriate OTR alias text to property text.
a)
Edit the respective UI element and open the input help for property text.
b)
Click on the appropriate OTR text in the list.
c)
Select Enter to assign the reference to the OTR alias text to the UI element
property.
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Internationalization
Lesson Summary
You should now be able to:
•
Define translatable texts in the OTR or as text symbols in an ABAP class.
•
Use OTR alias texts, text elements from ABAP classes, and data element texts to
define translatable literals in the Web Dynpro environment.
2009
© 2008 SAP AG. All rights reserved.
207
Unit 6: Internationalization and Messages
Lesson:
192
NET310
Messages
Lesson Duration: 60 Minutes
Lesson Overview
Messages are important to inform the user about the status of the application. This
lessons discusses in detail what kind of messages exist, how messages are reported
and how messages impact the phase model.
Lesson Objectives
After completing this lesson, you will be able to:
•
•
•
Report messages based on T100 texts, OTR texts, and text elements from ABAP
classes.
Report messages with and without connections to UI elements.
Define where messages are to be displayed on the screen.
Please use the demos from package NET310 to explain the content. Demos begin
with literal NET310_MES_.
Business Example
You have created a Web Dynpro application. However, if a user provides incorrect
field values, your application crashes or does not work correctly. You want to check
the user input and inform the user by displaying messages.
Messages and Error Handling
Messages are used to provide the user with status information of the application.
Depending on the message kind, different icons may be displayed left of the message
text. If a critical program status is determined, messages can be reported that cancel
208
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Messages
the navigation. Message texts may be linked to form fields, which are then displayed
highlighted. Clicking a message link will then position the cursor in the related form
field, or - if the message is linked to multiple form fields - in one of these fields.
Hint: If the user enters a field value that does not math the field type (defined
by the context attribute bound to the primary property of this UI element), the
system reports a so called validation error. The navigation is cancelled, the
last view assembly is displayed again, and the validation error is displayed.
This error message is automatically linked to the form field containing the
corrupt data.
Defining the Position of the Message Area
There are two ways to define where messages are displayed on the screen:
1.
2.
The default position of the message area is at the top of the page.
If a position different from the default position is desired, the MessageArea
container UI element has to be used. A MessageArea UI element can be defined
as a subelement of all other container elements.
Figure 86: Positioning of messages
2009
© 2008 SAP AG. All rights reserved.
209
Unit 6: Internationalization and Messages
NET310
Compare demo NET310_MES_D3 with demo NET310_MES_D3A. Calculate 1 / 0.
This will cause a message to be displayed. For the second demo, a message container
has been used to redefine the position of the message area.
Message Handling
In the Web Dynpro application, you can set the way messages are displayed. All
messages are displayed in a transparent container. On the Properties tab of a Web
Dynpro application, message handling can be defined by setting the radio button in
the group labeled “Handling of Messages”. The following settings are possible:
•
Show Message Component on Demand
If at least one message is reported, the message area is displayed.
•
Always Display Message Component
The message area is also displayed if no message is reported.
Figure 87: Message handling
210
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Messages
Show demo NET310_MES_D2 (2 different WD applications exist for this component,
allowing you to examine the different possibilities for handling messages).
Methods for Defining Messages: Categories
In order to report a message, methods of the IF_WD_MESSAGE_MANAGER
interface have to be used. The Web Dynpro runtime automatically instantiates a class
implementing this interface. The reference to this interface can be obtained from the
self-reference WD_THIS using the expressions:
lo_api_ctrl
= wd_this->wd_get_api().
lo_message_manager = lo_api_ctrl->get_message_manager().
All methods that are allowed to report methods can be divided into three categories:
•
TEXT
Methods belonging to this category allow to report messages that are based
on arbitrary text literals. Translatable texts can originate from the OTR (short
texts with alias), from text symbols defined in an ABAP class (preferably the
assistance class), or from the ABAP Dictionary.
•
T100
These methods allow to report messages that are based on texts defined in
database table T100.
•
EXCEPTIONS
Catchable runtime errors and the related texts can be used when choosing
a message of this category.
2009
© 2008 SAP AG. All rights reserved.
211
Unit 6: Internationalization and Messages
NET310
Figure 88: Methods for defining messages: categories
Methods of categories TEXT and T100 allow you to export parameters in addition to
the message text. This allows the use of message texts containing placeholders. In
standard SAP exception classes the texts do not contain placeholders. However, you
may define your own exception classes containing an appropriate message text.
All methods allow relating the message to a single form field or to multiple form
fields. The message text is then displayed as a link.
If the message is related to a single form field, clicking on the link sets the cursor in
this field. The field and its contents are highlighted.
If the message is related to multiple form fields, clicking the link sets the cursor in
the first related field visible on the UI from left to right and from top to bottom. The
content of this field is marked while all related fields are highlighted.
Summary
The list below summarizes the methods available for reporting messages.
212
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Messages
Category: TEXT
Method (REPORT_...)
Can parameters
be used in
message texts ?
Can the message
be related to UI
element(s) ?
ELEMENT_ERROR_MESSAGE
YES (parameter
PARAMS)
YES, to multiple UI
elements (parameters
ELEMENT,
ATTRIBUTES)
ATTRIBUTE_ERROR_MESSAGE
YES (parameter
PARAMS)
YES, to single UI
element (parameters
ELEMENT,
ATTRIBUTE_NAME)
SUCCESS
YES (parameter
PARAMS)
NO
WARNING
YES (parameter
PARAMS)
NO
ERROR_MESSAGE
YES (parameter
PARAMS)
NO
FATAL_ERROR_MESSAGE
YES (parameter
PARAMS)
NO
Category: EXCEPTIONS
Method (REPORT_...)
2009
Can parameters
be used in
message texts ?
Can the message
be related to UI
elements ?
ELEMENT_EXCEPTION
Only for own
YES, to multiple UI
exception classes elements (parameters
ELEMENT,
ATTRIBUTES)
ATTRIBUTE_EXCEPTION
Only for own
YES, to single UI
exception classes element (parameters
ELEMENT,
ATTRIBUTE_NAME)
EXCEPTION
Only for own
NO
exception classes
FATAL_EXCEPTION
Only for own
NO
exception classes
© 2008 SAP AG. All rights reserved.
213
Unit 6: Internationalization and Messages
NET310
Category: T100
Method (REPORT_...)
Can parameters
be used in
message texts ?
Can the message
be related to UI
elements ?
ELEMENT_T100_MESSAGE
YES (parameters YES, to multiple UI
MSG)
elements (parameters
ELEMENT,
ATTRIBUTES)
ATTRIBUTE_T100_MESSAGE
YES (parameters YES, to single UI
MSG)
element (parameters
ELEMENT,
ATTRIBUTE_NAME)
T100_MESSAGE
YES (parameters NO
P1, P2, P3, P4)
Reporting Messages
The source code for reporting messages can be generated using the Web Dynpro Code
Wizard. The generated code consists of a common part, containing the source code for
obtaining the reference to the message manager object, and a part that is dependent
on the method to be called. The message manager is responsible for collecting and
sending the messages reported in the actual component and all subcomponents.
Since obtaining the reference to the message manager is mandatory before a message
can be reported, the corresponding source code should be moved to the standard hook
method wddoinit() of the component controller and the reference should be stored
in a public controller attribute.
214
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Messages
Figure 89: Reporting a message: common part
Your component: Report any message using the WD Code Wizard. Restrict your
discussion to the general code section.
Messages related to UI Elements
Message can be related to form fields. However, the relation is not guided by the
names of the UI elements, but by the context attributes that are bound to the primary
properties of the form fields. These context attributes contain the faulty values. Thus,
the following information has to be supplied:
If a message has to be related to a single form field, then the reference to the context
element containing the attribute with the faulty value (element) and the name of the
attribute (attribute_name) have to be passed to the message manager method.
A message can also be linked to multiple form fields. However, this is only possible
if all related attributes belong to the same context element. Thus, the reference to
the context element containing the attributes with the faulty values (element) and
an internal table containing the names of all these attributes (attributes) have to be
passed to the message manager method.
2009
© 2008 SAP AG. All rights reserved.
215
Unit 6: Internationalization and Messages
NET310
Category TEXT
In order to report a TEXT message, at least the message text has to be exported using
the parameter message_text. If the message text contains placeholders, the parameter
list (params) must be defined before calling the method. Placeholders in message
texts can have arbitrary names (in the example below, X1).
Figure 90: Example: reporting a message - category TEXT
You can show different kinds of TEXT messages using demo NET310_MES_D2.
Error messages, warnings and success messages are reported. Some of them are
related to context attributes, some have placeholders. Discuss in detail.
Category T100
Two methods exist for using texts already defined in database table T100. The
message number, the message class and the message type have to be provided. If the
message text contains placeholders, appropriate values can be exported. Depending
on the method, all message fragments are exported using scalar parameters (MSGID,
MSGNO, MSGTY, P1 .. P4) or an export structure (MSG). At least the message text
has to be exported using the parameter message_text.
216
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Messages
Figure 91: Reporting a message: category T100
Demo NET310_MES_D1 reports different types of T100 messages. Discuss in detail.
Category EXCEPTIONS
Runtime exceptions can be caught in an exception object, which then contains the
text related to the error. This text is defined in the exception class and thus cannot
be influenced. The message object can be used to create a Web Dynpro message by
calling methods of the category EXCEPTIONS. The message object is exported using
the parameter message_object.
2009
© 2008 SAP AG. All rights reserved.
217
Unit 6: Internationalization and Messages
NET310
Figure 92: Reporting a message: category EXCEPTIONS
Demo NET310_MES_D3 shows how to report an exception message. Discuss in
detail.
Coding for Reporting Messages
In principle, the validation coding can be placed in any method processed by the Web
Dynpro runtime. However, if a message should cancel the navigation, the message
has to be reported in the hook methods wddobeforeaction( ), wddoafteraction( ) or
in the action handler method onaction<action> of the view or in the hook method
wddobeforenavigation( ) of the component controller. Checks that are only related to
fields of a certain view should be performed in methods of this view. Then, the three
hook methods related to the action handling have to be used. In this context, the hook
method wddobeforeaction( ) has some advantages over the methods wddoafteraction(
) and onaction<action>:
218
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Messages
If a fatal error message (this type of message always cancels the navigation) is send in
the hook method wddobeforeaction( ), then only this message will be displayed in the
next view assembly. Additional validation errors reported by the Web Dynpro runtime
(resulting from a user input that does not fit the field type) will not be displayed.
If an error message related to form fields is reported in the hook method
wddobeforeaction( ), then the action handler method and the method wddoafteraction(
) are skipped. Thus, coding not to be processed if an error is found can be separated
from the code to be processed in any case.
In addition wddobeforeaction( ) can be used for modularization reasons. If the same
checks are to be performed for different client side events - related to different action
handler methods - these checks can be defined in the hook method wddobeforeaction(
).
Hint: If a screen is composed of multiple views (nested views), then all
wddobeforeaction( ) methods are processed before any action handler method
is called and all wddoafteraction( ) methods are processed after any action
handler method has been processed.
Figure 93: Reporting messages: hook method WDDOBEFOREACTION()
2009
© 2008 SAP AG. All rights reserved.
219
Unit 6: Internationalization and Messages
NET310
The following source code section is used to find out the name of the action that was
triggered by the user. From the controller’s API, the method get_current_action( ) is
used to receive the reference to an object describing the action. The attribute name
contains the name of the last action that was triggered.
Figure 94: Determining the name of the current action
Reporting Messages: Impact on Navigation and Method Processing
This behavior can be visualized using demo NET310_I18N_D5. Use the drop down
boxes to choose what kind of message is sent in which controller method.
By default, messages of type Success, Warning and Error do not influence navigation.
Messages of the kinds listed here have no impact on the order of the controller
methods processed by the framework.
If a messages of type Fatal is reported in any hook method called by the Web Dynpro
runtime before the navigation queue processed, the navigation is cancelled. All the
view’s subsequent hook methods (except wddomodifyview( ) ) are skipped. The source
code of the hook method containing the method call (used to report the fatal message)
is only processed up to the call.
220
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Messages
For messages that are related to context attributes, the behavior depends not only on
the hook method containing the method call, but also on the property Action Type
of the triggered action:
By default, the property Action Type is set to validation-dependent (standard).
In this case the navigation is cancelled if the message is reported in any of the
hook methods wddobeforeaction( ), onaction<action>( ) or wddoafteraction( ).
In addition, the method wddomodifyview( ) is skipped. If the message is reported
in wddobeforeaction( ), the methods onaction<action>( ) and wddoafteraction( )
are also skipped. This default behavior can be changed by means of the interface
parameter IS_VALIDATION_INDEPENDENT, which exists for all methods used to
report context attribute related messages.
If the Action Type is set to validation-independent, then the navigation is not cancelled.
In this case, reporting a message related to context attributes does not influence the
number and order of the hook methods processed by the Web Dynpro runtime.
2009
© 2008 SAP AG. All rights reserved.
221
Unit 6: Internationalization and Messages
222
© 2008 SAP AG. All rights reserved.
NET310
2009
NET310
205
Lesson: Messages
Exercise 11: Value Checks and Messages
Exercise Duration: 40 Minutes
Exercise Objectives
After completing this exercise, you will be able to:
•
Implement value checks after user input
•
Access the message manager and send messages
•
Send messages with references to UI elements
Business Example
You want to develop a Web Dynpro application with a view that offers fields for user
input. You want to check the user input and send messages in case of missing or
incorrect values. Depending on the error, fields containing incorrect values should
be highlighted.
Template: NET310_I18N_S1
Solution: NET310_MES_S1
Task 1:
Copy your Web Dynpro component ZNET310_I18N_## (optional exercise) or the
template NET310_I18N_S1 to Web Dynpro component ZNET310_MES_##.
If you have not finished the optional exercise, but you would like to go on editing your
own component, you can copy your antecessor component ZNET310_CONR3_##.
Create a new Web Dynpro application to access your component.
1.
Copy the template.
2.
Create a new application to access your component.
Task 2:
In the controller of the view INPUT_VIEW, create a new method in which you will
implement the value checks. Make sure the new method is processed after the user
has pressed the button, but before the outbound plug of the view is fired.
1.
In the controller of the view INPUT_VIEW, create a new method (name:
CHECK_INPUT) in which you will implement the value checks.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
223
Unit 6: Internationalization and Messages
2.
NET310
In method WDDOBEFOREACTION, implement a call of the new method.
Task 3:
Implement the method CHECK_INPUT( ). The first step is to read all attributes of
context node FLIGHTINFO, to assign an assistance class to the component, and to
determine the reference to the message manager.
1.
Use the Web Dynpro Code Wizard to read all attributes of context node
FLIGHTINFO.
2.
Text symbols defined in the assistance class CL_NET310_I18N_S are to be
displayed as message texts. Thus assign this assistance class to your component.
3.
Get the reference to the message manager object before checking the user input.
Task 4:
Implement the following input checks:
If both input fields are initial, send an error message highlighting both fields.
If one field value is provided but the other field value is initial, send an error message
highlighting the initial field only.
If both field values are provided, check if a connection having this key does exist. If
this is not the case, send an error message highlighting both fields.
1.
Define an IF ... ENDIF statement for the different checks you would like to
perform.
2.
Before sending a message, get the appropriate text from the assistance object
and store the text in a local variable.
Hint: Use attribute WD_ASSIST of the view controller to access the
assistance object.
The method GET_TEXT( ) defined as a public alias in the assistance
class can be used to get the text.
→
Choose Goto
Text Symbols to get an overview over the texts and the
related identifiers.
3.
Implement the input checks that should result in an error message if at least
one field is initial.
Continued on next page
224
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Messages
4.
2009
Implement the existence check of the connection if values for both fields
are provided. Call the static method CHECK_CONNECTION( ) of class
CL_NET310_FLIGHTMODEL to check the existence. If the returning
parameter equals ABAP_FALSE, send an appropriate message.
© 2008 SAP AG. All rights reserved.
225
Unit 6: Internationalization and Messages
NET310
Solution 11: Value Checks and Messages
Task 1:
Copy your Web Dynpro component ZNET310_I18N_## (optional exercise) or the
template NET310_I18N_S1 to Web Dynpro component ZNET310_MES_##.
If you have not finished the optional exercise, but you would like to go on editing your
own component, you can copy your antecessor component ZNET310_CONR3_##.
Create a new Web Dynpro application to access your component.
1.
Copy the template.
a)
2.
Perform this step as in previous exercises.
Create a new application to access your component.
a)
Perform this step as in previous exercises.
Task 2:
In the controller of the view INPUT_VIEW, create a new method in which you will
implement the value checks. Make sure the new method is processed after the user
has pressed the button, but before the outbound plug of the view is fired.
1.
In the controller of the view INPUT_VIEW, create a new method (name:
CHECK_INPUT) in which you will implement the value checks.
a)
2.
Perform this step as in previous exercises.
In method WDDOBEFOREACTION, implement a call of the new method.
a)
Perform this step as in previous exercises.
b)
Source code see below.
Task 3:
Implement the method CHECK_INPUT( ). The first step is to read all attributes of
context node FLIGHTINFO, to assign an assistance class to the component, and to
determine the reference to the message manager.
1.
Use the Web Dynpro Code Wizard to read all attributes of context node
FLIGHTINFO.
a)
Perform this step as in previous exercises.
b)
Source code see below.
Continued on next page
226
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Messages
2.
Text symbols defined in the assistance class CL_NET310_I18N_S are to be
displayed as message texts. Thus assign this assistance class to your component.
a)
3.
Edit the Web Dynpro component and enter the name of the class in the
Assistance Class field.
Get the reference to the message manager object before checking the user input.
a)
Start the Web Dynpro Code Wizard.
b)
Select the tab General.
c)
Select the radio button Generate Message. Use the value help to select any
method of the message manager.
d)
Finish the dialog.
e)
Edit the generated source code. Delete the last statement (call of the
message manager method).
f)
Source code see below.
Task 4:
Implement the following input checks:
If both input fields are initial, send an error message highlighting both fields.
If one field value is provided but the other field value is initial, send an error message
highlighting the initial field only.
If both field values are provided, check if a connection having this key does exist. If
this is not the case, send an error message highlighting both fields.
1.
Define an IF ... ENDIF statement for the different checks you would like to
perform.
a)
Source code see below.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
227
Unit 6: Internationalization and Messages
2.
NET310
Before sending a message, get the appropriate text from the assistance object
and store the text in a local variable.
Hint: Use attribute WD_ASSIST of the view controller to access the
assistance object.
The method GET_TEXT( ) defined as a public alias in the assistance
class can be used to get the text.
→
Choose Goto
Text Symbols to get an overview over the texts and the
related identifiers.
a)
3.
Source code see below.
Implement the input checks that should result in an error message if at least
one field is initial.
a)
To define a method you can either use the Web Dynpro Code Wizard or
the Pattern function.
Hint: If you use the Web Dynpro Code Wizard, you have to delete
all the generated code but the statement to send the message.
Hint: If you use the Pattern function, you have to enter the
class (IF_WD_MESSAGE_MANAGER), the instance, and the
method’s name. The instance is the reference to the message
manager object determined in step 1 of this task.
4.
b)
Appropriate message texts have the identifier 001, 002, and 006.
c)
Source code see below.
Implement the existence check of the connection if values for both fields
are provided. Call the static method CHECK_CONNECTION( ) of class
CL_NET310_FLIGHTMODEL to check the existence. If the returning
parameter equals ABAP_FALSE, send an appropriate message.
a)
Use message text with identifier 007
b)
Declare and fill an internal table (name: lt_params) to supply values for
the parameters contained in the message text.
c)
Pass this internal table to the method used to define the message via
parameter PARAMS.
Continued on next page
228
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Messages
d)
Source code see below.
Result
View INPUT_VIEW, Method CHECK_INPUT
METHOD check_input .
DATA lo_nd_flightinfo TYPE REF TO if_wd_context_node.
DATA lo_el_flightinfo TYPE REF TO if_wd_context_element.
DATA ls_flightinfo
TYPE
DATA lo_api_controller
wd_this->element_flightinfo.
TYPE REF TO if_wd_controller.
DATA lo_message_manager TYPE REF TO if_wd_message_manager.
DATA lv_text
TYPE
string.
DATA lt_attributes TYPE TABLE OF string.
DATA lt_params
TYPE
wdr_name_value_list.
DATA ls_param
TYPE
wdr_name_value.
DATA lv_exist
TYPE
wdy_boolean.
* get user input
lo_nd_flightinfo = wd_context->get_child_node( name = wd_this->wdctx_flightinfo ).
lo_el_flightinfo = lo_nd_flightinfo->get_element( ).
lo_el_flightinfo->get_static_attributes(
IMPORTING
static_attributes = ls_flightinfo ).
* get message manager
lo_api_controller ?= wd_this->wd_get_api( ).
lo_message_manager = lo_api_controller->get_message_manager( ).
*********************************** CHECKS ********************************
IF ls_flightinfo-carrid IS INITIAL AND ls_flightinfo-connid IS INITIAL.
*
report message related to CARRID and CONNID
lv_text = wd_assist->get_text( key = ’006’ ).
APPEND ’CARRID’ TO lt_attributes.
APPEND ’CONNID’ TO lt_attributes.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
229
Unit 6: Internationalization and Messages
NET310
lo_message_manager->report_element_error_message(
message_text
= lv_text
element
= lo_el_flightinfo
attributes
= lt_attributes ).
ELSEIF ls_flightinfo-carrid IS INITIAL.
*
report message related to CARRID
lv_text = wd_assist->get_text( key = ’001’ ).
lo_message_manager->report_attribute_error_message(
message_text
= lv_text
element
= lo_el_flightinfo
attribute_name = ’CARRID’ ).
ELSEIF ls_flightinfo-connid IS INITIAL.
*
report message related to CONNID
lv_text = wd_assist->get_text( key = ’002’ ).
lo_message_manager->report_attribute_error_message(
message_text
= lv_text
element
= lo_el_flightinfo
attribute_name = ’CONNID’ ).
ELSE.
*
does connection exist?
lv_exist = cl_net310_flightmodel=>check_connection(
iv_carrid = ls_flightinfo-carrid
iv_connid = ls_flightinfo-connid ).
*
connection does not exist: report message related to CARRID and CONNID
IF lv_exist = abap_false.
ls_param-name = ’1’.
ls_param-value = ls_flightinfo-carrid.
APPEND ls_param TO lt_params.
ls_param-name = ’2’.
ls_param-value = ls_flightinfo-connid.
APPEND ls_param TO lt_params.
APPEND ’CARRID’ TO lt_attributes.
APPEND ’CONNID’ TO lt_attributes.
lv_text = wd_assist->get_text( key = ’007’ ).
lo_message_manager->report_element_error_message(
message_text = lv_text
Continued on next page
230
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Messages
element
= lo_el_flightinfo
params
= lt_params
attributes
= lt_attributes ).
ENDIF.
ENDIF.
ENDMETHOD.
View INPUT_VIEW, Method WDDOBEFOREACTION
METHOD wddobeforeaction .
wd_this->check_input(
).
ENDMETHOD.
2009
© 2008 SAP AG. All rights reserved.
231
Unit 6: Internationalization and Messages
NET310
Lesson Summary
You should now be able to:
•
Report messages based on T100 texts, OTR texts, and text elements from ABAP
classes.
•
Report messages with and without connections to UI elements.
•
Define where messages are to be displayed on the screen.
232
© 2008 SAP AG. All rights reserved.
2009
NET310
Unit Summary
Unit Summary
You should now be able to:
•
Define translatable texts in the OTR or as text symbols in an ABAP class.
•
Use OTR alias texts, text elements from ABAP classes, and data element texts to
define translatable literals in the Web Dynpro environment.
•
Report messages based on T100 texts, OTR texts, and text elements from ABAP
classes.
•
Report messages with and without connections to UI elements.
•
Define where messages are to be displayed on the screen.
2009
© 2008 SAP AG. All rights reserved.
233
Unit Summary
234
NET310
© 2008 SAP AG. All rights reserved.
2009
Unit 7
217
Value Help, Semantic Help, and
Keyboard Access
Web Dynpro ABAP can make use of the ABAP Dictionary, thus search help, check
tables and domain fixed values can be reused to generate a value help. The object
value selector is thus banned to the appendix.
The appropriate demos dealing with providing input help and defining value selectors
can be found in the NET310 package. Demos begin with NET310_HLP_D.
Semantic help has been added to this unit for course collection 63. Use demo
NET310_HLP_D4 to explain the details.
For the last topic, the demo NET310_KEY_D1 is included in package NET310. This
is a copy of NET310_CONR_S3. However, on the view INPUT_VIEW a default
button is defined, a hotkey is assigned to this button, and access keys may be used
anyway.
Unit Overview
Value help is essential to improve the usability of an application. Web Dynpro for
ABAP offers a wide variety of options for implementing value help. Beyond simple
value selectors like drop down boxes or radio button groups, more sophisticated input
help for input fields can be implemented. This unit deals with all types of value help
available for Web Dynpro ABAP.
There are various ways to define short help texts in Web Dynpro applications as
well as to display longer documentation texts from the Knowledge Warehouse for a
complete application or window. In the second lesson of this unit, all possibilities to
display semantic help to the user will be discussed.
Finally, Web Dynpro allows to set the focus on UI elements or to trigger client-side
events by means of keyboard commands. The third lesson sums up all concepts
dealing with this topic.
2009
© 2008 SAP AG. All rights reserved.
235
Unit 7: Value Help, Semantic Help, and Keyboard Access
NET310
Unit Objectives
After completing this unit, you will be able to:
•
•
•
•
•
•
•
•
•
•
Implement value help bound to drop down boxes, radio buttons or list boxes
(value selectors).
Implement value help bound to input fields (input help).
Define the values displayed by value help both statically and dynamically.
Define tool tips and short explanations related to a certain UI element.
Define explanation texts not related to a certain UI element.
Use the help center.
Access UI elements using keyboard commands
Define default buttons bound to container UI elements
Define and use hotkeys
Use access keys
Unit Contents
Lesson: Value Help ................................................................. 237
Exercise 12: Display allowed Field Values by Drop Down Box .......... 249
Lesson: Semantic Help ............................................................ 255
Lesson: Keyboard Access ......................................................... 267
236
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson:
219
Lesson: Value Help
Value Help
Lesson Duration: 70 Minutes
Lesson Overview
Web Dynpro for ABAP offers a great variety of value help. This is due to the fact
that ABAP Dictionary information (domain fixed values) and objects (search help)
can be reused. In addition, the value help available can be combined with a number
of UI elements in order to display the allowed values to the user (InputField,
DropDownByKey, DropDownByIndex, RadioButtonByKey, RadioButtonByIndex
and ItemListBox). This lesson covers all topics related to value help in Web Dynpro
for ABAP.
Lesson Objectives
After completing this lesson, you will be able to:
•
•
•
Implement value help bound to drop down boxes, radio buttons or list boxes
(value selectors).
Implement value help bound to input fields (input help).
Define the values displayed by value help both statically and dynamically.
Please take a look at the demos available in the package NET310 in each training
system. Further instructions can be found in this text.
Business Example
You are creating a Web Dynpro application that contains forms. The user has to enter
data in form fields. In some of these fields, arbitrary values will be entered by the
user. However, some other fields will be created which have a value help. There are
different value helps you want to implement:
For some of the form fields, a value help has to be implemented that can be used to
define the fields value. However, the user should still be able to input values which
are different from the values displayed by the value help.
For other fields, a value help must be implemented that has to be used to define the
field value, since values different from the values displayed by the value help are
not allowed.
2009
© 2008 SAP AG. All rights reserved.
237
Unit 7: Value Help, Semantic Help, and Keyboard Access
NET310
In order to create the correct value help, you have to learn more about the techniques
available.
Value Help for Input Fields
If the user is not to be restricted to a given value set, or if the value set is large and
the user needs filter functions to find a certain value, a value help related to an input
field is the right choice.
Figure 95: Different types of input help
238
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Value Help
The developer can influence the input help by setting the property Input Help Mode of
the context attribute bound to the input field. There are five settings for this property:
•
Deactivated
No input help is available. This is independent of the referred data type.
•
Automatic
The input help is determined by the Web Dynpro runtime.
•
Dictionary Search Help
The developer can choose a search help defined in the ABAP Dictionary.
•
Object Value Selector
A predefined, configurable Web Dynpro component implementing a search help
can be used to define the search help dialog.
•
User-Defined Programming
A user-defined Web Dynpro component implementing a search help dialog is
used to define the search help.
Figure 96: Input Help Modes
2009
© 2008 SAP AG. All rights reserved.
239
Unit 7: Value Help, Semantic Help, and Keyboard Access
NET310
For each of the possible ways to use a search help defined in the ABAP DDIC, a
corresponding field group can be found in the layout of the view defined in demo
NET310_HLP_D2.
Determining the Input Help for Input Help Mode Automatic
If the property Input Help Mode is set to Automatic, the Web Dynpro runtime decides
which input help will be displayed (and if a input help is displayed at all). The
mechanism for determining the input help is similar to the one used to determine the
input help for input fields on classic Dynpro screens. However, the name and type
of input help is determined only once at design time.
Depending on the attribute type, the input help is identified as follows:
1.
2.
3.
4.
5.
If the field of a flat structure defined in the ABAP Dictionary has been used to
type the context attribute, and a search help is related to this structure field,
then this search help will be displayed.
Next, the Web Dynpro runtime checks if a foreign key relationship is defined for
the structure field used to type the context attribute. If this is true, and the check
table is assigned a search help, this search help will be used.
If a foreign key relationship is defined but no search help is assigned to the check
table, then the key fields of the check table are displayed.
Next, the search help related to the underlying data element is displayed.
Finally, fixed values or the fixed value range related to the underlying domain
may be displayed.
If none of the above ways of determining a search help is successful, no input help
is displayed.
Hint: Not only context attributes but also context nodes can be typed with a
Dictionary structure. In this way, the type of multiple context attributes can be
related to fields belonging to the same structure. Only then does a search help
import the input of multiple input fields to build up the value list, and only
then does selecting a value from this list fill more then one input field.
240
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Value Help
Figure 97: Determining the input help for input help mode “Automatic”
If a data element is used to type the context attribute, an input help is only displayed
if fixed values or a fixed value range is assigned to the underlaying domain or if a
simple search help is assigned to the data element.
If a Web Dynpro runtime type is referenced, the fixed values related to this type are
displayed by the input help. If the Web Dynpro runtime types DATA, F, I, OBJECT,
STRING, STRING_TABLE, or XSTRING are referenced, no input help is offered.
Input Help for Input Help Mode Dictionary Search Help
Sometimes, automatic detection of the input help does not lead to the desired result. In
this case, the property Input Help Mode can be set to Dictionary Search Help. This
way, the developer can assign any search help to the context attribute that has one
import parameter and one export parameter.
2009
© 2008 SAP AG. All rights reserved.
241
Unit 7: Value Help, Semantic Help, and Keyboard Access
NET310
Figure 98: Input help for input help mode “Dictionary Search Help”
Value Selectors
A value selector is a value help that allows a user to choose one value or multiple
values from a predefined value set. The user is not allowed to enter values different
from the ones displayed by the value selector. Typical UI elements for implementing
value selectors are drop down boxes, radio button groups and item list boxes. Value
selectors should only be used if the number of values to be displayed is low (typically
fewer than 30).
242
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Value Help
Figure 99: Overview: value selectors
The values displayed by the value selector can be stored in the context, or they can
be related to the type to which the UI element refers.
In the first case, the UI element has to be bound to an attribute that is the child of
a context node of cardinality 0..n or 1..n. Before the view (containing the value
selector) can be rendered, the collection has to be populated. This means all values to
be displayed in the value selector are to be stored in the context as attribute values of
the collection elements. This kind of data binding is called index binding.
2009
© 2008 SAP AG. All rights reserved.
243
Unit 7: Value Help, Semantic Help, and Keyboard Access
NET310
Figure 100: Value selector using index binding
•
•
•
Selecting a value leads to a round trip only if the corresponding event property
is bound to an action.
Selecting a value will change the lead selection.
The data stored in the context will not be changed by selecting any value.
Show demo NET310_HLP_D1. Explain the first part of method WDDOINIT of
the component controller. The context is populated with all carriers beginning with
’A’. The context field VALUE contains the CARRIER, the field TEXT contains
the CARRNAME.
244
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Value Help
The second way of defining a value set displayed by the value selector is to relate the
value set to the type to which the UI element refers. In this case, the UI element has to
be bound to a context attribute, which is typed as follows:
•
The attribute is an ABAP Dictionary type which is based on a domain with
fixed values. The short texts related to the fixed values are displayed by the
value selector.
Hint: Web Dynpro runtime types are special data elements based on a
domain with fixed values.
•
The attribute’s type is arbitrary. The value set is assigned dynamically by
changing the attribute’s meta data at runtime.
This kind of data binding is called key binding.
Figure 101: Value selector using key binding (ABAP DDIC example)
2009
© 2008 SAP AG. All rights reserved.
245
Unit 7: Value Help, Semantic Help, and Keyboard Access
NET310
The following statements apply to this binding type:
•
•
•
Selecting a value leads to a round trip only if the corresponding event property
is bound to an action.
Selecting a value will not change the lead selection.
The data stored in the context element at lead selection will be overwritten by
the key value related to the selected data.
Show demo NET310_HLP_D1. Explain how the value selectors in the first group
in the layout are defined (attributes are related to DDIC). Show domain fixed values
via SE11, too.
Dynamically Assigning Value Sets to Context Attributes
If a value selector is implemented using the key binding technique, the value set can
be defined at runtime. This is done by manipulating the meta data of the attribute
which is bound to the UI element having the value selector. The value set has to
be defined as an internal table with the line type WDR_CONTEXT_ATTR_VALUE.
The reference to the meta data of a context node is determined using the method
get_node_info( ) of the nodes reference. The assignment of the value set to the meta
data of a context attribute is established using the method set_attribute_value_set()
of the reference to the node’s meta data.
246
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Value Help
Figure 102: Value selector: assigning the value set dynamically
Show demo NET310_HLP_D1. Explain the second part of method WDDOINIT of
the component controller. The value set contains all carriers with their carrier names.
If you like, you can also debug and show how the value set is stored in the context.
Exercise “Display allowed Field Values by a Drop Down Box”
2009
© 2008 SAP AG. All rights reserved.
247
Unit 7: Value Help, Semantic Help, and Keyboard Access
248
© 2008 SAP AG. All rights reserved.
NET310
2009
NET310
229
Lesson: Value Help
Exercise 12: Display allowed Field Values by
Drop Down Box
Exercise Duration: 30 Minutes
Exercise Objectives
After completing this exercise, you will be able to:
•
Assign individual value sets to input fields
•
Provide value help as a drop down box
Business Example
You would like to develop a Web Dynpro application offering a value help for each
input field. You will either use search help objects defined in the ABAP Dictionary or
individually defined value sets. In same cases you would like to restrict the user input
to the values offered by a value set. In the case you would like to display the allowed
values as entries of a drop down box (value selector).
Template: NET310_MES_S1
Solution: NET310_HLP_S1
Task 1:
Copy your Web Dynpro component ZNET310_MES_## or the template
NET310_MES_S1 to Web Dynpro component ZNET310_HLP_##. Create a Web
Dynpro application to access your component.
1.
Copy the template.
2.
Create a Web Dynpro application to access your component.
Task 2:
Assign an individual value set to the context attribute FLIGHTINFO.CARRID.
1.
In the component controller, create a new method (name: VS_CARRID).
2.
Make sure the new method is processed during initialization of the component
controller (that is, in method WDDOINIT( ) ).
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
249
Unit 7: Value Help, Semantic Help, and Keyboard Access
NET310
3.
Implement the new method. Obtain a reference to context node FLIGHTINFO,
then call method GET_NODE_INFO( ) to obtain a reference to the node’s meta
data.
4.
Call the static method CL_NET310_FLIGHTMODEL=>READ_CARRIERS_VS( ) to obtain a value set consisting of the key CARRID and the
describing information CARRNAME for all flight carriers. Declare an internal
table of appropriate type and fill this internal table by the static method.
5.
Sort the internal table content by the column TEXT .
6.
Call the method SET_ATTRIBUTE_VALUE_SET( ) to assign the value set to
the node info object.
Task 3:
In the layout of the view INPUT_VIEW, replace the input field related to the carrier
ID with a drop down box.
1.
250
Replace the input field for the carrier ID with a drop down box, that is, an UI
element of type DROPDOWN_BY_KEY. Bind this UI element to the same
context node attribute.
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Value Help
Solution 12: Display allowed Field Values by
Drop Down Box
Task 1:
Copy your Web Dynpro component ZNET310_MES_## or the template
NET310_MES_S1 to Web Dynpro component ZNET310_HLP_##. Create a Web
Dynpro application to access your component.
1.
Copy the template.
a)
2.
Perform this step as in previous exercises.
Create a Web Dynpro application to access your component.
a)
Perform this step as in previous exercises.
Task 2:
Assign an individual value set to the context attribute FLIGHTINFO.CARRID.
1.
In the component controller, create a new method (name: VS_CARRID).
a)
2.
3.
Make sure the new method is processed during initialization of the component
controller (that is, in method WDDOINIT( ) ).
a)
Perform this step as in previous exercises.
b)
Source code see below.
Implement the new method. Obtain a reference to context node FLIGHTINFO,
then call method GET_NODE_INFO( ) to obtain a reference to the node’s meta
data.
a)
4.
Source code see below.
Call the static method CL_NET310_FLIGHTMODEL=>READ_CARRIERS_VS( ) to obtain a value set consisting of the key CARRID and the
describing information CARRNAME for all flight carriers. Declare an internal
table of appropriate type and fill this internal table by the static method.
a)
5.
Perform this step as in previous exercises.
See the source code of the model solution.
Sort the internal table content by the column TEXT .
a)
See the source code of the model solution.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
251
Unit 7: Value Help, Semantic Help, and Keyboard Access
6.
NET310
Call the method SET_ATTRIBUTE_VALUE_SET( ) to assign the value set to
the node info object.
a)
See the source code of the model solution.
Task 3:
In the layout of the view INPUT_VIEW, replace the input field related to the carrier
ID with a drop down box.
1.
Replace the input field for the carrier ID with a drop down box, that is, an UI
element of type DROPDOWN_BY_KEY. Bind this UI element to the same
context node attribute.
a)
Delete the input field related to the carrier ID.
b)
From the context menu of the superordinate transparent container
choose the item Insert Element. Enter any ID and select Type =
DROPDOWN_BY_KEY. Confirm your entry.
c)
Drag the drop down box and drop it below the label to be displayed left of
the drop down box.
d)
Bind the property selectedKey of the drop down box to the context attribute
FLIGHTINFO.CARRID.
e)
Assign the label to the drop down box by setting the label’s property
labelFor to the ID of the drop down box.
Result
Comp.
Controller, Method VS_CARRID
METHOD vs_carrid .
DATA lo_nd_flightinfo
TYPE REF TO if_wd_context_node.
DATA lo_nd_info_flightinfo TYPE REF TO if_wd_context_node_info.
DATA lt_value_set
TYPE
wdr_context_attr_value_list.
* get node info for node FLIGHTINFO
lo_nd_flightinfo
= wd_context->get_child_node(
name = wd_this->wdctx_flightinfo ).
lo_nd_info_flightinfo = lo_nd_flightinfo->get_node_info( ).
Continued on next page
252
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Value Help
* get value set (VALUE = CARRID , TEXT = CARRNAME)
lt_value_set = cl_net310_flightmodel=>read_carriers_vs( ).
* sort the value set by the describing TEXT
SORT lt_value_set BY text.
* assign value set to context attribute
lo_nd_info_flightinfo->set_attribute_value_set(
name
= ’CARRID’
value_set = lt_value_set ).
ENDMETHOD.
Comp.
Controller, Method WDDOINIT
METHOD wddoinit .
* Create Value Selector for Planetype
wd_this->vs_carrid( ).
ENDMETHOD.
2009
© 2008 SAP AG. All rights reserved.
253
Unit 7: Value Help, Semantic Help, and Keyboard Access
NET310
Lesson Summary
You should now be able to:
•
Implement value help bound to drop down boxes, radio buttons or list boxes
(value selectors).
•
Implement value help bound to input fields (input help).
•
Define the values displayed by value help both statically and dynamically.
254
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson:
235
Lesson: Semantic Help
Semantic Help
Lesson Duration: 30 Minutes
Lesson Overview
Different possibilities for displaying help texts do exist for ABAP Web Dynpro.
Help texts can be related to UI elements. Tool tips are well-known here. This kind
of semantic help can be used to display a short help text when the user moves the
cursor over the related UI element. Explanation texts can be used to display a longer
information text directly below the related field. Finally, the standard Dictionary F1
help can also be used in the ABAP Web Dynpro context.
If a general help not related to a certain UI element has to be displayed, the
Explanation UI element can be used. In addition, a document defined in the
knowledge warehouse can be loaded and displayed in the so-called Help Center.
Lesson Objectives
After completing this lesson, you will be able to:
•
•
•
Define tool tips and short explanations related to a certain UI element.
Define explanation texts not related to a certain UI element.
Use the help center.
Take a look at the demo NET310_HLP_D4 assigned to package NET310. All other
instructor comments in this lesson refer to this Web Dynpro component.
Business Example
You have to change your application so that help texts related to certain UI element
can be displayed. In addition, a general help for your application should be available
on request.
Field-Dependent Help Texts
There are several techniques to relate a help text to a given UI element:
•
•
•
2009
Tool tips
Explanation texts
Standard Dictionary F1 help
© 2008 SAP AG. All rights reserved.
255
Unit 7: Value Help, Semantic Help, and Keyboard Access
NET310
Tool Tips
On view INPUT_VIEW, tool tips are assigned to the group, to the group header, to the
CARRID label, to the CARRID input field, to the CONNID input field, and to the
ROOTUIELEMENTCONTAINER. The tooltip property is not inherited. Thus, button
and image have no tooltip. However, the CONNID label displays a tooltip. This text
originates from the data element related to the input field CARRID.
Figure 103: Defining and displaying tool tips
Tool tips allow a short text (maximum length: 255) to be displayed in a yellow box.
This box appears if the mouse cursor is moved onto the field to which the tool tip is
assigned. If the mouse cursor is moved out of the area occupied by the field, the
tool tip vanishes.
The tool tip can be assigned to a UI element by setting the property tooltip accordingly.
The text can either be typed in the property field, can originate from an alias text
defined in the Online Text Repository (OTR), can be the content of a context attribute,
or it can be one of the texts related to a data element.
256
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Semantic Help
If no tool tip is assigned to a label explicitly, the Web Dynpro runtime checks if the
related form field is typed with a data element. In this case, the field label (long text)
of this data element is displayed as the labels tool tip.
Explanation Texts
On view INPUT_VIEW, explanation texts are assigned to the CONNID input field.
Display the binding and show how to switch the explanation text on and off (right
mouse button menu). Move the mouse cursor to the green link related to the CONNID
label to display the explanation text.
Figure 104: Creating an explanation text
An explanation text defined for a form field is displayed if the user moves the mouse
cursor to the label related to that UI element. If an explanation text is assigned to a UI
element, then the related label is underlined in green.
The explanation text can be assigned to a UI element by setting the property
explanation accordingly. The text (maximum length: 255) can either be typed in
the property field, or it can originate from an alias text defined in the Online Text
Repository (OTR).
2009
© 2008 SAP AG. All rights reserved.
257
Unit 7: Value Help, Semantic Help, and Keyboard Access
NET310
If the primary property of a UI element (e.g. value propery of InputField) is bound to
a context attribute, then the text can also originate from the data element related to this
context attribute. The developer can decide if the short text stored in the data element,
the content of the key block &DEFINITION&, or the content of the key block &USE&
is to be displayed (these key blocks are taken from the data element documentation).
Figure 105: Switching explanation texts on and off
The explanation text display can be switched on and off from within the context menu
that appears when the user clicks anywhere on the screen.
The explanation property can be set for the following UI elements:
TableColumn, Button, CheckBox, DropDownByIndex, DropDownByKey,
FileUpload, InputField, ItemListBox, RadioButton, TextEdit, TriStateCheckBox .
258
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Semantic Help
Classic F1 Help
Keep in mind, that the classical F1 Help in Web Dynpro is being used by pressing
CTRL + F1! Pressing F1 opens the Help Center. It is probably better to use the
right mouse button menu here ...
On view INPUT_VIEW, the input fields values are related to attributes that are typed
with ABAP Dictionary data elements. Thus, for both fields the F1 help will bring up
the semantic help. For all other fields, only technical information is displayed.
Switch off the F1 help for the CARRID input field. For this case, a second WD
application (ending with “...NO_EXPL”) has been created. Display the parameter list
of this application. Start and show F1 help for both input fields. For the CONNID
field the semantic help is still displayed, since an explanation text from the ABAP
Dictionary is assigned.
Figure 106: Displaying the classic F1 Help
By default, the classic F1 help derived from the data element’s documentation is
available for all UI elements whose primary property is bound to a context attribute
that is typed accordingly.
2009
© 2008 SAP AG. All rights reserved.
259
Unit 7: Value Help, Semantic Help, and Keyboard Access
NET310
To display the F1 help, the cursor has to be placed in the field and the key combination
CTRL + F1 has to be pressed. Another way of displaying the F1 help is to right-click
in the field and choose More Field Help from the context menu.
The data element documentation is displayed in the modal dialog box which pops up.
In addition, a link allows you to navigate to the technical information of the field. If
no data element documentation is available, the technical information related to the
field is displayed directly.
The data element documentation can be suppressed by adding the parameter
WDHIDEMOREFIELDHELPASDEFAULT (value = X) to the application
parameters. In this case, only the technical field information is displayed as F1 help.
However, this behavior can be changed for single fields as follows: If an explanation
text is assigned to the field and this explanation text originates from the ABAP
Dictionary, then the F1 help works (for this field) as if the application parameter
WDHIDEMOREFIELDHELPASDEFAULT was set to space (default).
Field-Independent Help Texts
To display one help text for multiple fields, or to display help information
independently of the field, two techniques exist:
•
•
Display text by Explanation UI element
Display knowledge warehouse (KW) documents in the Help Center
Using the Explanation UI Element
An Explanation UI element is located on the view INPUT_VIEW. The
document displayed by this element has been created using the function module
DOCU_CREATE with the editor switched to SAPScript editor. The source code to
load the object and to convert the object in a displayable text can be found in method
wddomodifyview(). The source code is written in such a way that the English version
of the document is loaded if it is not available in the logon language.
Switch the explanation text on/off.
260
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Semantic Help
Figure 107: Displaying long texts by EXPLANATION UI element
The UI element Explanation can be used to display a text that appears on the screen
permanently and should contain explanations about the screen or parts of the screen.
The text to be displayed can be provided as follows:
Using the property text, a statical text can be assigned. Using the value help for this
property field, the text (alias text) can also be loaded from the OTR. However, binding
this property to a context attribute is not possible. In addition, the text cannot be
read from an ABAP Dictionary data element, either. Thus, if texts are assigned to
the Explanation UI element as described above, the maximum length of these texts
is restricted to 255 characters.
2009
© 2008 SAP AG. All rights reserved.
261
Unit 7: Value Help, Semantic Help, and Keyboard Access
NET310
Figure 108: Assigning texts or documents to EXPLANATION UI element
There are different ways of assigning longer texts to the Explanation UI element. If the
support package level of the SAP NetWeaver AS 7.0 < 11, the text to be displayed can
be loaded in a controller method and stored in a corresponding variable. The value of
this variable can then be assigned to the property text of the UI element dynamically.
This has to be done in the hook method wddomodifyview( ) of the view containing the
Explanation UI element. This procedure is not only restricted to simple text literals.
The text to be displayed can also be a documentation object. This can be loaded by
calling the function module DOCU_GET. The name of the document, the language,
and the object id (TX) have to be submitted to the function module. This method
returns the documentation object and meta-information about the object. This data
can be passed to the statical method cl_wd_formatted_text=>create_from_sapscript(
) in order to create an object containing the text to be passed to the Explanation UI
element (attribute M_XML_TEXT of created object).
262
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Semantic Help
Figure 109: Assigning document name to property TEXTDOCUMENTNAME
If you want to create or change a document to be displayed by the Explanation UI
element, you can call the function module DOCU_CREATE. Choose General Class
when being asked for the documentation class and switch to the SAPScript editor to
maintain the document content.
For systems based an SAP NW 7.0 EhP1 or for SAP NW 7.0 having at least imported
SAP_ABA SPS>14, the Explanation UI element allows you to assign the name of the
document to be displayed via the property textDocumentName. This name can be
entered directly in the property field or it can be selected using the help dialog that
appears when the value help button related to the property field is pressed.
There are two ways to hide the explanation at runtime. The explanation text display
can be switched on and off from within the context menu that appears when the user
clicks anywhere on the screen. If the property design of the Explanation UI element is
set to emphasized, an additional link appears right of the element’s text. Pressing this
link will also make the text disappear.
2009
© 2008 SAP AG. All rights reserved.
263
Unit 7: Value Help, Semantic Help, and Keyboard Access
NET310
Displaying KW Documents in the Help Center
It is not clear if this works in the training environment. First, the RFC destination
has to be created. Next, to log on to the KW, a user has to be assigned to the RFC
destination. This user has to have the appropriate authorization to view the desired
object in KW. The object has to be stored in the correct context and it has to have the
correct state (released). At least the “How to” guide is provided here...
Documents created in the Knowledge Warehouse can be assigned to a Web Dynpro
application or to a window as the object’s help text (info object). To do this, the
following steps are necessary:
•
•
•
First the Properties tab of the application or of the window has to be edited.
Here, two fields with the labels Help Menu Text and Help Link can be found.
In the field with the label Help Menu Text, a text can be entered that will be
displayed as the title of the help window.
In the field with the label Help Link, the link to the info object in the Knowledge
Warehouse system has to be specified using the icon right of the input field
(Create/Change Link).
Hint: To do this, you need to define the RFC connection
AIO_FOR_HELP_LINKS for your Knowledge Warehouse system.
The first step of selecting a KW info object is to define the context (language, release,
and enhancement) appropriate for the productive system. On the next screen, the
correct area (for instance documentation or training) has to be chosen. On the third
screen, the object has to be specified by defining selections (e.g. for the technical
name, the title, the developer ...). Finally, all corresponding objects are displayed.
Double clicking on a list entry will close the dialog, and the link to the selected info
object will be entered in the field with the label Help Link.
At runtime, the info object can be called by choosing F1 or the help button in the
title bar. The help center opens in a new browser window and the info object for the
respective application or window is displayed. The explanation for the quick help, the
Knowledge Warehouse documentation, links to the SAP Library, and links defined for
the application windows are contained in the help center. The help center can also be
opened as a result of a user action. In this case, the appropriate source code can be put
in an action-handler method that is triggered by the client side event. It is also possible
to replace the statically assigned info object by another object by typing source code.
For details, please refer to the online documentation.
264
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Semantic Help
Facilitated Discussion
Discuss any open questions.
Discussion Questions
Use the following questions to engage the participants in the discussion. Feel free to
use your own additional questions.
If you like, you can let the customers create some tool tips and some explanation texts
related to UI elements. It is also a nice idea to let the students create a documentation
object and have this document then be displayed by an Explanation UI element.
2009
© 2008 SAP AG. All rights reserved.
265
Unit 7: Value Help, Semantic Help, and Keyboard Access
NET310
Lesson Summary
You should now be able to:
•
Define tool tips and short explanations related to a certain UI element.
•
Define explanation texts not related to a certain UI element.
•
Use the help center.
266
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson:
245
Lesson: Keyboard Access
Keyboard Access
Lesson Duration: 15 Minutes
Lesson Overview
Web Dynpro UIs can be accessed not only by left mouse-clicking on an element,
but also by using keyboard commands. This lesson sums up all concepts related
to this topic.
Lesson Objectives
After completing this lesson, you will be able to:
•
•
•
•
Access UI elements using keyboard commands
Define default buttons bound to container UI elements
Define and use hotkeys
Use access keys
This is a new lesson. Hotkeys and access keys require that LIGHTSPEED rendering is
not switched off. Please refer to demo NET310_KES_D1.
Business Example
You would like to enhance your Web Dynpro application in a way, that accessing the
UI elements displayed by the browser is not only possible via left mouse-clicking the
element or parts of the element, but also via keyboard commands.
Overview
Web Dynpro ABAP offers a variety of possibilities to use keyboard commands to
access UI elements displayed to the user. For each UI element, SAP has defined
keyboard commands to navigate between the parts of this element (e.g. move from
cell to cells in a Table, page in a TabStrip, or move from radio button to radio button in
a RadioButtonGroupByKey). Other keyboard commands exist to navigate between
the elements in the UI. The corresponding keyboard commands are well documented
and can be found in the online help searching for the term “Keyboard Access for
UI Elements in Web Dynpro”.
2009
© 2008 SAP AG. All rights reserved.
267
Unit 7: Value Help, Semantic Help, and Keyboard Access
NET310
Example: You can use the Tab key to move the focus rectangle forwards to the Button
UI element. Once the focus is on the Button element, you can trigger the associated
function by pressing the Enter key or the Space key. You can use the key combination
Shift + Tab to move the focus rectangle backwards from the Button element.
In addition to these keyboard commands provided out of the box, the application
developer has additional possibility to make UI elements accessible without the need
to left-mouse click the element:
•
•
•
To each container UI element, a default button (being a child of the container
element) can be assigned.
Events of certain UI elements can be triggered using hotkeys.
The focus can be set to certain UI elements using access keys.
Default buttons
In the demo NET310_KEY_D1, the button on the first view is defined as the default
button for the superordinate container. In addition, an action is assigned to the event
Enter of the CONNID field (property onEnter).
All container UI elements (ScrollContainer, TransparentContainer, Group, and Tray)
contain the property defaultButtonId. This allows to define which of the buttons
defined as subelements of this container serves as the default button.
If the user clicks on any element located in the container, the container’s default button
will be highlighted. Pressing Enter on the keyboard will then fire the client-side
event onAction related to the default button. Thus, clicking the button and pressing
Enter are functionally identical.
Caution: Form fields may offer client-side events that can also be triggered
by pressing Enter on the keyboard. If an action is assigned to such an event
and the form field has the focus, then pressing Enter will not fire the button
event’s event but the event of the form field.
Caution: In a transparent container, the property isLayoutContainer has
to be set to ABAP_FALSE before a default button can be assigned to this
container element.
Hint: For the Tray UI element, the default button must be defined in the
tray’s toolbar.
268
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Keyboard Access
Hotkeys
In the demo, a hotkey has been assigned to the default button.
A hotkey is a combination of keyboard keys that is assigned to a UI element via the
property hotkey. If the user triggers this keyboard command, the UI element’s only
client-side event is fired. Thus, using the hotkey and left mouse-clicking on the UI
element are functionally identical.
Hotkeys may be assigned to the following UI elements:
•
•
•
Buttons (Button and ToolBarButton)
Links (LinkToAction, LinkToURL, ToolBarLinkToAction, and
ToolBarLinkToURL)
Menu items (MenuActionItem)
The following key combinations may serve as hotkeys:
•
•
•
•
CTRL + 1 ... CTRL + 9
CTRL + F1 ... CTRL + F12
CTRL + A ... CTRL + Z
CTRL + SHIFT + F1 ... CTRL + SHIFT + F12
Caution: Note that additional browser programs such as HTTPWatch in
Internet Explorer can also use and, perhaps, block hotkeys. This depends on
the Web Dynpro ABAP framework control. If you use the SAP NetWeaver
Business Client, this problem is not relevant.
Visualization: If a hotkey is assigned to a UI element, the hotkey is automatically
appended to the element’s tool tip. If a hotkey is assigned to a MenuActionItem UI
element, the hotkey is automatically added to the item’s text.
Hotkey handlers: All container elements and the Table UI element can serve as
hotkey handlers by setting the container’s property handleHotkeys to ABAP_TRUE. In
this case, all hotkeys defined in the hotkey handler can only be triggered if the focus
is on any element that is a subelement of the hotkey handler. If the focus is on any
other UI element (outside the area defined by hotkey handler), pressing the same
hotkey combination triggers no action or triggers an action that belongs to another UI
element. By default, the entire pane is a hotkey handler.
2009
© 2008 SAP AG. All rights reserved.
269
Unit 7: Value Help, Semantic Help, and Keyboard Access
NET310
Using hotkey handlers is meaningful if one hotkey is used multiple times on the
UI. This may happen if multiple views are combined to view assemblies. Thus, the
ROOTUIELEMENTCONTAINER may also serve as a hotkey handler.
Caution: A hotkey can only be assigned once within a hotkey handler. If it is
defined more than once, the hotkey is completed deleted.
Hint: If handleHotKey is not set (ABAP_FALSE), the hotkey can be triggered
throughout the entire page. However, the focus must be in the browser page to
enable global hotkeys to be triggered.
Access Keys
Access keys are keys or key combinations that allow to set the focus directly on a UI
element without triggering any client-side event. An access key is defined as follows:
•
•
An access key is always a combination of ALT and one additional character.
This character may be any first character of a text, caption, or label related to a
UI element that can be accessed this way.
The following UI elements may get the focus by using the appropriate access key:
•
•
•
•
•
•
•
•
•
•
•
•
•
270
Buttons (Button, ToggleButton) - button text
Drop down boxes (DropDownByKey, DropDownByIndex) - label
Inputfield - label
Check boxes (CheckBox, CheckBoxGroup, TriStateCheckBox) - each check
box or (if existent) label
FileUpload - label
Group - caption
ItemListBox - label
Links (LinkToAction, LinkToURL, ToggleLink, ToolBarLinkChoice - link or
(if existent) label
Radio buttons (RadioButton, ReadioButtonGroupByKey, RadioButtonGroupByIndex - each radio button or (if existent) label
Table - caption
TabStrip - each tab’s caption
TextEdit - label
Tray - caption
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Keyboard Access
Visualization: If the user presses the key ALT, the first character of all texts related to
accessible UI elements are underlined.
Hint: Access keys can be activated or deactivated using personalization.
Caution: The key combination ALT + D is an exception - it does not work
in Internet Explorer. The Web Dynpro framework automatically assigns an
alternative key combination.
2009
© 2008 SAP AG. All rights reserved.
271
Unit 7: Value Help, Semantic Help, and Keyboard Access
NET310
Facilitated Discussion
Discuss on open questions.
Discussion Questions
Use the following questions to engage the participants in the discussion. Feel free to
use your own additional questions.
Do you want to define the button on the first view of your application as the default
button?
Do you want to assign a hotkey to this button?
Want to test access keys?
272
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Keyboard Access
Lesson Summary
You
•
•
•
•
2009
should now be able to:
Access UI elements using keyboard commands
Define default buttons bound to container UI elements
Define and use hotkeys
Use access keys
© 2008 SAP AG. All rights reserved.
273
Unit Summary
NET310
Unit Summary
You should now be able to:
•
Implement value help bound to drop down boxes, radio buttons or list boxes
(value selectors).
•
Implement value help bound to input fields (input help).
•
Define the values displayed by value help both statically and dynamically.
•
Define tool tips and short explanations related to a certain UI element.
•
Define explanation texts not related to a certain UI element.
•
Use the help center.
•
Access UI elements using keyboard commands
•
Define default buttons bound to container UI elements
•
Define and use hotkeys
•
Use access keys
274
© 2008 SAP AG. All rights reserved.
2009
Unit 8
Component Reuse
253
Please take a look at the demos stored in the NET310 package. Corresponding demos
are available for all kinds of component reuse (component instantiation, calling
method, event handling, ofusing plugs for data exchange, context mapping). Further
information can be found in this unit.
Advanced topics (visual recognition of component interfaces, using multiple instances
of the same component, using an unknown number of components with the same
interface, defining navigation dynamically, defining event handling dynamically, and
so on) are not discussed here, but in course NET311.
Unit Overview
Modularization is the breaking down of a program into individual, reusable parts. This
unit explains how the visual interface and the programmatic interface of a component
can be reused from other components.
Unit Objectives
After completing this unit, you will be able to:
•
•
•
•
•
•
Define methods, events, and context nodes in a component interface controller.
Define which plugs of a window are visible in the interface view.
Declare the usage of a component in another component.
Call methods and subscribe to events defined in a used component.
Interchange data between components.
Instantiate and delete a component usage at runtime.
Unit Contents
Lesson: Component Reuse ....................................................... 276
Exercise 13: Component Reuse.............................................. 293
2009
© 2008 SAP AG. All rights reserved.
275
Unit 8: Component Reuse
Lesson:
254
NET310
Component Reuse
Lesson Duration: 120 Minutes
Lesson Overview
The Web Dynpro component encapsulates visual and programmatic Web Dynpro
entities so that they can be reused from other components. The components can
offer reusable functionality in multiple ways: For each window, a visual interface is
generated, allowing you to embed this visual entity in a window of another component.
Methods and events can be exposed in the component’s interface controller. Finally,
the context can be mapped between the interface controller of a component usage and
a controller of the consumer component.
Lesson Objectives
After completing this lesson, you will be able to:
•
•
•
•
•
•
Define methods, events, and context nodes in a component interface controller.
Define which plugs of a window are visible in the interface view.
Declare the usage of a component in another component.
Call methods and subscribe to events defined in a used component.
Interchange data between components.
Instantiate and delete a component usage at runtime.
Data can be exchanged between components in several ways. The easiest way is
discussed in detail: context mapping. However, it is also possible to pass data
via the parameters of an interface plug, via the parameters of a method defined in
the interface controller or via the parameters of an event defined in the interface
controller. Be prepared for a discussion about which of these concepts should be used
for interchanging data.
Business Example
You have to create Web Dynpro functionality that is needed in different contexts. You
want to define it in a way that allows you to reuse this functionality. You know that
Web Dynpro components are the entities that should be used to encapsulate Web
Dynpro functionality in such a way that other Web Dynpro components can reuse it.
However, you do not know what has to be done to combine components. You also
have no idea how functionality can be exposed by one component and reused by
another component. You want to learn more about combining components.
276
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Component Reuse
Web Dynpro Component Usage: Overview
Usually, real business applications based on the Web Dynpro programming model
consist of several Web Dynpro components. This is because some functionality
is needed in more than one application (for example, customer address display or
order details display) or because some functionality is provided by the Web Dynpro
framework by means of generic Web Dynpro components (WDR_OVS for defining
a search help, WDR_MESSAGE_AREA to display messages, SALV_WD_TABLE
for displaying mass data in the SAP List Viewer, or WDR_SELECT_OPTIONS for
defining select options in Web Dynpro).
Figure 110: Web Dynpro component usage (1)
As an example for this scenario, start the solution for this lesson.
Another common scenario is that multiple components may be embedded in a
consumer component. Thus, at design time, the developer has to prepare the
application to reuse each of the possible subcomponents. However, at runtime the user
2009
© 2008 SAP AG. All rights reserved.
277
Unit 8: Component Reuse
NET310
decides (for example by pressing a link) which one of the potential subcomponents
will be embedded. By this technique, multiple dependent pieces of information may
be displayed in a consumer component’s view, depending on the user’s choice.
Figure 111: Web Dynpro component usage (2)
Component Interface
External access to the functionality of a component is provided by the interface
controller and by the interface views. Each component has exactly one interface
controller and an arbitrary number of interface views. Components without any visual
interface are called faceless components.
The interface controller may contain ordinary methods, events, and context nodes
defined in the component controller.
In order to expose ordinary methods and events to the interface controller, the
developer has to mark the corresponding check box in the Interface column.
278
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Component Reuse
In order to expose context nodes defined in the component controller to the interface
controller, the check box related to the node’s InterfaceNode property must be
selected. If the check box for property Input Element (Ext.) is also selected, the node
has to be mapped to a node defined in a controller of a consumer component.
Hint: If a context node is exposed to the component’s interface, all of its
subnodes are also exposed to the component’s interface.
For each window defined in a component, an interface view is generated. Each
window can contain inbound plugs and outbound plugs that may be exposed to the
interface view.
Figure 112: Component interface
First step: Show demo NET310_COMP_D1. This component will act as a
subcomponent with respect to NET310_COMP_D2.
Second step: Create your own component and add all entities that could be located in
the component interface. Add these constituents to the component interface.
2009
© 2008 SAP AG. All rights reserved.
279
Unit 8: Component Reuse
NET310
Context nodes: Define two nodes in the component interface. One node (N1) should
be typed and have some attributes. For this node, do NOT mark the property Input
Element (Ext.). Define a second context node (N2) having the property Input Element
(Ext.) checked. This node should have no attributes and the node should not be typed
(like the node DATA of the ALV component).
Exercise “Component Reuse”, steps 1, 2, and 3
After having finished the first three steps of the exercise, you could discuss how to
test this component. For testing you have to define an application. When starting the
application, you will see an empty form. To display data, the interface method has to
be called. This can be done in any WDDOINIT( ) method supplying a valid customer
number. However, this is a nice possibility to introduce window plug parameters:
Define an importing parameter (name NO, type STRING) in the event handler method
for the window’s DEFAULT plug. This parameter will be used to import the customer
number in a query string appended to the application URL (<URL>?NO=00000001).
Next edit the application. On the parameters list use the drop down box to select the
parameter NO. Assign a default value.
Finally implement the default plug event handler method: Call the interface controller
method and pass the customer number to the importing parameter of this method. The
interface controller has to be declared as a used controller for the window controller.
Component Usage
The following section explains how the functionality of one component can be used
by another component.
Declaring a Component Usage
If one component (consumer component) needs to access the functionality of another
component (used component), it has to declare the usage of this component. This is
done on the Used Components tab of the consumer component. The name entered in
the Component Use column will be a fragment of method names that will be used at
runtime to access the functionality of the component usage (which is an instance of
the used component) from any controller of the consumer component.
280
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Component Reuse
Figure 113: Declaring a component usage
Step 1: Show demo NET310_COMP_D2, tab PROPERTIES.
Step 2: Create a second component. This component will serve as the consumer
component. Define a node (N3) in the component controller. This node will be
mapped later on by node N1 of the used component. In addition, create a view
containing a view container. Embed the view in the window. Now, define the usage of
the component you created before. Show every change in the consumer component.
Instantiating and Deleting a Component Usage
Declaring the usage of a component does not imply that this component usage is
instantiated automatically. This happens only in special cases not discussed here. In
general, the component usage has to be instantiated from the source code of any
controller belonging to the consumer component.
To instantiate, delete, or clone a component usage, a proxy object has to be used
which is provided by the Web Dynpro runtime. For each component usage, a separate
proxy object is created by the Web Dynpro runtime. The reference to the proxy object
related to a component usage with name <comp_usage> can be obtained from the
variable wd_this by calling the method wd_cpuse_<comp_usage>( ). The proxy
2009
© 2008 SAP AG. All rights reserved.
281
Unit 8: Component Reuse
NET310
object contains the method has_active_component( ). This method can be called
to find out if the component usage has already been instantiated. To instantiate the
component usage, call method create_component( ).
Hint: The Web Dynpro Code Wizard can be used to generate the coding
necessary to instantiate a component usage.
By default, the component usage instance lives as long as the consumer component
lives. However, it is also possible to delete the component usage instance explicitly by
calling the method delete_component( ) of the related proxy object.
Your consumer component: Instantiate the component usage in the component
controller WDDIONIT. Use the WD Code Wizard.
Demo NET310_COMP_D2: Start application and use buttons to trigger plug. This
will embed the interface view of the component usage. Data is passed via the plug
parameters. Then use the button to call a method. Data is passed via the method’s
interface parameters. Now, restart the application. Call the interface method of the
component usage before the interface view has been embedded. This will dump the
application -> this is because the component usage has not been instantiated yet.
Restart again and use the button to instantiate the component usage. Then, call the
method.
282
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Component Reuse
Figure 114: Instantiating and deleting a component usage
The source code displayed above may be defined in any controller method in the
consumer component.
Hint: The controller instantiating the component usage needs to declare
the usage of the component usage.
Interface Views
The interface view is the standardized mechanism by which all view assemblies can
be presented through the generic Web Dynpro framework. By means of the interface
view, a component’s visual interface becomes a reusable unit, thus allowing you to
embed it into a window defined in a consumer component.
The inbound plugs of the interface view can be connected to the outbound plugs
of views or a window defined in the consumer component. This allows you to
embed different interface views depending on the outbound plug triggered in the
consumer component. Information can be passed to the used component via the
plug’s parameters.
2009
© 2008 SAP AG. All rights reserved.
283
Unit 8: Component Reuse
NET310
The outbound plugs of the interface view can be connected to inbound plug of views
or the embedding window defined in the consumer component. Using the plug’s
parameters, the used component can hand back data to the consumer component (for
example, information about the view assembly displayed by the interface view when
leaving the used component).
Demo NET310_COMP_D2. Show how the interface view of a component usage
is embedded.
Your consumer component: Embed interface view of component usage.
Figure 115: Embed windows defined in other components
Interface Controller Methods
Methods defined in the interface controller of a component usage can be called from
any controller of the consumer component. However, before the interface method can
be called, the interface controller of the component usage must be declared as
a used controller.
284
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Component Reuse
Since the method is defined in the interface of the component usage, the controller in
the consumer component has to determine the reference to this interface controller to
be able to call the method. This reference can be obtained from the variable wd_this
by calling the method wd_cpifc_<used_component>( ).
Hint: The Web Dynpro Code Wizard can be used to generate the code
necessary to call an interface controller method of a component usage.
Your consumer component: Call method of interface controller from any controller.
Use code wizard. Do not forget to declare the usage of the interface controller on the
Properties tab of the controller containing the method call.
Figure 116: Calling interface controller methods
2009
© 2008 SAP AG. All rights reserved.
285
Unit 8: Component Reuse
NET310
Interface Controller Events
Methods defined in any controller of the consumer component can subscribe to events
that are defined in the interface controller of a component usage. However, to be
able to define the event handling, the interface controller of the component usage
must be declared as a used controller.
The component usage can pass information to the consumer component using the
event parameters.
Example: This concept is used for implementing the Object Value Selector (OVS).
Here, the OVS component usage raises an event every time information is needed
from the consumer component. A method in a controller of the consumer component
has to subscribe for this event. Event parameters are used to inform the consumer
component about what kind of information is needed. Finally, the information is
passed back to the OVS component usage by calling interface controller methods.
Your consumer component: Create a method in any controller. Subscribe to the event
in the interface controller of the component usage. Do not forget: The controller
containing the event handler method has to declare the usage of the component
usage’s interface controller.
286
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Component Reuse
Figure 117: Interface controller events
2009
© 2008 SAP AG. All rights reserved.
287
Unit 8: Component Reuse
NET310
Figure 118: Subscribe to interface controller events
Exercise “Component Reuse”, tasks 4
Cross-Component Context Mapping
There are two ways to map context structures defined in different components:
•
•
288
The mapping origin is defined in the interface controller of the component usage
(direct context mapping).
The mapping origin is defined in a component controller or in a custom controller
of the consumer component (external context mapping).
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Component Reuse
Direct context mapping is typically used if the component usage provides data needed
in the consumer component. External context mapping is used if the component usage
needs information from the consumer component to perform its task.
Hint: When using direct context mapping, the lifetime of the component
usage is important. Deleting this instance means that the mapping origin
will no longer be available.
To establish direct context mapping, a controller of the consumer component needs
to access a context node defined in the interface controller of the component usage.
Thus, the usage of the component usage’s interface controller has to be added to
the list of used controllers. This is defined on the Properties tab of the consumer
component’s controller.
Your consumer component: Edit component controller. Declare usage of the
component usage’s interface controller. Edit context. Drag and drop a context node
N1 from the interface controller of the component usage to the component controller
of the consumer component. This will copy the structure and map the nodes.
Figure 119: Cross-component context mapping
2009
© 2008 SAP AG. All rights reserved.
289
Unit 8: Component Reuse
NET310
To establish external context mapping, the interface controller of the component usage
needs to access the context of a consumer component’s controller. Thus, the interface
controller of the component usage has to declare the usage of the controller in the
consumer component. This is a bit more complicated, since an interface controller
usage is not defined automatically when declaring a component usage. The single
steps of defining external context mapping are:
•
•
•
•
•
•
In the used component’s component controller, edit the properties of the context
node which should be used as the mapping target. Select the check boxes for the
Interface Node and Input Element (ext.) properties.
Define a component usage for this component in the consumer component.
Create an interface controller usage for the component usage. This is done from
the context menu in the navigation tree of the consumer component.
Double-click the interface controller usage. In the object window, the interface
controller usage can be edited.
On the Properties tab of the interface controller usage, add the controller of
the consumer component containing the mapping origin to the list of used
controllers.
On the Context tab, the mapping can now be established. Drag the target node
from the context of the interface controller usage and drop it on the node acting
as the mapping origin (from left to right).
Your consumer component. Edit the interface controller usage of the component
usage. Declare the component controller of the consumer component as a used
controller. Drag and drop the interface controller node N2 (with the property Input
Element (Ext.) checked) to the corresponding node N3 of the consumer component’s
component controller.
Dynamic Component Usage
In complex Web Dynpro applications, it is often desirable to embed interface views
of other Web Dynpro components, depending on the user’s choice at runtime. For
the developer, this means that it is not known at design time which one of multiple
possible subcomponents will be used at runtime.
Programming is significantly simplified if all components that may be used at runtime
offer the same component interface. In that case, the consumer component can pass
information via well-known interface parameters of well-known methods, or methods
defined in the consumer component can register for well-known events defined in any
used component.
290
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Component Reuse
To ensure that all used components implement the same interface, Web Dynpro
component interfaces can be created as independent development objects. A Web
Dynpro component interface consists of methods, events and a context. Interface
views can be added if desired.
Each Web Dynpro component can implement an arbitrary number of Web Dynpro
component interfaces as follows:
•
•
The names of the component interfaces to be implemented have to be added to
the component using the Implemented Interfaces tab.
On the same tab, the Reimplement button has to be pressed for each component
interface. This will embed the component interface in the local component
controller interface.
Caution: Deleting the Web Dynpro component interface from the list of
implemented interfaces will not delete the interface entities (methods, events,
context and interface views) from the component controller.
Caution: Web Dynpro component interfaces and Web Dynpro components
use the same name space.
Caution: Methods, events and the context defined in the Web Dynpro
interface are not automatically added to the interface controller of the
implementing component. For each of these constituents, the Interface flag
has to be set manually.
Package NET310 contains a component Interface (NET310_COMP_D3). You may
implement this component by your used component. Demo NET310_COMP_D4
already implemented this component interface.
2009
© 2008 SAP AG. All rights reserved.
291
Unit 8: Component Reuse
NET310
Figure 120: Dynamic component usage
292
© 2008 SAP AG. All rights reserved.
2009
NET310
267
Lesson: Component Reuse
Exercise 13: Component Reuse
Exercise Duration: 70 Minutes
Exercise Objectives
After completing this exercise, you will be able to:
•
Expose functionality of a Web Dynpro component to other components
•
Declare the usage of one component by another component
•
Call methods defined in the interface controller of a used component
•
Embed an interface view of a component usage in a view container of the
consumer component
Business Example
While developing your Web Dynpro component, you find out that parts of the
functionality have already been developed in another Web Dynpro component. This
comprises the controller source code and also the related layout (for example, reading
and displaying details for a given flight passenger). Thus, you want to reuse the
component’s functionality from within your Web Dynpro component.
Template: NET310_HLP_S1
Solution: NET310_COMP_S1 (consumer component)
Solution: NET310_COMP_S2 (used component – created from scratch)
Task 1:
Copy your Web Dynpro component ZNET310_HLP_## or the template
NET310_HLP_S1 to Web Dynpro component ZNET310_COMP1_##. This
component will act as the consumer component. Define a new Web Dynpro
application to access this component.
1.
Copy the template, activate your component, and create a Web Dynpro
application.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
293
Unit 8: Component Reuse
NET310
Task 2:
Create the new Web Dynpro component ZNET310_COMP2_##. This component
will be used by the consumer component ZNET310_COMP1_##.
1.
Create the Web Dynpro component with one view (name:
CUSTOMER_DATA_VIEW). Embed this view in the window (name:
MAIN_WINDOW).
Task 3:
Implement the Web Dynpro component ZNET310_COMP2_##.
This component should read the details of a flight passenger and display the data on
the view. The related coding should be encapsulated in a method that is exposed to the
consumer component. The method should have an interface parameter to import the
customer ID.
1.
Edit the component controller. Create a new method (name:
SHOWCUSTOMER) that can also be called from other components.
2.
Add an importing parameter of type SCUSTOM-ID to the method’s interface
(parameter name: IV_CUSTOMER_ID).
3.
In the component controller, define a context node of type SCUSTOM (name:
CUSTOMER_DATA) having the attributes ID, NAME, STREET, POSTBOX,
POSTCODE, CITY, COUNTRY, and TELEPHONE. Do not change the default
cardinality (1..1).
4.
Copy this context node to the context of view CUSTOMER_DATA_VIEW and
map the view node to the component controller node.
5.
Display the customer data in the layout of the view.
6.
Go back to method SHOWCUSTOMER( ) defined in Step 1 of this task. Read
the customer data for the customer ID passed to this method. Use the static
method CL_NET310_FLIGHTMODEL=>READ_CUSTOMER( ).
Store the data in the controller context.
Continued on next page
294
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Component Reuse
Task 4:
Use the component defined in the last task to display details of a customer in the
consumer component ZNET310_COMP1_##. The customer details should be
displayed below the booking table on view OUTPUT_VIEW. The customer details
should always fit with the booking highlighted in the booking table on this view.
1.
Edit the component ZNET310_COMP1_##. Define a usage of the component
ZNET310_COMP2_## (usage name: CUSTOMER_COMP_USAGE).
2.
Edit the component controller. Declare the usage of the interface controller of
component usage CUSTOMER_COMP_USAGE.
3.
In the component controller, create a new method (name: CUSTOMER_READ).
This method will encapsulate the code to instantiate the used component and to
call the used component’s interface method.
4.
Implement the method CUSTOMER_READ( ):
For the selected booking, read the customer ID from the context. If necessary,
instantiate the used component. Finally, call the interface method of the
component usage and pass the customer ID to this method.
2009
5.
Edit the layout of view OUTPUT_VIEW. Create a ViewContainerUIElement
between the booking table and the button. Change the LayoutData property
to MatrixHeadData.
6.
In order to see the interface view of the component usage, you have to embed
this interface view in the view container of view OUTPUT_VIEW.
7.
Go back to the view OUTPUT_VIEW. The customer information has to be
read if the user navigates from view INPUT_VIEW to view OUTPUT_VIEW,
if a new flight is selected, or if a new booking is selected. Call the component
controller method CUSTOMER_READ( ) for these three situations.
8.
If time is remaining, you may translate the texts that are used on the layout of
both views.
9.
Activate your consumer component and test your application.
© 2008 SAP AG. All rights reserved.
295
Unit 8: Component Reuse
NET310
Solution 13: Component Reuse
Task 1:
Copy your Web Dynpro component ZNET310_HLP_## or the template
NET310_HLP_S1 to Web Dynpro component ZNET310_COMP1_##. This
component will act as the consumer component. Define a new Web Dynpro
application to access this component.
1.
Copy the template, activate your component, and create a Web Dynpro
application.
a)
Perform this step as in previous exercises.
Task 2:
Create the new Web Dynpro component ZNET310_COMP2_##. This component
will be used by the consumer component ZNET310_COMP1_##.
1.
Create the Web Dynpro component with one view (name:
CUSTOMER_DATA_VIEW). Embed this view in the window (name:
MAIN_WINDOW).
a)
Perform this step as in previous exercises.
Task 3:
Implement the Web Dynpro component ZNET310_COMP2_##.
This component should read the details of a flight passenger and display the data on
the view. The related coding should be encapsulated in a method that is exposed to the
consumer component. The method should have an interface parameter to import the
customer ID.
1.
Edit the component controller. Create a new method (name:
SHOWCUSTOMER) that can also be called from other components.
a)
To expose a component controller method to the component interface,
select the check box in the column labeled Interface.
Continued on next page
296
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Component Reuse
2.
3.
4.
Add an importing parameter of type SCUSTOM-ID to the method’s interface
(parameter name: IV_CUSTOMER_ID).
a)
Double-click on the method name to open the source code editor. In the
parameter list that is displayed above the source code, enter the name of the
new parameter (name: IV_CUSTOMER_ID).
b)
Choose Type = Importing and Associated Type = SCUSTOM-ID.
In the component controller, define a context node of type SCUSTOM (name:
CUSTOMER_DATA) having the attributes ID, NAME, STREET, POSTBOX,
POSTCODE, CITY, COUNTRY, and TELEPHONE. Do not change the default
cardinality (1..1).
a)
Select the Context tab.
b)
Choose Create
c)
Enter the node’s name and the dictionary type SCUSTOM in the related
fields.
d)
Choose Add Attribute from Structure and select the fields listed above.
Copy this context node to the context of view CUSTOMER_DATA_VIEW and
map the view node to the component controller node.
a)
5.
→ Node from the context menu of the root node.
Perform this step as in previous exercises.
Display the customer data in the layout of the view.
a)
Change the Layout of the ROOTUIELEMENTCONTAINER to
MatrixLayout, set width to 100% and check the check box related to
property stretchHorizontally.
b)
Use the Web Dynpro Code Wizard to create a form for all attributes of the
context node containing the customer information.
c)
For the generated transparent container, change the property LayoutData to
MatrixHeadData, set width to 100%, cellBackgroundDesign to fill1 and
width (LayoutData (MatrixHeadData) ) to 100%.
d)
For the TEXTVIEW UI element being the first subelement in the generated
transparent container, set LayoutData = MatrixHeadData and assign a text
to be displayed above the form fields to property text.
e)
Change the property readOnly for all input fields by selecting the
corresponding check box.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
297
Unit 8: Component Reuse
6.
NET310
Go back to method SHOWCUSTOMER( ) defined in Step 1 of this task. Read
the customer data for the customer ID passed to this method. Use the static
method CL_NET310_FLIGHTMODEL=>READ_CUSTOMER( ).
Store the data in the controller context.
a)
Define a local variable of type SCUSTOM (suggested name:
LS_CUSTOMER_DATA).
b)
Use the pattern function to generate the statement for calling the static
method. Fill the variable created above (LS_CUSTOMER_DATA).
c)
Define a reference variable of type IF_WD_CONTEXT_NODE (name:
LO_ND_CUSTOMER_DATA).
d)
Get the reference to the context node that will hold the customer data
in LO_ND_CUSTOMER_DATA.
e)
Use the method BIND_STRUCTURE( ) for this reference to pass the
customer data to the context node.
f)
Source code see below.
Task 4:
Use the component defined in the last task to display details of a customer in the
consumer component ZNET310_COMP1_##. The customer details should be
displayed below the booking table on view OUTPUT_VIEW. The customer details
should always fit with the booking highlighted in the booking table on this view.
1.
2.
Edit the component ZNET310_COMP1_##. Define a usage of the component
ZNET310_COMP2_## (usage name: CUSTOMER_COMP_USAGE).
a)
On the Used Components tab, enter ZNET310_COMP2_## in the
Component column.
b)
Enter the usage name (CUSTOMER_COMP_USAGE) in the Component
Usage column.
Edit the component controller. Declare the usage of the interface controller of
component usage CUSTOMER_COMP_USAGE.
a)
On the Properties tab, choose Create Controller Usage.
b)
Select the entry for the interface controller of the component usage
CUSTOMER_COMP_USAGE.
Continued on next page
298
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Component Reuse
3.
In the component controller, create a new method (name: CUSTOMER_READ).
This method will encapsulate the code to instantiate the used component and to
call the used component’s interface method.
a)
4.
Perform this step as in previous exercises.
Implement the method CUSTOMER_READ( ):
For the selected booking, read the customer ID from the context. If necessary,
instantiate the used component. Finally, call the interface method of the
component usage and pass the customer ID to this method.
5.
a)
Use the Web Dynpro Code Wizard to read the value of the attribute
CUSTOMID from the context. Remember that selecting a booking in the
table sets the lead selection in the node BOOKINGTAB.
b)
The code for instantiating the component usage and for calling the interface
method SHOWCUSTOMER( ) can also be created by means of the Web
Dynpro Code Wizard. You only have to pass the parameter containing the
customer ID to the method.
c)
Source code see below.
Edit the layout of view OUTPUT_VIEW. Create a ViewContainerUIElement
between the booking table and the button. Change the LayoutData property
to MatrixHeadData.
a)
6.
Perform this step as in previous exercises.
In order to see the interface view of the component usage, you have to embed
this interface view in the view container of view OUTPUT_VIEW.
a)
Edit the window of the consumer component. Select the view container
of view OUTPUT_VIEW.
b)
Choose Embed View from the context menu of the view container.
c)
Select the interface view of the component usage.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
299
Unit 8: Component Reuse
7.
8.
Go back to the view OUTPUT_VIEW. The customer information has to be
read if the user navigates from view INPUT_VIEW to view OUTPUT_VIEW,
if a new flight is selected, or if a new booking is selected. Call the component
controller method CUSTOMER_READ( ) for these three situations.
a)
Select the tab Actions. Create a new action (name: SHOW_CUSTOMER).
b)
Implement the action handler method. Call the component controller
method CUSTOMER_READ( ) (use Web Dynpro Code Wizard).
c)
Select the Layout tab. Assign the action SHOW_CUSTOMER to the
property onLeadSelect of the flights table and of the booking table,
respectively.
d)
Select the Inbound Plugs tab. Double-click the plug’s name to navigate
to the source code of the related method. Call the component controller
method CUSTOMER_READ( ) after having read the flights (use Web
Dynpro Code Wizard).
If time is remaining, you may translate the texts that are used on the layout of
both views.
a)
9.
NET310
Perform this step as in previous exercises.
Activate your consumer component and test your application.
a)
Perform this step as in previous exercises.
Result
Used Component, Comp.
SHOWCUSTOMER
Controller, Method
METHOD showcustomer .
DATA ls_customer_data
TYPE
wd_this->element_customer_data.
DATA lo_nd_customer_data TYPE REF TO if_wd_context_node.
ls_customer_data = cl_net310_flightmodel=>read_customer(
iv_customid = iv_customer_id ).
lo_nd_customer_data = wd_context->get_child_node(
wd_this->wdctx_customer_data ).
lo_nd_customer_data->bind_structure( ls_customer_data ).
Continued on next page
300
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Component Reuse
ENDMETHOD.
Parent Component, Comp.
CUSTOMER_READ
Controller, Method
METHOD customer_read .
DATA lo_nd_bookingtab TYPE REF TO if_wd_context_node.
DATA lo_el_bookingtab TYPE REF TO if_wd_context_element.
DATA ls_bookingtab
TYPE
wd_this->element_bookingtab.
DATA lv_customid
TYPE
wd_this->element_bookingtab-customid.
DATA lo_cmp_usage
TYPE REF TO if_wd_component_usage.
DATA lo_interfacecontroller TYPE REF TO iwci_net310_comp_s2 .
* read value of attribue CUSTOMID from context
lo_nd_bookingtab = wd_context->path_get_node(
path = ‘FLIGHTTAB.BOOKINGTAB‘ ).
lo_el_bookingtab = lo_nd_bookingtab->get_element( ).
lo_el_bookingtab->get_attribute(
EXPORTING
name =
‘CUSTOMID‘
IMPORTING
value = lv_customid ).
* Instantiate component CUSTOMER_COMP_USAGE if necessary
lo_cmp_usage = wd_this->wd_cpuse_customer_comp_usage( ).
IF lo_cmp_usage->has_active_component( ) IS INITIAL.
lo_cmp_usage->create_component( ).
ENDIF.
* call interface method SHOWCUSTOMER passing customer number
lo_interfacecontroller = wd_this->wd_cpifc_customer_comp_usage( ).
lo_interfacecontroller->showcustomer(
iv_customer_id = lv_customid ).
ENDMETHOD.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
301
Unit 8: Component Reuse
NET310
View OUTPUT_VIEW, Method HANDLEIN_DEFAULT
METHOD handlein_default .
DATA lo_componentcontroller TYPE REF TO ig_componentcontroller .
lo_componentcontroller = wd_this->get_componentcontroller_ctr( ).
lo_componentcontroller->flighttab_fill( ).
lo_componentcontroller->customer_read(
).
ENDMETHOD.
View OUTPUT_VIEW, Method ONACTIONSHOW_CUSTOMER
METHOD onactionshow_customer .
DATA lo_componentcontroller TYPE REF TO ig_componentcontroller.
lo_componentcontroller = wd_this->get_componentcontroller_ctr( ).
lo_componentcontroller->customer_read( ).
ENDMETHOD.
302
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Component Reuse
Lesson Summary
You
•
•
•
•
•
•
2009
should now be able to:
Define methods, events, and context nodes in a component interface controller.
Define which plugs of a window are visible in the interface view.
Declare the usage of a component in another component.
Call methods and subscribe to events defined in a used component.
Interchange data between components.
Instantiate and delete a component usage at runtime.
© 2008 SAP AG. All rights reserved.
303
Unit Summary
NET310
Unit Summary
You should now be able to:
•
Define methods, events, and context nodes in a component interface controller.
•
Define which plugs of a window are visible in the interface view.
•
Declare the usage of a component in another component.
•
Call methods and subscribe to events defined in a used component.
•
Interchange data between components.
•
Instantiate and delete a component usage at runtime.
304
© 2008 SAP AG. All rights reserved.
2009
Unit 9
Dialog Boxes (Popups)
281
This unit contains the basic information of how to send a popup. Details are contained
in course NET311
Unit Overview
Web Dynpro ABAP allows you to send windows as dialog boxes. These dialog boxes
are modal (window in background is locked). In addition, modal confirmation dialogs
displaying a simple text, and external browser windows may be opened.
Unit Objectives
After completing this unit, you will be able to:
•
•
•
•
Describe what kind of dialog boxes exist.
Create and open a dialog box displaying a window of the same component or an
interface view of a component usage.
Create and open a confirmation dialog box.
Create and open an external dialog box.
Unit Contents
Lesson: Dialog Boxes (Popups) .................................................. 306
Exercise 14: Displaying Interface View of Component Usage as Popup 317
2009
© 2008 SAP AG. All rights reserved.
305
Unit 9: Dialog Boxes (Popups)
Lesson:
282
NET310
Dialog Boxes (Popups)
Lesson Duration: 45 Minutes
Lesson Overview
This lesson describes how to define and display windows in modal dialog boxes.
These windows may be defined in the same component or in a subcomponent.
Lesson Objectives
After completing this lesson, you will be able to:
•
•
•
•
Describe what kind of dialog boxes exist.
Create and open a dialog box displaying a window of the same component or an
interface view of a component usage.
Create and open a confirmation dialog box.
Create and open an external dialog box.
Defining buttons in the frame of the popup and handling events of these buttons is not
discussed here. Please refer to the course NET311 to find a complete explanation for
these topics.
Business Example
You know that the visual interface of a component usage - an interface view - can be
embedded in the window of the consumer component. This allows you to reuse the
window of a used component as if it was a view of your own component. However,
you want to display such a window as a popup.
Overview
Dialog boxes are used to display concrete information or possible settings in a view
which pops up on top of the browser window which the user clicked on. After the
dialog has been exited, either the browser window underneath becomes active again
or another screen may appear.
306
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Dialog Boxes (Popups)
There are two different types of dialog boxes:
•
External dialog box:
An external dialog box is opened in a separate browser window and can be
moved around the screen independently of the original window. External dialog
boxes are generally modeless.
•
Modal dialog box:
A modal dialog box is opened in the current browser window. The modal dialog
box may display a window of the same component, the interface view of a
component usage or a confirmation dialog.
Common Code Section
The first part of the source code is identical, independent of the kind of dialog box to
be created. This consists of the following parts.
1.
2.
3.
4.
5.
6.
2009
First, the reference to the component controller’s generic functionality (API) has
to be determined. To do so, the method wd_get_api( ) has to be called for the
controller reference WD_COMP_CONTROLLER.
This method call will return a reference of type IF_WD_COMPONENT.
To store this reference, a corresponding reference variable has to be created
(lo_api_component).
Next, the reference to the so-called window manager has to be determined. This
object offers the functionality of creating all kinds of dialog boxes. To do so, the
method lo_api_component->get_window_manager( ) has to be called.
This method call will return a reference of type IF_WD_WINDOW_MANAGER.
To store this reference, a corresponding reference variable has to be created
(lo_window_manager).
Now, the different kinds of dialog boxes can be created by calling the appropriate
method of lo_window_manager.
You will receive a reference to an object representing the dialog box, independent
of the kind of dialog box you created. This can be used to open or close (only for
modal popups) the dialog box. This reference is of type IF_WD_WINDOW. A
corresponding reference variable has to be created.
© 2008 SAP AG. All rights reserved.
307
Unit 9: Dialog Boxes (Popups)
NET310
Figure 121: Dialog box: common source code
The Web Dynpro Code Wizard will generate the complete code for sending windows
of the same component and interface views of component usages as modal dialog
boxes. If you want to create an external dialog box or if you want to create a
confirmation dialog box, you have to replace the generated method call (step 5) with
the correct method call.
External Dialog Box
Discuss demo NET310_POP_D1 here. All code is to be found in the view
controller. The creation of an external dialog box is to be found in method
ONACTIONEXT_POPUP().
The method create_external_window( ) of the window manager object is used to
create an external dialog box. This method’s parameter allows you to set the window
title and the URL of the object to be displayed in the dialog box. In addition, there
are boolean parameters to display or hide the browser’s menu bar, scroll bars, status
bar, tool bar and address bar. Finally, the developer can decide whether the browser
window should be resizeable or not.
308
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Dialog Boxes (Popups)
Figure 122: External dialog box: example
Figure 123: External dialog box: source code
2009
© 2008 SAP AG. All rights reserved.
309
Unit 9: Dialog Boxes (Popups)
NET310
Modal Dialog Boxes
There are three different kinds of modal dialog boxes that can be implemented with
Web Dynpro for ABAP:
1.
Confirmation dialog box:
This dialog box is used to display simple texts in a window with a standardized
set of buttons to define the next step.
2.
Dialog box displaying window of the same component:
This dialog box can be used to display any window of the same component
as a popup. The content is arbitrary.
3.
Dialog box displaying interface view of a component usage:
This dialog box can be used to display any interface view of any component
usage as a popup.
Confirmation Dialog Box
Discuss demo NET310_POP_D1 here. All code is to be found in the action handler
method ONACTIONCONF_POPUP().
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_confirm(
) of the window manager object has to be called. Parameters allow you to set the text to
be displayed by the confirmation dialog box, as well as its title. Optionally, an icon can
be displayed on the left-hand side of the text indicating its significance (e.g. warning).
Buttons can be displayed in the dialog box; one of these buttons can be defined as
the default button. A certain action can be assigned to each of the buttons displayed
by the dialog box. The popup’s close button in the upper right-hand corner can be
displayed or hidden.
310
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Dialog Boxes (Popups)
Figure 124: Confirmation dialog box: example
Figure 125: Confirmation dialog box: source code
2009
© 2008 SAP AG. All rights reserved.
311
Unit 9: Dialog Boxes (Popups)
NET310
Dialog Box displaying a Window of the same Component
Discuss demo NET310_POP_D1. All code is to be found in the action handler method
ONACTIONOWN_WINDOW().
In order to display a window of the same component as a dialog box, the method
create_window( ) of the window manager object has to be called. Parameters allow
you to define which window of the same component is to be displayed as a modal
dialog box. The title of the modal dialog box can be set.
Buttons can be displayed in the dialog box; one of these buttons can be defined as
the default button. A certain action can be assigned to each of the buttons displayed
by the dialog box. The popup’s close button in the upper right-hand corner can be
displayed or hidden.
Optionally, an icon can be displayed on the left-hand side of the dialog box indicating
the significance of the content (e.g. information).
Figure 126: Window of same component as dialog box: example
312
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Dialog Boxes (Popups)
Figure 127: Window of same component as dialog box: source code
Dialog Box Displaying an Interface View of a Component Usage
Discuss demo NET310_POP_D1. All code is to be found in the action handler method
ONACTIONCMP_WINDOW().
In order to display an interface view of a component usage as a dialog box, the method
create_window_for_cmp_usage( ) of the window manager object has to be called.
The title of the modal dialog box can be set.
The name of the component usage and the name of its interface view which is to be
displayed as a dialog box have to be defined by setting the related interface parameters
of the method.
Buttons can be displayed in the dialog box; one of these buttons can be defined as
the default button. A certain action can be assigned to each of the buttons displayed
by the dialog box. The popup’s close button in the upper right-hand corner can
be displayed or hidden. Optionally, an icon can be displayed on the left-hand side
of the dialog box indicating the significance of the content (e.g. information).
However, these settings cannot be defined by just passing information to the method
create_window_for_cmp_usage( ), but by calling subsequent methods.
2009
© 2008 SAP AG. All rights reserved.
313
Unit 9: Dialog Boxes (Popups)
NET310
External context mapping can be used to exchange data between the consumer
component and the component usage containing the popup window. A second way
of passing data from the consumer component to the component usage is to call a
method defined in its interface controller. The passing back of data to the consumer
component can be implemented by raising an event defined in the interface controller
using the event parameters. A method defined in any controller of the consumer
component may then register for this event.
Figure 128: Interface View of component usage as dialog box: example
314
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Dialog Boxes (Popups)
Figure 129: Interface View of component usage as dialog box: source code
Exercise “Displaying Interface View of Component Usage as Popup”
2009
© 2008 SAP AG. All rights reserved.
315
Unit 9: Dialog Boxes (Popups)
316
NET310
© 2008 SAP AG. All rights reserved.
2009
NET310
293
Lesson: Dialog Boxes (Popups)
Exercise 14: Displaying Interface View of
Component Usage as Popup
Exercise Duration: 15 Minutes
Exercise Objectives
After completing this exercise, you will be able to:
•
Display the interface view of a used component as a modal dialog box (popup)
Business Example
To display details for a given data set, you can reuse an existing component. The
interface view of this component can be embedded in a view container that is defined
in one of the views related to the consumer component. However, you want to display
this interface view as a modal dialog box (popup).
Template: NET310_COMP_S1 (consumer component)
Solution: NET310_POP_S1 (consumer component)
The used component will not be changed.
Task 1:
Copy your Web Dynpro component ZNET310_COMP1_## or the template
NET310_COMP_S1 to Web Dynpro component ZNET310_POP_##. This
component will act as the consumer component.
Do not copy a template for the used component. If you copy the template for the
consumer component (NET310_COMP_S1), this copy will reuse the component
(NET310_COMP_S2). However, nothing has to be changed in the used component.
Thus it is not a restriction to work with a subcomponent defined in the SAP name
space.
If you copy your own consumer component (ZNET310_COMP1_##), this copy will
reuse your component ZNET310_COMP2_##.
1.
Copy the template and create a Web Dynpro application for the consumer
component.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
317
Unit 9: Dialog Boxes (Popups)
NET310
Task 2:
You want to display the customer details in a popup. Thus the view container defined
on view OUTPUT_VIEW can be deleted again. In addition, the interface view
embedded in the window of the consumer component has to be deleted, too.
1.
Delete the UI element of type ViewContainerUIElement from the view
OUTPUT_VIEW.
2.
Remove the interface view from the window of the consumer component.
Task 3:
The customer details should be displayed if the user marks a booking on view
OUTPUT_VIEW. You can add the code for displaying the modal dialog box to the
related action handler method.
318
1.
Create and open a modal dialog box to display the interface view
MAIN_WINDOW of the component usage. Create the code in method
ONACTIONSHOW_CUSTOMER( ) of the view OUTPUT_VIEW.
2.
Customer data should not be displayed directly after the navigation to view
OUTPUT_VIEW has been conducted. The popup should also not be displayed if
a flight is selected by the user.
3.
Activate your consumer component and test the related application.
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Dialog Boxes (Popups)
Solution 14: Displaying Interface View of
Component Usage as Popup
Task 1:
Copy your Web Dynpro component ZNET310_COMP1_## or the template
NET310_COMP_S1 to Web Dynpro component ZNET310_POP_##. This
component will act as the consumer component.
Do not copy a template for the used component. If you copy the template for the
consumer component (NET310_COMP_S1), this copy will reuse the component
(NET310_COMP_S2). However, nothing has to be changed in the used component.
Thus it is not a restriction to work with a subcomponent defined in the SAP name
space.
If you copy your own consumer component (ZNET310_COMP1_##), this copy will
reuse your component ZNET310_COMP2_##.
1.
Copy the template and create a Web Dynpro application for the consumer
component.
a)
Perform this step as in previous exercises.
Task 2:
You want to display the customer details in a popup. Thus the view container defined
on view OUTPUT_VIEW can be deleted again. In addition, the interface view
embedded in the window of the consumer component has to be deleted, too.
1.
Delete the UI element of type ViewContainerUIElement from the view
OUTPUT_VIEW.
a)
Edit the view OUTPUT_VIEW. Open the Layout tab.
b)
Mark the ViewContainerUIElement. Delete it by selecting the
corresponding item from the UI element’s context menu. Save.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
319
Unit 9: Dialog Boxes (Popups)
2.
NET310
Remove the interface view from the window of the consumer component.
a)
Edit the consumer component’s window. Open the node related to view
OUTPUT_VIEW.
b)
Mark the entry related to the interface view of the component usage. This
entry is marked with a special sign because the container has already been
deleted in the view.
c)
Delete the interface view by selecting the corresponding item in its context
menu.
Task 3:
The customer details should be displayed if the user marks a booking on view
OUTPUT_VIEW. You can add the code for displaying the modal dialog box to the
related action handler method.
1.
2.
Create and open a modal dialog box to display the interface view
MAIN_WINDOW of the component usage. Create the code in method
ONACTIONSHOW_CUSTOMER( ) of the view OUTPUT_VIEW.
a)
Edit the view OUTPUT_VIEW. Select the tab Methods. Double click
on the entry ONACTIONSHOW_CUSTOMER to display the method’s
source code.
b)
Position the cursor below the call of the component controller method
CUSTOMER_READ( ). Use the Web Dynpro Code Wizard to create
and open a modal dialog box for the interface view MAIN_WINDOW of
the component usage.
c)
To set the title displayed by the modal dialog box, you can pass an
appropriate text literal to the interface parameter title of method
CREATE_WINDOW_FOR_CMP_USAGE( ).
d)
Source code see below.
Customer data should not be displayed directly after the navigation to view
OUTPUT_VIEW has been conducted. The popup should also not be displayed if
a flight is selected by the user.
a)
Remove the call of the component controller method CUSTOMER_READ(
) from the inbound plug handler method.
b)
Source code see below.
c)
Clear the value of property onLeadSelect for the table displaying the flights.
Continued on next page
320
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Dialog Boxes (Popups)
3.
Activate your consumer component and test the related application.
a)
Perform this step as in previous exercises.
Result
View OUTPUT_VIEW, Method ONACTIONSHOW_CUSTOMER
METHOD onactionshow_customer .
DATA lo_componentcontroller TYPE REF TO ig_componentcontroller.
DATA lo_window_manager TYPE REF TO if_wd_window_manager.
DATA lo_api_component
TYPE REF TO if_wd_component.
DATA lo_window
TYPE REF TO if_wd_window.
DATA lv_text
TYPE
string.
lo_componentcontroller = wd_this->get_componentcontroller_ctr( ).
lo_componentcontroller->customer_read( ).
lv_text = wd_assist->get_text( ’008’ ).
lo_api_component
= wd_comp_controller->wd_get_api( ).
lo_window_manager = lo_api_component->get_window_manager( ).
lo_window
=
lo_window_manager->create_window_for_cmp_usage(
interface_view_name
*
= ’MAIN_WINDOW’
component_usage_name
= ’CUSTOMER_COMP_USAGE’
title
= lv_text
close_in_any_case
= abap_true
message_display_mode
= if_wd_window=>co_msg_display_mode_selected
).
lo_window->open( ).
ENDMETHOD.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
321
Unit 9: Dialog Boxes (Popups)
NET310
View OUTPUT_VIEW, Method HANDLEIN_DEFAULT
METHOD handlein_default .
DATA lo_componentcontroller TYPE REF TO ig_componentcontroller .
lo_componentcontroller = wd_this->get_componentcontroller_ctr( ).
lo_componentcontroller->flighttab_fill( ).
* lo_componentcontroller->customer_read(
).
ENDMETHOD.
322
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Dialog Boxes (Popups)
Lesson Summary
You should now be able to:
•
Describe what kind of dialog boxes exist.
•
Create and open a dialog box displaying a window of the same component or an
interface view of a component usage.
•
Create and open a confirmation dialog box.
•
Create and open an external dialog box.
2009
© 2008 SAP AG. All rights reserved.
323
Unit Summary
NET310
Unit Summary
You should now be able to:
•
Describe what kind of dialog boxes exist.
•
Create and open a dialog box displaying a window of the same component or an
interface view of a component usage.
•
Create and open a confirmation dialog box.
•
Create and open an external dialog box.
324
© 2008 SAP AG. All rights reserved.
2009
Unit 10
Adaptation Techniques
303
The important topics of configuration are covered completely in this unit.
Enhancements are only introduced and the enhancement options for Web Dynpro are
listed. For both topics, detailed information can be found in course NET311.
Dynamic programming is a wide field. Only the very basics of dynamic programming
are explained here.
Unit Overview
Web Dynpro components can be adapted by different means.
Configuration (together with customizing and personalization) can be used to alter the
value of UI element properties for different user groups. If the possibilities offered
out of the box are not sufficient, additional adaptation options can be defined by
the developer of the component.
Enhancing a Web Dynpro component allows to add functionality not foreseen by the
developer without having to modify the component. All kinds of controller entities
can be defined this way. Even new views and new windows can be created and
existing navigation paths can be changed.
Finally, dynamic programming allows to define the data storage (context) and the
user interface very comfortably at runtime. This is the precondition for creating
generic Web Dynpro components (the Object Value Selector component WDR_OVS,
or the SAP List Viewer for Web Dynpro, for example) and solving problems like
implementing a data browser for displaying arbitrary database tables.
Unit Objectives
After completing this unit, you will be able to:
•
•
2009
Adapt Web Dynpro applications using implicit configuration and personalization.
Create a configuration controller and implement explicit configuration.
© 2008 SAP AG. All rights reserved.
325
Unit 10: Adaptation Techniques
•
•
•
•
NET310
List the Web Dynpro adaptation options offered by the new enhancement
concept.
Create context nodes and context attributes dynamically.
Create new UI elements in an existing UI element hierarchy dynamically.
Bind existing actions to UI elements dynamically.
Unit Contents
Lesson: Configuration and Personalization ..................................... 327
Exercise 15: Adaptation via Configuration .................................. 341
Lesson: Enhancements for Web Dynpro ABAP ................................ 352
Lesson: Dynamic Modifications at Runtime ..................................... 362
Exercise 16: Dynamic Modifications at Runtime ........................... 389
326
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson:
305
Lesson: Configuration and Personalization
Configuration and Personalization
Lesson Duration: 90 Minutes
Lesson Overview
This lesson covers the adaptation of applications and components via configuration
and personalization. This includes implicit adaptation – which means possibilities
that are available out of the box – and explicit adaptations, where the developer has to
define the kind of additional functionality that can be adapted by certain user groups
(administrators, normal users).
Lesson Objectives
After completing this lesson, you will be able to:
•
•
Adapt Web Dynpro applications using implicit configuration and personalization.
Create a configuration controller and implement explicit configuration.
For all topics listed above, demos are available in the package NET310. Further
instructions can be found in this unit.
Business Example
You have created a Web Dynpro application. Everything works fine, and the
applications can even be started in several languages. However, you need to define
your Web Dynpro application in a way that customizing the UI is possible by the
users of this application.
Adaptation of Web Dynpro Applications
The UI of applications defined with Web Dynpro ABAP can be adapted in different
ways and by different user groups. There are two categories of application adaptation:
configuration and personalization.
Configuration is a concept that lets the developer create configuration data sets
containing values for UI element properties or context attributes (typically bound to
UI element properties). This allows the developer to overwrite many of the statically
defined UI 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).
2009
© 2008 SAP AG. All rights reserved.
327
Unit 10: Adaptation Techniques
NET310
In contrast to configuration, personalization allows any user of the application
to change the UI element properties at runtime. However, these changes are very
restricted (for example, for simple UI elements like the TextView, only the visibility
can be changed; for the Table element, the order of the columns can also be altered).
Personalization is user-dependent.
Customizing is the process of personalizing Web Dynpro applications for all users in
a client (user-independent personalization). The customizing possibilities are much
more far-reaching than the possibilities offered by personalization. To be able to
customize an application, special authorization is required.
Adaptation Hierarchy
The concepts of configuration, customizing, and personalization can be combined to
define the final adaptation. Here, the changes defined by personalization overwrite
the changes defined by customizing, and customizing overwrites the configuration
adaptation. On the other side, the parameters available for configuration can be set
to final so they cannot be changed using customizing or personalization. Parameters
available for customizing can be set to final so they cannot be changed using
personalization.
328
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Configuration and Personalization
Figure 130: Personalization, customizing, and configuration
Hint: Personalization and customizing is always based on a configuration.
Thus when interchanging the configuration, different customizing and
personalization data will be loaded.
Hint: Technically, personalization and customizing results in data sets stored
on the same data base table.
Implicit and Explicit Adaptation
Web Dynpro ABAP offers configuration, customizing, and personalization out of the
box. This means that it is possible to adapt a Web Dynpro application without any
programming effort. This kind of adaptation is called implicit adaptation.
If the flexibility provided by implicit adaptation is not sufficient, the developer can
modify the application in a way that all adaptations based on changing context
attributes are possible. However, for this explicit adaptation, programming effort is
required.
2009
© 2008 SAP AG. All rights reserved.
329
Unit 10: Adaptation Techniques
NET310
Figure 131: Implicit and explicit adaptation
Implicit Configuration
Discuss demo NET310_CONF_D1. Two WD applications exist for this component.
Start both of them and compare them.
For NET310_CONF_D1 an application configuration has been created.
However, this application has to be assigned dynamically. Start this application
without assigning the application configuration. This is the design as defined
by the developer. Now, start the application and append the query string
sap-wd-configID=NET310_CONF_D1_APPL. Analyze the changes by displaying the
component configuration and the application configuration.
For NET310_CONF_D1A an application configuration has been created that is
assigned to the application statically. Start the application. Analyze the parameter list
of the WD application.
Finally, create a component configuration and an application configuration for any of
your WD components.
330
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Configuration and Personalization
To define which properties of a Web Dynpro component are to be changed, a
Component configuration) must be created for this component. Component
configurations allow you to change properties of UI elements defined in any view
of a single component. For each component, an arbitrary number of component
configurations can be defined. Each component configuration is bound to a certain
Web Dynpro component.
At runtime, a component configuration has to be loaded for each component that has
to be adapted. This could be achieved by adding the appropriate coding section to the
source code of any controller belonging to the application. However, it is also possible
to load component configurations without defining additional source code. For this
purpose, Application configurations do exist. Application configurations are bound
to Web Dynpro applications. They define which component configuration is used for
which component in this application. For each application, an arbitrary number of
application configurations can be defined.
Application changes related to configuration affect every user of this application in
every client.
Figure 132: Configuration
2009
© 2008 SAP AG. All rights reserved.
331
Unit 10: Adaptation Techniques
NET310
The following steps have to be executed to define a component configuration:
1.
2.
Choose Create/Change Configuration from the Context menu of a Web Dynpro
component. This starts the configuration tool in the Web browser.
On the first screen, enter the id of the component configuration to be created.
This id has to be unique (not only in respect to the component it is created for
but in respect to all Web Dynpro components).
Caution: In a customer system, you may only choose names in the
customer name space (beginning with Z or Y).
3.
4.
5.
6.
7.
332
Click on the button having the text Create. This will open a dialog box. Enter a
description and a package name and click on the OK button.
A new dialog box appears. Enter the transport task the component configuration
is to be assigned to and click on the OK button. If the component configuration
is defined as a local object, this dialog box will not appear.
On the tab labeled Web Dynpro Built-In, all views are displayed by a table. If a
view is marked, the UI element hierarchy of this view will be displayed. Choose
any UI element you want to manipulate. Change the property values and set the
Final flag if you do not want this property to be changed by customizing or by
personalization.
Click on the button with the text Save. This will store the configuration data
set on the data base.
Close the browser. In the ABAP Workbench, refresh the object list. The
component configuration can be found as a subelement of the Web Dynpro
component.
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Configuration and Personalization
After having defined a component configuration for each component used in a Web
Dynpro application, an application configuration may be created:
1.
2.
Choose Create/Change Configuration from the Context menu of a Web Dynpro
application. This starts the configuration tool in the Web browser.
On the first screen, enter the id of the application configuration to be created.
This id has to be unique (not only in respect to the application it is created for
but in respect to all Web Dynpro application).
Caution: In a customer system, you may only choose names in the
customer name space (beginning with Z or Y).
3.
4.
5.
6.
7.
Click on the button having the text Create. This will open a dialog box. Enter a
description and a package name and click on the OK button.
A new dialog box appears. Enter the transport task the application configuration
is to be assigned to and click on the OK button. If the application configuration
is defined as a local object, this dialog box will not appear.
In the second tab labeled Structure the main component and all component
usages are displayed by a table. Use the value help related to the column
Configuration to define which component configuration is to be loaded for
which component (usage).
Finally, click the Save button. This will save the application configuration on
the data base.
Close the browser. In the ABAP Workbench, refresh the object list. The
application configuration can be found as a subelement of the Web Dynpro
application.
Using an Application Configuration
As long as the application configuration is not assigned to the related application, the
changes defined by the application configuration are not visible. There are two ways
to assign an application configuration to a Web Dynpro application:
1.
Dynamic assignment
Add the query string sap-wd-configID=<appl_config> to the URL used to start
the Web Dynpro application. Here, <appl_config> is the name of the application
configuration.
2.
Static assignment
Edit the parameter list related to the Web Dynpro application. Add the parameter
WDCONFIGURATIONID. In the Value column, enter the name of the
application configuration.
2009
© 2008 SAP AG. All rights reserved.
333
Unit 10: Adaptation Techniques
NET310
Analyze demo NET310_CONF_D1. Discuss the configuration objects related to the
component and related to the applications.
For NET310_CONF_D1 an application configuration has been created.
However, this application has to be assigned dynamically. Start this application
without assigning the application configuration. This is the design as defined
by the developer. Now, start the application and append the query string
sap-wd-configID=NET310_CONF_D1_APPL. Analyze the change by viewing the
component configuration and the application configuration.
For NET310_CONF_D1A an application configuration has been created that is
assigned to the application statically. Start the application. Analyze the parameter list
of the WD application.
Finally, create a component configuration and an application configuration for any of
your WD components.
Implicit Customizing
Implicit Customizing is provided by the Web Dynpro runtime and can be used
by everyone who has sufficient authorization. To be able to customize a Web
Dynpro application, the application must be started by adding the query string
SAP-CONFIG-MODE=X to the application’s URL. Customizing is conducted by
right-clicking on any UI element. A context menu appears. By selecting the entry
Settings for Current Configuration the customizing dialog is displayed.
Hint: Before the customizing dialog starts, the user’s authorization for the
authorization object S_DEVELOP is checked. If a sufficient authorization
for S_DEVELOP is not found, the authorization for the authorization object
S_WDR_P13N is checked.
For each UI element, a predefined number of properties can be changed. Elements
that are excluded from customizing by configuration are not available. Selecting the
Final check box for any property excludes this property from personalization.
The customizing data sets are client-dependent but user-independent.
334
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Configuration and Personalization
Figure 133: Implicit customizing
Analyze demo NET310_CONF_D1. Two WD applications exist for this component,
one of them with application configuration statically assigned. Start both of them
and compare.
Now, start both applications and add the query string sap-config-mode=X to the URL.
Click with the right mouse button on any UI element. Click on “Settings for current
Configuration” in the menu that appears. Change some of the properties and save.
If the application NET310_CONF_D1A is started, not all of the properties can be
changed. This is because some of the properties are set to final in the component
configuration.
Change some properties. For some of the properties mark the check box final. Save.
Check the result: Start the application without adding a query string.
Implicit Personalization
Implicit personalization is provided by the Web Dynpro runtime and can be used by
anyone starting any Web Dynpro application. Personalization is conducted by right
mouse-clicking on any UI element. A context menu appears. For each UI element
2009
© 2008 SAP AG. All rights reserved.
335
Unit 10: Adaptation Techniques
NET310
the visibility can be changed. For more complex elements like the Table UI element,
additional properties may be altered (such as the order of columns). Elements that are
excluded from personalization by customizing or configuration are not available.
The personalization data sets are user-dependent.
Figure 134: Implicit personalization
Analyze demo NET310_CONF_D1. Two WD applications exist for this component,
one of them with application configuration statically assigned. Start both of them
and compare.
Click with the right mouse button on any UI element. Click on “User Settings” in the
menu that appears. Only very few properties can be changed. This is because the
query string sap-config-mode=X has not been added to the URL that is used to start
the WD application. Not all properties can be changed. All properties that have been
set to final in the component configuration or by customizing are not available.
Change some properties and save. Check the result by starting the WD application
without adding any query string.
336
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Configuration and Personalization
Explicit Configuration
To allow explicit configuration of a component, a configuration controller has
to be created. A configuration controller is a special custom controller. Only one
configuration controller may exist for each Web Dynpro component.
All attributes that will be accessible via configuration have to be defined in the
context of the configuration controller. Using context mapping and data binding,
these attributes can then be used to change UI element properties directly in any
view. However, any other functional changes based on these attributes are also
possible, since the attributes are visible to all controllers that declare the usage of the
configuration controller.
To define a configuration controller, a custom controller has to be created first. From
the context menu of this controller, the item (Re)Set as Config. Controller has to be
selected to make this custom controller the component’s configuration controller.
The developer has to decide which attributes are to be defined in the component
controller and how changing these attributes will influence the functionality and the
UI of this component.
When defining a component configuration, not only can predefined UI element
property values be changed, but so can the values of the attributes defined in the
configuration controller. These attributes are accessible via the Configuration-Defined
tab.
2009
© 2008 SAP AG. All rights reserved.
337
Unit 10: Adaptation Techniques
NET310
Figure 135: Explicit configuration
Hint: Attributes defined in the configuration controller are not automatically
available for customizing and personalization.
Analyze demo NET310_CONF_D2. Here, a configuration controller has been
created. Display the configuration controller. Display the component configuration
(explicit configuration). Start WD applications NET310_CONF_D2 and
NET310_CONF_D2A. Not only is the look and feel different (implicit configuration),
but so is the data displayed (explicit configuration).
Now start the same applications by adding sap-config-mode=X to the URL. Start
customizing. Here, the configuration controller attributes cannot be changed.
Personalize the application. Again, the configuration controller attributes cannot be
changed.
338
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Configuration and Personalization
Exercise “Adaptation via Configuration”
2009
© 2008 SAP AG. All rights reserved.
339
Unit 10: Adaptation Techniques
340
© 2008 SAP AG. All rights reserved.
NET310
2009
NET310
315
Lesson: Configuration and Personalization
Exercise 15: Adaptation via Configuration
Exercise Duration: 30 Minutes
Exercise Objectives
After completing this exercise, you will be able to:
•
Create a component configuration
•
Create an application configuration
•
Assign an application configuration to a Web Dynpro application statically
•
Use configuration controllers to implement explicit configuration
Business Example
You have created a Web Dynpro component and a Web Dynpro application to
access the component. Now you have to adapt the look and feel of the Web Dynpro
application for different user groups. Depending on the user group, the properties of
some UI elements need to be modified and some messages should be displayed or
hidden. To implement these tasks, you want to use the configuration concept.
Template: NET310_POP_S1
Solution: NET310_CONF_S1
Task 1:
Copy the template NET310_POP_S1 or your component ZNET310_POP_## to
Web Dynpro component ZNET310_CONF_##. Create an application to access your
component. Test the functionality of your applicatin.
1.
Copy the template, activate your component, and create a Web Dynpro
application.
Task 2:
You would like to offer the possibility to display a message on the view
OUTPUT_VIEW indication if reading the flights was successful or not. However, it
should be possible to configure if this message is displayed. Thus you have to define a
configuration controller providing the interface to adapt this behavior.
1.
In your Web Dynpro component, create a custom controller (name:
CONFIG_CTRL) and make this controller the component’s configuration
controller.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
341
Unit 10: Adaptation Techniques
NET310
2.
In the context of the configuration controller, define a node
(name: MESSAGE_SETTINGS) having a single attribute (name:
DISPLAY_MESSAGE) of type WDY_BOOLEAN.
3.
Copy the context node MESSAGE_SETTINGS from the configuration
controller context to the component controller context. Map the node defined
in the component controller context to the node defined in the configuration
controller context.
4.
Edit the component controller method FLIGHTTAB_FILL( ). After having
read the flights using the static method READ_FLIGHTS( ), check the
internal table imported from this method. If the internal table is empty,
report a warning. If the internal table contains at least one line, report a
success message. However, report these messages only if the attribute
MESSAGES_SETTINGS.DISPLAY_MESSAGE is set to ABAP_TRUE.
Task 3:
Create a component configuration. Switch on the message display on the view
OUTPUT_VIEW. In addition change the following implicit options:
View
UI Element
INPUT_VIEW
OUTPUT_VIEW
1.
Property
Value
Button
Design
next
Image
Visible
none
Button
Design
back
both Tables
Design
Alternating
both Tables
ReadOnly
X
Create a component configuration for your component. Name the component
configuration ZNET310_CONF_##_COMP1.
Task 4:
Create an application configuration for your Web Dynpro application. Assign this
application configuration to your Web Dynpro application statically.
1.
Create the application configuration (name: ZNET310_CONF_##_APPL1).
Continued on next page
342
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Configuration and Personalization
Task 5:
Assign the application configuration to your Web Dynpro application statically. Test
your Web Dynpro application.
1.
2009
Add the name / value pair WDCONFIGURATIONID /
ZNET310_CONF_##_APPL1 to the parameter list of your Web
Dynpro application.
© 2008 SAP AG. All rights reserved.
343
Unit 10: Adaptation Techniques
NET310
Solution 15: Adaptation via Configuration
Task 1:
Copy the template NET310_POP_S1 or your component ZNET310_POP_## to
Web Dynpro component ZNET310_CONF_##. Create an application to access your
component. Test the functionality of your applicatin.
1.
Copy the template, activate your component, and create a Web Dynpro
application.
a)
Perform these steps as in previous exercises.
Task 2:
You would like to offer the possibility to display a message on the view
OUTPUT_VIEW indication if reading the flights was successful or not. However, it
should be possible to configure if this message is displayed. Thus you have to define a
configuration controller providing the interface to adapt this behavior.
1.
2.
In your Web Dynpro component, create a custom controller (name:
CONFIG_CTRL) and make this controller the component’s configuration
controller.
a)
Create the custom controller by choosing the option from the context menu
of your component.
b)
From the context menu of the custom controller, choose (Re)Set as Config.
Controller to make this custom controller the component’s configuration
controller.
In the context of the configuration controller, define a node
(name: MESSAGE_SETTINGS) having a single attribute (name:
DISPLAY_MESSAGE) of type WDY_BOOLEAN.
a)
3.
Perform this step as in previous exercises.
Copy the context node MESSAGE_SETTINGS from the configuration
controller context to the component controller context. Map the node defined
in the component controller context to the node defined in the configuration
controller context.
a)
Perform this step as in previous exercises.
Hint: The configuration controller has to be added to the list of
used controllers for the component controller.
Continued on next page
344
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Configuration and Personalization
4.
Edit the component controller method FLIGHTTAB_FILL( ). After having
read the flights using the static method READ_FLIGHTS( ), check the
internal table imported from this method. If the internal table is empty,
report a warning. If the internal table contains at least one line, report a
success message. However, report these messages only if the attribute
MESSAGES_SETTINGS.DISPLAY_MESSAGE is set to ABAP_TRUE.
a)
Edit the component controller method FLIGHTTAB_FILL( ).
b)
Position the cursor below the call of the static method READ_FLIGHTS( ).
c)
Use the Web Dynpro Code Wizard to read the value of attribute
MESSAGES_SETTINGS.DISPLAY_MESSAGE.
d)
If this attribute is set to ABAP_TRUE define the following coding:
e)
Get the reference to the message manager.
f)
Check whether the internal table imported from method READ_FLIGHTS(
) is initial.
In this case get the text with identifier 003 from the assistance object.
Define an internal table having the line type WDR_NAME_VALUE. Add
two lines to display the current values of CARRID and CONNID instead of
the placeholders in the message text.
Finally report the text as a warning.
g)
If at least one flight is read from the data base, report the text with identifier
009 as a success message.
h)
Save your changes and activate your component.
i)
Source code see below.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
345
Unit 10: Adaptation Techniques
NET310
Task 3:
Create a component configuration. Switch on the message display on the view
OUTPUT_VIEW. In addition change the following implicit options:
View
UI Element
INPUT_VIEW
OUTPUT_VIEW
1.
Property
Value
Button
Design
next
Image
Visible
none
Button
Design
back
both Tables
Design
Alternating
both Tables
ReadOnly
X
Create a component configuration for your component. Name the component
configuration ZNET310_CONF_##_COMP1.
a)
Create the component configuration from the context menu of your
component. The configuration editor for Web Dynpro opens in the browser.
b)
On the first screen, enter the name of the component configuration to
be created. Click on the button having the text Create. This will open a
dialog box.
Enter a description and a package name and click on the OK button. A new
dialog box appears.
Enter the transport task the component configuration is to be assigned to
and click on the OK button.
On the next screen click on the tab labeled Component-Defined.
Set the value of the attribute DISPLAY_MESSAGE of node
MESSAGE_SETTINGS to ABAP_TRUE (check the check box).
Now click on the tab labeled Web Dynpro Built-In. Change the property
values as described above.
Click on the button with the text Save. Close the browser.
In the ABAP Workbench, refresh the object list. The component
configuration can be found as a subelement of the Web Dynpro component.
Continued on next page
346
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Configuration and Personalization
Task 4:
Create an application configuration for your Web Dynpro application. Assign this
application configuration to your Web Dynpro application statically.
1.
Create the application configuration (name: ZNET310_CONF_##_APPL1).
a)
Create the application configuration from the context menu of your
application. The configuration editor for Web Dynpro opens in the browser.
b)
On the first screen, enter the name of the application configuration to
be created. Click on the button having the text Create. This will open a
dialog box.
Enter a description and a package name and click on the OK button. A new
dialog box appears.
Enter the transport task the application configuration is to be assigned to
and click on the OK button.
On the next screen, select the second tab labeled Structure. Use the value
help related to the column Configuration to define which component
configuration is to be loaded for which component usage.
Finally, click the Save button. Close the browser.
In the ABAP Workbench, refresh the object list. The application
configuration can be found as a subelement of the Web Dynpro application.
Task 5:
Assign the application configuration to your Web Dynpro application statically. Test
your Web Dynpro application.
1.
Add the name / value pair WDCONFIGURATIONID /
ZNET310_CONF_##_APPL1 to the parameter list of your Web
Dynpro application.
a)
Edit your Web Dynpro application. Choose the Parameters tab.
b)
Enter WDCONFIGURATIONID in the Parameter column and the name of
your application configuration in the Value column.
c)
Start your application. Check the changes. The configured version of your
application should be displayed.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
347
Unit 10: Adaptation Techniques
NET310
Result
Comp.
Controller, Method FLIGHTTAB_FILL
METHOD flighttab_fill .
DATA lo_nd_flightinfo TYPE REF TO if_wd_context_node.
DATA lo_el_flightinfo TYPE REF TO if_wd_context_element.
DATA ls_flightinfo
TYPE
wd_this->element_flightinfo.
DATA lt_flighttab
TYPE
net310_t_sflight.
DATA lo_nd_flighttab
TYPE REF TO if_wd_context_node.
DATA lo_api_controller
TYPE REF TO if_wd_controller.
DATA lo_message_manager TYPE REF TO if_wd_message_manager.
DATA ls_params
TYPE
wdr_name_value.
DATA lt_params
TYPE
wdr_name_value_list.
DATA lv_text
TYPE
string.
DATA lo_nd_message_settings TYPE REF TO if_wd_context_node.
DATA lo_el_message_settings TYPE REF TO if_wd_context_element.
DATA ls_message_settings
TYPE wd_this->element_message_settings.
DATA lv_display_message
TYPE wd_this->element_message_settings-display_message.
* navigate from CONTEXT to FLIGHTINFO via lead selection
lo_nd_flightinfo = wd_context->get_child_node( name = wd_this->wdctx_flightinfo ).
* get element via lead selection
lo_el_flightinfo = lo_nd_flightinfo->get_element( ).
* get all declared attributes
lo_el_flightinfo->get_static_attributes(
IMPORTING
static_attributes = ls_flightinfo ).
* read all flights related to CARRID and CONNID entered by user
cl_net310_flightmodel=>read_flights(
EXPORTING
iv_carrid
= ls_flightinfo-carrid
iv_connid
= ls_flightinfo-connid
IMPORTING
Continued on next page
348
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Configuration and Personalization
et_flights = lt_flighttab ).
* read personalization data
lo_nd_message_settings = wd_context->get_child_node(
name = wd_this->wdctx_message_settings ).
lo_el_message_settings = lo_nd_message_settings->get_element( ).
lo_el_message_settings->get_attribute(
EXPORTING
name =
‘DISPLAY_MESSAGE‘
IMPORTING
value = lv_display_message ).
IF lv_display_message = abap_true.
*
get message manager
lo_api_controller ?= wd_this->wd_get_api( ).
lo_message_manager = lo_api_controller->get_message_manager( ).
IF lt_flighttab IS INITIAL.
*
report warning
ls_params-name = ’1’.
ls_params-value = ls_flightinfo-carrid.
APPEND ls_params TO lt_params.
ls_params-name = ’2’.
ls_params-value = ls_flightinfo-connid.
APPEND ls_params TO lt_params.
lv_text = wd_assist->get_text( ’003’ ).
lo_message_manager->report_warning(
message_text = lv_text
params
= lt_params ).
ELSE.
*
report success
lv_text = wd_assist->get_text( ’009’ ).
lo_message_manager->report_success(
message_text = lv_text ).
ENDIF.
ENDIF.
* navigate from CONTEXT to FLIGHTTAB via lead selection
lo_nd_flighttab = wd_context->get_child_node( name = wd_this->wdctx_flighttab ).
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
349
Unit 10: Adaptation Techniques
NET310
* bind table to context node FLIGHTTAB
lo_nd_flighttab->bind_table( new_items
= lt_flighttab
set_initial_elements = abap_true ).
ENDMETHOD.
350
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Configuration and Personalization
Lesson Summary
You should now be able to:
•
Adapt Web Dynpro applications using implicit configuration and personalization.
•
Create a configuration controller and implement explicit configuration.
2009
© 2008 SAP AG. All rights reserved.
351
Unit 10: Adaptation Techniques
Lesson:
326
NET310
Enhancements for Web Dynpro ABAP
Lesson Duration: 20 Minutes
Lesson Overview
The new enhancement concept of the ABAP Workbench enables the integration
of different concepts for modifying and enhancing development objects. The
enhancement concept is supported by the Enhancement Builder tool and ABAP
language elements. The overall goal of the enhancement framework is to provide a
technology to create modification-free enhancements and to unify all possible ways of
modifying or enhancing Repository objects.
Lesson Objectives
After completing this lesson, you will be able to:
•
List the Web Dynpro adaptation options offered by the new enhancement
concept.
This is a short version of the lesson with the same title being part of NET311.
Business Example
You have to adopt an Web Dynpro ABAP application that has not been developed in
your company. You know about the possibilities to change the look and feel of Web
Dynpro applications via configuration and personalization. However, these techniques
are not sufficient since not only the UI element properties have to be changed. In
addition you know that SAP offers enhancement techniques to change repository
objects modification-free. Thus you would like to know, whether modification-free
enhancement possibilities do also exist for Web Dynpro ABAP and what kind of
changes are supported.
Enhancement Concept
In many cases, it will be necessary to change or enhance applications delivered by
SAP or ones that already exist. Unstructured changes to the source code or layout of
an application are called modifications. Modifications can cause conflicts when a new
release of the application programs is to be imported.
352
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Enhancements for Web Dynpro ABAP
The new enhancement concept of the ABAP Workbench (Enhancement Framework as of SAP NetWeaver 7.0) enables the integration of different concepts for modifying
and enhancing development objects. The enhancement concept is supported by the
Enhancement Builder tool, which is integrated in the ABAP Workbench and ABAP
language elements (ABAP language elements are not yet supported by Web Dynpro
ABAP).
The aim of the new enhancement concept is to unify all possible ways of modifying or
enhancing SAP products (more precisely, Repository objects of the SAP NetWeaver
Application Server ABAP), which go beyond the scope of Customizing.
In the context of the new enhancement concept, the following can be handled as
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 incorporates
enhancements of Repository objects at predefined positions called
enhancement options.
Here, the general introduction to the enhancement framework is finished. If you
want to be prepared for customer questions, please check out the pretty good
documentation for this topic on the help portal (http://help.sap.com). It’s good to
know the terms explicit enhancement, implicit enhancement, possible enhancement
options, enhancement element, enhancement spot, and enhancement implementation.
The enhancements of the enhancement concept can be switched using the Switch
Framework. This means that an enhancement takes effect when the package in which
the above enhancement components are defined is assigned to a switch of the Switch
Framework and this switch is not deactivated.
Enhancements for Web Dynpro ABAP
You can create enhancement implementations for existing applications that were
implemented using Web Dynpro for ABAP. These enhancement implementations are
independent development objects that are managed separately from the respective
original object. They are part of the enhancement concept that was integrated into the
2009
© 2008 SAP AG. All rights reserved.
353
Unit 10: Adaptation Techniques
NET310
ABAP Workbench in the SAP NetWeaver Application Server 7.0. The original objects
enhancement implementations are based on are not changed by such an enhancement
and can therefore be updated whenever there is a release change.
Hint: Conflicts related to software updates can be solved using transaction
SPAU_ENH.
ABAP source texts in a Web Dynpro application can be enhanced using BAdIs. For
this purpose, explicit anchor points (called enhancement options) are implemented in
the source code at suitable points during the development of the application. Using
these options, you can insert a separately developed BAdI later on into the flow of the
program. Each BAdI is therefore an explicit enhancement.
An implicit enhancement, on the other hand, does not need any advance
implementation through the application development department.
In addition to the source code enhancements described above, you can also perform
enhancements to individual sections of a Web Dynpro component. For example, you
can insert UI elements into a view or suppress them, or you can insert new nodes
in a controller context.
In this lesson, implementing implicit enhancements is discussed in detail. Besides
BAdIs, explicit enhancement options are not available for Web Dynpro ABAP yet.
Start Web Dynpro application NET311_ENH_D1 (version without implementation)
and in a second browser window start NET311_ENH_D2 (enhanced version).
Compare.
354
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Enhancements for Web Dynpro ABAP
Figure 136: Enhancements: Web Dynpro application without enhancements
Figure 137: Enhancements: same Web Dynpro application with enhancements
2009
© 2008 SAP AG. All rights reserved.
355
Unit 10: Adaptation Techniques
NET310
Enhancements in Detail
The following Web Dynpro entities can be enhanced modification-free using the
new enhancement framework. The first list contains the enhancement options for all
kinds of Web Dynpro controllers.
Most of the enhancement options possible for Web Dynpro ABAP (SAP NetWeaver
7.0 EhP1, SAP_ABA SPS1) have been applied to the application NET311_ENH_D2.
•
•
•
•
•
•
•
•
•
•
At the beginning and at the end of each method, pre-exit and post-exit methods
can be created that are called at the beginning of this method or at the end of this
method, respectively.
Overwriting the complete source code of an existing controller method is
facilitated by means of an overwrite-exit.
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.
Context mapping can be updated.
The list of used components/controllers can be extended statically.
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.
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.
For the component controller and custom controllers, new events can be defined.
356
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Enhancements for Web Dynpro ABAP
For Web Dynpro components, the list of used components can be extended statically.
The following enhancement options do not exist for SAP NetWeaver 7.0:
Creating an Enhancement Implementation
In order to use a predefined enhancement option, an enhancement implementation
has to be created and activated.
Hint: Enhancing of Web Dynpro controllers is only possible, if the related
Web Dynpro components belong to a software component having the correct
system change settings (Transaction SE06).
2009
© 2008 SAP AG. All rights reserved.
357
Unit 10: Adaptation Techniques
NET310
Figure 138: Prerequisite for enhancing repository objects: adequate system
change settings
Hint: Deactivating enhancement implementations is only possible
via the switch framework. To use this functionality, the enhancement
implementations have to be stored in a package that is assigned to a switch
(Transaction SFW1). In addition, this switch has to be assigned to a
business function (Transaction SFW2). Then, activating / deactivating the
enhancement implementations can be realized by activating the related
business function using transaction SFW5.
To create an enhancement implementation for any Web Dynpro controller, the
controller object has to be displayed (not edited) in the ABAP Workbench. Next, for
switching to the enhancement implementation mode, the related icon in the button
bar has to be clicked (or menu entry <left menu> Enhance, or key combination
Ctrl + F4). A dialog box will pop up asking for the name of the enhancement
implementation to use. You can either create a new enhancement implementation or
you can select an existing one, if available.
→
To switch back to the display mode of the controller, the button to toggle between
the display mode and the change mode has to be pressed once (or menu entry <left
menu> Display <-> Change, or key combination Ctrl + F1).
→
358
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Enhancements for Web Dynpro ABAP
Figure 139: Creating / extending an enhancement implementation
Open the enhancement implementation to list all changes.
2009
© 2008 SAP AG. All rights reserved.
359
Unit 10: Adaptation Techniques
NET310
Facilitated Discussion
Discuss on open questions.
Discussion Questions
Use the following questions to engage the participants in the discussion. Feel free to
use your own additional questions.
360
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Enhancements for Web Dynpro ABAP
Lesson Summary
You should now be able to:
•
List the Web Dynpro adaptation options offered by the new enhancement
concept.
2009
© 2008 SAP AG. All rights reserved.
361
Unit 10: Adaptation Techniques
Lesson:
334
NET310
Dynamic Modifications at Runtime
Lesson Duration: 80 Minutes
Lesson Overview
This lesson gives an introduction to dynamic modifications at runtime. This includes
changing the controller’s context hierarchy, changing a view’s UI element hierarchy
and assigning actions to UI elements.
Lesson Objectives
After completing this lesson, you will be able to:
•
•
•
Create context nodes and context attributes dynamically.
Create new UI elements in an existing UI element hierarchy dynamically.
Bind existing actions to UI elements dynamically.
Demos exist in the package NET310 for all techniques. Discuss these demos with
the students or – even better – develop something comparable while teaching. Be
prepared for questions that are not covered in this lesson (e.g. How can I map a
context node between controllers dynamically?; How can I search in a dynamically
created context for some information ... ?). All of these questions would cover a
two-day workshop of their own.
Business Example
You want to create a generic Web Dynpro component that can be used as a
subcomponent of many other consumer components (such as a Web Dynpro
component displaying all the details of an arbitrary entity). The generated UI differs
depending on the data the consumer component provides to the generic component
(for example, details of a flight or details of a booking). This problem can only be
solved if the context hierarchy and the UI element hierarchy are defined at runtime.
You wish to learn more about these topics.
362
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Dynamic Modifications at Runtime
Dynamic Runtime Modifications: Overview
Dynamic modifications can be made at runtime as follows:
•
Dynamic Context Manipulation
Context nodes and context attributes can be created and deleted. The meta data
of existing context elements can be modified.
•
Dynamic UI Manipulation
UI elements can be created and added to the UI element hierarchy. Existing
UI elements can be removed from the hierarchy, and their position or their
properties can be changed at runtime.
•
Dynamic Assignment of Actions to UI Elements
Statically created actions can be assigned to statically or dynamically created
UI elements.
Usually, you would declare the structure of a controller’s context at design time, and
then create a view’s layout statically in order to display the data stored in the declared
context. However, it is also possible to create a context structure and a view’s layout
partially or completely at runtime.
It is preferable, though, to create as much of the context and the view’s layout as
possible at design time. Dynamic programming comprises a significant amount
of manually written source code. There are several situations in which dynamic
modifications could be required:
•
•
•
2009
If the structure of the data is not known at design time
If the behavior of the screen will be generic
If Web Dynpro utility components have to be developed which work in a generic
manner
© 2008 SAP AG. All rights reserved.
363
Unit 10: Adaptation Techniques
NET310
Dynamic Context Modifications
Figure 140: Dynamic context data creation
The figure above shows an example of a controller context structure to be created at
runtime. The coding steps include the generation of two context nodes, one being a
subelement of the other, and context attributes related to these nodes.
Creating an Independent Context Node
All context nodes created by the application developer must have some other node
acting as their parent. This is why a context containing a root node is always supplied.
The root node is the anchor point for all other nodes, irrespective of whether they are
created statically at design time or dynamically at runtime.
Thus, in order to create a new independent context node, a reference to the meta data
of the context root node has to be obtained first. This reference is obtained by calling
the method wd_context->get_node_info( ).
Next, the new node has to be defined. To create a new node, the method
add_new_child_node( ) from the reference to the context root node can be used. This
method hands back the reference to the meta data of the new node.
An important parameter of the method add_new_child_node( ) is is_static. Only if
this parameter is set to abap_false can the related node can be deleted at runtime.
364
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Dynamic Modifications at Runtime
Figure 141: Dynamic Node Creation (1)
Figure 142: Dynamic Node Creation (2)
Creating Context Attributes
Each attribute of the previously created context node can be defined by calling the
method add_attribute( ) from the reference to the meta data of the node.
2009
© 2008 SAP AG. All rights reserved.
365
Unit 10: Adaptation Techniques
NET310
Figure 143: Dynamic attribute creation (1)
Figure 144: Dynamic attribute creation (2)
366
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Dynamic Modifications at Runtime
Here you can show demo NET310_DYN_D1A, View, Method WDDOINIT. If you
like, you may debug this method and show how the context is build up (look at
WD_CONTEXT or LO_ND_INFO_ROOT).
Creating a Context Node and Context Attributes from a Structure
Creating a context node and its attributes comprises a lot of manually written code,
since the method add_attribute( ) has to be called once for each attribute. However,
the method add_new_child_node( ) not only allows you to create a context node, but
also to create related attributes as follows:
•
•
•
An ABAP Dictionary flat structure type (structure, database view or transparent
table) can be passed to the method using the parameter static_element_type. All
attributes for this structure are created automatically.
An RTTI structure descriptor can be passed to the method using the parameter
static_element_rtti. The attributes are created accordingly.
Finally, a table, with each line containing one attribute description, can be passed
to the method using the attribute parameter. Attributes are created accordingly.
Figure 145: Dynamic creation of a context node from a DDIC structure (1)
2009
© 2008 SAP AG. All rights reserved.
367
Unit 10: Adaptation Techniques
NET310
Figure 146: Dynamic creation of a context node from a DDIC structure (2)
Here you can show demo NET310_DYN_D1, View, Method WDDOINIT. If you
like, you may debug this method and show how the context is build up (look at
WD_CONTEXT or LO_ND_INFO_ROOT).
Creating Dependent Context Nodes
Creating a subnode of an already existing context node is very much the same as
creating an independent context node. However, now the reference to the meta data
of the parent node has to be obtained, which is different from the reference to the
context root node.
If a context node is created dynamically, the reference to the new node is returned by
the creation method. From this reference, further subnodes can be created. However,
the reference to a node’s meta data can also be obtained at any time by determining the
reference to the context node instance and then getting the reference to its meta data:
lo_nd_<node> =
wd_context->get_child_node( name = ’<node>’ ).
lo_nd_info_<node> =
lo_nd_<node>->get_node_info( ).
368
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Dynamic Modifications at Runtime
It is also possible to obtain the reference to the context root node’s meta data in the
first step and determine the reference to the node’s meta data afterwards:
lo_nd_info_root =
wd_context->get_node_info( ).
lo_nd_info_<node> =
lo_nd_info_root->get_child_node( name = ’<node>’ ).
The second approach is preferable, as the existence of the parent node is guaranteed.
Information about subnodes can be determined from the reference to the meta data of
an existing node (for example, by using method get_child_nodes( )). This allows you
to check the existence of subnodes before accessing them.
Figure 147: Dynamic subnode creation (1)
2009
© 2008 SAP AG. All rights reserved.
369
Unit 10: Adaptation Techniques
NET310
Figure 148: Dynamic subnode creation (2)
Additional Interesting Methods Acting on Context meta data
The following table lists methods that are not discussed in this section. All of these
methods belong to the interface IF_WD_CONTEXT_NODE_INFO.
Method
370
Meaning
get_attributes( )
Returns the meta data of all attributes
related to a given node
get_attribute( )
Returns the meta data of a certain
attribute related to a given node
get_child_nodes( )
Returns the meta data of all subnodes
related to a given parent node
get_child_node( )
Returns the meta data of a certain
subnode related to a given parent
node
get_parent( )
Returns the meta data of the parent
node to a given context node
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Dynamic Modifications at Runtime
Method
Meaning
remove_attribute( )
Deletes an attribute for a given
dynamic context node
remove_dynamic_attributes( )
Deletes all dynamically created
attributes for a given context node
remove_child_node( )
Deletes context node for a given
parent node
Discuss the demo NET310_DYN_D3A (everything besides WDDOMODIFYVIEW).
Debug. Take your time.
Exercise “Dynamic Modifications at Runtime”, tasks 1 and 2 only!
Dynamic UI Modifications
To display the value of dynamically created context attributes or to keep the UI
generic, the UI element hierarchy of a view can be manipulated at runtime.
The source code for all of these changes has to be defined in the standard hook method
wddomodifyview(), since only in this method is a reference to the UI element hierarchy
(parameter view) provided by the Web Dynpro runtime.
Wddomodifyview() is called just before the view layout is rendered and it is called
every time the view controller is processed. However, because Web Dynpro is a
stateful technology, the developer has to take note of how often the same coding
section is interpreted by the Web Dynpro runtime. The Web Dynpro runtime provides
a parameter, firsttime, that can be used to assure that the source code is processed only
once in the view controller’s lifetime. This parameter has the value abap_true if the
view’s layout is rendered the first time; otherwise it has the value abap_false.
2009
© 2008 SAP AG. All rights reserved.
371
Unit 10: Adaptation Techniques
NET310
Figure 149: Standard hook method wddomodifyview( )
The following coding principles must be adhered to during UI element manipulation:
•
•
•
•
372
Only perform direct manipulation of UI element objects when it is not possible
to control their behavior through context binding.
UI manipulation is only permitted within the wddomodifyview( ) method of the
view controller.
wddomodifyview( ) has a Boolean parameter called firsttime. Typically, you will
only build a dynamic UI element hierarchy when firsttime = abap_true. This
avoids unnecessarily rebuilding the UI element hierarchy.
Do not implement code that modifies the context in wddomodifyview( )! The
context should be considered “read-only” during the execution of this method.
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Dynamic Modifications at Runtime
Figure 150: Dynamic UI manipulation: example
Start demo NET310_DYN_D1, Display layout of view -> layout is generated
dynamically.
Accessing Elements
If new elements are going to be added to the UI element hierarchy of a view layout,
the first step is to get a reference to the container element which acts as the parent
for the new element. This container element could be the RootUIElementContainer
(for example, when beginning with an empty view layout) or any other container
element. To obtain this reference, methods of the parameter view have to be used. To
access an arbitrary element, the method get_element( ) can be called. To access the
RootUIElementContainer, the special method get_root_element( ) is appropriate,
since no additional information has to be provided.
Both methods return a reference of type IF_WD_VIEW_ELEMENT, which is a
general interface implemented by all UI element classes. Accessing the special
properties of a container element requires that you cast the reference to an object
2009
© 2008 SAP AG. All rights reserved.
373
Unit 10: Adaptation Techniques
NET310
with the correct type (down cast). The super class for all container UI elements is
CL_WD_UIELEMENT_CONTAINER. All UI elements are described by inheritors of
the superclass CL_WD_UIELEMENT.
Hint: To get familiar with the class hierarchy describing all the UI
elements, check the inheritance tree related to the abstract superclass
CL_WD_VIEW_ELEMENT
Here you could view the class CL_WD_VIEW_ELEMENT in the
navigation tree of the object navigator. Show all relevant subclasses
(CL_WD_LAYOUT with subclasses, CL_WD_UI_ELEMENT with subclasses, e.g.
CL_WD_ABSTRACT_INPUT_FIELD -> CL_WD_INPUT_FIELD). You can also
sketch the class hierarchy (e.g. white board).
Figure 151: Dynamic UI manipulation: accessing the container element (1)
374
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Dynamic Modifications at Runtime
Figure 152: Dynamic UI manipulation: accessing the container element (2)
Before adding new child elements to a container element, the element’s properties
should be adjusted. This is especially important for the Layout property, since this
influences the properties of the child elements.
To adjust properties that are not inherited by the container’s child elements, methods
of the container reference can be called (for example, set_width( )).
To assign the desired layout to the container element, a static method of the
class representing the layout must be called. All layout classes are subclasses of
CL_WD_LAYOUT.
Figure 153: Adjusting container properties and assigning the layout
2009
© 2008 SAP AG. All rights reserved.
375
Unit 10: Adaptation Techniques
NET310
Adding UI elements to a container
Before a new UI element can be added to the UI element hierarchy, the UI element has
to be created. A corresponding class describing the element exists for each kind of UI
element. All of these classes are subclasses of CL_WD_UIELEMENT. These classes
follow the naming convention CL_WD_<element_kind>, so the class describing a
Label UI element would be CL_WD_LABEL.
To create a new element, all of these classes offer a static method. These methods have
the name new_<element_kind>( ) and return a reference to an object representing
the UI element.
Set the properties of the UI elements by calling the appropriate methods of the
generated object.
To define the value of the property LayoutData, an object representing this
property has to be assigned to the UI element. For all possible values of the
property LayoutData, a corresponding class exists which has a static method
to create the property object and assign it to a UI element. All of these classes
are subclasses of CL_WD_LAYOUT_DATA and follow the naming convention
CL_WD_<layout_data_kind>. The static methods follow the naming convention
new_<layout_data_kind>( ).
Thus, to create an object representing LayoutData = MatrixHeadData, the static
method new_matrix_head_data( ) of the class CL_WD_MATRIX_HEAD_DATA must
be called.
To add a UI element to the UI element hierarchy, the add_child( ) method of the
parent element has to be used. The index parameter allows you to define where the
new element is inserted. If this parameter is not used, the new element is appended.
Hint: For composite UI elements like the table element, special methods
exist to create the parent UI element and all of its child elements. Examples
can be found in the helper class CL_WD_DYNAMIC_TOOL (for example,
method create_table_from_node( )).
376
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Dynamic Modifications at Runtime
Figure 154: Adding a new UI element to the UI element hierarchy (1)
Figure 155: Adding a new UI element to the UI element hierarchy (2)
2009
© 2008 SAP AG. All rights reserved.
377
Unit 10: Adaptation Techniques
NET310
Show demos NET310_DYN_D1 (easy version). A more complex but very instructive
demo is NET310_DYN_D1A. Here, the complete context is scanned for nodes. For
each node, a form is created for each of the node’s attributes. For each attribute,
a label and a related input field are created. If the user presses the button on the
layout, the complete UI element hierarchy is deleted and a single TextView is added
afterwards. Debug!
Additional Methods Acting on UI Element Hierarchy
The following table lists some methods that may be used to manipulate the context
of a view layout.
Method
378
Meaning
Available for
get_<prop>( )
Returns the value of the
property <prop>
all UI elements
set_<prop>( )
Sets the property <prop>
to the desired value
all UI elements
bind_<prop>( )
Binds the property’s value
to a context attribute/node
all UI elements
bound_<prop>( )
Returns the context
all UI elements
attribute/node to which the
property <prop> is bound
set_on<event>( )
Binds action to property
on<event> of UI element
UI elements able
to trigger events
get_on<event>( )
Gets action bound to
property on<event> of UI
element
UI elements able
to trigger events
get_child( ) /
get_children( )
Returns the subelement(s)
of a given UI element
container UI
elements
remove_child( ) /
remove_all_children( )
Deletes subelement(s) of a
given UI element
container UI
elements
add_child( )
Adds UI element to
the element hierarchy
of a container element;
position can be defined.
container UI
elements
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Dynamic Modifications at Runtime
Discuss the demo NET310_DYN_D3A (WDDOMODIFYVIEW). Debug. Take your
time.
Exercise “Dynamic Modifications at Runtime”, Task 3
Assigning Actions to UI Elements Dynamically
Certain UI elements can trigger client-side events (such as toggling a Checkbox or
selecting a Table row). Web Dynpro uses the concept of actions for the client-side
event to trigger the execution of a server-side method. Actions can be assigned
to UI element events either declaratively at design time or dynamically at runtime.
Actions assigned dynamically can only refer to existing server-side action handler
methods. It is not possible to define the source code of an action handler method
dynamically. But it is possible to define which existing action handler will be called
when a client-side event is caught.
2009
© 2008 SAP AG. All rights reserved.
379
Unit 10: Adaptation Techniques
NET310
Figure 156: Action declaration
You can assign an action to an UI element dynamically when creating the UI element
or at a later point in time. Any UI element that allows you to trigger client-side events
has a property on_<event> for each of the events. The static method used to create
such a UI element has an import parameter for each of the client-side events. This
allows you to hand over the name of the action to be assigned as a string.
For example, a Button has the property on_action related to the client-side event
“pressing the button”. The static method new_button( ) of the class CL_WD_BUTTON
is used to create the button. This method allows you to assign the action using the
import parameter on_action.
If an action is to be assigned to an already existing UI element, a corresponding setter
method can be used for the object representing the UI element. This method follows
the naming convention set_on_<event>( ). Thus, an action can be assigned to a
button, using the method set_on_action( ).
380
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Dynamic Modifications at Runtime
Figure 157: Assigning an action to a UI element (1)
Figure 158: Assigning an action to a UI element (2)
2009
© 2008 SAP AG. All rights reserved.
381
Unit 10: Adaptation Techniques
NET310
Here, you should show demo NET310_DYN_D2. Discuss the coding in
WDDOMODIFYVIEW.
Parameter Extraction
If an action is assigned to multiple UI elements, the action handler should be able to
distinguish between the UI elements in order to offer element-specific functionality.
All action handler methods have the interface parameter wdevent, which is filled by
the Web Dynpro runtime if a client-side event is triggered. The following information
can be extracted from this parameter:
•
wdevent
→ name:
The name of the client-side event (for example, ON_ACTION).
•
wdevent
→ parameters:
This internal table contains additional information about the UI element that
triggered the event. The table has the columns name and value.
The ID of the UI element that triggered the event is always contained in the
table. Additional name /value pairs may be available depending on the type of
UI element that triggered the event (such as CHECKED = ’X’ or CHECKED
= ’ ’ for a checkbox).
382
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Dynamic Modifications at Runtime
Figure 159: Action handling: the interface parameter WDEVENT
Here, you should debug the action handler methods of demo NET310_DYN_D2.
Look at WDEVENT->parameters. Here you can find the ID of the element that
triggered the client-side event.
If the information available from the interface parameter wdevent is not sufficient,
additional information can be passed from the UI element to the action handler
method. This technique is called parameter mapping. Details can be found in the
appendix of this course.
2009
© 2008 SAP AG. All rights reserved.
383
Unit 10: Adaptation Techniques
NET310
Coding Example: Data Browser
Figure 160: Example of dynamic programming (1)
384
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Dynamic Modifications at Runtime
Figure 161: Example of dynamic programming (2)
2009
© 2008 SAP AG. All rights reserved.
385
Unit 10: Adaptation Techniques
NET310
Figure 162: Example: WDDOBEFOREACTION and the action handler method
Figure 163: Example: checking user input
386
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Dynamic Modifications at Runtime
Figure 164: Example: building the context
Figure 165: Example: reading data and filling context
2009
© 2008 SAP AG. All rights reserved.
387
Unit 10: Adaptation Techniques
NET310
Figure 166: Example: defining the layout
388
© 2008 SAP AG. All rights reserved.
2009
NET310
359
Lesson: Dynamic Modifications at Runtime
Exercise 16: Dynamic Modifications at
Runtime
Exercise Duration: 50 Minutes
Exercise Objectives
After completing this exercise, you will be able to:
•
Create context nodes and context attributes dynamically
•
Add elements to the UI element hierarchy dynamically
Business Example
You want to develop a data browser based on Web Dynpro ABAP. Since the name of
the database table to be displayed is not known at design time, you want to define the
context structure and the UI at runtime.
Template: NET310_DYN_T
Solution: NET310_DYN_S
Task 1:
Copy the Web Dynpro component NET310_DYN_T to Web Dynpro component
ZNET310_DYN_##.
Test the functionality of the template Web Dynpro application.
1.
Copy the template and create a Web Dynpro application.
2.
Activate the component and test the application.
Result
The template component consists of two views: One view to enter the name of a
database table, and a second view to display the content of the database table.
The user input on the first view is checked. If the name entered in the input field
is not the name of a transparent table, an error message is displayed. Otherwise,
the second view is processed. In the template component, nothing is displayed on
the second view, since neither the context structure for storing the database table
content nor the TABLE UI element to display this content has been created yet.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
389
Unit 10: Adaptation Techniques
NET310
Task 2:
In the second view (RESULT_VIEW), method HANDLEIN_DEFAULT( ), define
a context structure for the selected database table. This structure should consist of
one node with attributes for each database table column. Read the first 100 data
sets from the selected database table and store the data in the dynamically defined
context structure.
1.
Edit the method HANDLEIN_DEFAULT( ) of the view RESULT_VIEW.
2.
Get the reference to the meta data of the context root node.
3.
Call the method ADD_NEW_CHILD_NODE( ) for this reference. Use the
pattern for calling methods to generate the statement.
Evaluate the export parameter STATIC_ELEMENT_TYPE with the name of
transparent table to be displayed (variable LV_TABNAME).
Evaluate the export parameter NAME, which is the name of the context node
to be created (name: DB_TABLE).
The method returns the reference to the generated context node. Store the
returned reference in the variable LO_ND_INFO_DYN. This reference variable
has already been created.
4.
Create the data object for the reference variable LR_DB_TAB. This data object
will be used to hold the data sets read from the database table.
Type this variable with an internal table type corresponding to the database
table the user wants to display.
Hint: Use the statement:
CREATE DATA <ref_var> TYPE TABLE OF (<type_var>).
Here, <ref_var> is the name of the data reference variable and
<type_var> is the name of the variable containing the name of the
transparent table.
5.
Dereference LR_DB_TAB into the field symbol <LT_DB_TAB>. This field
symbol has already been declared and will be used in the SELECT statement.
Continued on next page
390
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Dynamic Modifications at Runtime
6.
Select the first 100 rows of the database table requested by the user and store
them in field symbol <LT_DB_TAB>.
Hint: The table name can be used dynamically in the select statement
as follows:
SELECT * FROM (<type_var>) INTO ....
7.
Determine the reference to the context node you created previously. The
reference can be stored in the variable LO_ND_DYN, which has already been
defined.
8.
Call the method BIND_TABLE( ) for this reference to store the selected data
in the context. Use the pattern function for calling methods to generate the
statement.
Task 3:
In the second view (RESULT_VIEW), define a TABLE UI element as a child of the
already existing GROUP UI element (name: GROUP_1). Display the data stored in
the context structure you defined in the last task.
1.
Edit the hook method WDDOMODIFYVIEW( ) of the view RESULT_VIEW.
Check if this method is called for the first time (parameter FIRST_TIME).
2.
Get the reference to the GROUP UI element GROUP_1.
Call the method GET_ELEMENT( ) for the parameter VIEW. Use the pattern
for calling methods to generate the statement.
Hint: The method returns a reference of type IF_WD_VIEW_ELEMENT. To handle the object correctly, you have to cast this reference.
The correct type for GROUP UI elements is CL_WD_GROUP. You can
either work with two reference variables and cast after having called
the method, or change your statement in order to cast the receiving
parameter directly (GET_ELEMENT( ) is a functional method).
3.
Define a reference variable of type CL_WD_TABLE (name: LO_TABLE). This
will point to the TABLE UI element to be created later.
4.
Define a reference variable of type IF_WD_CONTEXT_NODE (name:
LO_ND_DYN). Store the reference to the node containing the selected data
sets in this reference variable.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
391
Unit 10: Adaptation Techniques
5.
NET310
Call the static method CL_WD_DYNAMIC_TOOL=>CREATE_TABLE_FROM_NODE( ) to create the TABLE UI element, and add it to the UI
element hierarchy. Use the pattern for calling methods to generate the statement.
Use an arbitrary UI element ID (parameter TABLE_ID; suggested name:
TABLE).
Pass the reference to the GROUP UI element to the method using the parameter
UI_PARENT.
Pass the reference LO_ND_DYN to the method using the parameter NODE.
Store the returned reference to the created TABLE UI element in the variable
LO_TABLE.
392
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Dynamic Modifications at Runtime
Solution 16: Dynamic Modifications at
Runtime
Task 1:
Copy the Web Dynpro component NET310_DYN_T to Web Dynpro component
ZNET310_DYN_##.
Test the functionality of the template Web Dynpro application.
1.
Copy the template and create a Web Dynpro application.
a)
2.
Perform this step as in previous exercises.
Activate the component and test the application.
a)
Perform this step as in previous exercises.
Result
The template component consists of two views: One view to enter the
name of a database table, and a second view to display the content of the
database table. The user input on the first view is checked. If the name
entered in the input field is not the name of a transparent table, an error
message is displayed. Otherwise, the second view is processed. In the
template component, nothing is displayed on the second view, since neither
the context structure for storing the database table content nor the TABLE
UI element to display this content has been created yet.
Task 2:
In the second view (RESULT_VIEW), method HANDLEIN_DEFAULT( ), define
a context structure for the selected database table. This structure should consist of
one node with attributes for each database table column. Read the first 100 data
sets from the selected database table and store the data in the dynamically defined
context structure.
1.
Edit the method HANDLEIN_DEFAULT( ) of the view RESULT_VIEW.
a)
2.
Get the reference to the meta data of the context root node.
a)
3.
Perform this step as in previous exercises.
Source code see below.
Call the method ADD_NEW_CHILD_NODE( ) for this reference. Use the
pattern for calling methods to generate the statement.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
393
Unit 10: Adaptation Techniques
NET310
Evaluate the export parameter STATIC_ELEMENT_TYPE with the name of
transparent table to be displayed (variable LV_TABNAME).
Evaluate the export parameter NAME, which is the name of the context node
to be created (name: DB_TABLE).
The method returns the reference to the generated context node. Store the
returned reference in the variable LO_ND_INFO_DYN. This reference variable
has already been created.
a)
4.
Source code see below.
Create the data object for the reference variable LR_DB_TAB. This data object
will be used to hold the data sets read from the database table.
Type this variable with an internal table type corresponding to the database
table the user wants to display.
Hint: Use the statement:
CREATE DATA <ref_var> TYPE TABLE OF (<type_var>).
Here, <ref_var> is the name of the data reference variable and
<type_var> is the name of the variable containing the name of the
transparent table.
a)
5.
Dereference LR_DB_TAB into the field symbol <LT_DB_TAB>. This field
symbol has already been declared and will be used in the SELECT statement.
a)
6.
Source code see below.
Source code see below.
Select the first 100 rows of the database table requested by the user and store
them in field symbol <LT_DB_TAB>.
Hint: The table name can be used dynamically in the select statement
as follows:
SELECT * FROM (<type_var>) INTO ....
a)
Source code see below.
Continued on next page
394
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Dynamic Modifications at Runtime
7.
Determine the reference to the context node you created previously. The
reference can be stored in the variable LO_ND_DYN, which has already been
defined.
a)
8.
Source code see below.
Call the method BIND_TABLE( ) for this reference to store the selected data
in the context. Use the pattern function for calling methods to generate the
statement.
a)
Source code see below.
Task 3:
In the second view (RESULT_VIEW), define a TABLE UI element as a child of the
already existing GROUP UI element (name: GROUP_1). Display the data stored in
the context structure you defined in the last task.
1.
Edit the hook method WDDOMODIFYVIEW( ) of the view RESULT_VIEW.
Check if this method is called for the first time (parameter FIRST_TIME).
a)
2.
Source code see below.
Get the reference to the GROUP UI element GROUP_1.
Call the method GET_ELEMENT( ) for the parameter VIEW. Use the pattern
for calling methods to generate the statement.
Hint: The method returns a reference of type IF_WD_VIEW_ELEMENT. To handle the object correctly, you have to cast this reference.
The correct type for GROUP UI elements is CL_WD_GROUP. You can
either work with two reference variables and cast after having called
the method, or change your statement in order to cast the receiving
parameter directly (GET_ELEMENT( ) is a functional method).
a)
3.
Define a reference variable of type CL_WD_TABLE (name: LO_TABLE). This
will point to the TABLE UI element to be created later.
a)
4.
Source code see below.
Source code see below.
Define a reference variable of type IF_WD_CONTEXT_NODE (name:
LO_ND_DYN). Store the reference to the node containing the selected data
sets in this reference variable.
a)
Source code see below.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
395
Unit 10: Adaptation Techniques
5.
NET310
Call the static method CL_WD_DYNAMIC_TOOL=>CREATE_TABLE_FROM_NODE( ) to create the TABLE UI element, and add it to the UI
element hierarchy. Use the pattern for calling methods to generate the statement.
Use an arbitrary UI element ID (parameter TABLE_ID; suggested name:
TABLE).
Pass the reference to the GROUP UI element to the method using the parameter
UI_PARENT.
Pass the reference LO_ND_DYN to the method using the parameter NODE.
Store the returned reference to the created TABLE UI element in the variable
LO_TABLE.
a)
Source code see below.
Result
View OUTPUT_VIEW, Method HANDLEIN_DEFAULT
METHOD handlein_default .
DATA lo_nd_info_root
TYPE REF TO if_wd_context_node_info.
DATA lo_nd_info_dyn
TYPE REF TO if_wd_context_node_info.
DATA lo_nd_table_name TYPE REF TO if_wd_context_node.
DATA lo_nd_dyn
TYPE REF TO if_wd_context_node.
DATA lo_el_table_name TYPE REF TO if_wd_context_element.
DATA lv_tabname
TYPE
DATA lr_db_tab
TYPE REF TO data.
string.
FIELD-SYMBOLS <lt_db_tab> TYPE ANY TABLE.
* read db table name from context
lo_nd_table_name = wd_context->get_child_node( wd_this->wdctx_table_name ).
lo_el_table_name = lo_nd_table_name->get_element( ).
lo_el_table_name->get_attribute(
EXPORTING
name
= ’TABLENAME’
IMPORTING
value
= lv_tabname ).
Continued on next page
396
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Dynamic Modifications at Runtime
TRANSLATE lv_tabname TO UPPER CASE.
* get meta data info of root context node
lo_nd_info_root = wd_context->get_node_info( ).
* create context structure
lo_nd_info_dyn = lo_nd_info_root->add_new_child_node(
static_element_type = lv_tabname
name
= ’DB_TABLE’ ).
* create data object of correct type and assign field symbol
CREATE DATA lr_db_tab TYPE TABLE OF (lv_tabname).
ASSIGN lr_db_tab->* TO <lt_db_tab>.
* read DB content
SELECT * FROM (lv_tabname)
INTO CORRESPONDING FIELDS OF TABLE <lt_db_tab>
UP TO 100 ROWS.
* bind table to context
lo_nd_dyn = wd_context->get_child_node( ’DB_TABLE’ ).
lo_nd_dyn->bind_table( <lt_db_tab> ).
ENDMETHOD.
View OUTPUT_VIEW, Method WDDOMODIFYVIEW
METHOD wddomodifyview .
DATA lo_group
TYPE REF TO cl_wd_group.
DATA lo_table
TYPE REF TO cl_wd_table.
DATA lo_nd_dyn TYPE REF TO if_wd_context_node.
* Check, whether this method has been processed before
IF first_time = abap_true.
* Get reference to group, which shall be modified
lo_group ?= view->get_element( id = ’GROUP_1’ ).
**********************************************************************************
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
397
Unit 10: Adaptation Techniques
NET310
* Define table bound to node DB_TABLE
**********************************************************************************
lo_nd_dyn = wd_context->get_child_node( name = ’DB_TABLE’ ).
lo_table = cl_wd_dynamic_tool=>create_table_from_node(
ui_parent = lo_group
table_id
= ’TABLE_DB_TABLE’
node
= lo_nd_dyn ).
** hide mark column
*
lo_table->set_selection_mode( value = cl_wd_table=>e_selection_mode-none ).
ENDIF.
ENDMETHOD.
398
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Dynamic Modifications at Runtime
Lesson Summary
You
•
•
•
2009
should now be able to:
Create context nodes and context attributes dynamically.
Create new UI elements in an existing UI element hierarchy dynamically.
Bind existing actions to UI elements dynamically.
© 2008 SAP AG. All rights reserved.
399
Unit Summary
NET310
Unit Summary
You should now be able to:
•
Adapt Web Dynpro applications using implicit configuration and personalization.
•
Create a configuration controller and implement explicit configuration.
•
List the Web Dynpro adaptation options offered by the new enhancement
concept.
•
Create context nodes and context attributes dynamically.
•
Create new UI elements in an existing UI element hierarchy dynamically.
•
Bind existing actions to UI elements dynamically.
400
© 2008 SAP AG. All rights reserved.
2009
Unit 11
Additional Topics
373
The NET310 package contains demos for each of the topics listed below. See the
appendix to view the individual steps for integrating WD applications into the SAP
NetWeaver Portal. In addition you can refer to demos located in the packages NET311
and NET312 which are available in the same system. These demos can be used
to answer customer questions about topics not mentioned here. Integrating SAP
Interactive Forms by Adobe, displaying business graphics, context menus, drag &
drop, using all kinds of UI elements (all NET312), using personalization to define the
used component, clone components, popups in detail, enhancements (all NET311).
Unit Overview
Beyond the topics covered in previous units, there are more concepts that the
developer of a Web Dynpro application may need to know about. These include using
the SAP List Viewer for Web Dynpro to display and change mass data, integrating
Web Dynpro applications into the SAP NetWeaver Portal, or embed SAP Interactive
Forms by Adobe.
Unit Objectives
After completing this unit, you will be able to:
•
•
•
•
•
2009
Use the SAP List Viewer component for Web Dynpro ABAP to display mass
data.
Explain how more sophisticated SAP List Viewer functionality can be
implemented.
Explain how Web Dynpro applications can be integrated into the SAP NetWeaver
Portal.
Implement portal eventing.
Embed SAP Interactive Forms by Adobe into Web Dynpro views.
© 2008 SAP AG. All rights reserved.
401
Unit 11: Additional Topics
NET310
Unit Contents
Lesson: SAP List Viewer for Web Dynpro ABAP ............................... 403
Exercise 17: Using the SAP List Viewer..................................... 411
Lesson: Portal Integration ......................................................... 417
Lesson: Integrating SAP Interactive Forms by Adobe ......................... 429
402
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson:
374
Lesson: SAP List Viewer for Web Dynpro ABAP
SAP List Viewer for Web Dynpro ABAP
Lesson Duration: 30 Minutes
Lesson Overview
This lesson discusses the reuse of the SAP List Viewer component for Web Dynpro
ABAP.
Lesson Objectives
After completing this lesson, you will be able to:
•
•
Use the SAP List Viewer component for Web Dynpro ABAP to display mass
data.
Explain how more sophisticated SAP List Viewer functionality can be
implemented.
For all topics listed above, demos are available in the package NET310. SAP List
Viewer is a tough topic, so check out the demos BEFORE teaching. In addition, there
are lots of system demos you should look at (see remarks at end of topics).
Business Example
You have created a Web Dynpro application. However, you know the classical ABAP
Dynpro. Here, the SAP List Viewer control can be used to display mass data. You
want to learn about using the SAP List Viewer component for Web Dynpro ABAP to
realize a more sophisticated UI.
SAP List Viewer for Web Dynpro ABAP
The Table UI element is the standard UI element in the Web Dynpro context to display
mass data. Basic functionality like selecting rows and scrolling vertically is provided
out of the box. The developer can set a large number of table properties at design
time to change the visual design and the functionality offered to the user at runtime.
However, in the classical SAP GUI, the developer and the user can work with the SAP
List Viewer control, which offers a much larger functionality.
2009
© 2008 SAP AG. All rights reserved.
403
Unit 11: Additional Topics
NET310
Such a control does not exist for Web Dynpro ABAP. However, SAP has developed
a generic component allowing to display mass data stored in an arbitrary context
node by a Table UI element. This component offers basic functionality by default.
This includes:
•
•
•
•
•
•
•
•
•
•
•
•
Printing (system with BI usage type has to be connected via RFC destination)
Exporting to Microsoft Excel
Filtering (also complex filter criteria for multiple columns)
Hiding columns
Changing sequence of columns
Sorting (multi column sorting)
Changing number of table lines displayed
Changing number of columns displayed
Changing table design
Toggling grid visibility
Changing print settings
Storing settings as personalization variant (also default variant)
Hint: If the Web Dynpro application is started in customizing mode
(adding sap-config-mode=X to the URL), the settings can be saved for
all users. In addition, the settings can be added to a transport request
using a customizing task.
404
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: SAP List Viewer for Web Dynpro ABAP
Figure 167: SAP List Viewer for Web Dynpro ABAP: basic functionality
Functionality not listed here, but offered by the Table UI element, can be added
programmatically (for details please refer to the section “Advanced Functionality:
Configuration Model”).
Using the SAP List Viewer component
The SAP List Viewer for Web Dynpro ABAP is implemented as a Web Dynpro
component. The name of this component is SALV_WD_TABLE. If the SAP List
Viewer is to be reused by any component, this component has to declare the usage of
the SAP List Viewer component. The interface view TABLE has to be embedded in a
window of the consumer component to display the SAP List Viewer. Finally, data has
to be exchanged between the main component and the SAP List Viewer component.
Here, external context mapping can be used, or the interface method set_data( ) can
be called to pass the reference to the data source node (mapping origin) to the SAP
List Viewer component.
2009
© 2008 SAP AG. All rights reserved.
405
Unit 11: Additional Topics
NET310
Figure 168: Using the SAP List Viewer in Web Dynpro ABAP
406
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: SAP List Viewer for Web Dynpro ABAP
The single steps of embedding are:
•
•
•
•
Add a component usage of component SALV_WD_TABLE to the list of used
components (Used Components tab).
If the SAP List Viewer’s interface view should be displayed as part of a view
assembly, define a ViewContainerUIElement in the layout of the corresponding
view.
Embed the SAP List Viewer interface view TABLE in the window of
the consumer component. If the interface view should be displayed as
part of a view assembly, embed the interface view in the corresponding
ViewContainerUIElement.
Make sure, that the component usage is instantiated before any interface method
is called. The corresponding source code may be defined in the component
controller or - if the interface view TABLE is part of a view assembly - in the
view defining the container area to embed the interface view. In this controller:
–
–
•
Add the component usage to the list of used components/controllers.
Define the source code making use of the code wizard. Choose any
controller method processed before the subcomponent’s interface method
is called.
Interchange the data. If the method set_data( ) is called, the following steps need
to be performed in the controller calling set_data( ):
–
•
Add the interface controller of the component usage to the list of used
components/controllers.
–
Define the source code making use of the code wizard. Get the reference
to the data source node and pass this reference to the subcomponent by
calling the method set_data( ).
If external context mapping is to be used, the following needs to be implemented:
–
–
–
–
Define an interface controller usage for the SAP List Viewer component
usage (from the context menu of the SAP List Viewer component usage in
the object tree of the ABAP Workbench).
Edit the interface controller usage.
Declare the component controller of the consumer component as a used
controller.
Define an external mapping between the data node of the interface
controller usage and the data source node of the consumer component
controller containing the data to be displayed.
Having performed all of these steps, the basic functionality of the SAP List Viewer
can be used.
2009
© 2008 SAP AG. All rights reserved.
407
Unit 11: Additional Topics
NET310
Start demo NET310_ALV_D1. Show standard functionality.
Embed the SAP List Viewer into one of your applications. Replace a TABLE UI
element.
Exercise “Using the SAP List Viewer”
Advanced Functionality: Configuration Model
When instantiating the SAP List Viewer component usage, a configuration model is
generated automatically. The configuration model offers a large number of methods
that allow adaptation of the look and feel of the SAP List Viewer. A reference to
the configuration model is returned by the interface controller method get_model(
) of the SAP List Viewer component usage. The model reference is of type
CL_SALV_WD_CONFIG_TABLE. This class implements several interfaces, allowing
changes in the following parts of the SAP List Viewer:
SAP List Viewer Configuration Model: Interfaces Implemented by the
Model Class
Interface Name
408
Usage
IF_SALV_WD_COLUMN_SETTINGS
Settings for the columns in the SAP
List Viewer output
IF_SALV_WD_EXPORT_SETTINGS
Settings for data export to Microsoft
Excel
IF_SALV_WD_FIELD_SETTINGS
Settings for the fields of the internal
data table (e.g., group aggregation)
IF_SALV_WD_FUNCTION_SETTINGS
Settings for user-defined functions
(e.g., position)
IF_SALV_WD_GRAPHICS_SETTINGS
Settings for embedded graphical
elements (e.g., ValueComparison UI
element displayed in table cell)
IF_SALV_WD_PDF_SETTINGS
Settings for data export to PDF (e.g.,
set margins)
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: SAP List Viewer for Web Dynpro ABAP
Interface Name
Usage
IF_SALV_WD_STD_FUNCTIONS
Settings for generic SAP List Viewer
functions (e.g., hide Print Version
button)
IF_SALV_WD_TABLE_HIERARCHY
Settings for hierarchical SAP List
Viewer list display (e.g., collapse
hierarchical view)
IF_SALV_WD_TABLE_SETTINGS
Settings for entire SAP List Viewer
output (e.g., make SAP List Viewer
available for edit)
Discuss the following demos:
NET310_ALV_D2: Component controller, method ALV_TABLE_SETTINGS. Here
the table and the column settings are changed.
NET310_ALV_D3: Component controller, method ALV_CELL_SETTINGS. The
text color and the background color of table cells are set here.
NET310_ALV_D4: Component controller, method ALV_CELL_VARIANT. The
design of some cells is changed here. This is guided by a cell variant. In addition, the
SAP List Viewer is editable (see method ALV_TABLE_SETTINGS).
Calling methods defined in these interfaces is possible from all standard hook methods
of a consumer component controller.
Advanced Functionality: Eventing
The SAP List Viewer component triggers a number of events to influence SAP List
Viewer processing. This may happen at certain points of time (for example, before
rendering a table cell) or as a reaction to a user action (for example, selecting a row
or clicking a button in a table cell). Methods defined in the main component can
register to these events.
For example, when the user clicks on a link or on a button defined in a table cell, the
SAP List Viewer component triggers the event ON_CLICK. If a method of the main
component has registered to this event, it will be processed after clicking.
The event ON_DATA_CHECK is triggered after the user has changed the value of a
table cell. Data checks can be performed in the main component.
2009
© 2008 SAP AG. All rights reserved.
409
Unit 11: Additional Topics
NET310
Figure 169: Advanced SAP List Viewer functionality
Show demo NET310_ALV_D5. If the user clicks on a button or on a link, the SAP
List Viewer component triggers an event. The event parameters are displayed below
the SAP List Viewer. Discuss method ALV_EVENT_ON_CLICK.
410
© 2008 SAP AG. All rights reserved.
2009
NET310
381
Lesson: SAP List Viewer for Web Dynpro ABAP
Exercise 17: Using the SAP List Viewer
Exercise Duration: 30 Minutes
Exercise Objectives
After completing this exercise, you will be able to:
•
Reuse the SAP List Viewer component
Business Example
You have created a view that contains a Table UI element to display mass data. The
functionality of this element is restricted. For this reason you want to display the data
using the SAP List Viewer which offers more features, even in the basic version
(without having to add custom code).
Template: NET310_CONF_S1
Solution: NET310_ALV_S
Task 1:
Copy your Web Dynpro component ZNET310_CONF_## or the template
NET310_CONF_S1 to Web Dynpro component ZNET310_ALV_##. Create an
application to access your component.
1.
Copy the template.
2.
Activate the component. Create a Web Dynpro application and test the
application.
Task 2:
Embed the SAP List Viewer component SALV_WD_TABLE into your component.
Replace the flight table on the view OUTPUT_VIEW with the interface view TABLE
of the SAP List Viewer component.
1.
Declare the usage of the SAP List Viewer component in your component.
2.
In the view OUTPUT_VIEW, replace the TABLE UI element for displaying
flight information with a view container. Embed the interface view TABLE of
the SAP List Viewer component usage into this view container.
3.
Add the interface controller of the SAP List Viewer component usage to the list
of used controllers for the component controller.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
411
Unit 11: Additional Topics
4.
NET310
Create a new method in the component controller (name:
PROCESS_ALV_FLIGHTS). Implement the method:
Determine the reference to the context node FLIGHTTAB.
Instantiate the SAP List Viewer component usage if necessary.
Call the SAP List Viewer’s interface controller method SET_DATA( ) to
pass the reference to the context node FLIGHTTAB to the SAP List Viewer
component usage.
5.
Call the method PROCESS_ALV_FLIGHTS( ) each time the navigation to the
view OUTPUT_VIEW is conducted.
Task 3:
Test your Web Dynpro application.
1.
412
Activate the component with all of its constituents and test the application.
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: SAP List Viewer for Web Dynpro ABAP
Solution 17: Using the SAP List Viewer
Task 1:
Copy your Web Dynpro component ZNET310_CONF_## or the template
NET310_CONF_S1 to Web Dynpro component ZNET310_ALV_##. Create an
application to access your component.
1.
Copy the template.
a)
2.
Perform this step as in previous exercises.
Activate the component. Create a Web Dynpro application and test the
application.
a)
Perform this step as in previous exercises.
Task 2:
Embed the SAP List Viewer component SALV_WD_TABLE into your component.
Replace the flight table on the view OUTPUT_VIEW with the interface view TABLE
of the SAP List Viewer component.
1.
Declare the usage of the SAP List Viewer component in your component.
a)
2.
On the Used Components tab of your component, enter the name of the
SAP List Viewer component (SALV_WD_TABLE) in the Component
column and enter the usage name in the Component Usage column (name:
ALV_FLIGHTS).
In the view OUTPUT_VIEW, replace the TABLE UI element for displaying
flight information with a view container. Embed the interface view TABLE of
the SAP List Viewer component usage into this view container.
a)
Edit the layout of view OUTPUT_VIEW. Delete the table for
displaying the flights. Instead, insert a UI element of type
VIEWCONTAINERUIELEMENT at this position.
b)
Edit the window of your component.
c)
Open the Window tab. Select the view container defined in view
OUTPUT_VIEW and embed the interface view TABLE of the SAP List
Viewer component usage into this container.
Hint: From the context menu of the view container choose the
item Embed View.
Continued on next page
2009
© 2008 SAP AG. All rights reserved.
413
Unit 11: Additional Topics
3.
4.
NET310
Add the interface controller of the SAP List Viewer component usage to the list
of used controllers for the component controller.
a)
Edit the component controller.
b)
Open the tab labeled Properties. Add the interface controller of the SAP
List Viewer component usage to the list of used controllers.
Create a new method in the component controller (name:
PROCESS_ALV_FLIGHTS). Implement the method:
Determine the reference to the context node FLIGHTTAB.
Instantiate the SAP List Viewer component usage if necessary.
Call the SAP List Viewer’s interface controller method SET_DATA( ) to
pass the reference to the context node FLIGHTTAB to the SAP List Viewer
component usage.
5.
a)
For each coding section, the Web Dynpro Code Wizard can be used.
b)
Source code see below.
Call the method PROCESS_ALV_FLIGHTS( ) each time the navigation to the
view OUTPUT_VIEW is conducted.
a)
Call the method from the handler of the inbound plug IN_DEFAULT.
b)
Source code see below.
Task 3:
Test your Web Dynpro application.
1.
Activate the component with all of its constituents and test the application.
a)
Perform this step as in previous exercises.
Hint: All columns of the database table SFLIGHT are displayed,
because the context node FLIGHTTAB, which holds the data, is
typed with the dictionary structure SFLIGHT. You can use the SAP
List Viewer configuration option to hide columns and save the
result as your default variant.
Continued on next page
414
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: SAP List Viewer for Web Dynpro ABAP
Result
Comp.
Controller, Method PROCESS_ALV_FLIGHTS
METHOD process_alv_flights .
DATA lo_nd_flighttab
TYPE REF TO if_wd_context_node.
DATA lo_cmp_usage
TYPE REF TO if_wd_component_usage.
DATA lo_interfacecontroller TYPE REF TO iwci_salv_wd_table .
* navigate from CONTEXT to FLIGHTTAB via lead selection
lo_nd_flighttab = wd_context->get_child_node( name = wd_this->wdctx_flighttab ).
* instantiate ALV component usage if necessary
lo_cmp_usage = wd_this->wd_cpuse_alv_flights( ).
IF lo_cmp_usage->has_active_component( ) IS INITIAL.
lo_cmp_usage->create_component( ).
ENDIF.
* pass reference to data node to instance of ALV usage
lo_interfacecontroller = wd_this->wd_cpifc_alv_flights( ).
lo_interfacecontroller->set_data( r_node_data = lo_nd_flighttab ).
ENDMETHOD.
View OUTPUT_VIEW, Method HANDLEIN_DEFAULT
METHOD handlein_default .
DATA lo_componentcontroller TYPE REF TO ig_componentcontroller .
lo_componentcontroller = wd_this->get_componentcontroller_ctr( ).
lo_componentcontroller->flighttab_fill( ).
* lo_componentcontroller->customer_read(
).
lo_componentcontroller->process_alv_flights( ).
ENDMETHOD.
2009
© 2008 SAP AG. All rights reserved.
415
Unit 11: Additional Topics
NET310
Lesson Summary
You should now be able to:
•
Use the SAP List Viewer component for Web Dynpro ABAP to display mass
data.
•
Explain how more sophisticated SAP List Viewer functionality can be
implemented.
Related Information
The package SALV_WD_DEMO contains demos dealing with the usage of the SAP
List Viewer configuration model. Adapting table settings, column settings, and cell
settings, reacting on events triggered by the SAP List Viewer component and much
more can be implemented in a large number of Web Dynpro applications. The package
SALV_WD_DEMO can be found in SAP NetWeaver 7.0.
Additional information about SAP List Viewer topics not covered in this lesson can
be found in the documentation for SAP Net Weaver 7.0 or later, which is available
at http://help.sap.com. Open the documentation about Web Dynpro for ABAP and
navigate as follows: Web Dynpro ABAP: Development in Detail Integration
SAP List Viewer in Web Dynpro for ABAP
→
416
© 2008 SAP AG. All rights reserved.
→
2009
NET310
Lesson:
387
Lesson: Portal Integration
Portal Integration
Lesson Duration: 45 Minutes
Lesson Overview
This lesson covers the integration of Web Dynpro applications in the SAP NetWeaver
Portal. This includes special Web Dynpro functionality that is only available if Web
Dynpro applications are embedded in the SAP NetWeaver Portal as iViews.
Lesson Objectives
After completing this lesson, you will be able to:
•
•
Explain how Web Dynpro applications can be integrated into the SAP NetWeaver
Portal.
Implement portal eventing.
Additional information about iView generation, system definition, and page definition
is available in the appendix to this course.
A test portal has been set up at http://twdf0336.wdf.sap.corp:50100/irj/portal
for demo purposes. All trainers share the same portal and the same portal user
(portalsetup/trainer). Therefore, it is a good idea to create your own user on Monday,
before this common user may be locked on Friday :-)
The URL and user/password for this test portal may change in the future. Please
check out http://service.sap.com/curr-net for updates.
Business Example
You have created a Web Dynpro application. Now you want to embed your application
in the SAP NetWeaver Portal. In this context, your application should be able to
exchange information with other portal applications that may be non-SAP applications.
Portal Integration
The portal offers a single point of access to SAP and non-SAP information sources,
enterprise applications, information repositories, databases, and services inside and
outside your organization – all integrated into a single user experience. It provides
you with the tools to manage and analyze this knowledge, and to share and collaborate
on the basis of it.
2009
© 2008 SAP AG. All rights reserved.
417
Unit 11: Additional Topics
NET310
With its role-based content and personalization features, the portal enables users –
from employees and customers to partners and suppliers – to focus exclusively on data
relevant to daily decision-making processes.
Figure 170: SAP NetWeaver Portal
418
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Portal Integration
Portal Content Structure
Figure 171: Portal content structure
Content can be integrated into the SAP NetWeaver Portal by generating a related
iView. An iView (integrated view) is a logical portal content building block
representing a given visual application or a part thereof. iViews let you extend the
reach of your portal to any available information resource, regardless of where it
may be stored.
A portal page holds iViews and other portal pages organized in a layout. This allows
you to combine multiple iViews in rows and/or columns. Each iView is placed on a
tray, so it can be opened or closed when displaying the page in the portal.
Worksets let you bundle iViews and pages in folder hierarchies; for roles, for
example. Worksets represent generic, reusable structures or modules that can be added
to roles. A workset may be used in any number of roles, and a role may consist of a
number of different worksets.
Roles are the largest semantic unit within the content objects. A role is a folder
hierarchy comprising other content objects (worksets, pages, or iViews).
Roles are assigned to users. This means that users can only access the content that is
relevant to them if they have the appropriate role.
2009
© 2008 SAP AG. All rights reserved.
419
Unit 11: Additional Topics
NET310
Integrating Web Dynpro Applications into the SAP NetWeaver Portal
Web Dynpro applications can be integrated into the SAP NetWeaver portal; that is,
they can be bound into portal navigation as an iView. In addition, it is possible to
address portal functions from within a Web Dynpro application. For this purpose, you
can access portal manager methods (interface IF_WD_PORTAL_INTEGRATION) as
source code templates for the different functions by calling up the Web Dynpro Code
Wizard. This includes:
•
•
Using portal events
Navigation between Web Dynpro applications within the portal or to any other
portal content using:
–
–
–
Object-based navigation
Absolute navigation
Relative navigation
The main steps in the process of generating an iView for a Web Dynpro application are:
•
•
•
•
Defining the system in the SAP NetWeaver Portal system landscape
Defining the mapping between portal users and users in the previously defined
ABAP system
Creating iViews for Web Dynpro applications in the ABAP system
Combining different iViews that have to interact via the portal using a portal page
Using the notes in the appendix, create iViews for the WD applications
NET310_PORT_D1 and NET310_PORT_D2. Test the iViews.
When defining the iView, you have to add ?sap-client=<your_client> to the
application name (Figure: Portal iView generation II, step 2). Otherwise your
user and password are checked against client 000. Alternatively, you can also set
sap-client=<your_client> when defining the system.
420
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Portal Integration
Figure 172: Portal integration of Web Dynpro ABAP
Portal Eventing
If one Web Dynpro application needs to interact with another Web Dynpro application,
it can declare the usage of the other component. The other component’s interface is
then visible and usable by the consumer component. This type of coupling is called
tight coupling.
In the SAP NetWeaver Portal, you can process different application types in special
iViews on the same portal page. Here, iViews can be included using different
technologies (such as Web Dynpro ABAP, Web Dynpro Java, or Business Server
Pages). The communication between these iViews takes place through an event
function called portal eventing (or client-side eventing).
A Web Dynpro application can register for portal events. In this way, the Web Dynpro
application can react to an event that was triggered in another iView in the portal.
Therefore, it does not matter what technique you used to set up the application that is
the basis for the other iView. The assignment of which event handler is to be called
when an event occurs is stored in the Web Dynpro application that has registered
itself on the portal event.
2009
© 2008 SAP AG. All rights reserved.
421
Unit 11: Additional Topics
NET310
Similar to registration, a Web Dynpro application can trigger any portal event. In this
case, the event is passed to the portal by the respective iView. The portal passes the
event to all iViews that have registered for this event. The application that finally
handles this event can, in turn, have been set up with a different technique than the
Web Dynpro application triggering it.
Caution: Portal eventing functions only between iViews that are on the same
browser window. Events between iViews in different browser windows
cannot be transported. All participating iViews must also belong to the same
domain; otherwise, portal eventing cannot work due to JavaScript restrictions.
For this reason you have to add the domain name when working with the portal. If
you omit adding the domain, portal eventing will not work!
Figure 173: Portal eventing
422
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Portal Integration
Create a page containing both iViews in the portal. Test the page. Mark a line in
the first iView (Net310_PORT_D1). This will trigger a portal event. The second
application has registered for this event. Thus, the corresponding data set will appear
in the iView related to NET310_PORT_D2.
Raising a Portal Event from an Web Dynpro ABAP Application
The source code for triggering a portal event can be generated using the Web Dynpro
Code Wizard.
Figure 174: Triggering a portal event
2009
© 2008 SAP AG. All rights reserved.
423
Unit 11: Additional Topics
NET310
Portal events have to be triggered from a controller method of a view. Before a portal
event can be triggered, the reference to the portal manager has to be determined.
Three parameters must be exported when triggering an event:
•
portal_event_namespace
In each event name space, each event name is unique. The event name space
is an arbitrary string.
•
portal_event_name
Name of the triggered event (arbitrary string). The combination of event
namespace and event name identifies an event uniquely.
•
portal_event_parameter
This string contains all data that will be exchanged between the application
triggering the event and the application that registered for the event.
Thus, to be able to interact via portal eventing, the application triggering the event and
the application registering for the event have to use the same names for the event name
space and for the event name. In addition, the method of extracting the information
from the event parameter must be known to the application that subscribed to the
portal event.
Analyze the source code of NET310_PORT_D1. Generate the source code for
triggering an event in any of your applications.
Subscribe to a Portal Event in an Web Dynpro Application
The source code for subscribing to a portal event can also be generated using the Web
Dynpro Code Wizard. Only a view can subscribe with an action handler method to a
portal event. Subscribing to the portal event is to be implemented in the standard hook
method wddoinit( ) of the view. The name of the action whose related method will
handle the portal event has to be exported.
424
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Portal Integration
Figure 175: Subscribing to a portal event
In the event handler method, information about the portal event can be extracted from
the interface parameter WD_EVENT. The attribute WDEVENT->PARAMETERS is an
internal table containing name/value pairs in each row. In the portal event context,
three lines are filled containing the event name space, the event name, and the event
parameter. The event parameter can be extracted by adding importing parameters to
the action handler method’s interface having the name of the event parameters and
the type STRING.
2009
© 2008 SAP AG. All rights reserved.
425
Unit 11: Additional Topics
NET310
Figure 176: Handling the portal event
Analyze the source code of NET310_PORT_D2. Generate the source code for
triggering an event in any of your applications.
426
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Portal Integration
Facilitated Discussion
You may discuss the topics covered in this lesson.
Discussion Questions
Use the following questions to engage the participants in the discussion. Feel free to
use your own additional questions.
What are the pros and cons of using portal eventing for relating applications in the SAP
NetWeaver Portal? Is the concept of component reuse not always a better solution?
2009
© 2008 SAP AG. All rights reserved.
427
Unit 11: Additional Topics
NET310
Lesson Summary
You should now be able to:
•
Explain how Web Dynpro applications can be integrated into the SAP NetWeaver
Portal.
•
Implement portal eventing.
Related Information
Additional information about portal topics not covered in this lesson can be found
in the documentation for SAP Net Weaver 7.0 or later, which is available at
http://help.sap.com.
428
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson:
397
Lesson: Integrating SAP Interactive Forms by Adobe
Integrating SAP Interactive Forms by Adobe
Lesson Duration: 20 Minutes
Lesson Overview
This lesson discusses the integration of SAP Interactive Forms by Adobe into Web
Dynpro ABAP application views.
Lesson Objectives
After completing this lesson, you will be able to:
•
Embed SAP Interactive Forms by Adobe into Web Dynpro views.
Please refer to the demos of package NET312. You can find a demo dealing with
the integration of statical PDF documents, a demo dealing with the Integration of
print forms, a finally one using an interactive form. A detailed discussion of how to
integrate forms can be found in course NET312.
Business Example
You have created a Web Dynpro application. To allow the UI content displayed by
the Web Dynpro clients to be printed, you want to integrate SAP Interactive Forms
by Adobe in your application.
SAP Interactive Forms by Adobe
As of SAP NetWeaver 2004, you can use a new solution to create interactive forms
and print forms for the optimization of your form-based business processes. This
solution uses Portable Document Format (PDF) and software from Adobe Systems
Inc. that has been integrated into the SAP environment.
2009
© 2008 SAP AG. All rights reserved.
429
Unit 11: Additional Topics
NET310
Figure 177: Integration of SAP Interactive Forms by Adobe
Interactive Form Scenario
For collaborative business processes, you can design interactive forms containing drop
down menus, buttons, text fields, and other elements that allow user entries. The form
is rendered in PDF format and you provide it to users in, for example, a browser. Users
fill in the form and save their entries inside the form in XML format. The SAP system
extracts the data saved in the form and stores it in the database for further processing.
In general, you can use such forms in two different scenarios:
•
•
Online: The user is logged on to an SAP system while filling in the form.
Offline: The user is not logged on to an SAP system while filling in the form.
After completing the form, the user sends the form back to the form provider
(for example by e-mail). The provider’s SAP system then extracts the data
from the form.
Form Processing Scenario
You can create PDF-based forms for printing, sending by e-mail, or faxing by merging
SAP system data with a form template. You can rely on the proven principle of
separation of data collection and form layout, which provides the required flexibility
in the case of changes to one or the other.
430
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Integrating SAP Interactive Forms by Adobe
Online Interactive Form Scenario: Example
You can use Adobe interactive forms in scenarios where an employee typically needs
to fill in a form to start or advance a related business process.
Let’s take the example of an assembly line worker. The worker needs to order new
materials to keep the work going.
In a traditional setup, he would fill in a paper form, sign it, and send it by in-house
mail. In the case of an interactive form, the worker can log on to the internal company
portal and call up the required form, which is displayed in PDF format in the browser.
The interactive form looks like the old paper-based form. During the time that
the form is displayed, the worker is logged on to the system where the required
information will be processed further. When the form is displayed, it already contains
all the relevant information about the worker, such as his name, the location and cost
center to which he is assigned, and so on. This information is determined based on the
user logon, and is automatically filled in by the system.
Next, the worker fills in the required information on the form. When finished, he
submits the form back to the system using, for example, a button. The data is written
to the system, and the corresponding workflow moves the process to the next step.
The worker also has the ability to print out the interactive form locally.
Figure 178: Online interactive form scenario
2009
© 2008 SAP AG. All rights reserved.
431
Unit 11: Additional Topics
NET310
Offline Interactive Form Scenario: Example
While the last example was for an online scenario in which the user maintains a
system connection, Adobe interactive forms offer new opportunities through offline
usage as well.
In this scenario, a company running a marketing campaign from its SAP CRM system
determines that certain data from a customer is missing. The company wants to obtain
the data through a customer visit. Triggered by the CRM system, the existing relevant
customer data is pre-filled in the corresponding form, which also contains fields for
entering the missing data. The form is automatically e-mailed to the responsible
sales representative.
The sales representative travels to the customer and, together with the customer
contact, fills in the form which he has received by e-mail and downloaded to his local
hard drive (or PDA). When finished, he prints the form for the customer’s records,
which is facilitated by the PDF format.
The sales representative then forwards the completed form to the SAP system. He can
do so by attaching it to an e-mail or by uploading it to the corresponding site in the
internal company portal upon his return to the office.
The SAP CRM system receives the data entered by the sales representative, processes
it, and automatically triggers the next step in the business process.
432
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Integrating SAP Interactive Forms by Adobe
Figure 179: Offline interactive form scenario
SAP Interactive Forms by Adobe: What Do They Look Like?
PDF forms look like your original paper form, and thus provide the familiar look and
feel users need to execute business processes quickly. Visual integrity and fidelity of a
form increase user acceptance.
Special functions of Adobe Reader allow users, among other features, to save PDF
forms locally, to distribute them via e-mail or an enterprise portal, to print them out, or
(from SAP NetWeaver 7.0) to sign them digitally before submitting them to the system.
All user entries made in a PDF form are stored in XML format and can thus easily
be transferred back into the SAP system. The integration of Adobe technology into
the SAP development environment also allows for pre-filling form fields with current
system information, including context-sensitive list boxes (value help) comparable
to SAP’s F4 help.
The necessary data is automatically extracted from the back-end system upon form
creation. When the form is returned to the system by the user, the XML-based data
is automatically returned to the system.
2009
© 2008 SAP AG. All rights reserved.
433
Unit 11: Additional Topics
NET310
Figure 180: SAP Interactive Forms by Adobe
SAP Interactive Forms by Adobe in Web Dynpro ABAP
PDF forms can be created and used for Web Dynpro user interfaces. The following
scenarios are available for Web Dynpro ABAP:
•
•
Print, offline, and display scenario: Here, unlike in the interactive scenario, it is
not only interactive PDF forms that are used.
Interactive scenario: For this scenario, interactive PDF forms are used.
The procedure for creating or using the relevant forms is largely the same for all
scenarios. For Adobe integration, the Adobe Library with the Interactive Form UI
element is provided in the Web Dynpro View Designer.
434
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Integrating SAP Interactive Forms by Adobe
Forms can be created and maintained independently of Web Dynpro applications
using the Form Builder (transaction SFP). You can integrate a form within every view
of any component. To include an existing form into a view, proceed as follows:
•
•
•
•
•
•
In the Web Dynpro Explorer, create a view for your component or select a view
into which to integrate the form.
In the layout of this view, add the UI element InteractiveForm to the UI element
hierarchy.
For the templateSource property, enter the name of the selected form (an input
help is available). Based on the interface of the selected form, a context node
with attributes is automatically created for the UI element InteractiveForm. The
dataSource property of the UI element is automatically bound to this context
node.
To define your form as an interactive form, select the check box for the enabled
property of the InteractiveForm UI element. By default, enabled is inactive; that
is, it is usually a non-interactive form.
Fill the created context structure, for example, by using a suitable supply
function.
Activate and test the application.
Hint: If your form is not of layout type “ZCI” (zero client installation),
additional boundary conditions are of importance. This is not discussed here.
2009
© 2008 SAP AG. All rights reserved.
435
Unit 11: Additional Topics
NET310
Figure 181: SAP Interactive Forms by Adobe in Web Dynpro ABAP
436
© 2008 SAP AG. All rights reserved.
2009
NET310
Lesson: Integrating SAP Interactive Forms by Adobe
Facilitated Discussion
You may discuss the topics covered in this lesson.
Discussion Questions
Use the following questions to engage the participants in the discussion. Feel free to
use your own additional questions.
2009
© 2008 SAP AG. All rights reserved.
437
Unit 11: Additional Topics
NET310
Lesson Summary
You should now be able to:
•
Embed SAP Interactive Forms by Adobe into Web Dynpro views.
Related Information
Additional information about integrating SAP Interactive Forms by Adobe into Web
Dynpro ABAP can be found in the documentation for SAP Net Weaver 7.0 or later,
which is available at http://help.sap.com.
438
© 2008 SAP AG. All rights reserved.
2009
NET310
Unit Summary
Unit Summary
You should now be able to:
•
Use the SAP List Viewer component for Web Dynpro ABAP to display mass
data.
•
Explain how more sophisticated SAP List Viewer functionality can be
implemented.
•
Explain how Web Dynpro applications can be integrated into the SAP
NetWeaver Portal.
•
Implement portal eventing.
•
Embed SAP Interactive Forms by Adobe into Web Dynpro views.
2009
© 2008 SAP AG. All rights reserved.
439
Course Summary
NET310
Course Summary
You should now be able to:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
440
Explain the architecture of a Web Dynpro component.
Describe the parts of a Web Dynpro controller.
Create context elements in Web Dynpro controllers.
Explain how navigation and data transfer in and between Web Dynpro
components can be realized.
Define the UI of a Web Dynpro component.
Internationalize a Web Dynpro application.
Define and send messages.
Define input help and semantic help related to UI elements.
Display dialog boxes.
Embed Web Dynpro components in other Web Dynpro components.
Manipulate the context and the UI element hierarchy at runtime.
Use the ABAP List Viewer (ALV) in the Web Dynpro UI.
Configure and personalize Web Dynpro components.
Integrate Web Dynpro applications into the SAP NetWeaver Portal.
© 2008 SAP AG. All rights reserved.
2009
Appendix 1
Phase Model
Figure 182: Phase model: processing controller methods
2009
© 2008 SAP AG. All rights reserved.
441
Appendix 1: Phase Model
442
NET310
© 2008 SAP AG. All rights reserved.
2009
Appendix 2
Dynamic Programming - Advanced Topics
Parameter Mapping
All action handler methods have the interface parameter wdevent, which is filled by
the Web Dynpro runtime if a client-side event is triggered. Information about the UI
element that triggered the event can be extracted from the action handler’s interface
parameter wdevent->parameters. If the information available from the interface
parameter wdevent is not sufficient, additional information can be passed from the UI
element to the action handler method. To do this, a list of name/value pairs can be
mapped to any event of the UI element. This must be performed in the hook method
wddomodifyview( ).
The parameter list is mapped to an event of the UI element object by using the
appropriate mapping method. For each client-side event, a different parameter list can
be added. The mapping methods follow the naming convention map_on_<event>.
2009
© 2008 SAP AG. All rights reserved.
443
Appendix 2: Dynamic Programming - Advanced Topics
NET310
Figure 183: Parameter mapping (1)
Figure 184: Parameter Mapping (2)
444
© 2008 SAP AG. All rights reserved.
2009
NET310
Appendix 2: Dynamic Programming - Advanced Topics
If an event of the UI element is triggered, the related parameter list is sent back to the
server. The name/value pairs are attached to the internal table wdevent->parameters
by the Web Dynpro runtime environment. To access the name/value pairs, methods
of the wdevent object can be called (e.g. get_string( ’<name>’ ), or get_object(
’<name>’ ). A second possibility is to add the names of the name/value pairs to the
list of importing parameters for the action handler method. Then, the parameters are
filled with the values of the event parameters having the same name by the Web
Dynpro runtime. All non-optional importing parameters need to be contained in the
internal table wdevent->parameters. If this is not the case, the application will dump.
2009
© 2008 SAP AG. All rights reserved.
445
Appendix 2: Dynamic Programming - Advanced Topics
446
© 2008 SAP AG. All rights reserved.
NET310
2009
Appendix 3
Input Help - Advanced Topics
Object Value Selector (OVS)
There are situations when reusing existing ABAP dictionary input helps is not
sufficient.
Say you want the input help to consider or fill multiple input fields of your view
composition. But the different input fields are related to different value nodes, which
in turn refer to different ABAP Dictionary structures. ABAP Dictionary search helps
are not able to fulfill this task, since the maximum scope of such a search help is
defined by the structure to which it is related to.
To overcome this restriction, complex input help can be implemented as part of the
Web Dynpro component. This kind of input help is referred to as the Object Value
Selector (OVS).
Debug the demo NET310_HLP_D3 line by line. Before debugging, show how to
reuse the OVS component (see cookbook).
2009
© 2008 SAP AG. All rights reserved.
447
Appendix 3: Input Help - Advanced Topics
NET310
Figure 185: Object Value Selector (OVS)
A reusable Web Dynpro component is responsible for displaying the selection screen,
allowing you to enter restrictions for data retrieval and for displaying the values fitting
these restrictions. The consumer of this component (the parent component) has to
perform specific tasks such as defining the selection screen setup and data retrieval.
Data has to be exchanged between the two components. Thus, the OVS component
has to offer an interface that can:
•
•
•
•
•
Receive information about which input fields should be displayed on the
selection screen
Receive information about the initial values of these input fields
Hand back the user’s input into these input fields
Receive the result of the data retrieval in order to display the list
Hand the selected dataset back to the consumer program
Phase Model of the Object Value Selector
After you press the input help button of an input field in the consumer component,
the OVS component usage is processed. However, the OVS component usage needs
additional information from the consumer component at runtime (for example,
whether an additional selection screen be displayed, which fields should be displayed
448
© 2008 SAP AG. All rights reserved.
2009
NET310
Appendix 3: Input Help - Advanced Topics
on this selection screen, which information should be displayed as the input help and
so on). Thus, at certain points in time, control has to be given back to the consumer
component. This is done using the standard event handling technique.
Every time the OVS component usage requires information from the consumer
component, the OVS event is triggered by the OVS component usage. An additional
parameter, phase_indicator, indicates the type of information that is requested. An
event handler method of the consumer component has to subscribe to the OVS event.
Depending on the value of the phase_indicator parameter, different coding sections
can be implemented to collect the required information and hand it back to the OVS
component.
Note: For some of the phases, handing back information to the OVS
component is optional.
In order to hand back the information to the OVS component usage, the corresponding
methods of the sub component have to be called. A reference to the object
(ovs_callback_object) containing these methods is also provided by the OVS event.
Figure 186: OVS phase model
2009
© 2008 SAP AG. All rights reserved.
449
Appendix 3: Input Help - Advanced Topics
NET310
Phase 0 (phase_indicator = 0): This phase is also called the configuration phase.
Here the consumer can define which texts are to be displayed by the OVS component
usage, either in the selection screen dialog box or in the input help list. In addition,
you can define the number of columns used to structure the selection dialog box.
To export the information to the OVS component usage, call method set_configuration(
) of the callback object.
Hint: Calling method set_configuration( ) in phase 0 may be omitted if no
selection dialog box is to be displayed by the OVS component usage.
Hint: Label texts not provided by the consumer component are obtained from
the ABAP Dictionary if the related input fields are typed accordingly.
Phase 1 (phase_indicator = 1): In this phase, the consumer can define which input
fields are to be displayed in the selection dialog box. This is done by exporting an
arbitrary structure containing these fields. Default values for the selection fields can
be provided by setting the structure fields to the corresponding value.
To export the information to the OVS component usage, call method
set_input_structure( ) of the callback object. Then the selection screen can be
rendered.
Hint: Calling method set_input_structure( ) in phase 1 may be omitted. In
this case the selection screen will not be displayed. This is useful if the user
has already entered values in the input fields of the consumer component, so
displaying the same values again on the OVS selection dialog box before
displaying the input help is not needed.
Phase 2 (phase_indicator = 2): This phase is processed after the user presses the
button in the OVS selection dialog box (if processed). In this phase, the consumer
has to collect the data that will then be displayed as the input help list by the OVS
component usage. However, to collect this information, the consumer component
needs to know what the user has entered in the fields of the selection dialog box. The
reference (data reference) to this information is available from the query_parameters
parameter of the callback object.
To export the value list to the OVS component usage, call method set_output_table( )
of the callback object. The value list is displayed.
Phase 3 (phase_indicator = 3): After selecting a value from the value list, the
selection has to be transported back to the consumer component. Thus, the OVS event
is triggered a fourth time. The reference to the user selection is available from the data
450
© 2008 SAP AG. All rights reserved.
2009
NET310
Appendix 3: Input Help - Advanced Topics
reference variable selection, which is a parameter of the callback object. In the related
coding section of the consumer component’s event handler method, these values
have to be written back to the context. The selected data is displayed as input field
values of the consumer component’s view.
Figure 187: Object Value Selector: distinguishing phases
Cookbook for Using the OVS
The following steps must be performed in order to use the OVS concept:
•
•
•
•
2009
A component usage of the component WDR_OVS has to be declared by the
consumer component.
A usage of the OVS interface controller has to be declared in a controller of the
consumer component, for example the component controller or the displaying
view controller.
The input help mode Object Value Selector has to be chosen for the attribute
under consideration.
A handler method for event OVS of the OVS component usage has to be created
and implemented.
© 2008 SAP AG. All rights reserved.
451
Appendix 3: Input Help - Advanced Topics
NET310
User-Defined Input Help
In addition to the input help technique discussed above, a developer can define a
completely user-defined input help. Technically, this kind of input help is implemented
as a Web Dynpro component implementing the Web Dynpro component interface
IWD_VALUE_HELP. To use the input help for a certain input field, the following
steps are required:
•
•
•
A component usage of the input help component (HC) has to be declared by the
consumer component (CC).
A usage of the HC interface controller has to be declared in the CC view.
The input help mode User-Defined Programming has to be chosen for the
attribute under consideration. The HC usage must be related to this attribute.
The component interface of the HC has only one method: set_value_help_listener(
). This method is called by the Web Dynpro runtime environment if the input help
button of the input field under consideration is clicked.
The HC must be implemented as follows:
•
•
•
•
The method set_value_help_listener( ) has an import parameter. This means that
the reference to the listener, provided by the Web Dynpro runtime environment,
is passed to the user-defined HC. This reference has to be saved as a user-defined
controller attribute.
To close the help value dialog box, the close_window( ) method of the listener
has to be used.
All views have to be embedded in a window named WD_VALUE_HELP. This
name is used by the Web Dynpro runtime environment.
Context mapping can be used to exchange data between the CC and the HC.
Hint: To implement the component interface IWD_VALUE_HELP, you need
to choose the Reimplement button in the HC. The implementation status
changes to green and the events and the method of the component interface
are visible in the HC controller.
452
© 2008 SAP AG. All rights reserved.
2009
Appendix 4
Adapting Web Dynpro Applications - Advanced Topics
Explicit Customizing and Personalization
Start demo NET310_CONF_D3. The look and feel has been changed by the
configuration (implicit and explicit). Start customizing and personalizing the
application. Result: The attributes defined in the configuration controller are not
available for personalizing or customizing.
Now restart the application by adding sap-config-mode=X to the URL (Customizing).
This time, start Customizing by clicking the link Filter Data. In addition to the known
functionality, an additional tab appears which allows you to change the attribute
values. This is explicit customizing. Check it out.
Repeat the last step without adding sap-config-mode=X to the URL (personalization).
In addition to the known functionality, an additional tab appears which allows you to
change the attribute values. This is explicit personalization. Check it out.
2009
© 2008 SAP AG. All rights reserved.
453
Appendix 4: Adapting Web Dynpro Applications - Advanced Topics
NET310
If the functionality offered by implicit customizing and implicit personalization is
not sufficient, the developer can extend the functionality almost at will. However,
here the developer has to write the complete source code to call up and process the
adaptation dialog. This includes:
•
•
•
•
•
Defining a UI element, which is used to start the adaptation process
Defining the source code in the related event handler method to call up the
adaptation dialog
Defining the dialog, which consists of the standard implicit adaptation function
(optional) and the additional explicit adaptation function
Defining the logic to close the adaptation dialog (typically via the Save and
Cancel buttons).
Defining the functional changes in the component related to the user’s input in
the adaptation dialog
Figure 188: Combining implicit and explicit customizing / personalization
To combine the functions of implicit and explicit customizing / personalization in
one dialog, the component interface IWD_PERSONALIZATION has to be declared
as a used component (interface) by the component offering the adaptation function.
This interface offers an interface view (imp_personalization) that can be embedded
454
© 2008 SAP AG. All rights reserved.
2009
NET310
Appendix 4: Adapting Web Dynpro Applications - Advanced Topics
in a view container of the main component in order to create a layout combining
implicit and explicit customizing / personalization. Typically, a view containing a
TabStrip with two tabs is used to define the layout. One tab contains all fields that
are used for explicit customizing / personalization. The other tab contains only
a ViewContainerUIElement. The view is embedded in an extra window, which
is necessary to display the windows content as a dialog box. The interface view
imp_personalization is then embedded in the ViewContainerUIElement.
In addition, the interface offers the method init_personalization( ), allowing handover
of a reference to the UI element that is implicitly adaptable (with all of its sub
elements; this could also be the RootUIElementContainer).
Hint: All controllers that need to access the interface of the
personalization component usage have to declare the usage of the interface
IWD_PERSONALIZATION. Typically this is the view containing the link to
start Customizing / personalization and the view embedding the interface
view imp_personalization.
Discuss the coding of NET310_CONF_D3 (optional).
2009
© 2008 SAP AG. All rights reserved.
455
Appendix 4: Adapting Web Dynpro Applications - Advanced Topics
456
© 2008 SAP AG. All rights reserved.
NET310
2009
Appendix 5
Portal Integration
Creating a New System
→
To access the Web Application Server (Web AS) from the SAP NetWeaver Portal, a
new system has to be defined. This is done by choosing System Administration
System Configuration
System Landscape.
→
→
On the Browse tab, you first create a new folder to group all the systems. Choose New
Folder from the context menu that appears when you click on the main Portal
Content node or any child node.
→
After selecting a folder, a new system is created from the context menu by choosing
New
System (from template). In the wizard, choose SAP system using.... There are
three entries allowing you to log on to an application server, to use load balancing and
to use an SAP router string. On the next screen, enter a System Name and System ID.
Choose Finish. On the next screen, choose Open the object for editing.
2009
© 2008 SAP AG. All rights reserved.
457
Appendix 5: Portal Integration
NET310
Figure 189: Portal: creating a new system (1)
Choose Object from the Display drop down box. Then choose Web Application Server
(Web AS) as the Property Category. Enter the System ID, the URL (including the
port), the path to the Web Dynpro applications (default: sap/bc) and the protocol http.
Change the Property Category to User Management. On the related screen, select
Logon Method = UIDPW. This will allow everyone to log on, filling the user and
password in a logon dialog box that appears when starting the application from the
portal. In addition, choose User Mapping Type = admin,user. This allows to map all
portal users to back-end users. Fix the client by set SAP-Client = <your client>.
In the next step, an alias has to be created for the system. Choose Display = System
Alias. Enter an alias and press the Add button. Choose Save.
458
© 2008 SAP AG. All rights reserved.
2009
NET310
Appendix 5: Portal Integration
Figure 190: Portal: creating a new system (2)
User Mapping
→
At least for testing purposes, it is easiest to map the portal user to a user in the back-end
system. Choose User Administration
Identity Management. Enter your portal user
name in the input field and choose Go. Your user appears in the table below.
Mark the related table line. The details of your user now appear below the table listing
your user. The tabs allow you to select the details of your user. Select the rightmost
tab with the label User Mapping.
Select the alias of your system from the drop down box System. Press Modify. Enter
your user and password in the appropriate fields. Choose Save.
2009
© 2008 SAP AG. All rights reserved.
459
Appendix 5: Portal Integration
NET310
Figure 191: Portal: defining user mapping
Creating iViews for Web Dynpro ABAP Applications
Now that the technical system and the user mapping have been defined, iViews can be
created for the Web Dynpro applications.
460
© 2008 SAP AG. All rights reserved.
2009
NET310
Appendix 5: Portal Integration
Figure 192: Portal: iView Generation (1)
1.
→
To start the process, choose Content Administration
Portal Content. On
the right side of the browser window, select the Browse tab. Open the Portal
Content node and the subnode you want to use to group the content you develop.
To create a new folder, select New
Folder from the context menu that appears
when you click the Portal Content node or any child node. Choose New
iView from the context of the selected node. On the right side, select the type of
iView wizard you want to use.
Select the iView template radio button. This opens a special wizard offering you
a large set of predefined iView patterns.
On the first screen of this wizard (Step 1), select SAP Web Dynpro iView.
Next (Step 2), enter a name and an ID for the iView.
→
2.
3.
4.
2009
© 2008 SAP AG. All rights reserved.
→
461
Appendix 5: Portal Integration
NET310
Figure 193: Portal: iView Generation (2)
1.
2.
3.
On the third screen, select ABAP as the Web Dynpro Definition Type.
Finally, on screen four, application parameters have to be provided as follows:
The system alias has to be entered in the System field. SAP is the default
Namespace. This value will be added to the path of the Web Dynpro application.
The Web Dynpro application name has to be entered in the Application Name
field. Optionally, the name of an application configuration and/or application
parameters can be added (for example, sap-config-mode=X).
When the iView generation is finished, the result can be checked by choosing
Preview from the context menu of the iView.
Combining iViews on a Page
Multiple iViews can be arranged on a visible page using a portal page object.
462
© 2008 SAP AG. All rights reserved.
2009
NET310
Appendix 5: Portal Integration
Figure 194: Portal: Combining iViews on a Page (1)
1.
→
To create a page and its content, choose Content Administration
Portal
Content. On the Browse tab, locate the node that you want to use as the page’s
parent node. Create a portal page from the context of the node (choose New
Node).
On the following screen, enter the name and the ID of the page.
The next page offers two page templates: Default Page Template and Web
Dynpro Proxy Page. Choose the Default Page Template.
Next, the page layout has to be defined. To display two iViews, with one below
the other, choose 1 Column (Full Width). Choose Add, then Next.
To adjust the properties of the page and to assign the iViews, select Open the
object for editing on the next screen. Choose OK.
→
2.
3.
4.
5.
2009
© 2008 SAP AG. All rights reserved.
463
Appendix 5: Portal Integration
NET310
Figure 195: Portal: Combining iViews on a Page (2)
1.
2.
464
→
On the right side, a list of the iViews that are already embedded in the portal
page appears. To add another iView to the page, choose Add iView to Page
Delta Link from the context menu of the iView to be embedded.
By switching from Page Content to Page Layout, the resulting structure of the
page can be analyzed.
© 2008 SAP AG. All rights reserved.
2009
NET310
Appendix 5: Portal Integration
Figure 196: Portal: Combining iViews on a Page (3)
The last step in creating the page is to adapt the page’s properties. There are properties
related to the page object and there are properties related to the embedded iViews.
1.
2.
2009
An important group of properties is the Property Category Appearance Size. For
the portal page, the Height Type should be adjusted to Full Page. For the single
iViews, this property should be changed to Automatic so that the iView’s height
depends on the space the Web Dynpro application occupies.
You can test the result by choosing Preview, which can be found on top of the
tab page.
© 2008 SAP AG. All rights reserved.
465
Appendix 5: Portal Integration
466
NET310
© 2008 SAP AG. All rights reserved.
2009
Index
A
adaptation
explicit customizing, 454
personalization, 454
application, 24
assistance class texts, 201
attributes
WD_COMP_CONTROLLER, 153
WD_CONTEXT, 152
WD_THIS, 152
C
collection cardinality, 69
component, 9
component architecture
reuse, 23
visibility of entities, 20
component reuse, 277
component interface, 278,
280
context mapping, 288
dynamic component usage,
290
instantiating component
usage, 281
interface controller event,
286
interface controller method,
284
interface view, 283
component Reuse
declaring component usage,
280
composite UI elements, 109
configuration
2009
explicit, 337
implicit, 331
configuration and
personalization, 327
application configuration,
333
component configuration,
332
explicit configuration, 337
hierarchy, 328
implicit / explicit, 329
implicit configuration, 331
implicit customizing, 334
implicit personalization,
335
confirmation dialog box, 310
context, 9, 64
access at runtime, 154
access attributes, 159
access node, 156
add elements, 166
add node element, 169
bind internal table to node,
171
bind structure to node, 170
change attributes, 162
collection cardinality, 69
context mapping, 77
create node element, 167
delete node element, 172
dependent nodes, 70
element properties, 69
independent nodes, 70
lead selection, 72
singleton property, 73
© 2008 SAP AG. All rights reserved.
467
Index
NET310
supply function, 74
context mapping, 10, 77
cross-component, 288
external mapping, 80
internal mapping, 80
controller, 9
additional methods, 150
attributes, 151
context, 154
entities, 50
entities of component
controllers, 53
entities of custom
controllers, 53
entities of view controllers,
54
entities of window
controllers, 55
hook methods, 144
lifetime, 50
methods, 144
standard attributes, 152
types, 49
user-defined attributes, 153
customizing
explicit, 454
implicit, 334
D
data binding, 10, 101
dialog box, 306
confirmation dialog box,
310
display window of
component usage, 313
display window of same
component, 312
external, 308
modal, 310
types of dialog boxes, 307
dynamic context modification
create attributes, 365
create dependent node, 368
468
© 2008 SAP AG. All rights reserved.
create node, 364
dynamic modification
data browser, 384
UI, 371
dynamic modifications, 363
context, 364
dynamic UI modification, 371
access elements, 373
add element, 376
assign actions to UI
elements, 379
parameter extraction, 382
parameter mapping, 443
E
enhancements, 352
options, 353
external dialog box, 308
H
hook methods
wddoafteraction(), 148
wddoapplicationstatechange(), 146
wddobeforeaction(), 148
wddobeforenavigation(),
146
wddomodifyview(), 148
wddooncontextmenu(), 148
wddopostprocessing(), 146
I
inbound plugs, 14
input help, 238
help mode Dictionary
Search Help, 241
help mode OVS, 447
help mode user-defined
programming, 452
help modes, 239–240
internationalization, 197
ABAP Dictionary texts, 198
assistance class texts, 201
OTR Texts, 199
2009
NET310
Index
L
S
lead selection, 72
SAP Interactive Forms by
Adobe, 429
integration, 434
scenarios, 430
SAP List Viewer for Web
Dynpro ABAP, 403
advanced functionality, 408
basic functionality, 404
reuse, 405
SAP NetWeaver Portal, 417
eventing, 421
integration, 420
iView, 419
page, 419
roles, 419
workset, 419
SAP NetWeaver Portal
Integration
SAP NetWeaver Portal
Functions, 420
semantic help, 255
classic F1 help, 259
explanation text, 257
explanation UI element, 261
help center, 264
tool tip, 256
supply function, 74
M
messages, 208
categories, 211
EXCEPTION messages,
217
handling, 210
positioning, 209
reporting, 214
T100 messages, 216
text messages, 216
meta model, 4
modal dialog box, 310
Model View Controller (MVC),
19
N
navigation
inbound plugs, 14
links, 14
outbound plugs, 14
navigation link, 54
navigation links, 14
O
Object Value Selector (OVS),
447
phase model, 448
Online Text Repository (OTR),
199
outbound plugs, 14
P
parameter extraction, 382
parameter mapping, 443
personalization
explicit, 454
implicit, 335
plugs, 54
inbound, 14
outbound, 14
popup (see dialog box), 306
2009
U
UI element, 91
UI elements, 99
ABAP Dictionary texts, 109
composite UI elements, 109
container elements, 94
control behavior, 105
data binding, 101
layout managers, 94
table, 111
test page, 118
V
value help
© 2008 SAP AG. All rights reserved.
469
Index
NET310
context attributes, 246
index binding, 243
input fields, 238, 242
key binding, 245
value sets, 246
value selector, 242
view, 9
view assembly, 18
view controller
View Editor, 99
View Editor, 99
benefits, 7
component reuse, 277
Overview, 4
Web Dynpro entities
application, 24
component, 9
context, 9
controller, 9
view, 9
window, 9, 16
window, 9, 16
W
Web Dynpro
470
© 2008 SAP AG. All rights reserved.
2009
Feedback
SAP AG has made every effort in the preparation of this course to ensure the accuracy
and completeness of the materials. If you have any corrections or suggestions for
improvement, please record them in the appropriate place in the course evaluation.
2009
© 2008 SAP AG. All rights reserved.
471