NET312 en UI Development With Web Dynpro for ABAP Participant Handbook 2008

5/17/2018 NET312 en UI Development With Web Dynpro for ABAP Participant Handbook 2008 - slidepdf.com

http://slidepdf.com/reader/full/net312-en-ui-development-with-web-dynpro-for-abap-participant-handbook-2008 1/301

NET312NET312: UI Development with Web

Dynpro for ABAP

SAP NetWeaver

Date

Training Center

Instructors

Education Website

Participant HandbookCourse Version: 62

Course Duration: 3 Day(s)

Material Number: 50089127

An SAP 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 purposewithout 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 PRODUCTSCONTAINED 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.

g200832833223



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. Theseinclude field names, screen titles, pushbuttons as well

as menu names, paths, and options.

Also used for cross-references to other documentation

both internal (in this documentation) and external (in

other locations, such as SAPNet).

Example text Emphasized words or phrases in body text, titles of

graphics, and tables

EXAMPLE TEXT Names of elements in the system. These include

report names, program names, transaction codes, tablenames, 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 thedocumentation.

<Example text> Variable user entry. Pointed brackets indicate that you

replace these words and characters with appropriate

entries.

2008 © 2008 SAP AG. All rights reserved. iii



About This Handbook NET312

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



Contents

Course Overview ....... ....... ....... ....... ....... ...... ....... ....... .. vii

Course Goals ....... ........ ........ ........ ........ ....... ........ .....vii

Course Objectives ... .... ... .... .... .... .... .... .... ... .... ... .... .... .vii

Unit 1: Introduction........................................................ 1

Introduction ..............................................................2

Unit 2: Forming the Layout ... ... .... ... .... ... .... ... .... ... .... ... ... 31

UI Elements used to define the Layout .. .. .. .. .. .. .. .. .. .. .. .. .. .. 32

Unit 3: Complex UI Elements..... ... ... .... ... .... ... .... ... .... ... ... 77

The Table UI Element . ... .... .... .... ... .... ... .... ... .... ... .... .... 79

The Tree UI Element ... ... .... .... .... .... .... .... ... .... .... .... ... 159 Additional complex UI Elements . . .. . .. . . . .. . . . .. . .. . . . . .. . . . .. . .. .187

Unit 4: Defining Graphics .... ... .... ... .... ... .... ... .... ... .... ... ... 215

The BusinessGraphics UI Element .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 216 Additional UI Elements to define Presentation Graphics . .. . . ..238

Unit 5: Integrating BEx Web Applications and non-ABAPTechnologies. ....... ....... ....... ....... ....... ....... ....... ....... .... 259

Integrating BEx Web Applications and non-ABAPTechnologies...................................................... 260

Index ....................................................................... 291

2008 © 2008 SAP AG. All rights reserved. v

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-



Contents NET312

vi © 2008 SAP AG. All rights reserved. 2008



Course Overview

This course explains in detail how to implement user interfaces (UIs) based on

Web Dynpro for ABAP. This includes the creation of a view's layout based on the

UI element library provided with Web Dynpro for ABAP, the definition of the

related view context and the discussion of the UI element specific events.

Target Audience

This course is intended for the following audiences:

• Developers of applications based on Web Dynpro for ABAP

Course Prerequisites

Required Knowledge

• Web Dynpro for ABAP (NET310)

Recommended Knowledge

• It is preferable, if you have created some Web Dynpro for ABAP applications

before you attend this class

Course GoalsThis course will prepare you to:

• Implement complex UIs based on Web Dynpro for ABAP

Course Objectives

After completing this course, you will be able to:

• Use the complete functionality of the complex UI elements DateNavigator,

PhaseIndicator, RoadMap, TableView, and Tree

• Define the layout using the UI elements ContextualPanel,HorizontalContextualPanel, NavigationList, MultiPane, and TabStrip

• Define graphics based on the UI elements BusinessGraphics, GeoMap,

ValueComparison, and ProgressIndicator

• Integrate other technologies using the UI elements Interactive Form,

BIApplicationFrame, OfficeControl, and FileUpload

2008 © 2008 SAP AG. All rights reserved. vii



Course Overview NET312

viii © 2008 SAP AG. All rights reserved. 2008



Unit 1Introduction

Unit Overview

In this unit, the basics about the UI creation with Web Dynpro for ABAP - as

discussed in NET310 - are summed up.

Unit Objectives

After completing this unit, you will be able to:

• Define the UI element hierarchy

• Set UI element properties

• Bind UI element properties to context attributes

• Handle UI element events

• Create and change UI element properties dynamically

Unit Contents

Lesson: Introduction...............................................................2

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

2008 © 2008 SAP AG. All rights reserved. 1

http://-/?-

http://-/?-



Unit 1: Introduction NET312

Lesson: Introduction

Lesson Overview

This lesson sums up the basic concepts related to the definition of the user

interface (UI). This includes the definition of the UI element hierarchy, defining

the UI element's properties, binding the properties to context attributes, and using

the UI element's events.

Lesson Objectives

After completing this lesson, you will be able to:






Business Example

Before you can start to create sophisticated UIs with Web Dynpro for ABAP, you

have to recall the basic knowledge about the definition of a view's UI element

hierarchy. You have attended the class NET310 and you remember that your

trainer has explained all of this to you. However, that's long ago so it is good to

have a summary to look up the main topics.

Defining the UI Element Hierarchy

The layout of a view consists of UI elements that are defined in a hierarchical

structure called the UI element hierarchy. At runtime, the single UI elements are

represented by instances of globally defined classes that describe the properties of

the corresponding UI element. This allows to define or change the UI element

hierarchy not only statically at design time but also programmatically at runtime.

There are different types of UI elements: Some of the elements may have

dependent elements (e.g. the TextView may have a Menu defined as its subelement). Other elements may not have sub elements at all (e.g. the Button).

Finally, there are elements that need to have sub elements to be defined correctly

(e.g. the TableColumn defining a column in a Table, needs to have one sub element

(TableCellEditor ) in order to display the related context data).




NET312 Lesson: Introduction

Figure 1: Types of UI elements

To define the UI element hierarchy at design time, the developer has to edit the

layout of the corresponding view. New elements can be added by drag them from

the tool bar displayed on the left side and drop them to the View Designer areadisplayed right of the tool bar. Alternatively, new elements can be added by right

mouse click on the parent element in the UI element hierarchy (displayed in the

right upper side) and choose Insert Element from the context menu popping up.





Figure 2: Defining the UI element hierarchy

One UI element always exists in the UI element hierarchy - the

ROOTUIELEMENTCONTAINER. This is the root for the complete UI element

hierarchy.

Container Elements and Layout Managers

Container elements are used to arrange UI elements in a rectangular sub area of

the view's layout. The kind of arrangement is defined by the layout manager that

has been assigned to the container element. The layout manager defines how the

sub elements of the container are arranged in the rectangular area defined by

the container element.

Container elements can be nested. This means, that in a certain sub area of a

surrounding area a different way for arranging the UI elements can be determined.





Four kinds of container UI elements do exist:

• TransparentContainer :

This container type is not visible. The ROOTUIELEMENTCONTAINER is a

transparent container.

• Group:

This container type is always visible and it contains a caption.

• Tray:

Alike the Group UI element, this kind of container is always visible and it

contains a caption. However, in addition a menu can be assigned to the

group. Clicking on an icon in the right upper corner of the tray will open

/ close the tray.

• ScrollContainer :

This UI element is deprecated! Instead, the transparent container should

be used.

To each of the container UI elements any of the four layout manager has to be

assigned:

• FlowLayout :

A FlowLayout sequentially arranges the container children. Line breaks can

not be defined.

• RowLayout :

A RowLayout sequentially arranges the container children to exactly one

column. Line breaks can be defined by assigning a RowHeadData object to a

certain UI element.

• GridLayout :

A GridLayout arranges the container children in a two dimensional grid.

Each row contains the same number of cells. Line breaks are automatically

inserted when the number of columns occupied by a UI element is larger then

the remaining number of cells in a line.• MatrixLayout :

A MatrixLayout arranges the container children in a tabular format.

However, the number of cells can very from row to row. Line breaks can be

defined by assigning a MatrixHeadData object to a certain UI element.

Hint: Instead of the GridLayout , use the MatrixLayout whenever possible.





Figure 3: Layout managers - MatrixLayout

Defining UI Element Properties statically and dynamically

If the developer clicks on an element in the View Area or in the UI element

hierarchy, the element's properties are displayed in the lower right corner of the

Web Application Designer. UI element properties can be set statically by entering

an allowed value in the input field right of the property's name. If only predefined

values may be assigned to a UI element property, a value selector or a check box

appears in the value field related to the property.





Figure 4: Defining UI element properties statically

Data binding (context binding) is the preferred way to change UI element

properties at runtime. Most of the properties related to a UI element may be

bound to a context attribute being defined in the view's context and being typedaccordingly. Properties that can be bound to context attributes have a button

displayed right of the property's value field. To define or change the binding

between a property and a context attribute, the button has to be pressed. In the

dialog popping up, the corresponding context attribute has to be marked and the

dialog has to be finished by pressing Enter . The binding can be deleted by opening

the same dialog and clicking on the trash box icon.





Figure 5: Defining UI element properties dynamically (1)

Figure 6: Defining UI element properties dynamically (2)

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.





Up to ABAP support package stack 11, each of these properties had to be bound to

a separate context attribute which led to a mass of attributes in the view's context.

Beginning with ABAP support package stack 12, each context attribute doesallow to bind not only the UI element's key property to it, but also the properties

enabled , visible, readOnly, and state.

Figure 7: Context binding for SAP NW AS 7.0 (ABAP SPS ≥ 12)

To do this, 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 is established. This corresponds to the

situation up to ABAP SPS 11. However, by selecting the lower radio button, the

properties enabled , visible, readOnly, and state can be bound to the corresponding

context attribute properties, respectively.





Figure 8: Code sample: Setting context attribute properties for SAP NW AS

7.0 (ABAP SPS ≥ 12)

Hint: The object describing a context element at runtime contains an

instance attribute for each context attribute defined in a context node.

For ABAP SPS 12 and higher, the object contains additional instance

attributes: For each context attribute the object contains four boolean

instance attributes, the UI element properties enabled , readOnly, state,

and visible may be bound to.

To read or set these additional attributes, new methods have

been created in the interface IF_WD_CONTEXT_NODE ,

namely GET_ATTRIBUTE_PROPS_FOR_ELEM(

), SET_ATTRIBUTE_PROPS_FOR_ELEM( ), and

SET_ATTRIBUTE_PROPERTY( ).

UI Element Events

Some UI elements support client side eventing. Typically, such a client side event

is fired by left mouse clicking on some part of the element.

Examples: The Button UI element supports clicking on the rendered element.

The Table supports distinguishable left mouse clicks (marking a line, clicking

on the related icons to scroll, clicking on the column header to sort, clicking on

the filter icon to filter).





Figure 9: Action - Relating client-side event to server-side action handler

method

To handle the client side event, the application has to provide an appropriate event

handler method. In addition, this event handler method has to be assigned to theclient side event of the UI element. This is realized as follows:

• An event handler method that may be assigned to a UI element event is

generated by creating an action. Actions belong to a view controller.

• To assign such an event handler method to a given event of a UI element,

the UI element property related to this event has to be evaluated with the

action's name.

All events supported by a certain UI element are listed in the property view.

They are grouped in the section Events.

• An action may also be created and assigned to an UI element in a single step.

This is done by pressing the button right of the event property and enteringthe action's name in the related field of the dialog popping up.

If a client side event is fired, the corresponding action handler method is

processed. Depending on the UI element, additional information about the last

state of the UI element is passed to the action handler method. This information is

accessible via the method's interface parameter WDEVENT . This parameter is

predefined for all event handler methods. WDEVENT contains an internal table

(WDEVENT->PARAMETERS ) filled by the Web Dynpro runtime. For each





parameter provided by the event, a line of this table is filled. Each line consists of

the field NAME (filled with the name of the event parameter) and the field VALUE

(filled with the value of the event parameter).

Figure 10: Extracting event-specific information (1)

Because the types of different event parameter may be different, the type of the

value field is generic (TYPE REF TO DATA). Thus, before a value of a certain

event parameter can be accessed, it has to be casted to a variable of the correct

type. If the correct type is a classical data type, this can be done by de-referencing

the reference variable into a field symbol using the addition CASTING (for typed

field symbol) or CASTING TYPE <TYPE_NAME> (for untyped field symbol).





Figure 11: Extracting event-specific information (2)

However, it is also possible that additional event specific information is passed

as an object to the event handler method. In this case, the table PARAMETERS

contains a reference to an object references in the VALUE column. Then the Web

Dynpro runtime types the reference variables with dynamically generated typesthat are not compatible with statically available reference types defined in the

class builder. Thus a different way of de-referencing the variable value into a

field symbol has to be used:

At runtime, the type of a variable can be described by an object using RTTI (run

time type information). On the other side, a RTTI type description can be used

to type variables using the addition TYPE HANDLE TO. This addition can also





be used when de-referencing a reference variable into a generically typed field

symbol (CASTING TYPE HANDLE TO). Thus, accessing the event parameters

involves the following steps:

• First the dynamically created reference type of an event parameter is

obtained by means of RTTI ( e.g. the method DESCRIBE_BY_DATA_REF(

) of class CL_ABAP_TYPEDESCR)

• Next, the parameter VALUE is de-referenced in a field symbol using the

addition CASTING TYPE HANDLE TO <RTTI_TYPE>.

• If the static type of this parameter is known, the field symbol can finally be

casted to a reference variable of this static type.

Hint: The procedure described above can be omitted for statically known

parameters related to the event. In this case the parameter's names (with

their appropriate types) can be added to the action handler's interface. At

runtime, the Web Dynpro runtime does not only fill the PARAMETERS

table of the interface parameter WDEVENT , but also all additionally

defined interface parameters having a name that is identical to an event

parameter.

Caution: The interface of the action handler must not contain any

parameter having a name that is different from the event parameter names.

This will lead to a dump at runtime.

Dynamically changing the UI

Each UI element of type <UI_ELEMENT_TYPE> (e.g. Button) is described by a

globally defined class having the name CL_WD_<UI_ELEMENT_TYPE> (e.g.

CL_WD_BUTTON ). The properties of any UI element are defined as instance

attributes of the related global class. All element classes are part of an inheritance

tree having the class CL_WDR_VIEW_ELEMENT as its root. This root class

implements the interface IF_WD_VIEW_ELEMENT .





Figure 12: UI element class hierarchy (extract)

At runtime, all classes related to the UI elements defined in a view's element

hierarchy are instantiated. The values of the UI element properties are stored as

instance attributes of the runtime objects and the hierarchy itself is reflected by

dependencies between the runtime objects.





Figure 13: Each UI element is described by a global class

The Web Dynpro framework allows to access the UI element hierarchy related

to a view's layout from the controller method WDDOMODIFYVIEW( ) of this

view. The signature of this method contains the importing parameter VIEW .

Calling the method GET_ELEMENT( ID = <ID> ) for this reference variable

returns the reference to the runtime object related to the UI element having

the id <ID>. This returning parameter is typed generically (TYPE REF TO

IF_WD_VIEW_ELEMENT ), so calling this method is possible for all UI element

types. However, in order to access the attributes specific for a certain UI element

type, the generically typed reference has to be casted to a reference variable having

the correct type (CL_WD_<UI_ELEMENT_TYPE>).





Figure 14: Accessing UI elements at runtime

The global class related to a UI element type contains methods to get and set

the values of all possible element properties. Additional methods can be used

to establish the context binding for a certain element property by providing the

context binding path (or to delete the context binding). Other methods allow toassign an action to a certain event supported by the UI element or to remove this

assignment. Thus, calling these methods for the runtime object related to a certain

UI element allows to change the UI element properties - even if these properties

are not bound to context attributes.





Figure 15: Functionality typically available for UI elements

Hint: Context binding is the preferred way to allow changing UI element

properties at runtime. Changing UI element properties by accessing the

runtime object representing the UI element directly should be restricted

to properties that are not bindable.

It is also possible to delete existing UI elements from the UI element hierarchy or

to add new UI elements to the UI element hierarchy at runtime:

To delete an existing UI element from the UI element hierarchy, the following

steps are necessary:

• First, the reference to the parent element of the UI element to be deleted

has to be determined.

• This object contains methods beginning with REMOVE_...( ) which can be

called to delete dependent UI elements (by providing their id or their index).





To create and subsequently add a new element to the UI element hierarchy, the

following steps are necessary:

• First of all, an instance of the class representing the UI element has to be

created. For this purpose, each UI element class contains a static method

NEW_<UI_ELEMENT_TYPE>( ).

• All obligatory properties of the new UI element have to be set accordingly.

• The reference to the UI element that should serve as the parent of the

previously created new UI element has to be determined.

• To insert the new UI element to the UI element hierarchy, the appropriate

method (beginning with ADD_...( ) of the parent element has to be called.

The reference to the new UI element has to be passed to this method.









Exercise 1: Create a simple Web Dynpro

ApplicationExercise Objectives

After completing this exercise, you will be able to:

• Proof your basic Web Dynpro knowledge by creating a simple Web Dynpro

application.

Business Example

You have to create a Web Dynpro application having a sophisticated UI. You know

the Web Dynpro basics since you have taken the class NET310. Thus you begin to

create the basic parts of the application. The exercises of the following lessons

will extend this application step by step.

The basic application displays an empty table and a button. After having pressed

the button, all flights of all carriers are read and displayed by the table.

Template Component: n/a

Solution Component: NET312_INTR_S

Task 1:

Create a package that will contain all the repository objects you are going to

develop.

1. Create the package ZNET312_##. Assign the application component

BC-WD, the software component HOME , and a short description.

A transport request has been created by your trainer.

Task 2:

Create a Web Dynpro component, having one window and a single view embedded

in this window.

1. Create the Web Dynpro component ZNET312_INTR_## with a window

MAIN_WINDOW and a view MAIN_VIEW .

Continued on next page





Task 3:

In the component controller of your component create a context node. At runtime,

this node will be populated with context elements, each element storing the

attributes of one flight.

In addition, create a method containing the code for reading the flights from the

data base and saving the flight data in the context.

To read the flights, the static method READ_FLIGHTS( ) of class

CL_NET310_FLIGHTMODEL is to be used.

1. In the component controller create a node FLIGHTS , having cardinality

(0:n) and type SFLIGHT . Add the attributes CARRID, CONNID, FLDATE ,

PRICE , CURRENCY , PLANETYPE , SEATSMAX , and SEATSOCC to the

node.

2. Create the ordinary method GET_FLIGHTS( ). Add two optional import

parameters ( IV_CARRID of type S_CARR_ID and IV_CONNID of type

S_CONN_ID) to the method's interface to allow submitting the connection

key.

In the source code, pass the connection key to the static method

READ_FLIGHTS( ) defined in class CL_NET310_FLIGHTMODEL. This

method will provide the flights related to the connection key. Finally store

the flights in the context node FLIGHTS .

Hint: In this exercise, no values will be supplied to the import parameters. In this case, the static method READ_FLIGHTS( ) will

read all flights that are stored in the data base table SFLIGHT .

Task 4:

Copy the node FLIGHTS from the component controller context to the context

of view MAIN_VIEW and define the context mapping between the nodes (origin:

component controller context). In the view's layout, create a Table to display the

content of the context FLIGHTS . In addition, define a button in the layout. If

this button is pressed, all flights should be read and stored in the context node

FLIGHTS . Finally, optimize the layout.

1. Copy the node FLIGHTS from the component controller context to the

context of view MAIN_VIEW and define the context mapping between the

nodes.

2. In the view's layout, define a table to display the flights stored in the context

node FLIGHTS .

3. Define a button in the layout. If this button is pressed, all flights should be

read and stored in the context node FLIGHTS






4. Optimize the layout.

Task 5:Create an application, activate your component and test the application.

1. Create a Web Dynpro application having the name of your component.

2. Test your application.





Solution 1: Create a simple Web Dynpro

ApplicationTask 1:

Create a package that will contain all the repository objects you are going to

develop.

1. Create the package ZNET312_##. Assign the application component

BC-WD, the software component HOME , and a short description.

A transport request has been created by your trainer.

a) Perform this step like you (hopefully) have done often before.

Task 2:

Create a Web Dynpro component, having one window and a single view embedded

in this window.

1. Create the Web Dynpro component ZNET312_INTR_## with a window

MAIN_WINDOW and a view MAIN_VIEW .

a) In the navigation area of the ABAP Workbench, open the context menu

for the package and choose Create → WebDynpro→ WebDynpro

Component (Interface).

b) In the dialog box, enter the name of the component, a description, the

name of the main window, and the name of the view.

Hint: The view will be embedded in the window automatically.






Task 3:

In the component controller of your component create a context node. At runtime,

this node will be populated with context elements, each element storing the

attributes of one flight.

In addition, create a method containing the code for reading the flights from the

data base and saving the flight data in the context.

To read the flights, the static method READ_FLIGHTS( ) of class

CL_NET310_FLIGHTMODEL is to be used.

1. In the component controller create a node FLIGHTS , having cardinality

(0:n) and type SFLIGHT . Add the attributes CARRID, CONNID, FLDATE ,

PRICE , CURRENCY , PLANETYPE , SEATSMAX , and SEATSOCC to the

node.

a) Edit the component controller of your application.

b) Select the Context tab.

c) From the context menu of the root node CONTEXT choose Create→

Node. Enter name and type. Change the default cardinality (1:1) to

(0:n).

d) Press the button Add Attribute from Structure. Mark the attributes

CARRID, CONNID, FLDATE , PRICE , CURRENCY , PLANETYPE ,

SEATSMAX , and SEATSOCC .

e) Finish the dialog.2. Create the ordinary method GET_FLIGHTS( ). Add two optional import

parameters ( IV_CARRID of type S_CARR_ID and IV_CONNID of type

S_CONN_ID) to the method's interface to allow submitting the connection

key.






In the source code, pass the connection key to the static method

READ_FLIGHTS( ) defined in class CL_NET310_FLIGHTMODEL. This

method will provide the flights related to the connection key. Finally storethe flights in the context node FLIGHTS .

Hint: In this exercise, no values will be supplied to the import

parameters. In this case, the static method READ_FLIGHTS( ) will

read all flights that are stored in the data base table SFLIGHT .

a) Select the Methods tab. Enter the name of the method in the column

Method and press Enter . Double click on the method's name to edit

the source code.

b) Enter the parameter names in the column Parameter and choose Type = Importing for both parameters. Enter Associated Type = S_CARR_ID

and S_CONN_ID, respectively. Don't forget to mark the check box in

the column Opt for both parameters.

c) Source code of method see below.

Task 4:

Copy the node FLIGHTS from the component controller context to the context

of view MAIN_VIEW and define the context mapping between the nodes (origin:

component controller context). In the view's layout, create a Table to display the

content of the context FLIGHTS . In addition, define a button in the layout. If this button is pressed, all flights should be read and stored in the context node

FLIGHTS . Finally, optimize the layout.

1. Copy the node FLIGHTS from the component controller context to the

context of view MAIN_VIEW and define the context mapping between the

nodes.

a) Edit the context of view MAIN_VIEW .

b) Drag the node FLIGHTS from the component controller context and

drop it on the root node of the view controller context. This copies the

context node and defined the context mapping in one step.

2. In the view's layout, define a table to display the flights stored in the contextnode FLIGHTS .

a) Select the Layout tab.

b) Mark the ROOTUIELEMENTCONTAINER UI element. Use the Web

Dynpro Code Wizard to create a table displaying the content of node

FLIGHTS .






3. Define a button in the layout. If this button is pressed, all flights should be

read and stored in the context node FLIGHTS

a) Mark the ROOTUIELEMENTCONTAINER UI element in the layout of

view MAIN_VIEW .

b) Click the right mouse button to open the context menu. Select the

context menu entry Insert Element to add a Button UI element (name:

BUT_DETAILS ) to the UI element hierarchy.

c) Assign a text ( Display flights) to the Button UI element. Click on the

button behind the UI element property OnAction to create an action

(name: GET_DETAILS ) and assign this action to the property.

d) Implement the action handler method for action GET_DETAILS : Call

the method GET_FLIGHTS( ) defined in the component controller.

Do not export values for the interface parameters IV_CARRID and

IV_CONNID.

e) Source code see below.


a) For the ROOTUIELEMENTCONTAINER UI element set Layout =

MatrixLayout , width = 100%, and stretchHorizontally = abap_true.

For the Table UI element set LayoutData = MatrixHeadData,

selectionMode = none, visibleRowCount = 15, and width = 100%.

For the Button UI element set LayoutData = MatrixHeadData. b) Change additional layout properties if desired.

Task 5:

Create an application, activate your component and test the application.

1. Create a Web Dynpro application having the name of your component.

a) From the context menu of your application, choose Create→Web

Dynpro Application to create a Web Dynpro application having the

name of your component. Enter a description and save.

b) Activate your component with all dependent objects.






2. Test your application.

a) Start your application from the context menu of your application.

Result

Comp. Controller: GET_FLIGHTS( )

METHOD get_flights .

DATA lt_flights TYPE net310_t_sflight.

DATA lo_nd_flights TYPE REF TO if_wd_context_node.

cl_net310_flightmodel=>read_flights(

EXPORTING

i_carrid = iv_carrid

i_connid = iv_connid

IMPORTING

e_flights = lt_flights ).

lo_nd_flights = wd_context->get_child_node( name = wd_this->wdctx_flights ).

lo_nd_flights->bind_table( lt_flights ).

ENDMETHOD.

View Controller: ONACTIONGET_DETAILS( )METHOD onactionget_details .

DATA lo_componentcontroller TYPE REF TO ig_componentcontroller.

* Get all flights

lo_componentcontroller = wd_this->get_componentcontroller_ctr( ).

lo_componentcontroller->get_flights( ).

ENDMETHOD.





Lesson Summary

You should now be able to:• Define the UI element hierarchy








Unit Summary NET312

Unit Summary

You should now be able to:






Related Information

• The online documentation for SAP NetWeaver 7.0 contains an excellent

section about developing applications based on Web Dynpro ABAP.

Having opened the online documentation for SAP NetWeaver 7.0 athttp://help.sa

p.com, enter the search term Web Dynpro ABAP. This will open

a list of links pointing to the Web Dynpro section of the documentation.

• In each SAP system based on SAP NetWeaver 7.0, standard Web Dynpro

ABAP demo applications are available. The corresponding Web Dynpro

components begin with the literal WDR_TEST , DEMO, or WDT .


http://help.sap.com/





Unit 2 Forming the Layout

Unit Overview

This unit deals with UI elements that are used to structure the view's layout.

The container elements Group and TransparentContainer are not discussed here

since these elements are considered to be known from NET310, the antecessor

of this course.

Unit Objectives


• Implement the following UI elements: ContextualPanel,

HorizontalContextualPanel, NavigationList, MultiPane, TabStrip, Tray

Unit Contents

Lesson: UI Elements used to define the Layout .. .. .. .. .. .. .. .. .. .. .. .. .. .. . 32

Exercise 2: Implementing a NavigationList UI Element ................ 59Exercise 3: Implementing a TabStrip UI Element . .. .. .. .. .. .. .. .. .. .. .. 71


http://-/?-

http://-/?-



Unit 2: Forming the Layout NET312

Lesson: UI Elements used to define the Layout

Lesson Overview

In this lesson, UI elements to define the layout of a view are discussed. This

includes the NavigationList , the ContextualPanel , the HorizontalContextualPanel ,

the MultiPane, the Tabstrip, and the Tray.

Lesson Objectives




Business Example

You would like to implement the UI elements listed above. The implementation

of the basic features is feasible. However, you want to explore the complete

functionality.

Overview

The Web Dynpro UI element library contains a number of elements that can be

used to form a view's layout. The most interesting elements are discussed in this

lessen.The NavigationList provides a navigation area. The navigation elements are

organized in a tree like structure.

The HorizontalContextualPanel provides a navigation area with a two level

navigation hierarchy. Here, the navigation elements are horizontally arranged

as a row of tabs.

The ContextualPanel is a navigation object that can embed NavigationLists,

FreeContextualAreas (which can be used to display any content based on UI

elements), and ViewSwitches (which can be used to toggle between different

states).

The MultiPane is used to display the content of a context node containing multipleelements in the form of a grid.

The TabStrip is well known from the classical ABAP Dynpro. The context to

be displayed can be placed on different tab pages. The user can toggle between

several tab pages by clicking on a specific tab.

Finally, the Tray is a container element like a Group. However, this element

allows to toggle the visibility of its content.




NET312 Lesson: UI Elements used to define the Layout

The NavigationList

The NavigationList allows to display hierarchical organized content by means of

a tree-like structure. However, this element does not allow to define nodes that

can be expanded and collapsed like a Tree does. Elements defined in a certain

hierarchy level are displayed intended in respect to the parent navigation list item.

Figure 16: NavigationList

Defining the Context

Data to be displayed by a NavigationList have to be stored in a context node of

cardinality (0:n) or (1:n). This node has to be of type non-singleton. The elements

of this first level node contain the data of the first hierarchy level displayed by the

NavigationList . At least two context attributes should be created in the first level

node: One attribute to store the text displayed by the NavigationList , the second

attribute to store a key for this navigation list item. This allows to call related

functionality when the user selects a certain list item.

To be able to store data for additional hierarchy levels, a recursion node has to be defined as a sub node of the first level context node. This recursion node has

to repeat the first level node. At runtime, this allows to define a hierarchy of

context nodes having all the same structure.





Figure 17: NavigationList: Defining the context

The recursion node is defined as follows:

• From the context menu of the first level node the menu entry Create→

Recursion Node has to be selected.

• The node name can be chosen arbitrarily.• In the field having the label Repeated Node, the name of the first level node

has to be entered.





Creating the hierarchical Context Structure at Runtime

A recursion node allows to define a hierarchical context structure consisting of

identical context nodes forming a tree. However, at runtime only the collection for

the first level context nodes serving as the parent node of the hierarchical context

structure is created automatically. The source code to build up an additional

hierarchy level consists of the following steps:

• First, the reference to an element of the parent node collection has to be

determined.

• For this element, the method GET_CHILD_NODE( NAME =

'<RECURSION_NODE_NAME>' ) has to be called.

Hint: The name of the recursion node has to be typed as a textliteral. For recursion nodes, no constant containing the node's name

are generated in the local controller interface.

• If the collectionrelatedto the recursion node <RECURSION_NODE_NAME>

has not been created yet, it will be created by the framework.

Figure 18: NavigationList: Creating hierarchical context structure at runtime

To create additional hierarchy levels, the procedure described above is repeated

but starting with an element existing in a previously defined collection related

the recursion node.





UI Element Definition and Data Binding

To display the content of the hierarchical data structure a NavigationList has to

be defined in the view's layout. The property itemSource has to be bound to

the parent node of the hierarchical context structure. The property itemText has

to be bound to the context attribute of the parent node containing the text to be

displayed by the list item.

The property enabled has no influence on the generated list. However, the

property itemSelectable determines, on which of the list items the user can click.

For selectable list items the mouse cursor is displayed as a hand. The visibility of

the complete NavigationList can be toggled using the property visible. A tool tip

can be assigned to the NavigationList by setting the property tooltip accordingly.

The height of the NavigationList is optimized automatically. However, an arbitrary

height can be defined setting the property contentHeight (in pixels). If the content

can not displayed completely, a vertical scroll bar is displayed automatically.

Hint: The property visible can not be used to hide single list items but

only the complete NavigationList UI element.

Figure 19: NavigationList: Binding UI element properties





Events

The NavigationList supports only one event having the name Select (property

onSelect ). This event is fired if the used clicks on a selectable list item. In the

related action handler method the following informations can be extracted from

the interface parameter WDEVENT :

The table WDEVENT → PARAMETERS contains the id of the NavigationList

( NAME = ID) and the reference to the context element the user has selected

( NAME = CONTEXT_ELEMENT ). From the reference to the context element, the

data key related to the list item can be determined, so dependent functionality

can be triggered.

Figure 20: NavigationList: Handling the event Select

Aggregations

A NavigationList may contain a sub element of type ExpandableTitle. Thiskind of element allows to display a title on top of the list. If the property

expandable is set to ABAP_TRUE , an additional icon is displayed in the title

that allows to expand and collapse the complete list. In this case, the property

expanded can be used to define the actual state after initialization or at runtime

(if bound to a context attribute). If an action is bound to the event Toggle

(property onToggle), a round trip to the server is involved when toggling between

the collapsed and the expanded state. In the action handler method, the table

WDEVENT → PARAMETERS then contains the id of the ExpandableTitle ( NAME

= ID) and the last state ( NAME = EXPANDED).





The HorizontalContextualPanel

The HorizontalContextualPanel displays content that is organized in a hierarchical

context structure with up to two levels. Each element belonging to the first

level of this hierarchical structure is displayed as a tab. All tabs are arranged

horizontally. Each element of the first hierarchy level may have dependent data

stored in a dependent collection in the context. If the tab related to such a first level

context element is selected, then the single elements of the dependent collection

are displayed as links arranged horizontally on the area below the tab row.

Figure 21: HorizontalContextualPanel


Information to be displayed by tabs of a HorizontalContextualPanel has to

be stored in a context node of cardinality (0:n) or (1:n). The elements of this

first level node contain the data of the first hierarchy level displayed by the

HorizontalContextualPanel . At least two context attributes should be created in

the first level node: One attribute to store the text displayed by the tabs of the

HorizontalContextualPanel , the second attribute to store a key for each item. Thisallows to call related functionality when the user selects a certain tab.

In order to define a second level hierarchy in the controller context, a recursion

node has to be defined as a sub node of the first level context node. This recursion

node has to repeat the first level node.





Caution: Make sure that the lead selection is always set for all collections

related to the HorizontalContextualPanel . This is necessary, since the leadselection defines which of the tabs (first level hierarchy) and which of the

links (second level hierarchy) is emphasized. If the lead selection is not

set for the collections related to this UI element, the application will dump.

Caution: If a second level hierarchy is to be defined in the context, then

the first level node has to be a non-singleton node.

Figure 22: HorizontalContextualPanel: Defining the context

The definition of a recursion node has been discussed in the last section about the

UI element Navigation List .

Creating the hierarchical Context Structure at Runtime

This has also been discussed in the section about the UI element Navigation List .

Hint: In contrast to the NavigationList UI element, the node hierarchy for

a HorizontalContextualPanel may consist of a maximum of two nodes.






To display the content of the hierarchical data structure a HorizontalContextual-

Panel has to be defined in the view's layout. The property itemSource has to be

bound to the first level node of the hierarchical context structure. The property

itemText has to be bound to the context attribute of the first level node containing

the text to be displayed by the tabs.

The property itemEnabled defines, which of the tabs (first level hierarchy) and

which of the links (second level hierarchy) is selectable. Non-selectable items

appear grayed out.

Hint: This is different from the NavigationList UI element. For the

NavigationList UI element it is not possible to gray out non-selectable list

items.

The property itemVisible defines, which of the tabs (first level hierarchy) and

which of the links (second level hierarchy) are visible.

Hint: For the NavigationList UI element it is not possible to hide

individual list items.

The visibility of the complete HorizontalContextualPanel can be toggled

using the property visible. All tabs and all links can be disabled at once by

setting the property enabled to ABAP_FALSE . A tool tip can be assigned to the

HorizontalContextualPanel by setting the property tooltip accordingly.





Figure 23: HorizontalContextualPanel: Binding UI element properties

Events

The HorizontalContextualPanel supports only one event having the name Select

(property onSelect ). Handling the event and extracting event related information

is identical to the procedure described for the NavigationList UI element (see

corresponding section in this lesson).

In order to emphasize the tab or link the user has selected, the lead selection has

to be set accordingly. This is typically done in the action handler related to the

event Select .

Hint: Clicking on a tab or on a link does not set the lead selection in the

related collection automatically.





Figure 24: HorizontalContextualPanel: Setting lead selection to define

emphasized tab / link

Aggregations

A HorizontalContextualPanel may not have sub elements.

The ContextualPanel

The ContextualPanel serves as a container for an arbitrary number of sub elements

being of type NavigationList , FreeContextualArea, or ViewSwitch. Details about

sub element types will be discussed in the sub section Aggregations





Figure 25: ContextualPanel


The content displayed by a ContextualPanel is related to its sub elements. Thus

no extra context nodes and context attributes related to this element type needto be defined.


A ContextualPanel can be defined as a sub element of any container UI element

in the view's layout. From the context menu of this UI element, sub elements of

type NavigationList , FreeContextualArea, or ViewSwitch can be added to the

UI element hierarchy.

The ContextualPanel has the properties enabled , tooltip, visible, and width.

Setting enabled to ABAP_FALSE will disable the complete content defined by

the sub elements.

Events

The ContextualPanel supports only one event having the name Personalize

(property onPersonalize). This can be used to manipulate the content displayed

by the UI element. There is no special information provided by the interface

parameter WDEVENT .





Aggregations

The ContextualPanel has to contain at least one of the UI elements NavigationList ,

FreeContextualArea, or ViewSwitch as its sub element. If necessary, an arbitrary

number of theses element types can be combined to form the content of the

ContextualPanel UI element.

The NavigationList UI element has been discussed in detail before.

The FreeContextualArea UI element can be used to display any Web Dynpro

UI element in an expandable area that may also contain an ExpandableTitle.

Details about the ExpandableTitle can be found in the sub section about the

NavigationList . The only properties related to the FreeContextualArea itself are

the property design to change the background color of the UI element and the

property contentHeight , to restrict the area height (in pixels). If this property is set

to 0, the height of the UI element is optimized automatically.

Figure 26: FreeContextualArea

The ViewSwitch UI element can be used to display a switch for each element in

a context node of cardinality (0:n) or (1:n). The binding has to be defined by

assigning the path to the context node to the UI element property itemSource. The

lead selection of this node determines, which of the switches is emphasized.

Caution: Make sure, that the lead selection is always set in the context

node related to the ViewSwitch. If the lead selection is not set, the

application will dump at runtime.





The context node should contain at least one attribute to define the text displayed

by each switch (bound to the property itemText ). In addition, each switch can be

enabled / disabled (property itemEnabled has to be bound to context attributeof type WDY_BOOLEAN ) and each switch can be displayed / hidden (property

itemVisible has to be bound to context attribute of type WDY_BOOLEAN ).

Figure 27: ViewSwitch

The ViewSwitch supports only one event having the name Select (property

onSelect ). Handling the event and extracting event related information is identical

to the procedure described for the NavigationList UI element (see corresponding

section in this lesson).

In order to emphasize the switch the user has clicked on, the lead selection has

to be set accordingly. This is typically done in the action handler related to the

event onSelect .

Hint: Clicking on a switch does not set the lead selection in the related

collection automatically.

The MultiPane

The MultiPane UI element is used to order the content of a context node in the

form of a grid. Thus, the MultiPane is an alternative to the Table for displaying

multiple congeneric data sets.





Each cell of the grid is described by sub elements of the MultiPane. All grid

cells have the same structure.

Figure 28: MultiPane


The content to be displayed by a MultiPane has to be stored in a context node of

cardinality (0:n) or (1:n). Defining an filling the context is identical to the case

that the data has to be displayed by a Table UI element. However, the settings of

the Lead Selection and the settings of the Selection property are irrelevant.


The MultiPane UI element can be defined as a sub element of any container UI

element. The path to the context node containing the data to be displayed has to

assigned to the key property dataSource of the MultiPane.





Figure 29: MultiPane: Binding UI element properties

The number of columns and rows to be displayed can be defined by the properties

colCount and rowCount , respectively. By default, one column is displayed, while

the number of rows equals the number of context elements. If the number of data

sets is larger then the number of visible grid cells, the paginator elements in the

footer have to be used to navigate to the actually hidden data sets.

The value of the property emptyText defines which text is displayed if the data

source contains no elements. footerVisible can be used to hide the line containing

the paginator icons. This is meaningful, if all data sets are displayed anyway.

The size of the MultiPane can be adjusted by setting the properties width and

height in pixels or percent, respectively. stretchHorizontally and stretchVertically

can be used to spread the grid cells equally across the complete space occupied

by the MultiPane.

The property paneCount influences the number of rows, that are accessible by

using the paginator functionality of the MultiPane. If paneCount is set to a value

different from the initial value (-1) and rowCount is set to its initial value (-1), then

the number of rows that may be accessed is set as follows:

The value of the property paneCount is increased up to the next multiple R of

the colCount property value. The value R is then displayed in the footer as the

maximum number of accessible rows.

Example: Number of data sets = 33, colCount = 5, paneCount = 27⇒ R = 6.

Thus, 5 * 6 = 30 data sets are accessible.





The property firstVisiblePane can be used to define which of the stored data sets is

displayed as the first data set visible in the MultiPane (offset).

Example: If the topmost data set displayed by the MultiPane should be related to

the context element with index 11, firstVisiblePane has to be set to 10.

Finally, firstActualPane, paneCount , and firstVisiblePane can be used to

implement a technique called context paging. This technique may be used if the

number of potentially accessible data sets is very large. In this case it is possible to

store only a small number of all data sets in the context right from the beginning.

This reduces the load significantly. However, at runtime it may be necessary that

additional data sets are requested (user scrolls to data sets not loaded yet), so these

additional data sets have to be copied to the context node.

The user of the application should get the information that more data sets are

potentially accessible than the number of data sets actually stored in the context.By default, this is not the case, since the actual row number and the maximum

row number displayed by the footer are related to the number of elements stored

in the corresponding context node. This can be changed by setting the properties

firstActualPane, paneCount , and firstVisiblePane, accordingly. For simplicity,

colCount is assumed to be 1.

First, paneCount has to be set to the total number of data sets that may be

accessible by the MultiPane. If the first data set stored in the context is not the

first data set that could be accessible, firstActualPane has to be used to define

this offset. This parameter describes, which grid cell (pane) in the MultiPane

should display the first element stored in the context. Finally, the parameter

firstVisiblePane has to be used to correct this offset when displaying the gridthe first time.

Example: The number of data sets that may be displayed be the MultiPane is

200000. When initializing the controller, only the data sets with index 101 to 130

are stored to the context. 5 rows are displayed in 1 column.

Without adjusting firstActualPane, paneCount , and firstVisiblePane, the footer

of the MultiPane will indicate that data set 1 is displayed and 30 data sets may

be displayed. However, the footer should indicate that data set 101 is displayed

and 200000 may be displayed.





Figure 30: MultiPane: Context paging not implemented

After having set paneCount to 200000, the footer displays that data set 1 is

displayed and 200000 data sets may be displayed.

Now firstActualPane is set to 100 in order to relate the first data set in the contextnode to the pane with index 101. Result: The footer displays that data set 1 is

displayed and 200000 data sets may be displayed. However, no pane is displayed

yet. To display the first data set stored in the context, the user of the application

has to navigate to pane with index 101.

Thus, firstVisiblePane has to be set to any number between 100 and 125, in order to

see five data sets in parallel. If the first data set stored in the context should also be

the first data set displayed by the MultiPane, firstVisiblePane has to be set to 100.





Figure 31: MultiPane: Context paging implemented

Caution: Each time the user scrolls, the program has to check if all data

sets demanded by the user have already been stored in the context. If this

is not the case, additional data sets have to be copied to the context.

Events

The MultiPane UI element supports only one event having the name Scroll

(property onScroll ). This event is triggered if the user clicks on one of the paging

icons displayed in the footer of the UI element. In the related action handler

method the following informations can be extracted from the interface parameter

WDEVENT :

The table WDEVENT → PARAMETERS contains the id of the MultiPane

( NAME = ID). The index of the pane that was displayed in the first row and

the first column when the user fired the event is provided by the parameter OLD_FIRST_VISIBLE_PANE . The index of the pane that should be displayed in

the first row and the first column when the layout is rendered next time is provided

by the parameter NEW_FIRST_VISIBLE_PANE .





Caution: If context paging is implemented, the application has to check

if all data sets demanded by the user have already been stored in thecontext. The indices of these data sets can be determined from the values

of the parameter NEW_FIRST_VISIBLE_PANE and from the UI element

properties rowCount and colCount :

• First context element to be displayed next time has index

NEW_FIRST_VISIBLE_PANE .

• Last visible context element to be displayed next time has index

NEW_FIRST_VISIBLE_PANE + row_count * colCount .

Aggregations

To display the content of a single context element in a pane, the UI element MultiPane has to have sub elements defined in the UI element hierarchy. Only

one direct sub element may be defined for the MultiPane. However, this is not a

restriction since this sub element may be a container element.

The TabStrip

The TabStrip UI element is used to display horizontally aligned tabs. The user

can toggle between several tab pages by clicking on a specific tab. The number of

tabs defined in the application may be larger then the number of tabs displayed

at runtime. In this case, additional navigation elements are activated in the right

upper corner of the rendered UI element. Clicking on these icons allows to display

the next / previous tab (however, the selected tab will not change). A navigationmenu (always active) allows to display the titles of all tabs existing at runtime.

Clicking on a menu entry allows no navigate to any tab. The new tab will be

the selected tab.

On each tab page, an arbitrary combination of UI elements can be used to define

the layout.





Figure 32: TabStrip


TabStrip UI elements do not contain properties that have to be bound to context

attributes. Thus, it is not obligatory to define TabStrip-related context nodes or

context attributes.


The TabStrip UI element can be defined as a sub element of any container UI

element. For each tab, an element of type Tab has to be defined as a sub element

of the TabStrip. Finally, the content displayed on each tab is defined by creating

sub elements of the corresponding Tab UI element.

The complete TabStrip and all of its sub elements can be enabled / disabled using

the parameter enabled . If enabled is set to ABAP_FALSE , the selected tab can not

be changed by the user at runtime. The visibility of the complete TabStrip can be

toggled by setting the property visible accordingly.

The height and width of the TabStrip can be defined by setting the properties height

and width, respectively (in pixels or percent). If height and width are set to values

that do not allow to display the complete content of a given tab, then the size of

the TabStrip will be optimized (being exactly large enough to display the complete

content). This optimized size depends on the content and thus on the selected tab.

By default, the next selected tab is defined by clicking on any selectable tab.

However, it is also possible to deactivate this automatic definition of the selected

tab. This can be done by setting the parameter selectionChangeBehaviour to





manual (default value auto). In this context it is meaningful to bind the property

selectedTab to a context attribute of type string. Then, the next selected tab can be

defined from the source code by assigning the tab's id to this context attribute.

Finally, the property tabAlignment can be used to influence the width and height

of all tabs. However, this feature is not supported for browser based clients.

Figure 33: TabStrip: Binding UI element properties

Events

The TabStrip UI element supports only one event having the name Select (property

onSelect ). This event is triggered if the user clicks on one of the tabs or if the user

selects a menu entry from the navigation menu. This event is not triggered, if the

user navigates to the previous / next tab by clicking on the appropriate icon in

the right upper corner of the TabStrip. In the related action handler method the

following informations can be extracted from the interface parameter WDEVENT :

The table WDEVENT → PARAMETERS contains the id of the TabStrip ( NAME = ID). The id of the last selected tab is provided by the parameter OLD_TAB. The id

of the tab the user has clicked on is provided by the parameter TAB.

Aggregations

The TabStrip UI element may contain as many tabs as desired. Each tab is

described by a Tab UI element, which has to be created as a direct sub element of

the TabStrip. It is not possible to have one Tab UI element describing multiple





tabs. For each tab, the visibility can be toggled (property visible), the tab can be

enabled / disabled (property enabled ), and a padding between the content and the

tab border can be added / deleted (property hasContentPadding ).

Figure 34: TabStrip: Sub elements

The Tab UI elements are allowed to contain dependent elements:

Each tab has exactly one Caption containing the text and the image displayed

on the tab.

Each tab may also contain a ToolBar , which is displayed on top of the related

tab page.

Finally, each tab may contain one sub element to display the content on the

tab page. However, this is not a restriction, since this sub element may be a

container element (having an arbitrary number of dependent elements) or a

ViewContainerUIElement (allowing to embed other views or interface views).

The TrayA Tray UI element can be used to group a set of UI elements in a rectangular area

having a common title. Thus, the Tray is an alternative to the Group UI element.

However, unlike the Group it provides additional functions. For example, the Tray

UI element can be expanded or collapsed.





Figure 35: Tray


Tray UI elements do not contain properties that have to be bound to context

attributes. Thus, it is not obligatory to define Tray-related context nodes or context

attributes.


The Tray UI element can be defined as a sub element of any container UI element.

For displaying a function menu, a title, a tool bar, or the content displayed in the

Tray body, additional UI elements have to be defined as sub elements of the Tray.

These elements will be discussed in the section Aggregations.

The complete Tray and all of its sub elements can be enabled / disabled by setting

the parameter enabled accordingly. If enabled is set to ABAP_FALSE , not only the

content defined in the Tray body is disabled, but also the icons in the upper right

corner. Thus, the Tray may not be expanded / collapsed and no function may be

triggered if the Tray is disabled. The visibility of the complete Tray can be toggled by setting the property visible accordingly.

Any Button UI element defined in the Tray body can be defined as the default

button by assigning the button's ID to the property defaultButton. If the user clicks

in the Tray, this button will get the focus. If the user presses Enter , the event

Action (property onAction) of the default button will be fired.

The property design allows to change the color of background and border line

related to the Tray body.





The property expanded is used to define the state (expanded / collapsed) of the

Tray. This property is set automatically if the used clicks on the corresponding

icon in the right upper corner of the rendered UI element.

A padding between the content and the tab border can be added / deleted be setting

the property hasContentPadding accordingly.

The height and width of the Tray can be defined by setting the properties height

and width, respectively (in pixels or percent).

Finally, the setting of the property scrolling Mode defines what happens if the

width and height of the Tray is defined in a way that the Tray body is to small to

display the complete content.

If scrolling Mode is set to none, the Tray body will have a minimum size being

exactly large enough to display the complete content. Trying to decrease this

minimum size by setting width or height to smaller values will not change this

minimum size. If scrolling Mode is set to both, scroll bars will always be visible

in the Tray body. This is independent from the actual size of the Tray. If scroll

bars should only be displayed if the Tray body is too small for the content to be

displayed, the property scrolling Mode has to be set to auto.

Figure 36: Tray: Binding UI element properties





Events

The Tray UI element supports only one event having the name Toggle (property

onToggle). This event is triggered if the user expands or collapses the Tray by

clicking on the related icon in the right upper corner of the UI element. In the

related action handler method the following informations can be extracted from

the interface parameter WDEVENT :

The table WDEVENT → PARAMETERS contains the id of the Tray ( NAME = ID).

In addition, the last state (expanded / collapsed) of the Tray is provided by the

boolean parameter EXPANDED.

Aggregations

The Tray UI element can contain the following sub elements:

The Tray has to have exactly one Caption containing the text and the image

displayed above the Tray body.

Each tab may also contain a ToolBar , which is displayed below the Caption.

Another optional element is the Menu containing an arbitrary number of menu

entries. At runtime, an additional icon is then created left of the standard icon used

to collapse / expand the Tray. Clicking on this additional icon will open the menu.

The content of the Tray is defined by a single sub element. However, this is not a

restriction, since this sub element may be a container element (having an arbitrary

number of dependent elements) or a ViewContainerUIElement (allowing to embed

other views or interface views).





Figure 37: Tray: Sub elements





Exercise 2: Implementing a NavigationList

UI ElementExercise Objectives


• Implement a NavigationList UI element.

Business Example

You would like to change your application as follows:

All connections should be displayed by a NavigationList UI element. If the user

clicks on a list item, the related flights should be displayed by the Table UIelement. The Table should be positioned right of the NavigationList .

Template Component: NET312_INTR_S

Solution Component: NET312_LAYO_S1

Task 1:

If you have finished the previous exercise, you can skip this task. Then, all changes

can be implemented in the component you have created in your last exercise.

If you have not finished your last exercise, you can start with a copy of the

template component. In this case, copy the template component and name the copy ZNET312_LAYO1_##. Assign this component to your package ZNET312_##.

Create an application having the same name as your component and assign the

application to your package, too.

1. Copy the template component.

2. Create an application to access your component.

Task 2:

In the component controller of your component create a new non-singleton context

node having the attributes TEXT , SELECTABLE , CARRID, and CONNID and

having a sub node of type Recursion Node.

At runtime, this context structure will be populated with the information to be

displayed by the NavigationList UI element.

1. In the component controller create a node NAVI_LIST having the cardinality

(0:n). Make sure this node is a non-singleton and the lead selection is not

initialized.






2. Add the attributes TEXT (type STRING), SELECTABLE (type

WDY_BOOLEAN ), CARRID (type S_CARR_ID), and CONNID (type

S_CONN_ID) to the context node NAVI_LIST

3. Create a recursion node (name: NAVI_REC_NODE ) as a sub node

of NAVI_LIST . The recursion node has to repeat the structure of node

NAVI_LIST .

Task 3:

Define the algorithm to read the connection information and store the date in

the context node NAVI_LIST .

The navigation list entries on the first level hierarchy should be non-selectable

and they should display the carrier ids. The navigation list entries on the second

level hierarchy should be selectable and each entry should display the connectionid, departure city and destination city.

1. In the component controller, create a new method GET_CONNECTIONS(

) having a returning parameter (name: RT_CONNECTIONS ) of type

NET310_T_SPFLI . Implement the method:

Call the static method READ_CONNECTIONS( ) of class

CL_NET310_FLIGHTMODEL. Pass the internal table returned

by this method to the caller by means of the returning parameter

RT_CONNECTIONS .

2. Create another method in the component controller having the name

DEFINE_NAV_LIST( ). Implement the method:

Call the method GET_CONNECTIONS( ). This will return an internal table

with all connections.

Sort this internal table by CARRID and CONNID.

Loop over the internal table.

If a new carrier is found, add an element to the node NAVI_LIST . Set the

attribute SELECTABLE to ABAP_FALSE since clicking on carriers should

not be allowed. For these elements, assign the carrier id to the attribute






TEXT . The values of the attributes CARRID and CONNID are not used here,

so clear these attribute values. Get the reference to the node collection

NAVI_REC_NODE related to this carrier id.

Hint: Use method BIND_STRUCTURE( ) defined in interface

IF_WD_CONTEXT_NODE to create a new context element in the

node NAVI_LIST . This method will return the reference to the new

context element.

Hint: To access the node collection NAVI_REC_NODE

corresponding to a certain carrier id, start with the context element

related to this carrier and access to recursion node by calling the

method GET_CHILD_NODE( )

For all connections belonging to the same carrier id, add an element to the

related collection of recursion node NAVI_REC_NODE . Set the attribute

SELECTABLE to ABAP_TRUE to allow clicking on the connection entries.

For these elements, set CARRID and CONNID according to the actual

connection. Concatenate the connection id, the departure city and the

destination city and assign the result to the attribute TEXT.

3. Call the method DEFINE_NAV_LIST( ) from the hook method WDDOINIT(

) of the component controller

Task 4:Display the content of the node NAVI_LIST by a NavigationList UI element

defined in the layout of view MAIN_VIEW . The Layout should consist of a

PageHeader UI element, displaying the text NET312 - Exercises on top of the

page. The NavigationList (having an expandable title) should be displayed below

the page header on the left side of the page, the flight table should be displayed

below the page header on the right side of the page.

1. Copy the node NAVI_LIST from the component controller to the view

MAIN_VIEW and define the context mapping between the nodes (mapping

origin: component controller context).

2. Define a page header in the layout of view MAIN_VIEW . The page header should occupy 100% of the page width.

3. Define the navigation list in the view's layout. The navigation list should

cover 30% of the page with and it should be displayed below the page header.

4. Define an expandable title for the navigation list. Display the text Flight

Connections.






5. Correct the properties of the Table UI element. The table has to be displayed

right of the navigation list and it has to cover the remaining width of the page.

Task 5:

If the user clicks on a connection in the navigation list, the related flights should

be displayed by the table. The button can be deleted.

1. Delete the button in view MAIN_VIEW .

2. Assign the action GET_DETAILS to the event SELECT of the NavigationList

UI element.

3. Extend the source code of the action handler method. Add the parameter

CONTEXT_ELEMENT (TYPE REF TO IF_WD_CONTEXT_ELEMENT )

to the interface parameter list. At runtime, this parameter will contain thereference to the context element that is related to the selected navigation

list item.

Get the static attributes from this context element. Change the call of the

component controller method GET_FLIGHTS( ): Pass the connection key

to this method.





Solution 2: Implementing a NavigationList

UI ElementTask 1:




template component. In this case, copy the template component and name the copy

ZNET312_LAYO1_##. Assign this component to your package ZNET312_##.




a) Display the template component in the object tree. Clicking on the

component with the right mouse button will open the component's

context menu. Choose Copy.... Enter the name of the component to be

created. Press Continue.

b) Adapt the description of the new component.


a) An application having the same name as the component can be created

from the context menu of the component.






Task 2:

In the component controller of your component create a new non-singleton context

node having the attributes TEXT , SELECTABLE , CARRID, and CONNID and

having a sub node of type Recursion Node.

At runtime, this context structure will be populated with the information to be

displayed by the NavigationList UI element.

1. In the component controller create a node NAVI_LIST having the cardinality

(0:n). Make sure this node is a non-singleton and the lead selection is not

initialized.

a) Edit the component controller of your application. Select the Context

tab.

b) From the context menu of the root node choose Create→ Node. Enter the name and change the default cardinality (1:1) to (0:n).

c) Finish the dialog.

d) Click on the new node NAVI_LIST .

Make sure that the check box related to the node property Singleton

is not checked.

Make sure that the check box related to the node property Initialization

Lead Selection is not checked.

2. Add the attributes TEXT (type STRING), SELECTABLE (type

WDY_BOOLEAN ), CARRID (type S_CARR_ID), and CONNID (typeS_CONN_ID) to the context node NAVI_LIST

a) Attributes can be added to an untyped context node by selecting the

entry Create→ Attribute from the context menu of this node.

3. Create a recursion node (name: NAVI_REC_NODE ) as a sub node

of NAVI_LIST . The recursion node has to repeat the structure of node

NAVI_LIST .

a) Select the entry Create→ Recursion Node from the context menu of

node NAVI_LIST .

b) Enter the node's name and click on button Select , to choose the node to be repeated. Mark node NAVI_LIST and finish the dialog.






Task 3:

Define the algorithm to read the connection information and store the date in

the context node NAVI_LIST .

The navigation list entries on the first level hierarchy should be non-selectable

and they should display the carrier ids. The navigation list entries on the second

level hierarchy should be selectable and each entry should display the connection

id, departure city and destination city.

1. In the component controller, create a new method GET_CONNECTIONS(

) having a returning parameter (name: RT_CONNECTIONS ) of type

NET310_T_SPFLI . Implement the method:

Call the static method READ_CONNECTIONS( ) of class

CL_NET310_FLIGHTMODEL. Pass the internal table returned

by this method to the caller by means of the returning parameter

RT_CONNECTIONS .

a) Edit the controller component. Select the Methods tab.

b) Enter the method's name in column Method .

c) Double-click on method's name to edit the method's source code.

d) Enter name, type, and associated type of parameter RT_CONNECTIONS

in parameter list of method.

e) Call the static method CL_NET310_FLIGHTMODEL-

>READ_CONNECTIONS( ) in order to read all connections. Returnthe connection list via the return parameter RT_CONNECTIONS .

f) Source code see below.

2. Create another method in the component controller having the name

DEFINE_NAV_LIST( ). Implement the method:

Call the method GET_CONNECTIONS( ). This will return an internal table

with all connections.

Sort this internal table by CARRID and CONNID.

Loop over the internal table.

If a new carrier is found, add an element to the node NAVI_LIST . Set theattribute SELECTABLE to ABAP_FALSE since clicking on carriers should

not be allowed. For these elements, assign the carrier id to the attribute






TEXT . The values of the attributes CARRID and CONNID are not used here,

so clear these attribute values. Get the reference to the node collection

NAVI_REC_NODE related to this carrier id.

Hint: Use method BIND_STRUCTURE( ) defined in interface

IF_WD_CONTEXT_NODE to create a new context element in the

node NAVI_LIST . This method will return the reference to the new

context element.

Hint: To access the node collection NAVI_REC_NODE

corresponding to a certain carrier id, start with the context element

related to this carrier and access to recursion node by calling the

method GET_CHILD_NODE( )

For all connections belonging to the same carrier id, add an element to the

related collection of recursion node NAVI_REC_NODE . Set the attribute

SELECTABLE to ABAP_TRUE to allow clicking on the connection entries.

For these elements, set CARRID and CONNID according to the actual

connection. Concatenate the connection id, the departure city and the

destination city and assign the result to the attribute TEXT.

a) Source code see below.

3. Call the method DEFINE_NAV_LIST( ) from the hook method WDDOINIT(

) of the component controller


Task 4:

Display the content of the node NAVI_LIST by a NavigationList UI element

defined in the layout of view MAIN_VIEW . The Layout should consist of a

PageHeader UI element, displaying the text NET312 - Exercises on top of the

page. The NavigationList (having an expandable title) should be displayed below

the page header on the left side of the page, the flight table should be displayed

below the page header on the right side of the page.

1. Copy the node NAVI_LIST from the component controller to the view MAIN_VIEW and define the context mapping between the nodes (mapping

origin: component controller context).

a) Edit the view MAIN_VIEW . Select the Context tab.

b) Drag the node NAVI_LIST from the component controller context and

drop it to the root node of the view controller context. This copies the

context node and defined the context mapping in one step.






2. Define a page header in the layout of view MAIN_VIEW . The page header

should occupy 100% of the page width.

a) Edit the layout of view MAIN_VIEW .

b) From the context menu of the ROOTUIELEMENTCONTAINER choose

Insert Element to create a PageHeader UI element.

c) Edit the properties of the PageHeader UI element.

Assign the literal NET312 - Exercises to the property title.

Set layoutData = MatrixHeadData, colSpan = 2, and width (section

LayoutData) to 100%.

d) Make the page header the first sub element of the

ROOTUIELEMENTCONTAINER (drag & drop).

3. Define the navigation list in the view's layout. The navigation list should

cover 30% of the page with and it should be displayed below the page header.

a) From the context menu of the ROOTUIELEMENTCONTAINER choose

Insert Element to create a NavigationList UI element.

b) Edit the properties of the NavigationList UI element.

Set layoutData = MatrixHeadData, contentHeight = 450, vAlign

(section LayoutData) = top, and width (section LayoutData) = 30%.

c) Bind the property itemSelectable to the context attribute

NAVI_LIST.SELECTABLE , bind the property itemSource to the contextnode NAVI_LIST , and bind the property itemText to the context attribute

NAVI_LIST.TEXT .

d) Make the navigation list the second sub element of the

ROOTUIELEMENTCONTAINER (drag & drop).

4. Define an expandable title for the navigation list. Display the text Flight

Connections.

a) From the context menu of the NavigationList UI element choose Insert

Header to create an ExpandableTitle UI element.

b) Edit the properties of the ExpandableTitle UI element:

Assign the literal Flight Connections to the property title.

5. Correct the properties of the Table UI element. The table has to be displayed

right of the navigation list and it has to cover the remaining width of the page.

a) Edit the properties of theTable UI element.

Set layoutData = MatrixData, vAlign (section LayoutData) = top, and

width (section LayoutData) = 70%.






Task 5:

If the user clicks on a connection in the navigation list, the related flights should

be displayed by the table. The button can be deleted.

1. Delete the button in view MAIN_VIEW .

a) You should know how to delete UI elements.

2. Assign the action GET_DETAILS to the event SELECT of the NavigationList

UI element.

a) Edit the properties of the NavigationList UI element.

Select the action's name from the drop down list displayed for the

NavigationList property onSelect .

3. Extend the source code of the action handler method. Add the parameter CONTEXT_ELEMENT (TYPE REF TO IF_WD_CONTEXT_ELEMENT )

to the interface parameter list. At runtime, this parameter will contain the

reference to the context element that is related to the selected navigation

list item.

Get the static attributes from this context element. Change the call of the

component controller method GET_FLIGHTS( ): Pass the connection key

to this method.


Result

Comp. Controller: GET_CONNECTIONS( )

METHOD get_connections.

cl_net310_flightmodel=>read_connections(

IMPORTING

e_connections = rt_connections ).

ENDMETHOD.

Comp. Controller: DEFINE_NAV_LIST( )

METHOD define_nav_list .

DATA lt_connections TYPE net310_t_spfli.

DATA ls_connection TYPE spfli.

DATA lv_carrid_old TYPE s_carr_id.

DATA ls_nav_list TYPE wd_this->element_navi_list.

DATA lo_nd_navi_list TYPE REF TO if_wd_context_node.






DATA lo_el_navi_list TYPE REF TO if_wd_context_element.

DATA lo_nd_navi_rec_node TYPE REF TO if_wd_context_node.

* Get internal table containing all flight connections

lt_connections = wd_this->get_connections( ).

SORT lt_connections BY carrid connid.

* Get reference to node to store carriers

lo_nd_navi_list = wd_context->get_child_node( name = wd_this->wdctx_navi_list ).

* Build up navigation list

LOOP AT lt_connections INTO ls_connection.

*** If connections for a new carrier are processed ***********************

IF ls_connection-carrid <> lv_carrid_old.

lv_carrid_old = ls_connection-carrid.

* Define content of new context element

CLEAR ls_nav_list.

ls_nav_list-text = ls_connection-carrid.

ls_nav_list-selectable = abap_false.

* Create new context element, keep reference to context element

lo_el_navi_list = lo_nd_navi_list->bind_structure(

new_item = ls_nav_list

set_initial_elements = abap_false ).

* Create dependent element collection to store connections

lo_nd_navi_rec_node = lo_el_navi_list->get_child_node(

name = 'NAVI_REC_NODE' ).

ENDIF.

**************************************************************************

*** For all elements: Define content of new context element **************

CONCATENATE ls_connection-connid

ls_connection-cityfrom

'>'

ls_connection-cityto

INTO ls_nav_list-text

SEPARATED BY space.ls_nav_list-selectable = abap_true.

ls_nav_list-carrid = ls_connection-carrid.

ls_nav_list-connid = ls_connection-connid.

* Create new context element

lo_nd_navi_rec_node->bind_structure(

new_item = ls_nav_list


**************************************************************************






ENDLOOP.

ENDMETHOD.

Comp. Controller: WDDOINIT( )

METHOD wddoinit .

wd_this->defin e_nav_list( ).

ENDMETHOD.

View Controller: ONACTIONGET_DETAILS( )METHOD onactionget_details .


DATA ls_navi_list TYPE wd_this->element_navi_list.

* Get key information for selected navigation list entry

context_element->get_static_attributes(

IMPORTING

static_attributes = ls_navi_list ).

* Get related flights


lo_componentcontroller->get_flights(

iv_carrid = ls_navi_list-carrid

iv_connid = ls_navi_list-connid ).

ENDMETHOD.





Exercise 3: Implementing a TabStrip UI

ElementExercise Objectives


• Implement a TabStrip UI element.

Business Example

You would like to change your application as follows:

The Table UI element displaying the flights should be defined on a Tab of a

TabStrip. Two additional Tabs should already be created to allow displaying flightinformation by a Calendar UI element and by a BusinessGraphics UI element,

respectively. These UI elements will be implemented at a later time of point.

Template Component: NET312_LAYO_S1

Solution Component: NET312_LAYO_S2

Task 1:



If you have not finished your last exercise, you can start with a copy of thetemplate component. In this case, copy the template component and name the copy






Task 2:

Create a TabStrip UI element in the layout of view MAIN_VIEW . The TabStrip

should contains three Tab sub elements having the captions Flights, Calendar View, and Graphics View, respectively. The Table for displaying the flights should

be moved to the first Tab of the TabStrip.

1. Create a TabStrip in the layout of view MAIN_VIEW .

2. Add three Tab UI elements to the TabStrip. The tabs should display the

captions Flights, Calendar View, and Graphics View, respectively.

3. Move the Table displaying the flights to the first Tab.






Solution 3: Implementing a TabStrip UI

ElementTask 1:









a) Display the template component in the object tree. Clicking on the

component with the right mouse button will open the component's

context menu. Choose Copy.... Enter the name of the component to be

created. Press Continue.





Task 2:

Create a TabStrip UI element in the layout of view MAIN_VIEW . The TabStrip

should contains three Tab sub elements having the captions Flights, Calendar

View, and Graphics View, respectively. The Table for displaying the flights should

be moved to the first Tab of the TabStrip.

1. Create a TabStrip in the layout of view MAIN_VIEW .


b) From the context menu of the ROOTUIELEMENTCONTAINER choose

Insert Element to create a TabStrip UI element.

2. Add three Tab UI elements to the TabStrip. The tabs should display the

captions Flights, Calendar View, and Graphics View, respectively.

a) From the context menu of the TabStrip UI element choose Insert Tab to

add a Tab UI element. Repeat this step two times.

b) To assign a text to a tab's caption, click on the corresponding Caption

UI element and assign the text to the property text .






3. Move the Table displaying the flights to the first Tab.

a) Drag the Table UI element and drop it on the first Tab UI element.


a) Edit the properties of the TabStrip UI element.

Set height = 450, vAlign (section LayoutData) = top, width = 100%,

and width (section LayoutData) = 70%.





Lesson Summary

You should now be able to:• Implement the following UI elements: ContextualPanel,





NET312 Unit Summary

Unit Summary




Related Information


section about developing applications based on Web Dynpro ABAP. The

Web Dynpro ABAP documentation contains a section named Reference.

Here you can find a complete documentation of all UI elements and the

corresponding element classes. UI elements discussed in this unit can be

found in the sub section named Layout.

• In each SAP system based on SAP NetWeaver 7.0, standard Web DynproABAP demo applications are available. The demos WDR_TEST_EVENTS

and WDR_TEST_UI_ELEMENTS deal with UI elements in general.




Unit Summary NET312




Unit 3Complex UI Elements

Unit Overview

UI elements that need to have other elements to be defined as sub elements in

the UI element hierarchy are termed as complex UI elements. An example well

known from NET310 is the TableView UI element. This unit discusses all kinds of UI elements belonging to this categorization.

In the first lesson, the TableView UI element is reviewed, the Tree UI element

is the topic of second lesson, while the remaining complex UI elements are

investigated in the third lesson.

Unit Objectives


• Implement grouping of table column and table rows

• Implement sorting and filtering a table

• Define table popins

• Define the color for complete table columns or single table cells

• Use cell specific table cell editors

• Display subtotals and totals of numeric table columns

• Create tree tables

• Implement editable tables

• Create static trees

• Create dynamic trees having an undefined number of hierarchy levels

• Implement the DateNavigator UI element• Implement the PhaseIndicator UI element

• Implement the RoadMap UI element

Unit Contents

Lesson: The Table UI Element................................................. 79

Exercise 4: Table UI Element - Set Table Properties and define RowGroups .......................................................................135

Exercise 5: Table UI Element - Sorting and Filtering ..................141


http://-/?-

http://-/?-



Unit 3: Complex UI Elements NET312

Exercise 6: Table UI Element - Table Popins and Cell Colors........ 149

Lesson: The Tree UI Element .... ... .... .... .... .... .... .... ... .... ... .... ... .159

Exercise 7: Displaying hierarchical Content with a Tree UI Element 175Lesson: Additional complex UI Elements....................................187

Exercise 8: Implementing a DateNavigator UI element ............... 203


http://-/?-

http://-/?-

http://-/?-

http://-/?-



NET312 Lesson: The Table UI Element

Lesson: The Table UI Element

Lesson Overview

In this lesson the Table UI element is discussed in detail. This includes element

properties and element events, grouping columns, grouping rows, filtering,

sorting, using of table popins, setting the color of complete columns or single

cells, displaying subtotals and totals of numeric columns, and using cell-specific

cell editors. Further topics are tree tables end editable tables.

Lesson Objectives


• Implement grouping of table column and table rows• Implement sorting and filtering a table







Business ExampleThe content of a data base table has to be displayed by a table in an Web Dynpro

for ABAP application. However, the wizard provided in the ABAP Workbench

does only allows to create very simple tables. Thus you would like to learn more

about the Table UI element.

The Table - Basics

The Table UI element is the most complex UI element offered by the Web Dynpro

framework. It contains a large number of properties and possible kinds of sub

elements. In the following sections the implementation of all kind of functionality

related to the Table UI element will be discussed. As a prerequisite it is assumed,that you are familiar with the definition of a table using the wizard offered in

the ABAP Workbench.


The context of a stable consists of a context node having the cardinality (0:n) or

(1:n). The Table UI element will be bound to this node. At runtime, the node

collection will contain an arbitrary number of elements. Each element will be

displayed as a line in the table.





The context node can have an arbitrary number of context attributes. At runtime,

the values of these attributes for each context element may then be displayed

as cell values in the related table line.

If the node property Initialization Lead Selection is checked, then the first context

element in the node collection will get the lead selection, automatically. By default

(property selectionMode of Table UI element is set to auto), the related line of the

Table will then be highlighted.

Finally, the node's Selection property defines a proposal for the minimum and

maximum number of table lines that may be selected by the user. For each table

bound to this context node, this can be adjusted via the Table UI element property

selectionMode (see sub section dealing with the selection of rows).

Figure 38: Table: Context definition





Defining a simple Table

The basic table in the layout is defined by a combination of at least three types of

UI elements:

• The root element is the Table UI element. The property dataSource of this

element has to be bound to the context node containing the data.

• For each column to be displayed by the table, a TableColumn UI element

has to be defined as a sub element of the Table.

• The content of each column is defined by a table cell editor. The cell editor

may be a TextView, or a InputField , or some other UI element that can be

used to output the value of a context attribute. The cell editor defines how

the content in the complete column is rendered. The UI element serving as

the cell editor has to be defined as a sub element of the TableColumn. The

key property of the cell editor (e.g. text for the TextView) has to be boundto the related context attribute of the table node.

• Optionally, a column header can be assigned to each column. This is done by

creating a Caption UI element as a sub element of the related TableColumn.

Figure 39: Table: UI definition and context binding (1)





Figure 40: Table: UI definition and context binding (2)

If the key property of a cell editor is bound to a context attribute that is typed

with an ABAP Dictionary type, then the Caption will automatically display the

medium text of the related data element.

A simple table as sketched in this section can be created using the Web

Dynpro Code Wizard in the view's layout. In addition, the static method

CL_WD_DYNAMIC_TOOL=>CREATE_TABLE_FROM_NODE( ) can be

called from the hook method WDDOMODIFYVIEW( ) of a view in order to create

a simple table dynamically.

UI Element Properties

The visibility of the complete table can be toggled by setting the property visible

accordingly. footerVisible allows to toggle the visibility of the table footer.

readOnly is used to allow / forbid that the user enters a value in any editable field

of the table. enabled is used to enable / disable all table elements. This includesthe possibility to select lines or to navigate.

The value of the property emptyTableText will be displayed in the table, if the

number of visible rows is defined variable (visibleRowCount = -1) and the node

collection is empty.

The table with can be adjusted by setting the property width accordingly (in

pixels or percent).





The property fixedTableLayout allows to define each table column precisely as

wide as specified by the TableColumn property width. If fixedTableLayout is set to

ABAP_TRUE and the cell content is to wide to be displayed completely, then itis cut off on the right. If fixedTableLayout is set to ABAP_FALSE each column

is as wide as specified but at least as wide as the widest content in the related

table cell editor.

The property legendID allows to assign a Legend UI element to the Table. In this

case, the property has to be evaluated with the legend's id . The Legend UI element

is discussed as a sub element of the DateNavigator later in this chapter.

UI Element Properties: Design

The property design allows to choose between three different color schemes. The

value of this property determines the color of the cell content, the cell backgrounds

and the table elements (e.g. grid, border, footer, column header). However, the

visual design does also depend on the value of the properties readOnly and

enabled .

Figure 41: Table: Setting the design

The following table summarizes all possible combinations of these Table property

values:





Table design - non-editable cells

design read_only enabled cell content cell

background

standard X X standard white

X standard white

X standard gray

standard gray

alternating X X standard alternate

X standard alternate

X standard gray

standard gray

transparent X X standard transparent

X standard transparent


standard transparent

Table design - editable cells

design read_only enabled cell content cell

background

standard X X standard white

X standard white

X standard white

grayed out gray

alternating X X standard alternate

X standard alternate

X standard white

grayed out gray

transparent X X standard transparent



grayed out gray





Comparing the results displayed in the tables above, the following rules can be

found:

• If readOnly is set to ABAP_TRUE , the property enabled does not influence

the visual design. Having set design to standard , all cells will have a white

background. For design = alternating the table line color will alternate

between white and gray. Finally, design = transparent will result in

transparent cells.

• If readOnly is set to ABAP_FALSE , the property enabled will have no

influence on the design of non-editable cells.

Non-editable cells will have a gray background (design = standard or

alternating ) or transparent background (design = transparent ).

• If readOnly is set to ABAP_FALSE , the property enabled will have an

influence on the design of editable cells.

If enabled is set to ABAP_FALSE , then editable cells will have a gray

background and the content is grayed out (all designs).

If enabled is set to ABAP_TRUE , then editable cells will have a white

background (design = standard or alternating ) or a transparent background

(design = transparent ).

The visibility of the table grid can be adjusted by the property gridMode. This

setting has no effect if design is set to transparent .

UI Element Properties: Vertical Scrolling and Context Paging

Hint: If the application parameter WDTABLENAVIGATION is set to

SCROLLBAR, the elements used to initiate vertical scrolling are replaced

by a vertical scroll bar.

The number of table lines can be adjusted by the property visibleRowCount . By

default, this property has the value 5. If this property is set to -1, all data sets

stored in the context are displayed.

If the first element displayed by the table should not be related to the first element

stored in the context, the offset property visibleFirstRow can be used. The property

displayEmptyRows allows to omit that the table displays empty table lines. Thissituation occurs if visibleRowCount is larger then the difference between the index

of the first context element displayed by the table and the total number of elements

stored in the context.





Figure 42: Table: Vertical scrolling and context paging

To implement context paging (for details see section about the UI element

MultiPane), the properties rowCount and firstActualRow have to be adjusted. The

value of the property rowCount describes how many lines may be accessible byscrolling in the table. The value of this property is displayed in the table footer as

the total number of visible table lines. firstActualRow is used to define to which

table line the first context element is to be related. Finally visibleFirstRow has

to be set to a value larger then firstActualRow to display the context element that

are already stored in the context node.

Caution: If firstActualRow is set to a value larger then visibleFirstRow,

the application will dump.

UI Element Properties: Horizontal Scrolling

Hint: If the application parameter WDTABLENAVIGATION is set to

SCROLLBAR, the elements used to initiate horizontal scrolling are

replaced by a horizontal scroll bar.

While visibleRowCount defines the number of lines displayed by the table,

scrollableColCount defines the number of scrollable columns displayed by the

table. By default, this property is set to -1 so all columns are displayed and no





scrolling functionality is offered. However, if scrollableColCount is set to a value

larger then 0, then additional elements appear in the table footer. These elements

allow to navigate between the scrollable columns in the table horizontally.

Hint: A Table can contain non-scrollable columns. This is defined by the

property fixedPosition of the TableColumn UI element. All columns

having the value left assigned to this property will appear as fixed columns

left of the scrollable columns. All columns having assigned the value

right to the property will appear as fixed columns right of the scrollable

columns. All other columns (having assigned the default value not fixed

to the property fixedPosition) will be scrollable.

Figure 43: Table: Horizontal scrolling

If the first scrollable column displayed by the table should be different from

the first scrollable column defined in the layout of the view, the property firstVisibleScrollableCol can be used. If the id of any TableColumn is assigned

to this property, only this column and the columns right of the assigned column

will be displayed by the table.

Hint: If scrollableColCount is set to its default value (-1), it is not

possible to navigate to the table columns that are actually hidden.





UI Element Properties: Row Selection

Hint: Avoid confusing a selected context element and a context element

at lead selection. A selected element does not need to be the element at

lead selection and vice versa.

Clicking on the mark column will always select / deselect the

related element. This is displayed by the light orange color. The

selected elements of a node can be obtained by calling the method

GET_SELECTED_ELEMENTS( ).

The line corresponding to the element at lead selection will be displayed

in dark orange. This element is determined programmatically by calling

the method GET_ELEMENT( ).

The property rowSelectable is used to define which of the table lines may be

selected by the user. Statically, this property only allows to set the selectability for

all table lines to the same value. However, if the context node related to the table

data contains an additional attribute of type WDY_BOOLEAN , and if the Table

property rowSelectable is bound to this context attribute, then the selectability can

be defined row by row.

Figure 44: Table: Defining selectable rows





Caution: If a context element to be displayed by the Table is defined as

non-selectable and if this the element is also the element at lead selection,the application will dump.

This is typically a problem for context nodes having the node property

Initialize Lead Selection set to ABAP_TRUE . If the first element is also

defined as a non-selectable element, the application will dump.

By default ( selectionMode = auto), the lead selection is changed automatically if

the user selects a line in the table by clicking on the mark column. However, this

automatism can be switched off by setting the property selectionChangeBehaviour

to manual (default auto). Then, clicking on any table row will neither highlight

this row nor change the lead selection index in the related context node.

Programmatically, the information which line was selected by the user can bedetermined, if an action is assigned to the table property onLeadSelect . From the

interface parameter WDEVENT of the related action handler method, the index

of the table line selected by the user can be extracted (parameter ROW in table

WDEVENT → PARAMETERS ).

The property selectionMode can be used to define if multiple lines may be selected

by the user and if selecting a line does also change the lead selection index. The

selection mode as defined by the context node property Selection can be altered

this way. If selectionMode is set to none, no mark column is displayed and the line

corresponding to the element at lead selection is not highlighted.

Hint: If the user left-mouse clicks on the mark column without pressing

another key, the related table line will be selected and previously selected

table lines will be deselected.

To select additional table lines, the user can press CTRL when left mouse

clicking on the mark column.

Finally, if ALT+SHIFT is pressed when left mouse clicking on the mark

column, then all data sets between the previously selected data set and the

actually selected data set are marked.

If only one context element may be selected, then pressing CTRL or

ALT+SHIFT in addition to left-mouse clicking behaves identical toleft-mouse clicking without pressing any additional key.





Table: Row Selection Modes (LMC = left mouse click)

Node

property

Selection

Table property

selectionMode

Number of

selectable

table rows

Round trip

triggered by

selecting table

row (LMC /

LMC+CTRL /

LMC+ALT+SHIFT)

Lead

selection

index

changed

0:1, 1:1 single, auto 0:1, 1:1 Yes, Yes, Yes Yes, Yes,

Yes

singleNoLead 0:1,1:1 No, No, No No, No,

No

multi,

multiNoLead

dump dump dump

0:n, 1:n single 0:1, 1:1 Yes, Yes, Yes Yes, Yes,

Yes

singleNoLead 0:1, 1:1 No, No, No No, No,

No

multi, auto 0:n, 1:n Yes, No, Yes Yes, No,

No

multiNoLead 0:n, 1:n No, No, Yes No, No,

No

Implementing additional Table Functionality

Header and Toolbar

A Table UI element may have a title defined by a Caption UI element being a sub

element of the Table. The title can display a simple text or an image. If image

and text are displayed together, the developer can decide if the image is placed

left or right of the text.

In order to offer table-dependent functionality, a ToolBar UI element can

be defined as a sub element of the Table. The ToolBar itself may contain a

combination of the following elements:

• Buttons: ToolBarButton, ToolBarButtonChoice, ToolBarToggleButton

• Drop down boxes: ToolBarDropDownByIndex , ToolBarDropDownByKey

• Links: ToolBarLinkToAction, ToolBarLinkToURL

• Input field: ToolBarInputField

• Separator line: ToolBarSeparator





The toolbar elements can be created left-aligned or right-aligned in respect to the

toolbar. If too many tool bar elements are defined so all elements can not be

displayed in a single line, the ToolBar property wrapping allows to break the tool bar content in multiple lines.

Figure 45: Table: Defining title and tool bar





Grouping of Columns and Rows

Figure 46: Table: Grouping of columns and rows

Each table column may have a separate column title defined by the sub element of type Caption. In addition, multiple columns may have a common group header

displayed above the column-specific column titles. To create this common group

header, all related columns have to be defined as sub elements of the same

TableColumnGroup UI element, while this TableColumnGroup has to be defined

as a sub element of the Table. The common group header itself is defined by a

Caption element that is defined as a sub element of the TableColumnGroup UI

element.

The property visible of the TableColumnGroup allows to hide / display all columns

that depend on this column group. The property fixedPosition is used to fix all

columns related to the column group at the left border of the table (value = left ) or

at the right border of the table (value = right ). Only column groups not defined asfixed columns (value = notFixed ) are horizontally scollable.





Figure 47: Table: Defining column groups

If the data sets displayed by a table are sorted in respect to the leading columns, the

same value may appear multiple times in each of these columns. In this case it is

desirable to have each column value displayed only once (when it changes). This

simplifies the identification of new data groups in respect to the sorting criteria.

This result can be obtained, if the property groupingValue of the related

TableColumn UI element is set accordingly. This property can be bound to a

context attribute. Then, the cell content will only be displayed if the attribute value

changes in respect to the previous data set. If the column content should only be

displayed when it changed, then groupingValue has to be bound to the attribute

displayed by the table cell editor of this column.





Figure 48: Table: Defining row groups





Filtering

In order to allow filtering of the table data, the following things need to be

implemented:

• An action has to be assigned to the property onFilter of the Table UI element.

Result: An additional line will be displayed in the table above the table

content. However, it is not possible to enter any values yet.

Hint: From the interface parameter WDEVENT of the action handler

method, only the id of the UI element that fired the event can be

extracted.

• To be able to enter filter values for a certain attribute, the property filterValueof the related TableColumn UI element has to be bound to a context attribute

having the correct type.

• Thus, a node of cardinality (1:1) containing an attribute for each filter

column has to be defined in the context of the corresponding view.

Result: For each column having its property filterValue bound to a related

context attribute, an input field is displayed in the filter line.

• To display a drop down box instead of an input field in the filter line, a value

set has to be assigned to the related context attribute.

• Optionally, the property isFiltered of a TableColumn UI element can be

used to display / hide a filter icon in the column heading. This indicatesthat the current table entries are filtered according to restrictions on values

of this column.

To set this property dynamically, isFiltered has to be bound to a context

attribute of type WDY_BOOLEAN for each filter column.

• Thus, another node of cardinality (1:1) has to be defined in the context

of the corresponding view. For each filter column, an attribute of type

WDY_BOOLEAN has to be added keeping the information if a filter icon is

to be displayed in the column heading.





Figure 49: Table: Filtering

Figure 50: Table: Filtering - UI element properties





The implementation of filtering depends on the support package level installed

on the application server. Up to ABAP SPS 12, the filter algorithm has to be

written by the developer of the application. Beginning with ABAP SPS 13, thefilter algorithm is provided as a service method of a globally defined class. Both

implementations will be discussed below.

For SAP NetWeaver Application Server 7.0 ABAP having not applied at least

ABAP SPS 13 the following steps have to be implemented (typically in the action

handler method triggered by filtering):

• The filter values entered by the user have to be obtained from the context.

• All data sets have to be checked if they are compatible with the filter options

entered by the user. Only those data sets should be visible to the user after

filtering.

There are two approaches to have all data sets available without having to read

them again from the data base while the user only sees the filtered data sets

at the same time.

Approach one:

All data sets read from the data base are stored in a public component controller

attribute. Each time the user filters the data, the actual content of the context node

containing the data to be displayed is invalidated and refilled with data read from

the public component controller attribute. Only those data sets are copied to the

context, that are compatible with the filter criteria.

Approach two:

All data sets are stored in the context node bound to the Table. To filter the data,

all data being compliant with the filter criteria are shifted to the start of the node

collection. Then the number of context elements being compatible with the filter

criteria is calculated and the Table property rowCount is set accordingly. This

means that the context node always contains all data sets. However, data sets not

compliant with the filter values are hidden to the user.





Figure 51: Table: Filtering for SAP NW AS 7.0, up to ABAP SPS 12

For SAP NetWeaver Application Server 7.0 ABAP having applied at least ABAP

SPS 13 filtering is performed by calling a service method related to the Table UI

element. Internally, this service function checks to which context node the Table is

bound to. The content of this context node is then resorted according to approachtwo described above. Data sets not complient with the filter criteria are hidden to

the user by altering the Table property rowCount accordingly.

Hint: If the attributes related to the filter fields are of type STRING or of

type C , then logical operators may be used with the filter values. Allowed

operators are >, >=, <, <=, =, and ! (not equal). These parameters have

to be entered in front of the filter value (e.g. >=500). In addition to the

logical operators, the pattern sign * can be used as part of any filter

value (e.g. A*).

The programmer of the application only has to determine the reference to the

service object of the Table under consideration and he has to call the appropriate

method of this object to do the filtering.





The reference to the service object is most easily obtained in the hook method

WDDOMODIFYVIEW( ) of the related view:

• First, the reference to the runtime object describing the Table UI element

has to be determined. This reference is returned when calling the method

VIEW->GET_ELEMENT( ID = <TABLE_ID> ).

• The reference to the service object is available as a public attribute

_METHOD_HANDLER of the Table runtime object.

• However, _METHOD_HANDLER is typed generically. Thus, casting this

reference to a reference variable of type IF_WD_TABLE_METHOD_HNDL

is necessary to access table-specific functionality.

• Finally, the reference to the service object should be stored as a controller

attribute of the related view.

To filter the data stored in the context node, the method APPLY_FILTER( ) of the

service object has to be called.

Figure 52: Table: Filtering for SAP NW AS 7.0, ABAP SPS 13 and higher





Sorting

Figure 53: Table: Sorting

To allow sorting the content displayed by a Table, the following needs to be

implemented:

• An action has to be assigned to the Table property onSort . By default, all

columns will now display a pair of icons in their headers. Clicking on these

icons will lead to a round trip.

• If a column should not be sortable, the TableColumn property sortState

has to be set to nonSortable.

• If a column should be displayed presorted when the view is rendered the first

time, the TableColumn property sortState has to be set to down (descending)

or up (ascending).





Figure 54: Table: Sorting - UI element properties

The implementation of sorting depends on the support package level installed

on the application server. Up to ABAP SPS 12, the sort algorithm has to be

written by the developer of the application. Beginning with ABAP SPS 13, the

sort algorithm is provided as a service method of a globally defined class. Both

implementations will be discussed below.

For SAP NetWeaver Application Server 7.0 ABAP having not applied at least

ABAP SPS 13 the following steps have to be implemented (typically in the action

handler method triggered by event Sort ):

• The ID of the TableColumn the user has clicked on and the desired sorting

direction has to be determined. This information is contained by the

table WDEVENT → PARAMETERS available in the action handler method

(parameters COL and DIRECTION , respectively).

• The actual content stored in the context node has to copied to an internal

table.

• If the table contains a mark column, the indices of the selected table lines

and the lead selection index have to be determined and stored with the data.

• The internal table has to be sorted according to the user action.

• The sorted internal table has to be copied back to the context, replacing

the old content.

• If the table contains a mark column, the indices of the selected table lines

have to be transferred to the attribute selected of the related context elements.

In addition the lead selection index has to be set in the related context node.





Figure 55: Table: Sorting for SAP NW AS 7.0, up to ABAP SPS 12 - principle

Figure 56: Table: Sorting - source code (step 1 and step 2)





Figure 57: Table: Sorting - source code (step 3)

Figure 58: Table: Sorting - source code (step 4 and step 5)





Figure 59: Table: Sorting - details for step 2 (1)

Figure 60: Table: Sorting - details for step 2 (2)





Figure 61: Table: Sorting - details for step 5

For SAP NetWeaver Application Server 7.0 ABAP having applied at least ABAP

SPS 13 sorting is performed by calling a service method related to the Table UI

element.

The programmer of the application only has to determine the reference to theservice object of the Table under consideration and he has to call the appropriate

method of this object to do the filtering. Please refer to the last sub section for

details about determining the reference to this service object.

To sort the data stored in the context node, the method APPLY_SORTING( )

of the service object has to be called.





Figure 62: Table: Sorting for SAP NW AS 7.0, ABAP SPS 13 and higher

TablePopins

The TablePopin allows to display detail information related to a data set (row

popin) or a data cell (cell popin) as an insertion below the related row of the Table.

With a cell popin the associated cell is assigned the background color of the

popin, so popin and cell can be identified as belonging together. The UI element

TablePopinToggleCell is provided for expanding and collapsing the TablePopin.

However, the visibility of a TablePopin may also be toggled by clicking on any

clickable UI element on the view.





Figure 63: TablePopin: Row popin

Figure 64: TablePopin: Cell popin





To define a row popin, the UI element TablePopin has to be created as a direct

sub element of the Table. This is done from the context menu of the Table by

selecting the menu entry Insert Table Popin.

Hint: Each Table may only contain one TablePopin UI element defining

the row popin.

To define a cell popin for a cell being displayed in a certain column, a TablePopin

UI element has to be created as a direct sub element of this TableColumn. This is

done by choosing the menu entry Insert Table Popin from the context menu of

this TableColumn.

Hint: Each TableColumn may only contain one TablePopin UI elementdefining the cell popin related to this TableColumn.

The content displayed by the TablePopin is defined by the sub elements of the

TablePopin UI element. From the context menu of the TablePopin, only one

direct sub element can be created (menu entry Insert Content ). However, this is

no restriction, since the sub element can be a container element which can have

an arbitrary number of sub elements.

Caution: The content of a TablePopin may not be a

ViewContainerUIElement , since multiple row popins may be displayed at

runtime in parallel. This would imply that multiple instances of the sameview are to be embedded at runtime - which is not allowed.

Hint: The data displayed by a TablePopin UI element should be stored in

the data node. This allows to display row-related information by multiple

table popins that are opened in parallel.





Figure 65: Table: Defining a row popin and cell popins

The TablePopin has the following properties: design allows to influence the

background color of the table popin's content. hasContentPadding specifies

whether or not it is possible to insert a padding between the content and the UIelement borders. titleDesign allows to display an additional image in the title line

of the popin (ok , critical , or error ), or display the title without an image (text ).

Finally, the text in the title line is defined by the property titleText .

To define which table popin is displayed below a given table row, the property

selectedPopin of the Table UI element has to be set accordingly. Each table popin

has a unique id . If this id is assigned to the property selectedPopin, the related

table popin is displayed below each table row. To be able to define the table popin

and its visibility dependent on the table row, the property selectedPopin has to

be bound to a context attribute of type string being defined in the context node

keeping the table data. At runtime, this context attribute can have a different

value for each context element. If no value is assigned to this attribute, no table popin will be displayed for this table line.





Figure 66: Table: Data binding required for dynamically assigning a table

popin

Figure 67: Table: Displaying table popin





To change the visibility of a table popin, the application has to offer an associated

UI element the user can click on. All kinds of UI elements allowing to trigger a

round trip can be used for this purpose (e.g. a Button, a LinkToAction, a CheckBox,...).

To implement a cell popin, the associated UI element should be located in

the table cell the popin is related to. An action should be assigned to an

appropriate event of this UI element, so a related action handler method is

processed when the user clicks on the UI element. Event-related information can

then be extracted from the interface parameter WDEVENT . The internal table

WDEVENT → PARAMETERS will contain the reference to the context element

(parameter CONTEXT_ELEMENT ), that corresponds to the table line the user has

selected. This allows to generate related detail information.

To expand the cell popin, the id of the TablePopin has to be saved in the context

attribute, the Table property selectedPopin is bound to.

Figure 68: Table: Opening a cell popin

To close the table popin (call popin or row popin), the icon in the right upper corner

of the popin area may be used. Clicking on this icon will fire the popin's event

Close (property onClose). In the related action handler method the value of the

context attribute, the Table property selectedPopin is bound to, has to be cleared.





Figure 69: Table: Closing a table popin

To expand a row popin, a row-related UI element should be offered. This may be a

link in an extra table column. However, the Web Dynpro UI element library offers

a special element for this purpose, the TablePopinToggleCell UI element. Thiselement is used as a table cell editor in an extra TableColumn. When the popin

is closed, this UI element displays an arrow pointing right. When the popin is

opened, an arrow pointing down is displayed. Opening and closing the row popin

using a TablePopinToggleCell UI element is performed automatically. This means

that the value of the attribute, the Table property selectedPopin is bound to, does

not need to be coded by the developer.

To create a TablePopinToggleCell , the menu entry Insert Cell Variant defined in

the context menu of a TableColumn has to be selected. In the dialog popping

up different cell variant types are offered. The first entry in the variant list is





the TablePopinToggleCell . The TablePopinToggleCell is given an identifier by

setting the property variantKey to an appropriate value. The same value has to be

assigned to the property selectedCellVariant of the related TableColumn.

Hint: A cell variant is defined as a direct sub element of a TableColumn UI

element. For different purposes, different kinds of cell variants do exist:

• TablePopinToggleCell : This element is discussed in this section. It

may be used to define a special column used to expand and collapse

TablePopins displaying row-related information.

• TableSingleMarkableCell : This cell variant type may be used

to define cells the user can select and mark (e.g. in a time table).

The table cell editor will be defined as a sub element of this typeof cell variant.

• TableStandardCell : This cell variant type may be used to define a

cell-specific rendering of the table content. The table cell editor will

be defined as a sub element of this type of cell variant. This allows

to render different cells of the same table column differently.

• TableSummaryCell : This cell variant type may be used to define

cells for displaying totals of numeric columns. The table cell editor

will be defined as a sub element of this type of cell variant. This

kind of cell variant will be discussed in the section dealing with

displaying totals and subtotals.

• TableSummaryHierarchyCell : This cell variant type may beused to define subtotals for numeric columns. In contrast to the

TableSummaryCell , the TableSummaryHierarchyCell displays an

arrow-like icon. This is used to display / hide the group of cells

the subtotal / total is calculated for. The table cell editor will be

defined as a sub element of this type of cell variant. This kind of

cell variant will be discussed in the section dealing with displaying

totals and subtotals.

For each TableColumn, an arbitrary number of cell variants may

be defined. Each cell variant is identified by the value of its

property variantKey. At runtime, any of the cell variants can be

selected by assigning the variants key to the TableColumn property selectedCellVariant . If this property is bound to an attribute defined in the

table data node, each table cell can be rendered differently.

If the value of this attribute is initial, then the standard table cell editor

( the table cell editor that is defined as a direct sub element of the

TableColumn) is used to render the related table cell.





Clicking on a TablePopinToggleCell UI element will fire the element's event

Toggle (property onToggle). In the related action handler method, row related

information can be read and stored in the context.

Figure 70: Table: Defining a TablePopinToggleCell UI element

Colors

In a Table, complete columns can be given a background color by setting the

property cellDesign of the corresponding TableColumn accordingly. Binding this

property to a context attribute of type WDUI_TABLE_CELL_DESIGN allows to

change the background color of a complete TableColumn dynamically. If the

context attribute containing the color value is part of the data node, then the color

can be defined dependent on the row. In this case, each cell of a given column

can have an arbitrary background color.





Figure 71: Table: Defining the background color

Figure 72: Table: Defining the background color of a column





Editable Tables

Cell variants of type TableStandardCell can be used to offer different table cell

editors for each TableColumn. Thus, at runtime each table cell may be rendered

differently. This allows to create tables containing cells that are editable on

request. In a typical scenario, certain cells of selected table lines may be switched

from text field (cell editor TextView) to input fields (cell editor InputField ) if an

additional link or button is pressed by the user.

Figure 73: Table: Editable cells

To implement the possibility to toggle table cells between text fields and input

fields the following things need to be implemented:

1. An additional context attribute has to be added to the table data node. For

each context element this attribute will store the variant key of the cell

variant that should be used to render the related table line.

2. In the view's layout a cell variant of type TableStandardCell has to be added

to each TableColumn. The property variantKey has be set identically for

all cell variants.

3. An cell editor has to be defined for each cell variant (e.g. InputField ,

CheckBox, TextView, ...).

4. The property selectedVariantKey of the Table has to be bound to the context

attribute defined in step 1.





Incorrect data entered by the user can not checked before a round trip to the

application server takes place. If a round trip takes place, the Web Dynpro runtime

will check whether the values entered by the user have the correct type and if they are compliant with the domain fixed values. If an error is found by the Web

Dynpro runtime for at least one of the field values, the navigation is cancelled

and all error messages will be displayed on the previous view assembly. In this

context, incorrect field values are not passed to the related context attribute.

If application specific input checks have to be implemented, the following issues

have to be taken into account:

• The user of the application may trigger a round trip without firing an event

that is bound to an action. This may occur if the user clicks on the mark

column of the table or if the user scrolls in the table. In this case, input

checks that are implemented in the hook methods WDDOBEFOREACTION( ), WDDOAFTERACTION( ), or in any action handler method will not be

processed.

• The data entered by the user is stored in the related context attributes. The

previously stored data is deleted and can not be restored.

• The context node and the dependent context elements do not store any

information that can be used at runtime to find out which data cells have

been changed by the user.

To overcome these problems, the following implementation techniques could be

applied:

The input checks could be performed in the component controller methodWDDOBEFORENAVIGATION( ). This method is processed for each round trip

just before navigation takes place. If an error is found, a message related to the

appropriate context attribute could be created. To cancel the navigation, the

interface parameter CANCEL_NAVIGATION of the message method can be set

to ABAP_TRUE or the method CANCEL_NAVIGATION( ) (defined in the global

interface IF_WD_COMPONENT ) can be called.

Figure 74: Table: Implementing input checks





To find out which of the cells have been overwritten by the user, the context

change log could be checked. The context change log collects exact informations

about the previous value, the actual value, the column name, the line index, andthe binding informations for all table cells changed by the user. The context

change log can be accessed as follows:

• First, the reference to an object describing the controller context has to

be obtained from the attribute WD_CONTEXT by calling the method

GET_CONTEXT( ). The reference returned by this method is of type

IF_WD_CONTEXT .

• For the object returned in the last step, the method GET_CON-

TEXT_CHANGE_LOG( ) can be called. This will return the context change

log as an internal table of type WDR_CONTEXT_CHANGE_LIST .

Caution: By default, reading the context change log will

automatically reset the log. However, by setting the interface

parameter AND_RESET to ABAP_FALSE , the complete change

history is collected by the log.

• To stop logging, the method DISABLE_CONTEXT_CHANGE_LOG( ) can

be called.

• To enable logging or to switch on logging after having switched it off, the

method ENABLE_CONTEXT_CHANGE_LOG( ) has to be called.

Hint: Do not forget to call this method before changes by the user may take place.

• Finally, the method RESET_CONTEXT_CHANGE_LOG( ) can be called to

clear the log. Logging is not disabled by calling this method.

Let's consider the case that the context change log contains the complete history

of all changes performed by the user. If a table cell has been changed multiple

times by the user, multiple entries containing all historical values for this field are

accessible from the context change log. However, only the last entry is relevant in

respect to input checks and database updates. In addition only the first entry is

relevant to roll back the changes performed by the user.

Thus, checking the user input could be implemented as follows: To find out which

context attributes have been changed by the user, the application can loop over the

internal table returned by the method GET_CONTEXT_CHANGE_LOG( ). This

internal table contains the columns ATTRIBUTE_NAME and ELEMENT_INDEX

which can be used to identify the context element and the context attribute that





has to be checked. After having checked a certain context attribute, the attribute's

name and index should be stored in an internal table. This allows to find out, if

a context attribute has already been checked before.

Hint: If you forget this check, you may get as many identical error

messages for a table cell, as there have been changes of the related

attribute value.

Figure 75: Table: Implementing input checks - get change information





Figure 76: Table: Content of context change log

Figure 77: Table: Implementing input checks - avoid checking same attribute

more than once





Figure 78: Table: Implementing input checks - get actual values for edited

table cells

Before saving the data to the data base the application has to collect all relevant

information provided by the context change log in an internal table. If a field

value is changed several times, this collection should be implemented in a way,

that only one entry remains in the internal table (containing the last checkedvalue, entered by the user). From the context change log the last change can be

identified easily, since all changes performed by the user are serially numbered

(column SEQUENCE ).

Displaying Totals and Subtotals

The Table UI element offers the possibility to display subtotals and totals of

numeric columns. The data sets displayed by the Table can be sorted, so subtotals

can be displayed after each group of data sets having the same values in respect

to the sorting criteria. Special cell variants do exist to display subtotals or totals.

The background color of the related cell editors may be set to light yellow or dark

yellow. For one of the cell variants, an arrow is displayed with the cell value.Clicking on this arrow allows to fire an event. In the related action handler method,

expanding and condensing the related data sets of this group may be implemented.

Hint: Expanding and condensing a group of data sets is not done

automatically when clicking on the arrow displayed by the table cell editor.





Figure 79: Table: Displaying totals and subtotals

In this sub section, all aspects related to displaying subtotals and totals are

discussed. In the first step, displaying subtotals without the possibility to condense

/ expand the corresponding data set group is discussed.





The implementation consists of the following steps:

1. First, all data sets to be displayed have to be stored in an internal table. This

table should contain an additional column of type string. This column will

be filled with the name of the cell variant used to display the corresponding

table line.

2. The internal table has to be sorted according to the data set groups, subtotals

should be displayed for.

3. After each data set group an additional line has to be inserted into the

internal table. This table line has to contain the sums of the numeric columns

for this group. The cells forming the grouping criterion should contain the

corresponding values. The extra table column should be filled with the name

of the cell variant used to display this table line. All other nun-numeric

cells should be initial.4. The context of the controller has to be defined. The data node should contain

all attributes to be displayed by the table. In addition, an attribute related

to the extra table column has to be defined. At runtime, this attribute will

contain the name of the cell variant used to render the related table line.

5. The content of the internal table has to be copied to the context.

6. Next, the view's layout has to be defined. Using the wizard, a simple table

displaying the content of the context node can be defined. However, the

extra table column (containing the cell variant name) may not be displayed.

7. For each TableColumn the property selectedCellVariant has to be bound to

the context attribute containing the cell variant name.

8. For each TableColumn, a cell variant of type TableSummaryCell has to be

defined as a direct sub element. The property variantKey has to be evaluated

with the variant name for the subtotal lines (defined in step 3).

9. Finally, a table cell editor (typically a TextView UI element) has to be defined

for each cell variant defined in the previous step. The primary property has

to be bound to the context attribute related to this column.

Hint: The definition of the cell variants and the dependent table cell

editors may also be performed dynamically using the hook method

WDDOMODIFYVIEW( ).





Figure 80: Table: Displaying subtotals

Figure 81: Table: Displaying subtotals - concept





Figure 82: Table: Displaying subtotals - UI definition and data binding

The application could offer the possibility to expand and collapse a group of data

sets that is related to a subtotal table line. There are two ways to implement this

functionality.The cell variant type TableSummaryCell supports the event LevelAction (property

onLevelAction). If an action is assigned to this event, then the user may click on

the cell content to trigger a round trip. In the related action handler method, the id

of the cell variant (parameter ID) and the reference to the context element related

to the table line the user has clicked on (parameter CONTEXT_ELEMENT ) are

available from the interface parameter WDEVENT . This allows to determine,

which group of data sets has to be collapsed / expanded. However, the last state is





not provided by the framework. Thus the application has to store this information

for each group of data sets, subtotals are calculated for. Therefore, the content of

the context is defined as follows:

1. The internal table containing all data sets and all subtotals is defined as a

controller attribute visible to the view displaying the table (e.g. a public

attribute of the component controller).

2. An extra column for saving the key of the variant that has to be used to

render the subtotal lines has to be added. In addition, another column

containing the information which group of data sets should be collapsed /

expanded has to be added.

3. The internal table is filled with all data sets and it is sorted.

4. At the end of each data set group, an extra table line is inserted. This line

contains the common group values, the sums for all numeric columns, thekey of the cell variant used to render the subtotal line, and the boolean

information describing the next state of this data set group (expanded /

collapsed).

5. The view's context is defined accordingly.

6. Each time the view is rendered, the data sets are copied from the internal

table to the context. For data set groups marked as being expanded, all data

sets of this group plus the subtotal table line are copied. For data set groups

marked as being collapsed, only the subtotal table line is copied.

7. Each time the user clicks in a cell of the subtotal table line having an action

bound to the event LevelAction, a round trip takes place. In the action handler

method, the key values of the data set group are determined. In the internaltable, the boolean flag is toggled for the related summary table line.





Figure 83: Table: Expanding / collapsing data set groups

Figure 84: Table: Expanding / collapsing data set groups - concept

Expanding a data set group by a cell editor being a sub element of a

TableSummaryCell UI element has the following disadvantages:





The user gets no visual information, that he can click on the cell to expand

/ collapse the group. In addition, in the related action handler method, no

information is provided about the next status of the data set group the user hasselected.

Thus a second concept exists to allow expanding / collapsing data set

groups. In this concept the cell variant TableSummaryCell is replaced by a

TableHierarchySummaryCell for an arbitrary number of columns. Then, the

dependent table cell editors do not only display the cell content but also an arrow

being displayed left of the cell value. This arrow points to the right (status

collapsed) or to the top (status expanded). The kind of arrow displayed at runtime

is defined by the property expanded of the cell variant. This property will be

bound to the corresponding boolean context attribute.

Clicking on the arrow will fire the event StatusAction (property onStatusAction).

Assigning an action to this event allows to trigger a related action handler method.

From the internal table PARAMETERS of the interface parameter WDEVENT ,

not only the id (parameter ID) and the reference to the related context element

(parameter CONTEXT_ELEMENT ) can be determined, but also the information

about the next status of this data set group (parameter EXPANDED).

Figure 85: Table: Comparison TableSummaryCell and TableHierarchySum-

maryCell





If subtotals should be displayed for different data set groups, the concepts

explained up to now have to be extended as follows:

1. The internal table is changed in a way, that it contains a subtotal line after

each data set group. For each data set group a different key for the cell

variant used to display the related subtotal line in the table has to be stored.

Example:

Subtotal after each connection → Variant key SUM_CONNID. Subtotal after

all connections of same carrier → Variant key SUM_CARRID. Total after all

connections of all carriers → Variant key SUM_ALL.

2. In the view's layout, as many cell variants have to be added to each

TableColumn as there are different data set groups (variant keys). Each cell

variant needs to have a table cell editor being defined as its sub element.

Hint: This is really a lot of work (definition of n * m * 2 additional

UI elements, where m = number of columns and n = number of

data set groups). Thus, defining these UI elements dynamically

is the better way.

3. One of the cells displayed in a subtotal / total table line should be defined

by a TableHierarchySummaryCell cell variant. Typically the last grouping

criterion is displayed this way.

Example: The group of flights belonging to a certain connection is expanded

/ collapsed by clicking on the arrow displayed with the connection number.

The group of subtotal lines related to all connections of a given carrier is

expanded / collapsed by clicking on the arrow displayed with the carrier.

Finally, some properties of the TableSummaryCell and of the

TableHierarchySummaryCell that have not mentioned yet should be discussed.

Both elements contain the property cellDesign. This property may have the values

subtotal (light yellow) and total (dark yellow). The later property value should

be used, if totals over all data sets are to be displayed at the end of the table.

Thus totals and subtotals are technically identical, besides a different background

color of the cells.

The TableSummaryCell property level is used to display the hierarchy level byadding dots in front of the cell value in a subtotal line. The value of this property

corresponds to the number of dots added to the cell value. Three dots visualizes,

that this group has two sub groups, while the data sets are displayed on the third

level.





Tree Tables

Tables can represent a hierarchy using the aggregation master column. The master

column displays the grouping criterion (defined by the table cell editor) and an

arrow-like icon. This arrow points to the right (condensed state) or to the bottom

(expanded state). There are two ways to organize the table content:

If the table content is expanded, all data sets related to the selected grouping

criterion could be displayed directly. However, it is also possible that expanding

the table content will display additional sub groups that can also be expanded and

condensed. It is up to the developer to define the depth of the hierarchy.

Example: A table could display the carrier name in the master column. If the

table content is expanded for a certain carrier, all flights of this carrier could be

displayed. However, expanding the table content for a certain carrier could also

result in displaying additional master column entries for each connection number.To display the flights related to a certain connection number, the user then has to

click on the related master column entry.

Figure 86: Tree Tables: One level hierarchy





Figure 87: Tree Tables: Multiple level hierarchy

In the layout of the view, a special column has to be defined to display the

grouping criteria. From the context menu of the Table UI element, the menu item

Insert Master Column has to be selected to create this column.There are two types of master column UI elements, the TreeByKeyTableColumn

UI element and the TreeByNestingTableColumn UI element. Only the

TreeByKeyTableColumn that is bound to a flat context node is discussed here.

Next, a table cell editor has to be assigned to the master column. This table cell

editor will be used to display the content of the master column. An optional

Caption UI element can be created as a sub element of the master column to

define the column heading.

The TreeByKeyTableColumn UI element contains the following properties:

The property Cell Design allows to define the cell background color of the master

column.

childrenLoaded can be used to define if data sets related to a grouping criterion

have already been loaded. If this property is bound to a context attribute of type

WDY_BOOEAN this information can be defined differently for each data set

group. If the user expands a group, the application has to check the value of this

attribute in order to decide if the dependent data sets have to be read.





The property expanded has to be bound to a context attribute of type

WDY_BOOLEAN . At runtime, this attribute will contain the information, which

group is expanded and which group is condensed. The Web Dynpro runtime setsthis attribute according to the actual state of the data set group.

isLeaf should be bound to a context attribute of type WDY_BOOLEAN . Then,

this attribute allows to define, which context element is displayed as a grouping

criterion and which context element is displayed as an actual table data set.

rowKey should be bound to a context attribute of type STRING. This attribute

allows to assign a row-specific key to each context element. This is used to define

the data hierarchy.

The property parentKey should be bound to a context attribute of type STRING.

This attribute allows to relate a context elements to its parent context element by

assigning the value of the parent element's rowKey property to it.

Figure 88: Tree Tables: Defining UI and context

At runtime, the context has to contain at least the context elements that are related

to the first hierarchy level displayed by the Table UI element. Dependent context

elements may be pre-loaded. However, it is also possible to load dependent data

on request (when expanding a group). If a non-leaf context element is defined as

being collapsed (expanded = ABAP_FALSE), dependent context elements are

not displayed by the Table. For each hierarchy level, the order of the context





elements defines the sequence of the related table rows. In the following graphics

the setting of the context attributes is visualized for a one level hierarchy and for a

multiple level (here: two level) hierarchy.

Figure 89: Tree Table: One hierarchy level - defining the context





Figure 90: Tree Table: Multiple hierarchy level - defining the context

To allow loading dependent data on request, an action has to be assigned to the

property OnLoadChildren of the TreeByKeyTableColumn UI element.

Hint: The event LoadChildren is fired only, if the user expands a group

and the children of this group have not been loaded yet (value of context

attribute bound to UI element property ChildrenLoaded is initial). This

flag has to be set by the application.

In the action handler method, information about the related context element

can be extracted from the interface parameter WDEVENT . The internal table

WDEVENT → PARAMETERS contains the id of the master column (parameter

ID) and the reference to the context element (parameter CONTEXT_ELEMENT )

related to the table row the user has clicked on. Using the unique row key of this

context element, depended data sets can be read and stored in the context.





Exercise 4: Table UI Element - Set Table

Properties and define Row GroupsExercise Objectives


• Set properties of the Table UI element

• Define a table header

• Define row groups

Business Example

You would like to enhance the functionality and ergonomics of the table displayingthe flights. This includes the possibility to scroll vertically and horizontally across

the data and the reduction of redundant information displayed by the table. A table

header should explain what kind of data is displayed by the table.

Template Component: NET312_LAYO_S2

Solution Component: NET312_CMPX_S1

Task 1:





ZNET312_CMPX1_##. Assign this component to your package ZNET312_##.





Task 2:

Add a header to your table. The header should display the text Flights available for selected connection and the icon ICON_WS_PLANE .

1. Add a header to your table displaying text and icon.






Task 3:

Fix the columns related to the flight key on the left side of the table. Restrict the

number of scrollable columns to 4. Make sure that scrolling does not influence

the column widths. The carrier id and the connection number should only be

displayed once per group of flights belonging to the same connection. The

background of the data rows should alternate between two colors. Instead of the

standard elements used to scroll in the table scroll bars should be displayed to

allow vertical and horizontal scrolling.

1. Fix the columns related to the flight key on the left side of the table. Restrict

the number of scrollable columns to 4.

2. Make sure that scrolling does not influence the column widths.

3. The carrier id and the connection number should only be displayed once per

group of flights belonging to the same connection.

4. The background of the data rows should alternate between two colors.

5. Instead of standard elements used to scroll in the table, scroll bars should be

displayed to allow vertical and horizontal scrolling.

Task 4:

OPTIONAL:

The number of columns displayed by the table (fixed columns + scrollable

columns) and the number of table columns defined in the UI element hierarchy

is nearly identical. Horizontal scrolling is more interesting if the number of

table columns is increased. Thus, you could append additional attributes of the

Dictionary structure SFLIGHT to the context node FLIGHTS and display these

attribute values by additional TableColumn UI elements.

1. Create additional attributes in the context node FLIGHTS of the component

controller context. Add the attributes PAYMENTSUM , SEATSMAX_B,

SEATSOCC_B, SEATSMAX_F , and SEATSOCC_F .

2. Update the context of view MAIN_VIEW .

3. Display the content of the new context attributes by adding TableColumn UI

elements and related table cell editors to the Table UI element.

Hint: Deleting the existing table and using the wizard to create

a new table is not a good idea, since all changes of UI element

properties related to the table and its sub elements would then be

lost. In addition, all sub elements of the Table you have created

manually would also be lost.





Solution 4: Table UI Element - Set Table

Properties and define Row GroupsTask 1:









a) Display the template component in the object tree of transaction SE80.

Clicking on the component with the right mouse button will open the

component's context menu. Choose Copy.... Enter the name of the

component to be created. Press Continue.





Task 2:

Add a header to your table. The header should display the text Flights available

for selected connection and the icon ICON_WS_PLANE .

1. Add a header to your table displaying text and icon.

a) Edit the view MAIN_VIEW .

b) From the context menu of the Table UI element, choose Insert Header .

This will create a Caption UI element.

c) Assign the text Flights available for selected connection to the property

text of the Caption UI element.

Use the drop down box related to the property imageSource in order to

assign the SAP GUI Icon ICON_WS_PLANE (name displayed in icon

list: WS_PLANE ) to this property.






Task 3:

Fix the columns related to the flight key on the left side of the table. Restrict the

number of scrollable columns to 4. Make sure that scrolling does not influence

the column widths. The carrier id and the connection number should only be

displayed once per group of flights belonging to the same connection. The

background of the data rows should alternate between two colors. Instead of the

standard elements used to scroll in the table scroll bars should be displayed to

allow vertical and horizontal scrolling.

1. Fix the columns related to the flight key on the left side of the table. Restrict

the number of scrollable columns to 4.

a) The columns related to the flight key display the carrier id, the

connection number, and the flight date. For the corresponding

TableColumn UI elements set the property fixedPosition = left .

b) The number of scrollable columns is defined by the value of the Table

property scrollableColCount . Change the value from -1 (default) to 4.

2. Make sure that scrolling does not influence the column widths.

a) Set the Table property fixedTableLayout to ABAP_TRUE by marking

the related check box.

3. The carrier id and the connection number should only be displayed once per

group of flights belonging to the same connection.

a) For the TableColumn UI element related to the carrier id, bind the

property groupingValue to the context attribute FLIGHTS.CARRID.

b) For the TableColumn UI element related to the connection number, bind

the property groupingValue to the context attribute FLIGHTS.CONNID.

4. The background of the data rows should alternate between two colors.

a) Set the Table property design to alternating . In addition set the property

readOnly to ABAP_TRUE .

5. Instead of standard elements used to scroll in the table, scroll bars should be

displayed to allow vertical and horizontal scrolling.

a) Edit the parameters of your application (tab Parameters).

b) In the column Parameters enter the name WDTABLENAVIGATION , in

the column Value enter SCROLLBAR.






Task 4:

OPTIONAL:

The number of columns displayed by the table (fixed columns + scrollable

columns) and the number of table columns defined in the UI element hierarchy

is nearly identical. Horizontal scrolling is more interesting if the number of

table columns is increased. Thus, you could append additional attributes of the

Dictionary structure SFLIGHT to the context node FLIGHTS and display these

attribute values by additional TableColumn UI elements.

1. Create additional attributes in the context node FLIGHTS of the component

controller context. Add the attributes PAYMENTSUM , SEATSMAX_B,

SEATSOCC_B, SEATSMAX_F , and SEATSOCC_F .

a) Edit the context of the component controller.

b) From the context menu of the node FLIGHTS choose Create using

the Wizard → Attributes from Components of Structure. Mark all

components besides the component MANDT . Finish the dialog and

save the changes.

2. Update the context of view MAIN_VIEW .

a) Edit the context of the view MAIN_VIEW .

b) From the context menu of the mapped node FLIGHTS choose Update

Mapping . Choose Yes on the next dialog(s) to add the new attributes to

the mapped node.

3. Display the content of the new context attributes by adding TableColumn UI

elements and related table cell editors to the Table UI element.

Hint: Deleting the existing table and using the wizard to create

a new table is not a good idea, since all changes of UI element

properties related to the table and its sub elements would then be

lost. In addition, all sub elements of the Table you have created

manually would also be lost.

a) From the context menu of the Table UI element, choose Create Binding .

b) In the dialog box that pops up, select the context attributes PAYMENTSUM , SEATSMAX_B, SEATSOCC_B, SEATSMAX_F , and

SEATSOCC_F by marking the check boxes in the column Binding .

Finish the dialog.









Exercise 5: Table UI Element - Sorting and

FilteringExercise Objectives


• Implement sorting columns in Table UI elements

• Implement filtering the table content by entering filter options in input fields

or by selecting filter options from a drop down box

Business Example

You would like to enhance the functionality and ergonomics of the table displayingthe flights. The user should be able to sort the table content by clicking on the

header of table columns. In addition the application should offer the possibility to

filter the table content.

Template Component: NET312_CMPX_S1


Task 1:










Task 2:

Implement sorting the table content. Sorting should be allowed if the user clickson the header of the table columns displaying the flight date, informations about

occupied seats and capacity, and the total of current bookings

1. Assign a new action (name: SORT ) to the property onSort of the Table

UI element displaying the flights.

2. Get the reference to the method handler of this table and store this reference

as an attribute of the view controller.






3. Call the method APPLY_SORTING( ) of the method handler when the

event Sort is fired.

4. Do not allow to sort the table content by the carrier id, the connection

number, the price, the currency, or the plane type.

Task 3:

Implement the possibility to filter the table content by entering filter values for the

flight date and for the occupied seats in the economy class. For the flight date,

a drop down box should be offered, allowing to select all flights (possibility 1),

flights in the past (possibility 2), or flights in the future (possibility 3). For the

number of occupied seats an input field should allow to enter any restriction.

1. In the context of the view controller MAIN_VIEW add an untyped node of

cardinality (1:1) (name: FILTER), having two attributes of type STRING(name: DATE and SEATSOCC ).

2. Assign a new action (name: FILTER) to the property onFilter of the Table


3. For the columns displaying the flight date and the number of occupied seats

in the economy class: Bind the TableColumn property filterValue to the

corresponding attribute in the node FILTER. Set the width of the column

displaying the flight date to 100 pixels. This will be necessary, to display

the complete filter values by the drop down box.

4. Implement filtering: Call the method APPLY_FILTER( ) of the method

handler if the event Filter is fired.

5. Up to now, filter values for the flight date have to be entered into an input

field. To display a drop down box, a value set containing the allowed values

has to be assigned to the related context attribute. The drop down box should

display three values: All dates, <act. Date, and >=act. Date. Here, act. Date

is to be replaced by the actual date in the external format (e.g. <19.03.2008).

Create a new method (name: DEFINE_FILTER_VALUES( )) in the view

MAIN_VIEW encapsulating the source code to define the value set. Call this

method from the hook method WDDOINIT( ).





Solution 5: Table UI Element - Sorting and

FilteringTask 1:

















Task 2:

Implement sorting the table content. Sorting should be allowed if the user clicks

on the header of the table columns displaying the flight date, informations about

occupied seats and capacity, and the total of current bookings

1. Assign a new action (name: SORT ) to the property onSort of the Table



b) Click on the Table UI element used to display the flights. This will

display the table properties. Click on the button right of the propertyonSort to create and assign the action SORT .






2. Get the reference to the method handler of this table and store this reference

as an attribute of the view controller.

a) Edit the controller attributes of view MAIN_VIEW .

b) Declare a controller attribute (name: GO_TABLE_M_HNDL) being a

reference variable of type IF_WD_TABLE_METHOD_HNDL .

c) Now, edit the method WDDOMODIFYVIEW( ) of the view

MAIN_VIEW .

d) Call the method VIEW->GET_ELEMENT( ). Pass the id of the Table

UI element via the interface parameter ID. Cast the returning parameter

to a reference variable of type CL_WD_TABLE (name: LO_TABLE ).

Declare this reference variable locally.

e) Store the method handler (public attribute _METHOD_HANDLERof reference variable LO_TABLE ) in the controller attribute

GO_TABLE_M_HNDL. You need to cast the reference.

f) Make sure, that the reference to the method handler is determined

only once: Check the variable FIRST_TIME before you determine the

method handler reference.

g) Source code see below.

3. Call the method APPLY_SORTING( ) of the method handler when the

event Sort is fired.

a) Source code see below.4. Do not allow to sort the table content by the carrier id, the connection

number, the price, the currency, or the plane type.


b) Click on the icon left of the Table UI element to display the

TableColumn UI elements.

c) Set the property sortState to notSortable for the TableColumn UI

elements displaying carrier id, connection number, price, currency,

and plane type.






Task 3:

Implement the possibility to filter the table content by entering filter values for the

flight date and for the occupied seats in the economy class. For the flight date,

a drop down box should be offered, allowing to select all flights (possibility 1),

flights in the past (possibility 2), or flights in the future (possibility 3). For the

number of occupied seats an input field should allow to enter any restriction.

1. In the context of the view controller MAIN_VIEW add an untyped node of

cardinality (1:1) (name: FILTER), having two attributes of type STRING

(name: DATE and SEATSOCC ).


b) Click on the root node. From the context menu of this node choose

Create→ Node to create a new node. Enter the node's name in the

corresponding field and finish the dialog.

c) Click on the new node FILTER. From the context menu of this node

choose Create→ Attribute to create a new attribute. Enter the attribute's

name ( DATE ) and the type (STRING) in the corresponding fields and

finish the dialog.

d) Repeat the last step for the attribute SEATSOCC .

2. Assign a new action (name: FILTER) to the property onFilter of the Table



b) Click on the Table UI element used to display the flights. This will

display the table properties. Click on the button right of the property

onFilter to create and assign the action FILTER.

3. For the columns displaying the flight date and the number of occupied seats

in the economy class: Bind the TableColumn property filterValue to the

corresponding attribute in the node FILTER. Set the width of the column

displaying the flight date to 100 pixels. This will be necessary, to display

the complete filter values by the drop down box.

a) Edit the layout of the view MAIN_VIEW .

b) Mark the TableColumn displaying the flight date. This will display the properties of this column. Click on the button right of the property

filterValue to bind this property to the context attribute FILTER.DATE .

c) Repeat this procedure to bind the property filterValue of the column

displaying the number of occupied seats in the economy class to the

context attribute FILTER.SEATSOCC .

d) Finally, set the property width of the table column displaying the

flight date to 100.






4. Implement filtering: Call the method APPLY_FILTER( ) of the method

handler if the event Filter is fired.


5. Up to now, filter values for the flight date have to be entered into an input

field. To display a drop down box, a value set containing the allowed values

has to be assigned to the related context attribute. The drop down box should

display three values: All dates, <act. Date, and >=act. Date. Here, act. Date

is to be replaced by the actual date in the external format (e.g. <19.03.2008).

Create a new method (name: DEFINE_FILTER_VALUES( )) in the view

MAIN_VIEW encapsulating the source code to define the value set. Call this

method from the hook method WDDOINIT( ).

a) Edit the view MAIN_VIEW .

b) Navigate to the controller methods. Enter the name of the new method

( DEFINE_FILTER_VALUES ) in the column Method to create the

method. Double click on the method's name to edit the method.

c) Starting with WD_CONTEXT , determine the reference to the node

info of node FILTER. This will return a reference variable of type

IF_WD_CONTEXT_NODE_INFO.

d) Use the pattern function to call the method SET_AT-

TRIBUTE_VALUE_SET( ) for this reference. Set NAME = 'DATE'

and VALUE_SET = LT_VS . Create the internal table LT_VS and a

corresponding work area as local variables.e) Before calling the method SET_ATTRIBUTE_VALUE_SET( ), you

have to build up the value set table LT_VS . Use the CONCATENATE

statement to define the value (not visible) and the text (displayed by the

drop down box) for each table entry. You have to combine a logical

operator and the actual date in external format.

Hint: The date has to be defined in external format

since the filter algorithm automatically converts the filter

value according to the type of the filter column. Use the

WRITE....TO... statement to create the external format of the

actual date (SY-DATUM ).

f) Call the method DEFINE_FILTER_VALUES( ) from the hook method

WDDOINIT( ) of view MAIN_VIEW .

g) Source code see below.






Result

View Controller: WDDOMODIFYVIEW( )

METHOD wddomodifyview .

DATA lo_table TYPE REF TO cl_wd_table.

IF first_time = abap_true.

lo_table ?= view->get_element( id = 'TABLE' ).

wd_this->go_tabl e_m_hndl ?= lo_table->_met hod_handler.

ENDIF.

ENDMETHOD.

View Controller: ONACTIONSORT( )

METHOD onactionsort .

wd_this->go_tab le_m_hndl->apply _sorting( ).

ENDMETHOD.

View Controller: ONACTIONFILTER( )

METHOD onactionfilter .

wd_this->go_tab le_m_hndl->apply _filter( ).

ENDMETHOD.

View Controller: DEFINE_FILTER_VALUES( )

METHOD define_filter_values .

DATA lo_nd_root_info TYPE REF TO if_wd_context_node_info.

DATA lo_nd_filter_info TYPE REF TO if_wd_context_node_info.DATA ls_vs TYPE wdr_context_attr_value.

DATA lt_vs TYPE wdr_context_attr_value_list.

DATA lv_date_value TYPE c LENGTH 10.

lo_nd_root_info = wd_context->get_node_info( ).

lo_nd_filter_info = lo_nd_root_info->get_child_node( wd_this->wdctx_filter ).

* Convert actual date to external format






WRITE sy-datum TO lv_date_value.

* Build up drop down box entries

* Initial value to reset filter

ls_vs-text = 'All dates'.

INSERT ls_vs INTO TABLE lt_vs.

* Additional values

CONCATENATE '<' lv_date_value INTO ls_vs-value.

CONCATENATE '<' lv_date_value INTO ls_vs-text.


CONCATENATE '>=' lv_date_value INTO ls_vs-value.

CONCATENATE '>=' lv_date_value INTO ls_vs-text.


* Set value set -> Drop down box will be displayed

lo_nd_filter_info->set_attribute_value_set(

name = 'DATE'

value_set = lt_vs ).

ENDMETHOD.

View Controller: WDDOINIT( )

METHOD wddoinit .

* Define attribute value set related to filter for flight dates

wd_this->defin e_filter_values ( ).

ENDMETHOD.





Exercise 6: Table UI Element - Table

Popins and Cell ColorsExercise Objectives


• Implement table popins that depend on table rows

• Colorize table cells

Business Example

You would like to enhance the functionality and ergonomics of the table displaying

the flights. This includes the possibility to display a graphics for each data setdisplayed by the table using a table popin. In addition, the cells of a certain table

column should be colorized according to the cell content.



Task 1:










Task 2:

Create a table popin. This popin should be related to table rows. Expanding and

collapsing the table popin should be facilitated by clicking on an arrow-like iconat the beginning of the line. Collapsing the table popin should also be facilitated

by clicking on the cross icon displayed by the table popin.

Later on, the table popin will display a business graphic. However, in this exercise

the table popin only has to display a simple text.

1. Create a table popin that is related to a table row. The table popin should

display a simple text (e.g. to be implemented later...).






2. Create and assign a new action (name: CLOSE_POPIN ) to the event

onClose of the TablePopin UI element.

3. Create a new non-sortable table column being the leftmost column in the

table. Assign a text (Graph) and an icon (~Icon/VerticalBarChart ) to the

Caption of this TableColumn.

Define a cell variant of type TablePopinToggleCell being a sub element of

this new table column. Give the cell variant a key (name: POPIN )

4. Create and assign a new action (name: TOGGLE_POPIN ) to the event

onToggle of the TablePopinToggleCell UI element.

5. If you test your application in this state, you will find out that clicking on the

arrow-like icon will open / close a separate table popin for each table row.

In order to be able to open / close the table popin only for the selected row,a context attribute (name: POPIN_NAME ) has to be added to the node

containing the table data. In addition, the property selectedPopin of the

Table UI element has to be bound to this attribute.

6. Clicking the cross-like icon in the table popin still does not close the table

popin. This is because the action handler method related to the action

CLOSE_POPIN has not been implemented yet.

Implement the handler: The value of the attribute FLIGHTS.POPIN_NAME

has to be cleared for the corresponding context element. The reference to this

element is provided by the framework (parameter CONTEXT_ELEMENT

stored in parameter table WDEVENT →

PARAMETERS ).

Task 3:

Depending on the relative occupation, the cells of the table column displaying the

occupied seats in the economy class should have different background colors. If

the relative occupation is below 50%, the background color should be green,

between 50% and 95% the cell background should be orange, above 95% the

cell background should be red.

1. Add an attribute (name: COLOR) to the context node storing the flight data.

The type of this attribute has to be WDUI_TABLE_CELL_DESIGN .

2. Create the method DEFINE_COLORS( ) in the component controller. Editthe method. Get the data table from the context node FLIGHTS . Loop over

the data table, set the background color according to the relative occupation






of the seats in the economy class and store the color information in the

internal table (field COLOR). Finally, copy the modified internal table back

to the context node FLIGHTS .

Hint: Allowed color values are available as constants

in the global class CL_WD_TABLE_COLUMN (e.g.

CL_WD_TABLE_COLUMN=>E_CELL_DESIGN-

BADVALUE_MEDIUM ).

3. Call the method DEFINE_COLORS( ) each time the user selects a new

connection.

4. Update the mapping of node FLIGHTS in view MAIN_VIEW

5. In order to set the background color of the table cells, the property cellDesignof the TableColumn UI element displaying the occupied seats in the economy

class has to be bound to the context attribute FLIGHTS.COLOR.





Solution 6: Table UI Element - Table

Popins and Cell ColorsTask 1:

















Task 2:

Create a table popin. This popin should be related to table rows. Expanding and

collapsing the table popin should be facilitated by clicking on an arrow-like icon

at the beginning of the line. Collapsing the table popin should also be facilitated

by clicking on the cross icon displayed by the table popin.

Later on, the table popin will display a business graphic. However, in this exercise

the table popin only has to display a simple text.

1. Create a table popin that is related to a table row. The table popin should

display a simple text (e.g. to be implemented later...).

a) Edit the layout of the view MAIN_VIEW .

b) From the context menu of the Table UI element, choose Insert Table

Popin to create a row popin.

c) From the context menu of the TablePopin UI element, choose Insert

Content to create the popin content. Create a TextView UI element.

Assign any text to the TextView UI element by setting the property

text accordingly.






2. Create and assign a new action (name: CLOSE_POPIN ) to the event

onClose of the TablePopin UI element.

a) Use the button right of the event onClose to create and assign the action

to the TablePopin UI element.

3. Create a new non-sortable table column being the leftmost column in the

table. Assign a text (Graph) and an icon (~Icon/VerticalBarChart ) to the

Caption of this TableColumn.

Define a cell variant of type TablePopinToggleCell being a sub element of

this new table column. Give the cell variant a key (name: POPIN )

a) From the context menu of the Table UI element, choose Insert Table

Column to create a new column. Make this column the leftmost

column of the Table by move it to the top of the table's sub element

list (drag & drop).

b) Correct the properties of the new TableColumn UI element: Set

fixedPosition = left and sortState = notSortable

c) Assign the literal Graph to the property text of the Caption UI element.

d) Use the value help assigned to the Caption property imageSource to

assign an icon to the column header. Click on the tab Icon and select

the icon VerticalBarChart from the list.

e) From the context menu of the new TableColumn, choose Insert Cell

Variant to create a cell variant. In the following dialog, choose

TablePopinToggleCell as the variant type and any id.

f) Assign the literal POPIN to the property variantKey of the cell variant.

g) Correct the properties of the new TableColumn UI element: In order

to display the table popin, the literal POPIN has to be assigned to the

property selectedCellVariant .

4. Create and assign a new action (name: TOGGLE_POPIN ) to the event

onToggle of the TablePopinToggleCell UI element.

a) Use the button right of the event onToggle to create and assign the

action to the TablePopinToggleCell UI element.

5. If you test your application in this state, you will find out that clicking on thearrow-like icon will open / close a separate table popin for each table row.






In order to be able to open / close the table popin only for the selected row,

a context attribute (name: POPIN_NAME ) has to be added to the node

containing the table data. In addition, the property selectedPopin of theTable UI element has to be bound to this attribute.

a) Edit the component controller context.

b) Mark the data node FLIGHTS and delete the node type. This is

necessary to add arbitrary attributes to the node.

c) Add a new attribute (name: POPIN_NAME , type: STRING) to the

node FLIGHTS .

d) Now edit the context of the view MAIN_VIEW . Update the context

mapping for node FLIGHTS (context menu entry Update Mapping ).

e) Edit the layout of view MAIN_VIEW . Mark the Table UI element.Click on the button right of the Table property selectedPopin to bind

this property to the context attribute FLIGHTS.POPIN_NAME .

6. Clicking the cross-like icon in the table popin still does not close the table

popin. This is because the action handler method related to the action

CLOSE_POPIN has not been implemented yet.

Implement the handler: The value of the attribute FLIGHTS.POPIN_NAME

has to be cleared for the corresponding context element. The reference to this

element is provided by the framework (parameter CONTEXT_ELEMENT

stored in parameter table WDEVENT → PARAMETERS ).

a) Edit the method ONACTIONCLOSE_POPIN( ) defined in view MAIN_VIEW .

b) Add the import parameter CONTEXT_ELEMENT (TYPE REF TO

IF_WD_CONTEXT_ELEMENT ) to the signature of this method. Enter

the parameter's name in field Parameter , check the RefTo check box

and enter the interface name in field Associated Type.

c) Use the pattern functionality to create the method call for setting the

attribute POPIN_NAME of element CONTEXT_ELEMENT to space.

d) Source code see below.






Task 3:

Depending on the relative occupation, the cells of the table column displaying the

occupied seats in the economy class should have different background colors. If

the relative occupation is below 50%, the background color should be green,

between 50% and 95% the cell background should be orange, above 95% the

cell background should be red.

1. Add an attribute (name: COLOR) to the context node storing the flight data.

The type of this attribute has to be WDUI_TABLE_CELL_DESIGN .


b) Mark the data node FLIGHTS . Add a new attribute (name: COLOR,

type: WDUI_TABLE_CELL_DESIGN ) to the node FLIGHTS by

selecting the context menu entry Create→ Attribute of this node.

2. Create the method DEFINE_COLORS( ) in the component controller. Edit

the method. Get the data table from the context node FLIGHTS . Loop over

the data table, set the background color according to the relative occupation

of the seats in the economy class and store the color information in the

internal table (field COLOR). Finally, copy the modified internal table back

to the context node FLIGHTS .

Hint: Allowed color values are available as constants

in the global class CL_WD_TABLE_COLUMN (e.g.

CL_WD_TABLE_COLUMN=>E_CELL_DESIGN-

BADVALUE_MEDIUM ).


3. Call the method DEFINE_COLORS( ) each time the user selects a new

connection.

a) If the user clicks on a connection, the action handler method

ONACTIONGET_DETAILS( ) is triggered in view MAIN_VIEW . Add

the call of the component controller method DEFINE_COLORS( ) here.

b) Source code see below.

4. Update the mapping of node FLIGHTS in view MAIN_VIEW

a) Edit the context of the view MAIN_VIEW . Update the context mapping

for node FLIGHTS (context menu entry Update Mapping ).

5. In order to set the background color of the table cells, the property cellDesign

of the TableColumn UI element displaying the occupied seats in the economy

class has to be bound to the context attribute FLIGHTS.COLOR.







b) Click on the TableColumn UI element displaying the occupied seats in

the economy class.

c) Use the button right of the property cellDesign to bind this property to

the context attribute FLIGHTS.COLOR.

Result

View Controller: ONACTIONCLOSE_POPIN( )

METHOD onactionclose_popin .

context_element->set_attribute(

value = space

name = 'POPIN_NAME' ).

ENDMETHOD.

Comp. Controller: DEFINE_COLORS( )

METHOD define_colors .

DATA lo_nd_flights TYPE REF TO if_wd_context_node.

DATA lt_flights TYPE wd_this->elements_flights.

D AT A l s_ fli ght s TY PE w d_ thi s-> el eme nt _fl igh ts .

DATA lv_ratio TYPE i.


lo_nd_flights->get_static_attributes_table( IMPORTING table = lt_flights ).

LOOP AT lt_flights INTO ls_flights.

lv_ratio = 100 * ls_flights-seatsocc / ls_flights-seatsmax.

IF lv_ratio > 95.

ls_flights-color =

cl_wd_table_column=>e_cell_design-badvalue_medium.

ELSEIF lv_ratio > 50.

ls_flights-color =

cl_wd_table_column=>e_cell_design-criticalvalue_medium.

ELSE.

ls_flights-color =

cl_wd_table_column=>e_cell_design-goodvalue_medium.

ENDIF.

MODIFY lt_flights FROM ls_flights.

ENDLOOP.







ENDMETHOD.

View Controller: ONACTIONGET_DETAILS( )

METHOD onactionget_details .





IMPORTING







* Set background colors

lo_componentcontroller->define_colors( ).

ENDMETHOD.





Lesson Summary

You should now be able to:• Implement grouping of table column and table rows











NET312 Lesson: The Tree UI Element

Lesson: The Tree UI Element

Lesson Overview

This lesson deals with the definition of a Tree UI element. This includes the

definition of tree nodes and tree items in the view's layout, the definition of the

controller context, and the definition of methods to fill the context. Here, all kinds

of trees are discussed. These may consist of multiple node types and element

types per hierarchy level. In addition, the number of hierarchy levels may be

undefined at design time.

Lesson Objectives

After completing this lesson, you will be able to:• Create static trees


Business Example

You would like to present the hierarchically defined content of the view's context

by a tree like structure. The user should be able to expand / collapse the tree's

nodes and he should be able to select a tree item. When selecting a tree item, data

related to this tree item should be displayed by the application.

Tree Basics

Hierarchies defined in the context can be visualized using the Tree UI element.

The Tree UI element can be bound to any context node. Sub nodes of this context

node can be visualized as nodes in the tree using the UI element TreeNodeType.

Node elements defined in the context can be visualized as leafs in the tree using

the UI element TreeItemType. The sub elements of any tree node can be collected

at runtime or they can be pre-loaded when initializing the view's context.

Tree nodes and tree items that are related to context element at lead selection are

displayed highlighted.





Figure 91: Tree: Simple Tree

Figure 92: Tree: Additional functionality (1)





Figure 93: Tree: Additional functionality (2)


The context structure related to a tree consists of a parent context node and an

arbitrary number of sub nodes containing an arbitrary number of context elements.

Each sub node may have own sub nodes, so the depth of the context hierarchyis not limited. Each of the sub nodes may be defined as a normal node or as a

recursion node (repeating a node structure defined at a higher hierarchy level).


First, the Tree UI element is created in the UI element hierarchy. The property

dataSource allows to bind the Tree to any context node. The Tree may then display

the content of this context node and all of its child nodes.

The complete tree will be displayed in a rectangular box. A title can be displayed

on top of the box by setting the property titleVisible to ABAP_TRUE and by

assigning the text to be displayed to the property title.

A root node is only displayed, if the property rootVisible is set to ABAP_TRUE .

In this case an extra top node allows to hide / display the tree's content. The

text displayed right of the toggle icon related to this root node is defined by the

property rootText .

defaultItemIconSource may be set to define the default icon displayed left of all

tree leafs. defaultNodeIconSource may be set to define the default icon displayed

left of all tree nodes (but the root node). In both cases, a value help button allows

to select the Icon statically. Binding these properties to context attributes of type

STRING allows to define the icons programmatically





If enabled is set to ABAP_FALSE , all tree nodes are grayed out and the actual

state can not be changed by the user.

The width of the tree and the minimum width is determined of the values of the

properties width and minHeight , respectively.

Figure 94: Tree: Defining the UI and data binding (1)

Aggregations: TreeNodeType and TreeItemType

After having created the Tree UI element, sub elements of type TreeNodeType and

TreeItemType have to be created in order to display the content of the context node

that has been assigned to the Tree property dataSource.

In the most simple case, the data source does not contain sub nodes, but only

a number of context elements to be displayed as tree leafs. Then, a single UI

element of type TreeItemType (defined as a direct sub element of the Tree UI

element) is sufficient to display as many tree leafs as there are context elements.The text to be displayed by the single tree leafs (property text ) has to be related to

any attribute of the data source node.

The TreeItemType UI element contains additional interesting properties. The

property design allows to emphasize the texts displayed with the tree items. If this

property is bound to a context attribute of type WDUI_TREE_NODE_DESIGN ,

then the design can be set differently for each tree item. iconSource allows

to define an icon displayed left of each tree item. This overwrites the icon

defined by the property defaultItemIconSource of the Tree UI element. Finally,





if ignoreAction is set to ABAP_TRUE , then the action assigned to the property

onAction is not triggered. The hook methods WDDOBEFOREACTION( ) and

WDDOAFTERACTION( ) are also not processed by the Web Dynpro framework.However, clicking on a tree leaf's text will still result in a round trip.

Hint: Clicking on the text / icon related to a tree item will set the lead

selection in the related node collection.

Figure 95: Tree: Displaying leafs

Lets consider the a slightly more complicated situation. On the first hierarchy

level, the UI tree should not only display tree items, but also tree nodes that can be

opened and closed. Each tree node should display related tree items.

Now, two nodes being sub nodes of the tree root node have to be created in the

context. The first sub node (N1) has to contain all context elements that should bevisualized as tree leafs on the first hierarchy level of the UI tree. The second sub

node (N2) has to contain all context elements, that should be visualized as tree

nodes on the first hierarchy level of the UI tree. The tree leafs related to the nodes

of the UI tree have to be stored in a non-singleton context node (N2_1), being

defined as a sub node of context node N2.

In the view's layout, a view element of type Tree has to be created. The property

dataSource has to be bound to the tree root node in the view's context.





Figure 96: Tree: Displaying nodes and leafs on multiple hierarchy levels

To display the directly related tree leafs, a UI element of type TreeItemType has to

be created as a direct sub element of the Tree. The dataSource property has to be

bound to the first sub node in the context (N1). Any attribute of this node may bedisplayed as the text of the tree leafs (property text ).





Figure 97: Tree: Displaying nodes and leafs - leafs on first hierarchy level

To display the tree nodes, a UI element of type TreeNodeType has to be defined as

a direct sub element of the Tree UI element. The property dataSource has to be

bound to the second sub node in the view's context (N2). The text to be displayedwith the tree node (property text ) can be bound to any attribute of the node N2.

The tree leafs of these tree nodes are defined alike the tree leafs on the first level

hierarchy. This means another UI element of type TreeItemType has to be defined

as a direct sub element of the Tree UI element. Now, the property dataSource has

to be bound to the node N2_1.





Figure 98: Tree: Displaying nodes and leafs - nodes on first hierarchy level

The TreeNodeType UI element contains additional interesting properties. Binding

the property expanded to a context attribute of type WDY_BOOLEAN , allows to

define programmatically, which tree nodes are closed and which tree nodes areopen. If hasChildren is set to ABAP_FALSE , tree nodes are displayed as tree leafs.

The icon used to open / close the node will not be displayed. iconSource allows

to define an icon displayed left of each tree node. This overwrites the icon name

defined by the property defaultNodeIconSource of the Tree UI element. Finally,

if ignoreAction is set to ABAP_TRUE , then the action assigned to the property

onAction is not triggered (when clicking on the node's text). The hook methods

WDDOBEFOREACTION( ) and WDDOAFTERACTION( ) are also not processed

by the Web Dynpro framework. However, clicking on a tree node's text will still

result in a round trip.

Hint: Clicking on the text / icon related to a tree node will set the lead

selection in the related node collection.

The concept described above can easily be extended to multiple hierarchy levels

with one or more node types per hierarchy level. For each context node having no

sub nodes, one UI element of type TreeItemType has to be created to display the

context elements as leafs in the UI tree. For each context node having sub nodes, a

UI element of type TreeNodeType has to be defined in order to allow displaying

and hiding the context elements of these nodes.





Figure 99: Tree: Displaying nodes and leafs - two or more hierarchy levels

Hint: The hierarchy of the nodes as defined in the view context is not

mapped to the UI element hierarchy. All TreeItemType UI elements andall TreeNodeType UI elements are defined as direct sub elements of the

Tree UI element. The data binding of the property dataSource defines the

dependencies between nodes and leafs in the rendered tree.

Events

The Tree UI elements allows to bind an action to the property onExpand .

In this case, an additional icon appears in the upper right corner of the box

displayed with the tree. Clicking on this icon will fire the event Expand . In the

corresponding action handler method, the id of the tree, the user has clicked on

can be determined from the parameter ID that is provided by the internal table

WDEVENT → PARAMETERS . The application has to care for the expansion of the tree nodes.

Hint: To allow expanding and collapsing a tree node dynamically, the

property expanded of this TreeNodeType UI element has to be bound to a

context attribute of type WDY_BOOLEAN that is defined in the related

context node.





The TreeItemType UI element contains the property onAction (related event:

Action). If an action is assigned to this property and the user clicks on a related

tree leaf (text or icon), not only a server round trip is provoked, but the hook methods WDDOBERFOREACTION( ), WDDOAFTERACTION( ), and the

corresponding action handler method are processed. From the internal table

WDEVENT → PARAMETERS the following information can be extracted: The id

of the node, the tree item is related to, can be extracted from the parameter ID.

The path to the context element that is related to the tree item is obtained from the

parameter PATH . Finally, the reference to the context element that is related to the

selected tree item is provided by the parameter CONTEXT_ELEMENT .

The TreeNodeType UI element contains two properties, actions can be assigned to:

OnAction is triggered if the user clicks on the text or on the icon displayed with

a tree node. Technically, this property equals the TreeItem property onAction

discussed above.

The event LoadChildren (property OnLoadChildren) is triggered, if the user

opens a node. It is not triggered, if the user closes a node! If an action is

assigned to this property, not only a server round trip is provoked, but the hook

methods WDDOBERFOREACTION( ), WDDOAFTERACTION( ), and the

corresponding action handler method are processed. From the internal table

WDEVENT → PARAMETERS the following information can be extracted: The id

of the context node, the tree node is related to, can be extracted from the parameter

ID. The path to the context element that is related to the tree node is obtained from

the parameter PATH . Finally, the reference to the context element that is related to

the tree node is provided by the parameter CONTEXT_ELEMENT .

Hint: If an action is assigned to the property onLoadChildren, the

algorithm for collecting dependent data and storing them in the context

may be defined in the corresponding action handler method. This is of

special interest for trees with an dynamically defined hierarchy based on

recursion context nodes (see next sub section).





Figure 100: Tree: Using event LoadChildren to read tree content on request

(1)





Figure 101: Tree: Using event LoadChildren to read tree content on request

(2)

Tree Structure containing recursively repeated

combinations of Nodes and LeafsThe tree structure can consists of a recursively repeated combination of nodes and

leafs with an unknown number of hierarchy levels (e.g. the file system of a PC

operating system). In this case, the view context has to be defined in a way, that an

unknown number of hierarchy levels can be created at runtime. This is realized in

two steps. In step one, the combination of context nodes to be repeated is defined.

This combination consists of an arbitrary number of nodes on different hierarchy

levels. In step two, a sub node of type Recursion Node has to be defined on any

level of the context structure defined in step 1. This recursion node may repeat

any statically defined node and all of its child nodes (defined in step 1). The name

of the context node to be repeated (parent node) has to be assigned to the property

Repeated Node of the recursion node.

At runtime, the statically defined context structure related to the parent node is

cloned if the recursion node is accessed the first time programmatically (e.g.

method GET_CHILD_NODE( NAME = '<RECURSION_NODE>' )). The cloned

structure contains the recursion node, too. Thus cloning the context structure can

be repeated as often as desired.





Figure 102: Tree: Recursion nodes

The UI element hierarchy is defined as follows: A Tree UI element has to be

created in the view's layout. Next, for each context node containing child nodes, a

TreeNodeType UI element has to be created as a direct sub element of the Tree.Then, for all context nodes not containing child nodes, a TreeItemType UI element

has to be created as a direct sub element of the Tree. Each of these TreeNodeType

and TreeItemType UI elements can not only display the content of the statically

defined context node bound to it, but also the content of the cloned context nodes

having the same name.





Figure 103: Tree: Recursion nodes - creating UI element hierarchy and

defining data binding

Figure 104: Tree: Recursion nodes - relation between layout and context

structure at runtime





Cloning the parent context node structure has to be triggered if the user opens a tree

node that is bound to a context node being a parent of the recursion node and this

recursion node has not been accessed yet. Thus, an action has to be assigned to the property onLoadChildren of this tree node. The algorithm to access to recursion

node, to read data related to the selected node and to store these data in the cloned

context structure can then be defined in the corresponding action handler method.









Exercise 7: Displaying hierarchical

Content with a Tree UI ElementExercise Objectives


• Implement a Tree UI element

Business Example

You would like to enhance the functionality and ergonomics of your application.

Now you would like to replace the NavigationList by a Tree UI element. This

allows to hide / display the connections for each flight carrier on request.



Task 1:






Create an application having the same name as your component and assign theapplication to your package, too.



Task 2:

In order to display carriers and connections as nodes and items of a Tree UI

element, the context structure and the algorithm to fill the context structure needs

to be adjusted. A first level hierarchy node has to store the names of the carriers

and the information which of the context nodes are expanded / collapsed. A relatedsecond level hierarchy node has to store the texts displayed for the connections

and the key field values for the connection.

1. Create a new node (name: NODES ) in the component controller context

containing the attributes TEXT (type: STRING) and EXPANDED (type:

WDY_BOOLEAN ). This node will store the carriers. Make sure that the lead

selection index will not be initialized automatically.






2. Create a new non-singleton node (name: ITEMS ) as a sub node of node

NODES in the component controller context. This new node has to contain

the attributes TEXT (type: STRING), CARRID (type: S_CARR_ID, andCONNID (type: S_CONN_ID). Make sure that the lead selection index

will not be initialized automatically.

3. Now the algorithm used to fill the context node needs to be adapted. Copy

the component controller method DEFINE_NAV_LIST( ). Name the new

method DEFINE_TREE( ).

Rewrite the source code of this method: At runtime, for each carrier a tree

node has to be displayed. Expanding the tree node related to a carrier should

display the related connections as tree items. The texts displayed in the tree

should be identical to the texts displayed in the navigation list.

All nodes but the nodes related to American Airlines (CARRID = AA) and Lufthansa (CARRID = LH ) should be collapsed when the view is displayed

the first time.

4. Replace the call of method DEFINE_NAV_LIST( ) in the component

controller hook method WDDOINIT( ) by the call of method

DEFINE_TREE( ).

5. OPTIONAL: Delete the context node NAVI_LIST and the controller

method DEFINE_NAV_LIST( ).

Task 3:

Replace the navigation list in the view MAIN_VIEW by a tree displaying the

content of node NODES .

1. Copy the node NODES from the component controller context to the context

of view MAIN_VIEW and define the mapping between the nodes (mapping

origin in component controller context).

2. Delete the NavigationList UI element in the layout of view MAIN_VIEW .

3. Create a Tree UI element being positioned left of the TabStrip UI element.

The Tree should cover 30% of the complete browser page width and the

minimum height should be 450 pixels. The root node should not be visible

but a title should be displayed ( Flight Connections). By default, the icon

ICON_FLIGHT should be displayed with each flight connection.

The Tree has to display the content of node NODES .

4. In order to display the tree nodes, create a TreeNodeType UI element as

a sub element of the Tree UI element. For each context element of node

NODES , this UI element should display a tree node. The value of the

attribute NODES.TEXT should be displayed as the tree node's text. If the






context attribute NODES.EXPANDED of a given context element is set to

abap_true, the related tree node should be expanded when displaying the

view MAIN_VIEW the first time.

5. In order to display the tree items, create a TreeItemType UI element as a

sub element of the Tree UI element. For each context element of node

ITEMS , this UI element should display a tree item. The value of the attribute

NODES.ITEMS.TEXT should be displayed as the tree item's text. Clicking

on a tree item should result in displaying the related flights by the Table

UI element.





Solution 7: Displaying hierarchical

Content with a Tree UI ElementTask 1:






















Task 2:

In order to display carriers and connections as nodes and items of a Tree UI

element, the context structure and the algorithm to fill the context structure needs

to be adjusted. A first level hierarchy node has to store the names of the carriers

and the information which of the context nodes are expanded / collapsed. A related

second level hierarchy node has to store the texts displayed for the connections

and the key field values for the connection.

1. Create a new node (name: NODES ) in the component controller context

containing the attributes TEXT (type: STRING) and EXPANDED (type:

WDY_BOOLEAN ). This node will store the carriers. Make sure that the lead

selection index will not be initialized automatically.


b) Mark the root node. From the context menu of this node, choose

Create→ Node to define a new untyped context node (name: NODES ).

c) Perform the following changes in respect to the properties of this

new node: Set Cardinality to 0:n. Clear the check box related to the

property Initialization Lead Selection.

d) Mark the context node NODES . From the context menu of this node,

choose Create→ Attribute in order to define the attribute TEXT . Set

Type = STRING and finish the dialog.

e) Repeat the last step to create the attribute EXPANDED (type:

WDY_BOOLEAN ).2. Create a new non-singleton node (name: ITEMS ) as a sub node of node

NODES in the component controller context. This new node has to contain

the attributes TEXT (type: STRING), CARRID (type: S_CARR_ID, and

CONNID (type: S_CONN_ID). Make sure that the lead selection index

will not be initialized automatically.


b) Mark the node NODES . Add a new untyped sub node (name: ITEMS ).

c) Mark the node ITEMS . Perform the following changes in respect to the

node's properties: Set Cardinality to 0:n. Clear the check box related to

the property Initialization Lead Selection. Make sure that the check box related to the property Singleton is not checked.

d) Add the attributes TEXT (type: STRING), CARRID (type: S_CARR_ID,

and CONNID (type: S_CONN_ID).

3. Now the algorithm used to fill the context node needs to be adapted. Copy

the component controller method DEFINE_NAV_LIST( ). Name the new

method DEFINE_TREE( ).






Rewrite the source code of this method: At runtime, for each carrier a tree

node has to be displayed. Expanding the tree node related to a carrier should

display the related connections as tree items. The texts displayed in the treeshould be identical to the texts displayed in the navigation list.

All nodes but the nodes related to American Airlines (CARRID = AA) and

Lufthansa (CARRID = LH ) should be collapsed when the view is displayed

the first time.

a) To copy a controller method, navigate on the tab Methods, set the

cursor on the method's name and press the icon displaying two leaves

and having the quick info Copy. Then press the icon right of this icon

having the quick info Paste. In the following dialog enter the name of

the new method and finish the dialog.

b) Double click on the method's name to edit the source code of method DEFINE_TREE( ).

c) The algorithm consists of the following logical steps:

• Get all connections by calling the controller component method

GET_CONNECTIONS( ).

• Sort the internal table returned by this method by CARRID and

CONNID.

• Loop over the sorted internal table.

• For each connection check whether the carrier id has changed.

• If this is true, create a new context element in node NODES .Assign the carrier id to the attribute TEXT . For CARRID = AA or

CARRID = LH set EXPANDED = ABAP_TRUE , for all other

carriers set EXPANDED = ABAP_FALSE .

Hint: Use method BIND_STRUCTURE( ) defined in

interface IF_WD_CONTEXT_NODE to create a new

context element in the node NODES . This method will

return the reference to the new context element.

• Get the reference to the node collection ITEMS related to this

carrier id.

Hint: To access the node collection ITEMS corresponding

to a certain carrier id, start with the context element

related to this carrier and access to dependent collection

by calling the method GET_CHILD_NODE( )






• For each connection create a context element in node collection

ITEMS related to the carrier id. Set the attributes CARRID,

CONNID according to the connection data and concatenateconnection number, departure city and destination to define the

value of attribute TEXT .


4. Replace the call of method DEFINE_NAV_LIST( ) in the component

controller hook method WDDOINIT( ) by the call of method

DEFINE_TREE( ).


5. OPTIONAL: Delete the context node NAVI_LIST and the controller

method DEFINE_NAV_LIST( ).

a) Node and method are not needed any more.

Task 3:

Replace the navigation list in the view MAIN_VIEW by a tree displaying the

content of node NODES .

1. Copy the node NODES from the component controller context to the context

of view MAIN_VIEW and define the mapping between the nodes (mapping

origin in component controller context).


b) Drag the node NODES from the component controller context and drop

it to the root node of the view controller context. This will copy the

node structure and define the mapping in one step.

2. Delete the NavigationList UI element in the layout of view MAIN_VIEW .

a) Hope you know how to do this ...

3. Create a Tree UI element being positioned left of the TabStrip UI element.

The Tree should cover 30% of the complete browser page width and the

minimum height should be 450 pixels. The root node should not be visible

but a title should be displayed ( Flight Connections). By default, the icon

ICON_FLIGHT should be displayed with each flight connection.






The Tree has to display the content of node NODES .


b) From the context menu of the ROOTUIELEMENTCONTAINER,

choose Insert Element and create a Tree UI element.

c) Move the Tree UI element between the PageHeader and the TabStrip

(drag & drop).

d) Adjust the Tree UI element properties as follows:

layoutDate = MatrixHeadData, defaultItemIconSource =

ICON_FLIGHT , minHeight = 450, rootVisible = ABAP_FALSE , width

= 100%, vAlign = Top, and width ( MatrixHeadData) = 30%.

e) Assign the literal Flight Connection to the property title.

f) Click the button right of property dataSource to bind this property to

the context node NODES .

4. In order to display the tree nodes, create a TreeNodeType UI element as

a sub element of the Tree UI element. For each context element of node

NODES , this UI element should display a tree node. The value of the

attribute NODES.TEXT should be displayed as the tree node's text. If the

context attribute NODES.EXPANDED of a given context element is set to

abap_true, the related tree node should be expanded when displaying the

view MAIN_VIEW the first time.

a) From the context menu of the Tree UI element, choose Insert NodeType. In the following dialog select Type = TreeNodeType.

b) Click on the button right of property dataSource in order to bind this

property to the context node NODES .

c) Click on the button right of property text in order to bind this property

to the context attribute NODES.TEXT .

d) Click on the button right of property expanded in order to bind this

property to the context attribute NODES.EXPANDED.

5. In order to display the tree items, create a TreeItemType UI element as a

sub element of the Tree UI element. For each context element of node

ITEMS , this UI element should display a tree item. The value of the attribute NODES.ITEMS.TEXT should be displayed as the tree item's text. Clicking

on a tree item should result in displaying the related flights by the Table

UI element.

a) From the context menu of the Tree UI element, choose Insert Node

Type. In the following dialog select Type = TreeItemType.

b) Click on the button right of property dataSource in order to bind this

property to the context node NODES.ITEMS .






c) Click on the button right of property text in order to bind this property

to the context attribute NODES.ITEMS.TEXT .

d) Assign the action GET_DETAILS to the property onAction of the

TreeItemType UI element. Use the drop down box to select and assign

this (already existing) action.

e) Adopt the source code of this method since the key of the selected tree

leaf is now extracted from a context element of node ITEMS .


Result

Comp. Controller: DEFINE_TREE( )

METHOD define_tree .

DATA lt_connections TYPE net310_t_spfli.

DATA ls_connection TYPE spfli.

DATA lv_carrid_old TYPE s_carr_id.

DATA lo_nd_nodes TYPE REF TO if_wd_context_node.

DATA lo_el_nodes TYPE REF TO if_wd_context_element.

DATA ls_nodes TYPE wd_this->element_nodes.

DATA lo_nd_items TYPE REF TO if_wd_context_node.

DATA ls_items TYPE wd_this->element_items.

* Get internal table containing all flight connections

lt_connections = wd_this->get_connections( ).

SORT lt_connections BY carrid connid.

* Get reference to node to store carriers

lo_nd_nodes = wd_context->get_child_node( name = wd_this->wdctx_nodes ).

* Build up tree

LOOP AT lt_connections INTO ls_connection.

*** If connections for a new carrier are processed ***********************

IF ls_connection-carrid <> lv_carrid_old.

lv_carrid_old = ls_connection-carrid.

* Define content of new context element

ls_nodes-text = ls_connection-carrid.

IF ls_connection-carrid = 'AA' OR ls_connection-carrid = 'LH'.

ls_nodes-expanded = abap_true.

ELSE.

ls_nodes-expanded = abap_false.






ENDIF.

* Create new context element, keep reference to context element

lo_el_nodes = lo_nd_nodes->bind_structure(

new_item = ls_nodes


* Create dependent element collection to store connections

lo_nd_items = lo_el_nodes->get_child_node(

name = wd_this->wdctx_items ).

ENDIF.

**************************************************************************

*** For all elements: Define content of new context element **************

CONCATENATE ls_connection-connid

ls_connection-cityfrom

'>'

ls_connection-cityto

INTO ls_items-text

SEPARATED BY space.

ls_items-carrid = ls_connection-carrid.

ls_items-connid = ls_connection-connid.

* Create new context element

lo_nd_items->bind_structure(

new_item = ls_items


**************************************************************************

ENDLOOP.

ENDMETHOD.

Comp. Controller: WDDOINIT( )

METHOD wddoinit .

wd_this->defin e_tree( ).

ENDMETHOD.




DATA ls_items TYPE wd_this->element_items .






* Get key information for selected tree element


IMPORTING

static_attributes = ls_items ).




iv_carrid = ls_items-carrid

iv_connid = ls_items-connid ).

* Set background colors


ENDMETHOD.





Lesson Summary

You should now be able to:• Create static trees





NET312 Lesson: Additional complex UI Elements

Lesson: Additional complex UI Elements

Lesson Overview

In this lessons, interesting complex UI elements other then TableView and Tree

are discussed in detail. Theses are the DateNavigator , the PhaseIndicator , and

the RoadMap.

Lesson Objectives


• Implement the DateNavigator UI element

• Implement the PhaseIndicator UI element


Business Example

You have to enrich your Web Dynpro application by adding the elements

DateNavigator , PhaseIndicator , and RoadMap to the UI element hierarchy of a

view being part of your application. However, there are so many properties and

aggregations ...

The DateNavigator UI Element

The DateNavigator UI element enables users to display and select dates. Itsfeatures include the ability to navigate in a calendar and choose a day, month,

year, or range of dates.

The DateNavigator allows to choose, how many months are displayed in parallel.

Any day can be chosen to be the first day of the week. The user can click on a

day, on a week, or on a month in order to select dates or date ranges. He can also

navigate to months that are actually not displayed.

Single days or day ranges can be colorized. Finally, a legend can be added

containing explanations for the days and day ranges that have been colorized.





Figure 105: DateNavigator


Creating a context structure is not obligatory to define a DateNavigator UI

element. However, if certain dates or date ranges are to be colorized, or if anadditional legend is to be displayed, corresponding context structures need to be

defined.

To store information about the colorized days, a context node has to be created

containing three context attributes. At runtime, each context element defined

in this node will describe one colorized day. The first attribute being of type

WDUI_DATE_MARKING_CATEGORY allows to assign each day to one of four

possible categories. The second attribute (type WDUI_TABLE_CELL_DESIGN )

can be used to change the category color. The third attribute contains the date

and should thus be of type D.

To store the legend information, an additional context node needs to be defined.

At runtime, each context element defined in this node will describe one legendentry. The context node should contain two attributes. The first one being of

type WDUI_DATE_MARKING_CATEGORY is used to assign the legend text to

one of four possible categories. The legend text is stored in a second attribute

of type STRING.

Context elements related to the DateNavigator functionality will be discussed in

the next section.






The DateNavigator UI element can be defined as a sub element of any container

UI element. The following UI element properties are of interest:

To avoid that a round trip to the server is triggered if the user clicks on a day, a

week, or a month, the property enabled can be set to ABAP_FALSE . In this case,

the navigation to months that are actually not displayed by the DateNavigator

is also suppressed. firstDayOfWeek defines which day will be displayed as the

first day of any week. This property may be bound to a context attribute of type

WDUI_DAY_OF_WEEK .

firstSelectedDate and lastSelectedDate can be used to define the beginning and the

end of a date range. This date range is colorized, if the property selectionMode

is set to range. However, if the value of this property is single, only the date

given by firstSelectedDate is colorized. If range is set to none, the date given by firstSelectedDate is also not colorized. The property startsWith allows to define

the first month displayed by the DateNavigator . This property may be bound to a

context attribute of type D, so the first month can be defined programmatically.

Caution: If the value of the property startsWith is initial, the application

will dump.

The properties monthsPerColumn and monthsPerRow allow to define a grid. In

each grid cell one month is displayed. Thus, the total number of months displayed

by the DateNavigator is given by the product of these two integers.

Figure 106: DateNavigator: Binding UI element properties





Events

The following events are supported by the DateNavigator UI element:

The event DaySelect (property onDaySelect ) is triggered if the user clicks on an

arbitrary day. If an action is assigned to this event, the related action handler

method is processed by the Web Dynpro framework and event specific information

can be extracted from the interface parameter WDEVENT . The internal table

WDEVENT → PARAMETERS contains the id of the DateNavigator the user has

clicked on (parameter: ID) and the selected date (parameter: DAY ).

The event WeekSelect (property onWeekSelect ) is triggered if the user clicks on an

arbitrary week number. If an action is assigned to this event, the related action

handler method is processed by the Web Dynpro framework and event specific

information can be extracted from the interface parameter WDEVENT . The

internal table WDEVENT → PARAMETERS contains the id of the DateNavigator the user has clicked on (parameter: ID), the week number (parameter: WEEK ),

and the year (parameter: YEAR).

The event MonthSelect (property onMonthSelect ) is triggered if the user clicks on

an arbitrary month name. If an action is assigned to this event, the related action

handler method is processed by the Web Dynpro framework and event specific

information can be extracted from the interface parameter WDEVENT . The

internal table WDEVENT → PARAMETERS contains the id of the DateNavigator

the user has clicked on (parameter: ID), the month index (parameter: MONTH ),

and the year (parameter: YEAR).

Hint: The first month of the year (January) has the index 0.

The event StartDateChanged (property onStartDateChanged ) is triggered if the

user navigates to months actually not displayed by clicking on the corresponding

icons displayed with the DateNavigator . If an action is assigned to this event,

the related action handler method is processed by the Web Dynpro framework

and event specific information can be extracted from the interface parameter

WDEVENT . The internal table WDEVENT → PARAMETERS contains the id of

the DateNavigator the user has clicked on (parameter: ID) and the date of the

first day that will be displayed when the DateNavigator is rendered the next time

(parameter: START_DATE ).

Hint: By default, the navigation is performed in a way that there is

no overlap and no gap between the months displayed before and after

navigating. However, the DateNavigator contains the property startsWith.

If this property is bound to a context attribute, the navigation shift can be

defined arbitrarily.





Aggregations

If arbitrary days or date ranges are to be colorized, the DateNavigatorMark UI

element has to be used. This UI element has to be defined as a sub element of the

DateNavigator . The DateNavigatorMark has the following properties:

dataSource has to be bound to a context node that contains the information about

which days are to be colorized. At runtime, this node has to contain a context

element for each day to be colorized.

The property date has to contain the date of a day to be colorized. Thus, this

property has to be bound to the appropriate context attribute defined in the data

source node.

The property category allows to assign a category to the marked days. Binding

this property to an attribute of type WDUI_DATE_MARKING_CATEGORY allows

to assign the category dynamically. If this attribute is defined in the data source

node, the category assignment can be defined day-specific.

Four categories do exist. Days belonging to the same category may be displayed

in the same color (color depends on the category) and a common legend may

be displayed for them.

The category color is only used if the property daySemantics is set to standard .

Evaluating this property differently allows to redefine the color. Binding this

property to an attribute of type WDUI_TABLE_CELL_DESIGN allows to set the

color dynamically. If this attribute is defined in the data source node, the semantic

color can be defined day-specific.

Hint: The color palette used to define the background color of a table cell

is identical to the color palette used to define the background of single

days in a DateNavigator .





Figure 107: DateNavigator: Colorizing days

To define a legend which is displayed in the box displayed with the calender

sheets, the UI element DateNavigatorLegend has to be used. This UI element has

to be defined as a sub element of the DateNavigator .The property dataSource has to be bound to a context node that contains the

legend information. At runtime, this node has to contain a context element for

each legend text to be displayed.

The property category has to be bound to an attribute of type

WDUI_DATE_MARKING_CATEGORY . At runtime, this attribute has to contain

the category name. The corresponding color will be displayed in front of the

legend texts. If this attribute is defined in the data source node, the category

assignment can be defined differently for each legend text.

Finally, the value of the property text is displayed as the legend's text. However, if

this property is not bound to an attribute defined in the data source context node,the same text will appear as often as context elements are defined in the data

source node. Thus, this property should be bound to attribute of type STRING

defined in the data source node.





Figure 108: DateNavigator: Defining legend

The PhaseIndicator UI Element

The PhaseIndicator UI element allows to visualize the single steps of a process.Each step is represented by a separate phase object. The application can define

which of the phases is the first phase to be displayed and which phase is the

actually selected phase (emphasized). Each phase can be disabled, so clicking on

the phase does not trigger a round trip to the server. For each phase a text can be

displayed. Optionally an icon can be displayed indicating the status of the phase.

Each phase can be hidden.





Figure 109: PhaseIndicator


The definition of context nodes and context elements is not mandatory to

implement a PhaseIndicator UI element.


To implement the phase indicator in the view's layout, the following steps are

necessary:

First, a PhaseIndicator UI element has to be added to the UI element hierarchy.

Next, for each step a UI element of type Phase or MultiPhase has to be defined as

a sub element of the PhaseIndicator UI element. Choose the corresponding entry

in the context menu of the PhaseIndicator .

The following properties of the PhaseIndicator UI element are of interest:

The property backgroundDesign can be used to emphasize the background of

the PhaseIndicator . If this property is set to transparent , the color of the parent

container element will be displayed.

If the property enabled is set to ABAP_FALSE , all phases are disabled. The texts

displayed by the phases are grayed out. In addition, clicking on a phase will not

trigger a round trip to the server any more.

If the id of a Phase or of a MultiPhase is assigned to the property firstVisiblePhase,

then this phase will be the first visible phase. Phases that are defined before the

first visible phase in the UI element hierarchy can be accessed by clicking on the





corresponding navigation buttons that are displayed right of the visualized phases.

If the id of a Phase or of a MultiPhase is assigned to the property selectedPhase,

then this phase will be displayed emphasized.

Figure 110: PhaseIndicator: Defining UI and data binding

Events

Only one event ( Select - property onSelect ) is supported by the PhaseIndicator

UI element. This event is fired if the user clicks on any phase that has not been

disabled. If an action is assigned to this event, the action handler method is also

processed. From the interface parameter WDEVENT , the PARAMETERS table can

be extracted. This contains the id of the PhaseIndicator ( ID) and the id of the

Phase / MultiPhase the user has clicked on (parameter: Phase).

Aggregations

Each process step is visualized by means of a Phase UI element or by meansof a MultiPhase UI element.

The Phase UI element is used in the static case. The text displayed by the Phase

UI element is defined by the value of the property description. If the property

enabled is set to ABAP_FALSE the text displayed by the phases are grayed out

and clicking on this phase will not trigger a round trip to the server any more.

The property status allows to assign an icon to the phase (value different from

normal ). A phase can be hidden by setting the property visible of the related

Phase UI element to ABAP_FALSE .





The MultiPhase UI element allows to choose between different phase descriptions.

However, only one phase will be displayed at runtime.

The phase descriptions have to be stored in a context node. This context node has

to be bound to the property dataSource of the MultiPhase UI element. For each

property of the MultiPhase that should depend on the selected phase, an additional

context attribute has to be defined in the data source node. These context attributes

have to be bound to the corresponding UI element properties. At runtime, each

phase is represented by a context element stored in the data source node. The

context element at lead selection will be displayed by the MultiPhase UI element.

Figure 111: PhaseIndicator: Defining phases (here: MultiPhase UI element)

Caution: The application will dump if non of the context elements stored

in the data source node is the element at lead selection (lead selection

index ≤ 0).

The RoadMap UI Element

The RoadMap UI element is used to display step by step workflows. This enables

an application developer to visualize small steps of a clearly defined work process.

Each step displayed by the UI element can be defined by a separate step object.

However, a set of connected steps can also be represented by one multiple step

object being bound to a data source node. Steps can have sub steps. Various

symbols can be used to mark the start point and the end point of this UI element.

Depending on the setting of the related UI element property, the user can fire





an event by clicking on these symbols. This can be implemented in a way that

additional steps are displayed before the first visible step or after the last visible

step, respectively.

Figure 112: RoadMap


For a statically defined RoadMap UI element, no special context elements have

to be created. However, a connected series of steps may also be visualizes by a

single MultipleRoadMapStep UI element that has to be bound to a context node

containing the step information. In this case, the context node should contain a

number of attributes to store the step's id (type STRING), the name displayed on

the step (type STRING), the description displayed below the step (type STRING),

and the kind of the step (type WDUI_ROAD_MAP_STEP_TYPE ). Depending

on the requirements it may also be necessary to add an attribute describing the

step's visibility (type WDY_BOOLEAN ) and an attribute allowing to disable a

step (type WDY_BOOLEAN ).


The RoadMap UI element can be defined as a sub element of any container

element. The following properties are of interest:

All steps may be disabled by setting the property enabled to ABAP_FALSE . The

step, its name and description will be displayed grayed out and clicking on the

step will not result in a server round trip.





The end point design and the start point design of the RoadMap UI element

can be defined by setting the properties startPointDesign and endPointDesign

accordingly. Depending on the selected value of these properties the user maytrigger a server round trip when clicking on the related symbols. These properties

may be bound to context attributes of type WDUI_ROAD_MAP_EDGE_DESGIN .

The property selectedStep has to be evaluated with the id of the RoadMapStep

to be displayed emphasized. Binding selectedStep to a context attribute of type

STRING allows to set the selected step programmatically.

If a MultipleRoadMapStep is used to define multiple steps dynamically, the id of

the MultipleRoadMapStep has to be assigned to selectedStep. In this case, the step

bound to the context element at lead selection will be displayed emphasized.

Figure 113: RoadMap: Defining the UI and data binding

Events

The RoadMap UI element supports two events: LoadSteps (property

OnLoadSteps) and Select (property OnSelect ).

LoadSteps is fired if the user clicks on the start point or on the end point -

which is only possible if the value of the related property ( startPointDesign

/ endPointDesign) is set to more. If an action is assigned to the property

onLoadSteps, the following parameters can be extracted from the interface

parameter WDEVENT : The parameter ID contains the id of the RoadMap UI





element the user has clicked on. The parameter AT_END contains the information

if the end point was clicked (VALUE = X ) or if the start point was clicked (VALUE

= ' ' ).

Select is fired if the user clicks on a step that is enabled. If an action is assigned to

the property onSelect , the following parameters can be extracted from the interface

parameter WDEVENT : The parameter ID contains the id of the RoadMap UI

element the selected step belongs to. The parameter STEP contains the id of the

step the user has clicked on.

Aggregations

A single steps of a RoadMap UI element can be defined statically by adding a

RoadMapStep UI element to the UI element hierarchy (as a sub element of the

RoadMap UI element).

The property description allows to define a text which is displayed below the

step. The property enabled allows to disable this step (value = ABAP_FALSE ).

The value of the property name is displayed on the step. The property visible

allows to toggle the visibility of the step. Finally, the value of the property type

allows to define how the step is displayed. The possible values are standard ,

substep, roundTripStart (to be used for a parent step if sub steps are displayed),

roundTripEnd (to be used for the step following sub steps - this step can not be

selected), and roundTripClosed (to be used for a parent step if sub steps are

hidden).

The RoadMapStep UI element does not support events.





Figure 114: RoadMap: Defining steps based on the RoadMapStep UI element

A single MultipleRoadMapStep UI element may be used to display multiple

connected road map steps. This allows to define parts of the road map or

the complete road map programmatically. The information of the step has to be stored in a context node that is bound to the property dataSource of the

MultipleRoadMapStep UI element. At runtime, this context node has to contain a

context element for each road map step. For all properties that are step-dependent,

an attribute has to be defined in the data source node and the data binding between

property and context attribute has to be established. The following properties -

discussed in the last paragraph - have values that are typically step-dependent:

description, name, enabled , visible, and type.

The MultipleRoadMapStep UI element does not support events.





Figure 115: RoadMap: Defining steps based on the Multiple RoadMapStep

UI element

Hint:The steps of a RoadMap UI element may be defined by a

combination of RoadMapStep and MultipleRoadMapStep UI elements.

Hint: If the user clicks on any element that is related to a

MultipleRoadMapStep UI element, then the parameter STEP (available

from the internal table WDEVENT → PARAMETERS in the corresponding

action handler method) contains the id of the MultipleRoadMapStep UI

element. To find out which of the steps was selected by the user, the

parameter CONTEXT_ELEMENT has to be examined. This element

contains the reference to the related context element stored in the data

source node collection.









Exercise 8: Implementing a DateNavigator

UI elementExercise Objectives


• Implement a DateNavigator UI element

Business Example


The table on the first tab displays the flights for a selected connection. However,

you would like to offer a second diagram that allows to comprehend the

distribution of the flights along the timeline more easily. Thus you would like to

display the flight dates by a DateNavigator UI element on the second tab. The

background colors used to highlight the flight dates should indicate the relative

occupation in the economy class for each flight.



Task 1:


can be implemented in the component you have created in your last exercise.If you have not finished your last exercise, you can start with a copy of the












Task 2:

Implement the DateNavigator UI element.

First, you have to create a context node in the component controller containing

one attribute of type D. This attribute has to store the information which month is

the first month to be displayed by the date navigator. This should correlate with

the first flight date for the selected connection.

Next, you need to create a controller method to set the value of the this attribute.

Hint: Keep in mind that the application will dump if the DateNavigator

UI element is rendered having the property startsWith set to its initial

value '00000000' .

Then, you have to copy this new component controller node to the view

MAIN_VIEW and map the two nodes (origin: component controller context).

Finally, you have to define the DateNavigator UI element on the second tab of

the tab strip in order to display the flight dates. The background color used to

colorize the flight dates should be identical to the colors used in the table column

displaying the occupied seats in the economy class. The DateNavigator should

display 12 months in 3 rows.

1. In the component controller context, create a new node (name:

DATE_NAV_SETTINGS having the cardinality (1:1). Add an attribute

(name: START_DATE ) of type D to this node.

2. Define a new component controller method having the name

DEFINE_START_DATE( ). This method has to set the attribute

DATE_NAV_SETTINGS.START_DATE . The method should have an optional

interface parameter (name: IV_START_DATE ) of type D.

If a value is supplied to this parameter, this value has to be stored in the

context attribute DATE_NAV_SETTINGS.START_DATE .

If no value is supplied to this parameter, the start date should equal the flight

date of the earliest flight related to the selected connection.

3. To initialize the attribute DATE_NAV_SETTINGS.START_DATE , call the

method DEFINE_START_DATE( ) from the hook method WDDOINIT( ) of the component controller. Pass the actual date to the method.

Hint: The DateNavigator UI element can only be rendered, if the

start date has a reasonable value (not initial).






4. Every time the user selects a new connection, dependent flights are read and

the method DEFINE_COLORS( ) is processed. Make sure, that the method

DEFINE_START_DATE( ) is processed, too.

5. Copy the node DATE_NAV_SETTINGS from the component controller

context to the context of view MAIN_VIEW . Map the copied node to the

component controller node DATE_NAV_SETTINGS .

6. Now create the DateNavigator UI element on the second tab of the

TabStrip UI element. Bind the property startsWith to the attribute

DATE_NAV_SETTINGS.START_DATE . 12 months should be displayed in 3

rows. Clicking on a day should not colorize this day.

7. The last step to finalize the date navigator is to define a

DateNavigatorMarking UI element as a sub element of the DateNavigator

UI element. Bind the relevant properties to the node FLIGHTS and itsattributes, respectively





Solution 8: Implementing a DateNavigator

UI elementTask 1:






















Task 2:

Implement the DateNavigator UI element.

First, you have to create a context node in the component controller containing

one attribute of type D. This attribute has to store the information which month is

the first month to be displayed by the date navigator. This should correlate with

the first flight date for the selected connection.

Next, you need to create a controller method to set the value of the this attribute.

Hint: Keep in mind that the application will dump if the DateNavigator

UI element is rendered having the property startsWith set to its initial

value '00000000' .

Then, you have to copy this new component controller node to the view

MAIN_VIEW and map the two nodes (origin: component controller context).

Finally, you have to define the DateNavigator UI element on the second tab of

the tab strip in order to display the flight dates. The background color used to

colorize the flight dates should be identical to the colors used in the table column

displaying the occupied seats in the economy class. The DateNavigator should

display 12 months in 3 rows.

1. In the component controller context, create a new node (name:

DATE_NAV_SETTINGS having the cardinality (1:1). Add an attribute

(name: START_DATE ) of type D to this node.

a) Edit the context of the component controller.

b) From the context menu of the root node, choose Create→ Node to

create the new node DATE_NAV_SETTINGS . Finish the dialog.

c) From the context menu of node DATE_NAV_SETTINGS , choose

Create→ Attribute to create the attribute START_DATE . Set Type =

D and finish the dialog.

2. Define a new component controller method having the name

DEFINE_START_DATE( ). This method has to set the attribute

DATE_NAV_SETTINGS.START_DATE . The method should have an optional

interface parameter (name: IV_START_DATE ) of type D.

If a value is supplied to this parameter, this value has to be stored in the

context attribute DATE_NAV_SETTINGS.START_DATE .






If no value is supplied to this parameter, the start date should equal the flight

date of the earliest flight related to the selected connection.

a) Edit the component controller.

b) Navigate to the tab Methods. Enter the name of the new method

in column Method . Double-click on the method's name to edit the

method's source code.

c) Define the interface parameter. Put the parameter's name in the field

Parameter . Choose Type = Importing , Associated Type = D, and check

the check box Opt .

d) Implement the source code:

If IV_START_DATE is initial, copy the content of node FLIGHTS to

an internal table. Sort the internal table by the column FLDATE . Readthe first entry of the internal table to find out the date of the first flight.

Then save this date in attribute DATE_NAV_SETTINGS.START_DATE .

If IV_START_DATE is not initial, save the value of IV_START_DATE

as the attribute value.


3. To initialize the attribute DATE_NAV_SETTINGS.START_DATE , call the

method DEFINE_START_DATE( ) from the hook method WDDOINIT( ) of

the component controller. Pass the actual date to the method.

Hint: The DateNavigator UI element can only be rendered, if the

start date has a reasonable value (not initial).


4. Every time the user selects a new connection, dependent flights are read and

the method DEFINE_COLORS( ) is processed. Make sure, that the method

DEFINE_START_DATE( ) is processed, too.

a) The source code related to the selection of a new connection is stored

in the action handler method ONACTIONGET_DETAILS( ). Insert

the call of method DEFINE_START_DATE( ) at the end of the source

code section.

b) Source code see below.






5. Copy the node DATE_NAV_SETTINGS from the component controller

context to the context of view MAIN_VIEW . Map the copied node to the

component controller node DATE_NAV_SETTINGS .


b) Drag the node DATE_NAV_SETTINGS from the component controller

context and drop it on the root node of the context of view MAIN_VIEW .

6. Now create the DateNavigator UI element on the second tab of the

TabStrip UI element. Bind the property startsWith to the attribute

DATE_NAV_SETTINGS.START_DATE . 12 months should be displayed in 3

rows. Clicking on a day should not colorize this day.


b) Navigate in the UI element hierarchy to the second Tab UI elementhaving the caption Calendar View.

c) From the context menu of this Tab UI element, choose Add Element to

Tab in order to create a DateNavigator UI element.

d) Click on the button right of the property startsWith to bind this property

to the attribute DATE_NAV_SETTINGS.START_DATE .

e) Set the properties monthsPerColumn = 3, monthsPerRow = 4, and

selectionMode = none.

7. The last step to finalize the date navigator is to define a

DateNavigatorMarking UI element as a sub element of the DateNavigator UI element. Bind the relevant properties to the node FLIGHTS and its

attributes, respectively

a) From the context menu of the DateNavigator UI element, choose Insert

Selection in order to create a DateNavigatorMarking UI element.

b) Click on the button right of the property dataSource to bind this

property to the node FLIGHTS .

c) Click on the button right of the property date to bind this property to

the attribute FLIGHTS.FLDATE .

d) Click on the button right of the property day_semantics to bind this

property to the attribute FLIGHTS.COLOR.

Result

Comp. Controller: DEFINE_START_DATE( )

METHOD define_start_date .

DA TA lo _nd _f lig hts TY PE RE F TO if_ wd _co nt ext _no de .






D AT A l o_ el_ fli gh ts TYP E REF TO i f_w d_ con tex t_ ele me nt.

DATA ls_flights TYPE wd_this->element_flights.


DATA lo_nd_date_nav_settings TYPE REF TO if_wd_context_node.

DATA lo_el_date_nav_settings TYPE REF TO if_wd_context_element.

DATA ls_date_nav_settings TYPE wd_this->element_date_nav_settings.

lo_nd_date_nav_settings = wd_context->get_child_node(

name = wd_this->wdctx_date_nav_settings ).

lo_el_date_nav_settings = lo_nd_date_nav_settings->get_element( ).

IF iv_start_date IS INITIAL.



SORT lt_flights BY fldate.

READ TABLE lt_flights INTO ls_flights INDEX 1.

lo_el_date_nav_settings->set_attribute(

EXPORTING

name = ‘START_DATE‘

value = ls_flights-fldate ).

ELSE.

lo_el_date_nav_settings->set_attribute(

EXPORTING

name = ‘START_DATE‘

value = iv_start_date ).

ENDIF.

ENDMETHOD.

Comp. Controller: WDDOINIT( )METHOD wddoinit .

wd_this->define_tree( ).

wd_this->defin e_start_date( sy-datum ).

ENDMETHOD.












IMPORTING







* Set background colors and start day of date navigator


lo_componentcontroller->define_start_date( ).

ENDMETHOD.





Lesson Summary

You should now be able to:• Implement the DateNavigator UI element






NET312 Unit Summary

Unit Summary


• Implement grouping of table column and table rows








• Create static trees


• Implement the DateNavigator UI element



Related Information





corresponding element classes. UI elements discussed in this unit can befound in the sub section named Complex Category.


ABAP demo applications are available. Demos dealing with UI elements in

general are WDR_TEST_EVENTS , WDR_TEST_UI_ELEMENTS .

Special demos only dealing with the TableView UI element are

WDR_TEST_TABLE and WDT_TABLE .

Special demos dealing with Tree UI element are WDR_TEST_TREE and the

demos beginning with WDT_TREE .




Unit Summary NET312




Unit 4Defining Graphics

Unit Overview

in this unit, UI elements to create presentation graphics are explained. Since the

BusinessGraphics UI element is the most important one in this category, it will

be covered in an extra lesson. Other UI elements capable to define graphics are

summarized in the second lesson of this unit.

Unit Objectives


• Define the context nodes and context attributes to store the data displayed by

the BusinessGraphics UI element.

• Define simple graphics displaying a fixed number of series

• Define dynamic graphics displaying an non-fixed number of series

• Implement portfolio graphics and graphics displaying trends

• Implement the GeoMap UI element

• Implement the ProgressIndicator UI element

• Implement the ValueComparison UI element

Unit Contents

Lesson: The BusinessGraphics UI Element.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .216

Exercise 9: Defining Presentation Graphics ............................231

Lesson: Additional UI Elements to define Presentation Graphics........238

Exercise 10: Implementing the ValueComparison UI Element ... . . . .249


http://-/?-

http://-/?-

http://-/?-

http://-/?-



Unit 4: Defining Graphics NET312

Lesson: The BusinessGraphics UI Element

Lesson Overview

The BusinessGraphics UI element can be used to display graphical illustrations of

data and data relationships. These graphics are rendered by the Internet Graphics

Service (IGS), which is an integral part of the SAP NetWeaver 7.0. Not only

a large variety of chart types is available but, in addition, these charts can be

adapted using the Chart Designer.

This lesson describes in detail how to define the view's layout using the

BusinessGraphics UI element and the dependent element types Category,

SimpleSeries, Series, Points and NumericValues.

Lesson Objectives







Business Example

The graphical representation of numerical data should be implemented by your

application.

Internet Graphics Service (IGS)

The Internet Graphics Service (IGS) constitutes the infrastructure to enable the

application developers to display graphics in an Internet browser with a minimum

of effort. The IGS has been integrated in the different SAP UI technologies from

HTML GUI to Web Dynpro ABAP/Java and provides a server architecture where

data from an SAP system or another source can be used to generate graphical or

non-graphical output. Until SAP Web Application Server 6.20, the IGS has been

available only as standalone engine. As of SAP Web Application Server 6.40, the

IGS is additionally available as integral part of the SAP Web AS and will be

installed with every SAP Web AS installation. Thus, with SAP Web AS 6.40, you

had the choice to use either the standalone or the integrated IGS. And as of SAP

NetWeaver 7.0 only the integrated IGS version should be used. The integrated

IGS exists on every SAP NetWeaver Application Server and is started and stopped

with the SAP NetWeaver Application Server. However, IGS is not part of the

kernel which means it has to be patched separately.




NET312 Lesson: The BusinessGraphics UI Element

From the Web Dynpro ABAP framework, the IGS is connected via an RFC

destination. For the integrated IGS version, the necessary RFC destination

IGS_RFC_DEST is created automatically.

The graphics is rendered by the so called Chart Engine. The Chart Engine is a C++

library. Depending on the GUI technology, different chart types may be displayed.

For Web Dynpro ABAP, the following chart types are available:

• Column chart (columns and stacked columns)

• Bar chart (bars and stacked bars)

• Line chart (lines, stacked lines, profiles and stacked profiles)

• Area chart (area, stacked area, profile area, stacked profile area, and pipeline)

• Pie chart (pie and split pie)

• Doughnut chart• Radar chart (radar and stacked radar)

• Polar chart

• Speedometer chart

• Scatter chart (scatter and time scatter)

• Portfolio chart

• Gantt chart

• MTA Chart

The graphics rendered by the Chart Engine can be adapted using the Chart

Designer. The Chart Designer is a tool that enables you to influence the properties

of the graphical elements such as chart type, size, layout, color, and shading. To

edit BusinessGraphics UI elements the Chart Designer can be called directly

from the view designer.

One or multiple series of data points may be displayed by a BusinessGraphics

UI element. Each of the series can have an arbitrary number of data points.

Depending on the graphics type, each data point may be described by one

numerical value (e.g. describing the y-value in a coordinate system), or by

multiple numerical values (e.g. x-value and y-value of a point in a scatter diagram,

or x-value, y-value, and size of a point displayed by a portfolio diagram). In

addition the point description may contain a time value (e.g. in combination with

a numerical y-value - this is used in a time scatter diagram). Finally, a little chartdiagram may also be displayed with each data point and trend lines connecting the

points may be included.





Figure 116: BusinessGraphics


To allow storing an arbitrary number of data series, each data series consisting

of an arbitrary number of data points and each data point being described by an

arbitrary combination of numerical values (e.g. x, y, size) or time values, the

context can be defined as follows:

Series node: On the first hierarchy level, a context node has to be defined to

store the series information. At runtime, a context element for each data series

has to be created.

Point node: On the second hierarchy level, a context node (non-singleton) has

to be defined as a sub node of the series node. This node will store the point

informations for all data series. At runtime, a separate node collection will exist

for each data series. For each collection the application has to create as many

context elements as there are data points defined in the related data series.

Value node: On the third hierarchy level, a context node (non-singleton) has to be

defined as a sub node of the point node. This node will store the detail information

for all data points of one series. At runtime, a separate node collection will exist

for each data point. For each collection the application has to create as many

context elements as informations are related to this data point. Each information

can be a numerical value (e.g. x-value, y-value, size ...), or a time value (date or

timestamp).





For category-based graphic types, the descriptions of the categories has to be

stored in the context, too. For this reason a separate context node should be created

on the first hierarchy level. At runtime, for each category a context element has to be created containing the description of this category. Categories and data points

are correlated according to their index. This means that for each data series, the

data point no. n is displayed at a position corresponding to category no. n.

Figure 117: BusinessGraphics: Defining the context (1)





Figure 118: BusinessGraphics: Defining the context (2)

This most generic definition of the context can be simplified for most of the

graphic types:

• Simplification 1: If all points of all series are described identically (e.g. by

a y-value), then related attributes can be added to the point node (e.g. an

attribute Y_VALUE ). The value node can then be dropped.

• Simplification 2: If the number of series is known at design time, if

this number is fix and if the graphic type used to display the data is

category-based, then a common point node can be defined to store the point

information for all points of all series. For each point value of each series, an

attribute has to be defined in this node. The series node can then be dropped.

• Simplification 3: In the later case, the category information can also be

stored with the point information (another attribute in the point node) and no

extra category node needs to be defined.





Figure 119: BusinessGraphics: Defining the context - simplification 1







Defining the UI and Data Binding

The BusinessGraphics UI element can be added to any container element in the

UI element hierarchy.

In the general case, a Series UI element is defined as a direct sub element of the

BusinessGraphics UI element. This allows to display an arbitrary number of data

series for a category based or for a non-category based graphics. The path to the

context node containing the series information has to be assigned to the property

seriesSource of the BusinessGraphics UI element.

Next, a single Point UI element has to be created as a direct sub element of the

Series UI element. This element is used to access the point information stored in

the context. The path to the context node containing the point information has to

be assigned to the property pointSource of the Series UI element.

Finally, at least one sub element of type NumericValue or TimeValue has to beadded to the Point UI element. Each of these sub elements allows to access

one specific information describing a point (e.g. x-value, y-value, size, date...).

Depending on the graphics type, multiple value sub elements have to be created

(e.g. one TimeValue and one NumericValue sub element for a time scatter

graphics). The path to the context node containing the value information has to be

assigned to the property valueSource of the Point UI element.





For category based graphics, an additional Category UI element should be added

to the UI element hierarchy as a direct sub element of the BusinessGraphics UI

element. This allows to display arbitrary category descriptions stored in a relatedcontext node. In this case, the path to this context node is assigned to the property

categorySource of the BusinessGraphics UI element.

Figure 122: BusinessGraphics: Defining the UI and data binding - general

case (1)





Figure 123: BusinessGraphics: Defining the UI and data binding - general

case (2)

If the context structure is simplified in respect to the general case, then the UI

element hierarchy has to be adjusted accordingly. The following discussion refers

to the situations described in the sub section dealing with the context definition.

Simplification 1: The context node containing the value information is identical

to the point node. Thus the property valueSource of the Point UI element and the

property pointSource of the Series UI element have to be evaluated identically.

Simplification 2: Depending on the complexity of the point description, two

implementations are possible:

Case 1: The point node contains the information about one data series. However,

each data point is described by multiple values (e.g. displaying ranges by floating

columns - here the minimal and the maximal value of the range is stored for

each data point).

In this case, the UI element hierarchy as described for the general case is not

changed. However, the property seriesSource of the BusinessGraphics UI element,

the property pointSource of the Series UI element, and the property valueSource

of the Point UI element have the same value. All of these properties have to be

evaluated with the path to the context node containing the point information.

Case 2: The point node contains the information about one or multiple data

series. Each data point is described by one value.





Here, for each data series to be displayed by the Business Graphics UI element,

an element of type SimpleSeries has to be defined as a direct sub element of the

Business Graphics UI element. The property seriesSource of the BusinessGraphicsUI element has to be evaluated with path to the context node containing the point

information. The path to the context attribute containing the y-value has to be

assigned to the property value of the SimpleSeries UI element.

Simplification 3: In addition to the setup discussed for simplification 2, the

properties categorySource and seriesSource of the BusinessGraphics UI element

have to be evaluated identically.

Figure 124: BusinessGraphics: Defining the UI and data binding - displaying

data ranges (1)






data ranges (2)


simple category-based graphics





Properties of the BusinessGraphics UI Element

Besides the properties used to bind the series node and the category node, the

BusinessGraphics UI element has the following interesting properties:

The graphics type can be adjusted by setting the property chartType accordingly.

If the graphics type is category-based but a Category UI element is not defined,

then the term 'Category <n>' is displayed on the category axis. Here <n> is the

index of a data point displayed for the category.

Hint: Make sure that the graphics type, the context structure definition,

and the UI element hierarchy match.

The property dimension allows to add 3-D effects to the graphics.

Hint: Depending on the graphics type, the property values pseudo_three

and three are rendered identically (e.g. all stacked graphic types).

The graphics may be defined in a way that the user may trigger an event by

clicking on data point or by clicking on the legend. If the property enabled is set

to ABAP_FALSE , this feature is disabled.

The height and the width of the graphics can be adjusted by setting the parameters

height and width accordingly (in pixels).

By default, the IGS is connected as defined by the RFC destination

IGS_RFC_DEST . However, the property igsUrl allows to assign a different IGS

by providing the web address (URL) of the server on which the IGS is to run.

The graphic rendered by the IGS can be adapted using the Chart Designer. This

tool is started from the context menu of the BusinessGraphics UI element ( Edit

Customizing ).

Hint: This menu item is only available if the view is edited.

After having finished the adoption process (closing the Chart Designer by clicking

on Enter ), an XML file is created containing all delta information. This XML file

is stored in the MIME-Repository (path: /sap/bc/webdynpro/sap/<component>,

where <component> is the name of Web Dynpro component the view belongs to).





The generated name of this XML file is automatically assigned to the property

customizing of the BusinessGraphics UI element. If multiple customizing files do

exist, the value help of this property can be used to select one of them.

Hint: The customizing information can also be changed programmatically.

In order to do this, the reference to the BusinessGraphics UI element has

to be determined in the hook method WDDOMODIFYVIEW( ) of the

related view. The method handler for the BusinessGraphics UI element is

provided by the public attribute _METHOD_HANDLER of the element

reference. Finally, the reference to the method handler has to be casted to

a reference variable of type IF_WD_BUSIN_GRAPHICS_MTD_HNDL

to access the functionality specific for business graphics. This interface

provides the functionality to set, change and clear customizing data for

the graphics.

Properties of the Category UI Element

The property description allows to define the text to be displayed as the category

description. If a value is assigned to the property eventID, then clicking on the

category text will trigger the event Action that is related to the BusinessGraphics

UI element. If an action is assigned to the related property onAction, then the

value of the property eventID can be accessed in the action handler method.

Properties of the Series UI Element

Multiple data series may be stored in the context node that is bound to the SeriesUI element. The properties dataBeginIndex and dataLength allow to define which

data series is the first one to be displayed (the first data series has the index 0!) and

how many of the data series are to be displayed. The property showSelectedOnly

allows to restrict this number of data series using a different approach. If this

property is set to ABAP_TRUE , then only data series having the related context

element in the series node marked as selected will be displayed.

The value of the property label is used to generate the legend displayed below

the diagram.

It is also possible to adopt the properties of each data series separately. In order

to do this, series elements can be defined in the customizing file created by the

Chart Designer. Each series element is identified by its name. It allows to save

properties related to data series (e.g. the line style, the shape, size, and color of the

data points, if a legend is to be displayed, the font, font-size, and font-color... ). To

actually use this adoption information for a certain data series, the name of the

series element defined in the customizing file has to be assigned to the property

customizingID of the Series UI element. Since this property may be bound to

a context attribute, each data series may be displayed differently. Finally, the

property leadSelectionCustomizingID allows to adopt the series having the lead

selection set to ABAP_TRUE in a defined manner.





Properties of the Point UI Element

Labels for the single data points can be assigned to the property label of the

Point UI element. However, to display these texts, a customizing file containing

the related adoption information has to be assigned to the BusinessGraphics UI

element.

If a value is assigned to the property eventID, clicking on the data point

(e.g. column, bar, point) will trigger the event Action that is related to the

BusinessGraphics UI element. If an action is assigned to the related property

onAction, then the value of the property eventID can be accessed in the action

handler method. Using data binding, it is possible to assign a unique value for the

eventID to each data point of each data series.

It is possible to adopt the properties of each data point separately. In order to

do this, point elements can be defined in the customizing file created by theChart Designer. Each point element is identified by its name. It allows to save

properties related to data points (e.g. the shape, size, and color of the data point, if

the label is to be displayed, the font, font-size, and font-color... ). To actually use

this adoption information for a certain data point, the name of the point element

defined in the customizing file has to be assigned to the property customizingID

of the Point UI element. Since this property may be bound to a context attribute,

each data point may be displayed differently.

Properties of the NumericValue and TimeValue UI Elements

Both elements have the property value. For the NumericValue UI element,

the value of this property has to be of type DOUBLE . For the TimeValue UIelement, the value of this property has to be of type STRING. Valid strings

are dates (YYYYMMDD) or timestamps (YYYYMMDD;HHMMSS or

YYYYMMDD;HHMMSSZZZ).

For the NumericValue UI element, the property type is of importance. Allowed

values are x, y, size, trendx, trendy, and chart .

trendx and trendy allow to define arrows connecting data points. The type chart

allows to display a mini bar chart at the point's position. size describes the size of

the square (default design) displayed in the diagram.





Figure 127: BusinessGraphics: Displaying trend lines and charts

Properties of the SimpleSeries UI Element

The properties of this UI element are identical to the ones of the Point UI element.

However, for the SimpleSeries UI element, only the property value is bindable.

To set any of the other properties depending on the data point, the corresponding

setter method has to be called in the hook method WDDOMODIFYVIEW( ).

Events

The BusinessGraphics UI element does support the event Action. This event is

fired, if the user clicks on any selectable object being part of the graphics. This

may be a category text, a legend text or a data point (a bar, a column, a point...). If

an action is assigned to the related property onAction, the related action handler

method is processed by the Web Dynpro framework. From the interface parameter

WDEVENT of this action handler, the internal table PARAMETERS can be

extracted. This internal table contains two parameters:

The id of the UI element the user has selected (Category, Series, Point , or

SimpleSeries) is provided by the parameter ID. The value of the property eventID

of the selected UI element is provided by the parameter EVENT_ID.





Exercise 9: Defining Presentation

GraphicsExercise Objectives


• Implement the BusinessGraphics UI element

Business Example


In addition to the Table UI element displaying the flights on the first tab, and the

DateNavigator UI element illustrating the flight dates on the second tab, you

would like to add a graphics displaying the occupied seats of all flight classes on

the third tab.


Solution Component: NET312_GRPH_S1

Task 1:




template component. In this case, copy the template component and name the copy ZNET312_GRPH1_##. Assign this component to your package ZNET312_##.





Task 2:

Define a BusinessGraphics UI element on the rightmost tab of the TabStrip UI

element. This graphic has to display the number of occupied seats in all threeflight classes as a function of the flight date.

1. In the component controller context node FLIGHTS define a new attribute

(name: DATE_FORMATTED) of type STRING. For each flight, this

attribute has to contain the flight date in the external representation.

2. Create a new component controller method having the name

DEFINE_DATE_FORMATTED( ). For all flights, define the value of

attribute FLIGHTS.DATE_FORMATTED by this method.






3. Call the new method DEFINE_DATE_FORMATTED( ) if the user clicks on

a new connection in the tree.

4. Actualize the mapping of node FLIGHTS in the context of view

MAIN_VIEW .

5. Define a BusinessGraphics UI element on the rightmost tab of the TabStrip

UI element. The pseudo three dimensional profile area should occupy a

height of 400 pixels and a width of 600 pixels and it should display data

stored in node FLIGHTS .

6. Define the category axis displaying the formatted date of the flights. For

each flight class display the occupation as a function of the formatted date.

7. OPTIONAL PART:

Customize your business graphics. Change any settings you want to usingthe Chart Designer.





Solution 9: Defining Presentation

GraphicsTask 1:





ZNET312_GRPH1_##. Assign this component to your package ZNET312_##.












TYPE

Task 2:

Define a BusinessGraphics UI element on the rightmost tab of the TabStrip UI

element. This graphic has to display the number of occupied seats in all three

flight classes as a function of the flight date.

1. In the component controller context node FLIGHTS define a new attribute

(name: DATE_FORMATTED) of type STRING. For each flight, this

attribute has to contain the flight date in the external representation.


b) From the context menu of node FLIGHTS , choose Create→ Attribute

to create the attribute DATE_FORMATTED. Set Type = STRING and

finish the dialog.







DEFINE_DATE_FORMATTED( ). For all flights, define the value of

attribute FLIGHTS.DATE_FORMATTED by this method.

a) Now edit the methods of the component controller.

b) Enter the name of the new method in column METHODS . Double-click

on the method's name to edit the source code.

c) Copy the content of node FLIGHTS to an internal table. Loop over

the internal table. For each flight set the field DATE_FORMATTED

and modify the data set in the internal table. Finally, bind the internal

table to the node FLIGHTS .

Hint: Use the WRITE .. TO .... statement to define the contentof field DATE_FORMATTED.


3. Call the new method DEFINE_DATE_FORMATTED( ) if the user clicks on

a new connection in the tree.

a) If the user clicks on a connection displayed by the tree, the action

handler method ONACTIONGET_DETAILS( ) is processed. Call of

the component controller method DEFINE_DATE_FORMATTED(

) in this action handler method.

b) Source code see below.4. Actualize the mapping of node FLIGHTS in the context of view

MAIN_VIEW .


b) From the context menu of node FLIGHTS , choose Update Mapping .

5. Define a BusinessGraphics UI element on the rightmost tab of the TabStrip

UI element. The pseudo three dimensional profile area should occupy a

height of 400 pixels and a width of 600 pixels and it should display data

stored in node FLIGHTS .

a) Edit the layout of view MAIN_VIEW . b) Navigate to the last Tab UI element related to the TabStrip UI element.

From the context menu of the Tab UI element choose Add Element to

Tab and select Type = BusinessGraphics on the next dialog. Finish

the dialog.

c) Set the properties of the BusinessGraphics UI element as follows:

chartType= profile_area, dimension = pseudo_three, height = 400, and

width = 600. Do not forget to set seriesSource = FLIGHTS .






6. Define the category axis displaying the formatted date of the flights. For

each flight class display the occupation as a function of the formatted date.

a) From the context menu of the BusinessGraphics UI element, choose

Insert Category.

b) Click on the button right of the UI element property description

in order to bind this property to the context attribute

FLIGHTS.DATE_FORMATTED.

c) From the context menu of the BusinessGraphics UI element, choose

Insert Series. In the following dialog choose Type = SimpleSeries.

Finish the dialog.

d) Click on the button right of the UI element property value in order to

bind this property to the context attribute FLIGHTS.SEATSOCC_F . In

addition, define a legend text by assigning the text literal Occupied

seats in first class to the property label .

e) Repeat the last two steps to display the occupied seats in the business

class (attribute FLIGHTS.SEATSOCC_B) and in the economy class

(attribute FLIGHTS.SEATSOCC ).

7. OPTIONAL PART:

Customize your business graphics. Change any settings you want to using

the Chart Designer.

a) From the context menu of the BusinessGraphics UI element, choose

Edit Customizing to start customizing your graphics.

b) Change any settings and save your customizing data set by clicking

on the Enter button.

Result

Comp. Controller: DEFINE_DATE_FORMATTED()

METHOD define_date_formatted .

DA TA lo _nd _f lig hts TY PE RE F TO if_ wd _co nt ext _no de .



DATA lv_date_formatted TYPE c LENGTH 10.



LOOP AT lt_flights INTO ls_flights.






WRITE ls_flights-fldat e TO lv_date_formatte d.

ls_flights-date_formatted = lv_date_formatted.

MODIFY lt_flights FROM ls_flights.

ENDLOOP.


ENDMETHOD.







IMPORTING







* Set background colors and start day of date navigator


lo_componentcontroller->define_start_date( ).

* Define date representation in external format

lo_componentcontroller->define_date_formatted( ).

ENDMETHOD.





Lesson Summary

You should now be able to:• Define the context nodes and context attributes to store the data displayed by









Lesson: Additional UI Elements to define Presentation

Graphics

Lesson Overview

This lesson deals with special UI elements that are used to define presentation

graphics. This includes the GeoMap, the ValueComparison, and the

ProgressIndicator .

Lesson Objectives


• Implement the GeoMap UI element• Implement the ProgressIndicator UI element


Business Example

To enhance the functionality of your application you would like to integrate

graphics based on the GeoMap UI element. In addition, to visualize physical

quantities (e.g. occupied seats in respect to available seats) you want to integrate a

ValueComparison UI element into a view's layout. Finally, the progress of your

application should be displayed to the user by a ProgressIndicator UI element.

The GeoMap UI Element

The GeoMap UI element can be used to display a section of a map. The map

section to be displayed can be defined by the application. The geographical

coordinates are derived from the longitude and latitude values of a geographical

location and must be entered in WGS84 format based on the reference system

World Geodetic System –1984 (WGS84).

The possibility to position the map and to zoom in and out can be offered to the

user. Points can be marked and a text can be displayed below the marking. In

addition, lines and polygons can be displayed together with a describing text.

Finally, the map can be enabled. In this case a server round trip is triggered whenthe user click on geo objects (points, lines, or polygons).




NET312 Lesson: Additional UI Elements to define Presentation Graphics

Figure 128: GeoMap

Hint: The GeoMap UI element can only be used with a special software

component that is provided by the geographical maps. This software

component, which you can use to expand the Internet Graphics Service(IGS), is not delivered with the NetWeaver Application Server ABAP. It

must be purchased from a third-party provider. The GeoMap UI element

cannot be displayed without this complementary software component.

See also SAP Note 994568


It is not mandatory to define context elements for the GeoMap UI element.

Context attributes used in respect with an optional data binding of UI element

properties are discussed in the next sub section.

UI Element Definition and Data BindingThe GeoMap UI element can be defined as a sub element of any container element.

The following properties are of interest:

The width and height of the UI element can be defined by setting the properties

width and height , respectively (in pixels). These properties can not be bound to

context attributes. To change these properties at runtime, the GeoMap UI element

has to be accessed directly from the view's hook method WDDOMODIFYVIEW( ).





To define the section of the map displayed in this UI area, the properties left , right ,

top, and bottom should be set. The value of these properties have to be defined

in decimal numbers in accordance with the Standard World Geodetic System – 1984 (WGS84).

If the map displayed by the GeoMap UI element is stretched, the proportions

between width and height will always be stable. Thus, the map section actually

displayed is defined as follows:

The longitudinal positions defined by left and right always define the westernmost

and easternmost positions displayed by the map - independent of the values of

width and height . The arithmetic mean between the horizontal positions top and

bottom will define the horizontal position displayed in the middle of the map. The

northernmost and the southernmost positions are then calculated from the ratio

between the values of the properties height and width, respectively.

If geo objects are to be displayed, then the property geoObjectSource has to be

bound to a context attribute of type CL_WD_GEO_OBJECT . At runtime, each

geo object will be described by one context element. Thus, this context attribute

should be defined in a context node of cardinality 0:n to allow the definition

of an arbitrary number of geo objects.

The property moveType allows to define if the user can position the map section

displayed by the UI element. If the value of this property is set to panel , control

elements are displayed on all sides of the map border.

The property zoomType allows to define, if the user can change the zoom factor. If

the value of this property is set to panel , a control element is displayed in the leftupper corner of the area occupied by the UI element. By clicking on the plus sign

or on the minus sign, the zoom factor can be increased or decreased, respectively.

moveType and zoomType can not be bound to context attributes. To change these

properties at runtime, the GeoMap UI element has to be accessed directly from the

view's hook method WDDOMODIFYVIEW( ).

The property enabled can be set to ABAP_FALSE in order to disable the possibility

to position the map and change the zoom factor.

Caution: If an action is assigned to the event ObjectAction and the value

of property enabled is set to ABAP_FALSE , clicking on selectable geo

objects is still possible. However, the application will dump!

The property igsUrl can be used to assign the RFC destination to the IGS server

providing the geo maps (notation: $<RFC_destination>$). If the value of this

property is initial, the standard destination is used. igsURL can not be bound to

context attributes.

Finally, the values of the properties imageSource and mapSource are only visible

to the API and can thus not be changed by the application developer.





Figure 129: GeoMap: Defining the UI and data binding

Events

The GeoMap UI element does support one event: ObjectAction. This event is

fired, if the user clicks on any selectable geo object. If an action is assigned to therelated property onObjectAction, the related action handler method is processed

by the Web Dynpro framework. From the interface parameter WDEVENT of this

action handler, the internal table PARAMETERS can be extracted. This internal

table contains two parameters: The id of the GeoMap object is provided by the

parameter ID. The id of the selected geo object is provided by the parameter

EVENT_ID.

Defining Geo Objects

So-called geo objects can be positioned in the map in order to highlight specific

positions. These geo objects are used to provide specific information to the user

(e.g. the starting point or finishing point of a route or the complete route on themap can be marked). Three kind of geo objects can be defined by the application:

Points, lines, and polygons.

Technically, each geo object is represented by an instance of a global class:

• Points are described by the class CL_WD_GEO_POINT .

• Lines are described by the class CL_WD_GEO_LINE .

• Polygons are described by the class CL_WD_GEO_POLYGON .

All of these classes are sub classes of CL_WD_GEO_OBJECT .





To create a new geo object, the corresponding class has to be instantiated. The

constructors of all geo object classes do not have any interface parameters. Thus

all object properties have to be defined by calling the appropriate setter methodsof the created objects. The following properties can be adjusted:

• ID (STRING): Used to identify the geo object. If the user is allowed to click

on multiple geo object, the ID should be unique, since this parameter is used

to identify which geo object was selected by the user.

• COLOR (STRING): Color of point marker, polygon, or line drown on the

map. The color has to be defined in RGB notation (e.g. 255,151,151).

• LABEL (STRING): Text displayed permanently with the geo object.

• TOOLTIP (STRING): Text displayed as a quick help if the user moves the

mouse on the geo object.

• TRIGGERS_EVENT (WDY_BOOLEAN ): Defines, whether geo object isselectable. If this parameter is set to ABAP_TRUE , the event ObjectAction is

fired if the user clicks on the geo object.

The following additional properties do exist for geo objects of type point:

• IMAGE (STRING): Image to be displayed as a marker for the geo point. To

display the image, the parameter STYLE has to be set to 04.

• POSITION (GEOPOSITION ): Longitude and latitude values of a

geographical location to be defined in WGS84 format. These values have

to be stored in the fields LONGITUDE and LATITUDE of this structure,

respectively.

• SIZE ( INTEGER): Size of the marker (only effective for STYLE = 00, 01,or 02).

• STYLE (WDUI_GEO_POINT_STYLE ): Style of the marker to be displayed.

Possible values are 00 (circle), 01 (triangle), 02 (square), 03 (ellipse), and

04 (image).

The following additional properties do exist for geo objects of type lines:

• POSITIONS (GEOPOSITIONSTAB): Internal table containing as many lines

as geographical locations are necessary to describe the geo object. Each

table line is a structure (type GEOPOSITION ) containing longitude and

latitude values of a geographical location to be defined in WGS84 format.

These values are stored in the fields LONGITUDE and LATITUDE of thisstructure, respectively.

• WIDTH ( INTEGER): Width of the line.





The following additional properties do exist for geo objects of type polygon:

• BORDER_COLOR (STRING): Color of line surrounding polygon. The

color has to be defined in RGB notation (e.g. 255,151,151).

• POSITIONS (GEOPOSITIONSTAB): Internal table containing as many lines

as geographical locations are necessary to describe the geo object. Each table

line is a structure (type GEOPOSITION ) containing longitude and latitude

values of a geographical location to be defined in WGS84 format. These

values are stored in the fields LONGITUDE and LATITUDE of this structure,

respectively. At runtime, all lines are connected and the area surrounded by

the lines is filled. The last point and the first point listed in this internal

table are automatically connected.

• TRANSPARENCY ( INTEGER): Defines the degree of transparency of the

Map. Allowed values are between 0 (completely transparent - polygon coversmap completely) and 100 (completely intransparent - polygon is not visible).

Figure 130: GeoMap: Defining a geo object

The ProgressIndicator UI Element

The ProgressIndicator UI element shows how much progress an activity has

made in the form of a horizontal bar. A user-defined text may be displayed in the

progress bar. The bar color can be changed.





Figure 131: ProgressIndicator

Hint: To change the UI, a server round trip has to be completed. Thus,

this UI element can not be used to visualize how much percent of the

source code related to a single dialog step has been completed.


It is not mandatory to define context elements for the ProgressIndicator UIelement. Context attributes used in respect with an optional data binding of UI

element properties are discussed in the next sub section.


The ProgressIndicator UI element can be defined as a sub element of any

container element. The following properties are of interest:

The color of the bar can be adjusted by setting the property barColor accordingly.

Possible values are positive, negative, critical , and neutral . This property may be

bound to a context attribute of type WDUI_PROG_IND_BAR_COL.

The width of the ProgressIndicator UI element is defined by the value of the property width (in pixels or percent). The property percentValue defines the width

of the color bar relative to the width of the surrounding box. All positive integers

are allowed. If the value of this property is between 0 and 100, the width of the

box is fixed while the color bar has a relative width given by the property value. If

the value is larger then 100, then the color bar has a fixed width and the width of

the box is reduced accordingly.





By default, the value of the property percentValue is displayed in the color bar (a

%-sign is automatically added to the integer). To display a different text in the

bar, the property displayValue has to be evaluated. To suppress the output of anytext in the bar, the property showValue can be set to ABAP_FALSE . The tooltip

property can be used to define a quick info. However, the text displayed to the

user will always be constructed from the values of the properties displayValue,

percentValue, and tooltip.

Figure 132: ProgressIndicator: Defining the UI and data binding

Events

The ProgressIndicator UI element does not support any events.

The ValueComparison UI Element

This UI element is used to display various values within a horizontal bar. Example(see graphics below): Here, the actual booking situation of a flight is visualized by

a ValueComparison UI element. The width of the box indicates the total number

of available seats. The width of the horizontal bar indicates how many seats may

be booked. Our carrier overbooks their flight, thus the bar exceeds the width of the

box. The bar is divided in three sections having different colors. This is used to

indicate uncritical, critical, or neutral situations (e.g. to little bookings are critical

and overbooking is critical). In addition, a marker is displayed. In the context

discussed here, the marker is used to display the actual booking situation.





Figure 133: ValueComparison


It is not mandatory to define context elements for the ValueComparison UI

element. Context attributes used in respect with an optional data binding of UI

element properties are discussed in the next sub section.


TheValueComparison UI element can be defined as a sub element of any container


The maximum integer to be visualized by the ValueComparison UI element should

be assigned to the property maxValue. Then, the property width (integer value,

interpreted in pixels) defines the width occupied by the UI element.

The properties boxValue and barValue allow to set the relative width of the

horizontal bar and the surrounding box, respectively. The values of these

properties have to be provided as integers. The absolute width (in pixels) of the

box is given by <boxValue>/<maxValue>*<width>. The absolute width (in pixels) of the bar can be determined accordingly.

lowerThresholdValue and upperThresholdValue allow to define intersections of

the horizontal bar displayed in different colors. The values have to be provided

as integers. The positions of the section limits are given by the ratio between

these properties and the value of the property barValue, respectively. The color

of the first section (from left to right) is given by the value of the property

colorBelowThreshold , the color of the second section is given by the value of





colorBetweenThreshold , and the color of the last section is defined by the value of

colorAboveThreshold . If these properties are bound to context attributes, these

attributes have to be of type WDUI_BAR_COLOR.

The position of the marker can be adjusted by setting the property markerValue

accordingly. The marker can be displayed in black (neutral ) or red (critical ) by

adjusting the property markerType

Finally, the text to be displayed above the box is determined by the value of the

property text .

Figure 134: ValueComparison: Defining the UI and data binding (1)





Figure 135: ValueComparison: Defining the UI and data binding (2)

Events

The ValueComparison UI element does not support any events.





Exercise 10: Implementing the

ValueComparison UI ElementExercise Objectives


• Implementing the ValueComparison UI element

Business Example


A ValueComparison UI element should be used to illustrate the number of

occupied seats in the economy class in respect the total seats in this class as

a table popin graphic.

Template Component: NET312_GRPH_S1

Solution Component: NET312_GRPH_S2

Task 1:





ZNET312_GRPH2_##. Assign this component to your package ZNET312_##.Create an application having the same name as your component and assign the









Task 2:

Define a ValueComparison UI element to illustrate the occupation in the economy

class graphically. This graphics has to be displayed by the table popin.

The ValueComparison UI element has to display a green bar (color: positive)

below the lower threshold, a red bar (color: negative) above the upper threshold

and an orange bar (color: critical ) between these two values. The actual

occupation should be indicated by a marker. The threshold values should

correspond to the limits used to define the background color of the table cells

displaying the occupied seats in the economy class.

1. In order to control the settings of the ValueComparison UI element

programmatically, a new context node (name: GRAPHICS_VS ) has to be

created as a sub node of node FLIGHTS in the component controller context.

2. Add five attributes to the node GRAPHICS_VS :

- TEXT of type STRING to display a text above the ValueComparison UI

element.

- SEATSMAX of type SFLIGHT-SEATSMAX to define the number of seats

corresponding to the full bar length.

- SEATSOCC of type SFLIGHT-SEATSOCC to define the position of the

marker.

- L_THRESHOLD of type SFLIGHT-SEATSOCC to define for which

occupation the bar color changes from green to orange.

- U_THRESHOLD of type SFLIGHT-SEATSOCC to define for which

occupation the bar color changes from orange to red.


DEFINE_GRAPHICS_DATA( ). Add an import parameter

(name: IO_CONTEXT_ELEMENT ) having the reference type

IF_WD_CONTEXT_ELEMENT to the method's interface. At runtime,

the reference to the flight element the table popin is expanded for will be

supplied to this interface parameter. Set the values of the attributes defined

in node GRAPHICS_VS according to this flight.

4. Call the component controller method DEFINE_GRAPHICS_DATA( ) every

time the user expands the table popin. Pass the reference to the relatedcontext element to the interface parameter IO_CONTEXT_ELEMENT .


MAIN_VIEW .

6. Now you can define the ValueComparison UI element in the layout of view

MAIN_VIEW . This UI element has to replace the TextView UI element

assigned to the TablePopin UI element so far. Use the values stored in the

context node GRAPHICS_VS to control the UI element. Set colors (negative,

critical , and positive) and width (600 pixels) statically.





Solution 10: Implementing the

ValueComparison UI ElementTask 1:





ZNET312_GRPH2_##. Assign this component to your package ZNET312_##.












Task 2:

Define a ValueComparison UI element to illustrate the occupation in the economy

class graphically. This graphics has to be displayed by the table popin.

The ValueComparison UI element has to display a green bar (color: positive)

below the lower threshold, a red bar (color: negative) above the upper threshold

and an orange bar (color: critical ) between these two values. The actual

occupation should be indicated by a marker. The threshold values should

correspond to the limits used to define the background color of the table cells

displaying the occupied seats in the economy class.

1. In order to control the settings of the ValueComparison UI element programmatically, a new context node (name: GRAPHICS_VS ) has to be

created as a sub node of node FLIGHTS in the component controller context.


b) From the context menu of node FLIGHTS , choose Create→ Node to

create the untyped node GRAPHICS_VS . Finish the dialog.

2. Add five attributes to the node GRAPHICS_VS :






- TEXT of type STRING to display a text above the ValueComparison UI

element.

- SEATSMAX of type SFLIGHT-SEATSMAX to define the number of seats

corresponding to the full bar length.

- SEATSOCC of type SFLIGHT-SEATSOCC to define the position of the

marker.

- L_THRESHOLD of type SFLIGHT-SEATSOCC to define for which

occupation the bar color changes from green to orange.

- U_THRESHOLD of type SFLIGHT-SEATSOCC to define for which

occupation the bar color changes from orange to red.


b) From the context menu of node GRAPHICS_VS , choose

Create→ Attribute to create the attribute TEXT . Set Type = STRING

and finish the dialog.

c) Repeat the last step for each of the attributes SEATSMAX , SEATSOCC ,

L_THRESHOLD, and U_THRESHOLD, respectively.


DEFINE_GRAPHICS_DATA( ). Add an import parameter

(name: IO_CONTEXT_ELEMENT ) having the reference type

IF_WD_CONTEXT_ELEMENT to the method's interface. At runtime,






the reference to the flight element the table popin is expanded for will be

supplied to this interface parameter. Set the values of the attributes defined

in node GRAPHICS_VS according to this flight.

a) Edit the methods of the component controller.

b) Enter the name of the new method ( DEFINE_GRAPHICS_DATA)

in column Methods and double-click on the method's name to edit

the source code.

c) To define the interface parameter, enter the parameter's name in column

Parameter , set Type = Importing , check the check box RefTo, and put

the reference type in column Associated Type.

d) Implement the method:

• Get the flight information from the context element IO_CONTEXT_ELEMENT .

• Copy the number of occupied seats and the number of

totally available seats in the economy class to the context

attributes FLIGHTS.GRAPHICS_VS.SEATSOCC and

FLIGHTS.GRAPHICS_VS.SEATSMAX , respectively.

• Set FLIGHTS.GRAPHICS_VS.L_THRESHOLD to 0.5 *

FLIGHTS.GRAPHICS_VS.SEATSMAX .

• Set FLIGHTS.GRAPHICS_VS.U_THRESHOLD to 0.95 *

FLIGHTS.GRAPHICS_VS.SEATSMAX .

• Assign the literal Occupation Economy Class to the attribute FLIGHTS.GRAPHICS_VS.TEXT .







4. Call the component controller method DEFINE_GRAPHICS_DATA( ) every

time the user expands the table popin. Pass the reference to the related

context element to the interface parameter IO_CONTEXT_ELEMENT .

a) If the user expands the table popin for a certain table row, the

action handler method ONACTIONTOGGLE_POPIN( ) of view

MAIN_VIEW is processed. The reference to the related context

element is provided by the framework as an event parameter (name:

CONTEXT_ELEMENT ). The information if the table popin is

expanded is provided by the event parameter EXPANDED.

b) Edit the action handler method ONACTIONTOGGLE_POPIN( ) of

view MAIN_VIEW .

c) Add the parameter CONTEXT_ELEMENT (TYPE REF TO

IF_WD_CONTEXT_ELEMENT ) to the list of importing parametersfor this method.

d) Add the parameter EXPANDED (TYPE WDY_BOOLEAN ) to the list of

importing parameters for this method.

e) Edit the source code of action handler method ONACTIONTOG-

GLE_POPIN( ):

If the table popin is expanded, call the component controller

method DEFINE_GRAPHICS_DATA( ) and pass the event

parameter CONTEXT_ELEMENT to the importing parameter

IO_CONTEXT_ELEMENT of this method.



MAIN_VIEW .


b) Right mouse click on node FLIGHTS to open the context menu for

this node. Choose Update Mapping . This will copy the sub node

GRAPHICS_VS to the mapped node.

6. Now you can define the ValueComparison UI element in the layout of view

MAIN_VIEW . This UI element has to replace the TextView UI element

assigned to the TablePopin UI element so far. Use the values stored in thecontext node GRAPHICS_VS to control the UI element. Set colors (negative,

critical , and positive) and width (600 pixels) statically.


b) Navigate to the TablePopin UI element. Delete the TextView UI element

that has been defined as a sub element of the TablePopin UI element.






c) From the context menu of the TablePopin UI element, choose Insert

Content . In the next dialog select Type = ValueComparison (key:

GRAPHICAL_VALUE_CMP ).

d) Use the button right of the property name to bind the following

properties:

• barValue, boxValue, and maxValue have to be bound to the

attribute FLIGHTS.GRAPHICS_VS.SEATSMAX .

• lowerThresholdValue has to be bound to FLIGHTS.GRAPH-

ICS_VS.L_THRESHOLD.

• upperThresholdValue has to be bound to FLIGHTS.GRAPH-

ICS_VS.U_THRESHOLD.

• markerValue has to be bound to FLIGHTS.GRAPHICS_VS.SEAT-

SOCC .

• Finally, text has to be bound to FLIGHTS.GRAPHICS_VS.TEXT .

e) Set the values of the UI element properties as follows:

colorAboveThreshold = negative, colorBelowThreshold = positive,

colorBetweenThresholds = critical , and width = 600.

Result

Comp. Controller: DEFINE_GRAPHICS_DATA( )

METHOD define_graphics_data .


DATA lo_nd_graphics_vs TYPE REF TO if_wd_context_node.

DATA ls_graphics_vs TYPE wd_this->element_graphics_vs.

io_context_element->get_static_attributes(

IMPORTING

static_attributes = ls_flights ).

ls_graphics_vs-text = 'Occupation Economy Class'.ls_graphics_vs-seatsocc = ls_flights-seatsocc.

ls_graphics_vs-seatsmax = ls_flights-seatsmax.

ls_graphics_vs-l_threshold = '0.50' * ls_flights-seatsmax.

ls_graphics_vs-u_threshold = '0.95' * ls_flights-seatsmax.

lo_nd_graphics_vs = io_context_element->get_child_node(

name = wd_this->wdctx_graphics_vs ).

lo_nd_graphics_vs->bind_structure( ls_graphics_vs ).






ENDMETHOD.

View Controller: ONACTIONTOGGLE_POPIN( )

METHOD onactiontoggle_popin .

DATA lo_componentcontroller TYPE REF TO ig_componentcontroller .

IF expanded = abap_true.


lo_componentcontroller->define_graphics_data(

io_context_element = context_element ).

ENDIF.

ENDMETHOD.





Lesson Summary

You should now be able to:• Implement the GeoMap UI element






Unit Summary NET312

Unit Summary







• Implement the GeoMap UI element



Related Information• The online documentation for SAP NetWeaver 7.0 contains an excellent





found in the sub section named Graphic Category.


ABAP demo applications are available. Demos dealing with UI elements in


A special demo dealing with the GeoMap UI element is

WDR_TEST_GEOMAP .




Unit 5 Integrating BEx Web Applications and

non-ABAP Technologies

Unit Overview

UI elements that allow to integrate templates based on BEx Web Applicationsand non-ABAP technologies in Web Dynpro are summarized in the integration

category. Here, all of these elements are discussed in detail.

Unit Objectives


• Embed forms (in the context of SAP Interactive Forms by Adobe) and static

PDF documents in Web Dynpro

• Embed Microsoft Word and Microsoft Excel files in Web Dynpro

• Embed BI Web Templates based on Business Explorer (BEx) WebApplications in Web Dynpro

• Use the FileUpload UI element

Unit Contents

Lesson: Integrating BEx Web Applications and non-ABAPTechnologies.... .... ... .... .... .... .... .... .... ... .... ... .... .... .... ... .... .... .260


http://-/?-

http://-/?-



Unit 5: Integrating BEx Web Applications and non-ABAP Technologies NET312

Lesson: Integrating BEx Web Applications and

non-ABAP Technologies

Lesson Overview

For Web Dynpro UIs, forms (in the context of SAP Interactive Forms by Adobe)

can be embedded using the InteractiveForm UI element. BI Web Templates based

on Business Explorer (BEx) Web Applications may be embedded by means of the

BIApplicationFrame UI element. Microsoft Word and Microsoft Excel documents

may be embedded using the OfficeControl UI element. Finally, uploading a file

from the client PC to the context of your Web Dynpro application is supported

via the FileUpload UI element.

Lesson Objectives





• Embed BI Web Templates based on Business Explorer (BEx) Web

Applications in Web Dynpro


Business Example

Your application has to be enhanced by integrating PDF documents, office

documents or BEx Web Templates.

Integrating SAP Interactive Forms by Adobe

The InteractiveForm UI element can be used to integrate interactive and

non-interactive forms based on SAP Interactive Forms by Adobe, or it may be used

to embed an existing static PDF document into a Web Dynpro view.

SAP Interactive Forms by Adobe

The layout of the PDF form is designed with the Form Builder (transaction code

SFP). For efficient and straightforward development of the user interface, the

Adobe LiveCycle Designer tool with editor and the Adobe UI elements has been

integrated into the development workbench.

The required Adobe-specific standard objects are provided by a library. These

standard objects are subdivided into field objects and text module objects. They

represent layout elements like text fields, time fields, push buttons, or check

boxes. They can be inserted into the PDF form template. Field objects like push




NET312 Lesson: Integrating BEx Web Applications and non-ABAP Technologies

buttons, radio buttons, check boxes, and drop down list boxes enable the user to

interact with the application. On the other hand, text module objects like circles,

rectangles, and static texts have a static characteristic and can only be used for presentations with a static content.

The field objects have a function that is similar to Web Dynpro UI elements. They

are bound to the form context in the Designer. The form context is related to

the interface implemented by the form. The interface definition can be created

manually (based on the ABAP Dictionary, a Smart Form document's interface, or

an XML schema uploaded from the file system). However, the interface definition

may also be derived from an XML schema that is generated at design time on

the basis of the Web Dynpro context.

Hint: SAP strongly recommends to use form interfaces that are based onXML schema for all interactive forms. This kind of interface definition is

also the best choice for non-interactive forms.

Until now, Active Component Framework (ACF) had to be installed on the

front-end PC to use interactive forms. As of SAP NetWeaver 7.0 SPS 10, Zero

Client Installation (ZCI) allows to use interactive forms in Adobe Reader (Version

8.1 or higher) without any additional plug-ins. ACF is therefore no longer required

for interactive forms. To define which kind of layout type is to be used, the form

property Layout type has to be set to xACF (ACF), to ZCI (ZCI), or to standard

layout (for non-interactive forms).

Hint: SAP strongly supports to use forms that are ZCI compliant.





Scenarios

In the following, the possible scenarios of integrating PDF forms and PDF

documents are classified:

• Offline scenario: Forms that already exist in the system (as MIME objects

in the MIME Repository), or PDF documents that are uploaded within a Web

Dynpro application are displayed.

• Print scenario: This scenario is used for printing and displaying forms.

Unlike in the interactive scenario, only non-input-enabled PDF forms

(PDF-based print forms) are used here.

• Interactive scenario: With this scenario, forms containing input-enabled

elements are created and edited.

Hint: SAP recommends to use interactive forms only after carefully

checking the requirements of the related application. Interactive

forms should only be used if a PDF-based form really does have

advantages over a normal Web Dynpro view. This can include for

instance scenarios in which paper-based processes are to be replaced

or complimented by an online scenario with exactly the same form

layout. Other cases can be applications where, in addition to the

online scenario the same form is needed in static form for printing,

archiving, sending by e-mail, or for other purposes.

Caution: The integration of active controls like the InteractiveForm inWeb Dynpro ABAP pop-ups is not supported.

Caution: Only one form can be displayed at the same time in the same

browser window using InteractiveForm UI elements.





Offline Scenario

Figure 136: InteractiveForm: Offline scenario

In order to embed a statical PDF document in a Web Dynpro view, a UI element of type InteractiveForm has to be added to the UI element hierarchy of this view. An

InteractiveForm UI element can be a sub element of any container.

The property pdfSource has to bound to a context attribute of type XSTRING.

At runtime, this context attribute will store the PDF content. The UI element

properties dataSource and templateSource stay initial, since the PDF is not

obtained (dynamically) from a form. The values of the properties enabled and

readOnly are ignored and do not influence the result.





Figure 137: InteractiveForm: Offline scenario - defining the UI and data

binding

Hint: In this scenario, the PDF document is displayed without involving

the ADS or the ACF.

The PDF document can be retrieved from the MIME Repository by

calling the method GET(...) which is defined in the MIME Repository

API. The reference to this API is returned by the method call

CL_MIME_REPOSITORY_API=>GET_API( ).





Figure 138: InteractiveForm: Offline scenario - loading PDF

programmatically

It is also possible to upload the file from a file system to the Web Dynpro context

using a FileUpload UI element. The property data of this element type has to be

bound to a context attribute of type XSTRING. After having uploaded the file, thefile content will be stored in this attribute. Optionally, the properties fileName

and mimeType can be bound to context attributes of type STRING. Then, the

application can check from which location the file has been uploaded and if the

file has the expected MIME type. Finally, the property enabled has to be set to

ABAP_TRUE . Only then the path to the PDF document can be entered into the

input field related to the UI element.

The FileUpload UI element does not support events, thus submitting the data has

to be triggered by some other UI element. Typically a link or a button is used to

offer this functionality. In the action handler method related to the submit event,

the application has to check if the file uploaded by the user fulfills the requirements

(size, type, origin). Then, the file content can be copied to the context attribute

being bound to the InteractiveForm UI element property pdfSource.





Figure 139: InteractiveForm: Offline scenario - upload file

Print Scenario

Figure 140: InteractiveForm: Print scenario





For this kind of scenario, the following changes in respect to the offline scenario

have to be conducted:

The UI element property templateSource has to be evaluated with the name of the

form to be embedded into the view. The property dataSource has to be bound to

the context node that contains the data to be interchanged with the form. Finally,

the property enabled should be set to ABAP_FALSE (otherwise form fields may

be editable).

Hint: If the properties templateSource and dataSource are not initial, then

the value of the property pdfSource is ignored.

Hint: If the property enabled is set to ABAP_FALSE , then the value of the property readOnly is ignored.

Hint: For this kind of scenario, the form can only be created if an ADS

is available.

Figure 141: InteractiveForm: Print scenario - defining the UI and data binding





The following steps are necessary to assign an existing form to the InteractiveForm

UI element:

1. The name of the existing form has to be assigned to the property

templateSource of the UI element.

2. After having pressed Enter , a popup appears asking you whether a context

structure fitting the form's interface has to be created.

3. If you choose Yes, then a new node having the name of the form will be

created in the view's context. The property dataSource is bound to this

node automatically.

4. If you choose No, you have to assign a context node to the property

dataSource. The context structure has to fit exactly to the form's interface.

Figure 142: InteractiveForm: Print scenario - assign existing form

Hint: This approach allows to use forms having interfaces of all possible

types (based on the ABAP Dictionary, a Smart Form document's interface,

or an XML schema).





It is also possible to create a new form together with the related form interface

using forward navigation:

1. The name of a form (that does not exist yet) has to be assigned to the property

templateSource of the UI element.

2. After having pressed Enter , a popup appears asking you for the name of the

form interface. Enter the name of an existing form interface or enter the

name of the form interface to be created.

3. A button labeled Context allows to select the context node containing the

data to be transported to the form. Press this button, mark a context node

and choose Enter .

4. Form and form interface are created automatically and the form will

be opened for editing in the Layout Designer . In addition the context

node chosen in step 3 will be assigned to the property dataSource of the InteractiveForm UI element.

5. Now the layout of the form can be defined.

Hint: The form interface created by forward navigation will be based on

an XML schema that is generated from the structure of the context node

chosen in step 3.

The form created by forward navigation will have the layout type

unknown.

Figure 143: InteractiveForm: Print scenario - create and assign a new form





Let's consider the case that the data to be interchanged between Web Dynpro and

form does change. In this case both, the context of the Web Dynpro view and the

form interface definition have to be adapted. This is performed as follows:

First the relevant Web Dynpro context has to be adjusted. Next, the Form Builder

has to be opened by double-clicking on the template's name (assigned to the

property templateSource of the InteractiveForm UI Element). The system detects

the context changes and adjusts the XML schema, together with the data view in

Form Builder automatically.

Hint: Updating the interface definition of the form is only possible if the

form interface is based on a generated XML schema.

Interactive Scenario

Figure 144: InteractiveForm: Interactive scenario





For this kind of scenario, the following changes in respect to the print scenario

have to be conducted:

1. The layout type of the form has to be ZCI (Zero Client Installation) or xACF

(Active Component Framework).

To change the layout type of an existing interactive form from any type

to ZCI, the form has to be updated. This is done by use of transaction

SFP_ZCI_UPDATE. The changes can only be applied to activated forms.

2. To enable ZCI for forms embedded in Web Dynpro views, the forms must

contain special scripting. The developer has to embed this scripting. This is

done by editing the form in the Form Builder (SE80) and selecting Utilities

→ Insert Web Dynpro Scripting .

3. For forms having the layout type ZCI, elements defined in the Web Dynpro

Native Library have to be used to create the form's layout.

4. The property enabled of the UI element InteractiveForm has to set to

ABAP_TRUE . Now, the property readOnly can be used to enable / disable all

editable form fields.

5. The property displayType of the UI element InteractiveForm has to be set to

native (ZCI forms) or activeX (ACF forms).

6. The data entered by the user are transported to the corresponding context

structure automatically. However, it is also possible to access the XML

representation of the data entered by the user. For this purpose, the property

pdfSource has to be bound to an attribute of type XSTRING. After having

submitted a form, this attribute will contain the user input in XML format.

Hint: The attribute bound to property pdfSource must not be defined

in the context structure bound to property dataSource.





Figure 145: InteractiveForm: Interactive scenario - special form settings





Figure 146: InteractiveForm: Interactive scenario - defining the UI and data

binding

Hint: SAP recommends strongly to use forms having the layout type ZCI

and form interfaces which are based on a generated XML schema.

Hint: The development and usage of interactive forms having the layout

type ZCI requires:

The Adobe Reader Version 7.x with x >= 08 being installed on the user

PC (Version 8.1 if protocol HTTPs is used).

The Adobe Designer, version 7.1 SPS 1 being installed on the developer

PC (only this SPS is possible).

The SAP GUI release 6.40 patch level 20 being installed on the developer

PC.

After having changed the value of the form fields, these values have to be

submitted to the context of the Web Dynpro view.

This functionality can be offered by a submit button defined in the form. For

forms of layout type ZCI, this has to be a submit button defined in the Web

Dynpro Native Library. If this button is clicked, the event Submit related to the





UI element InteractiveForm is triggered. If an action is assigned to the related

property onSubmit , then the related action handler method is processed. Input

checks can then be performed as usual.

However, the element used to submit the form can also be a UI element (e.g.

Button, LinkToAction) defined in the UI element hierarchy of the view.

Accessing the Controls Functionality programmatically

It is possible to access a number of functions related to the form from the

source code of the view controller embedding the form. This is possible by

calling methods provided by the UI element's method handler. Details about

determining the reference to the UI element's method handler can be found in the

lesson about the Table UI element (filtering, sorting) or in the section about the

OfficeIntegration UI element (expert mode). The method handler functionality

available for the InteractiveForm UI element is described by the interface

IF_WD_IACTIVE_FORM_METHOD_HNDL.

Integrating Office Documents

Office documents of type Microsoft Word and Microsoft Excel can be embedded

in Web Dynpro views by means of the OfficeControl UI element. At runtime, the

office document is made accessible by an ActiveX control. Thus, this technique

requires the activation of ActiveX controls in the browser settings.

Hint: The integration of the OfficeControl UI element in Web DynproABAP pop-ups is not supported.

Without having to add any code, the OfficeControl UI element allows to create,

open, save and close office documents of the appropriate type ( non expert mode).

Hint: Keep in mind that saving a document means updating the value of

the corresponding context attribute.





Figure 147: OfficeControl: Standard mode

Additional functionality can be accessed if the expert mode is switched on. In

this case, the control settings can be manipulated programmatically. In addition

meta informations supported by the control can be read and changed. However,this also means that the control does not create, open, close, or save documents

automatically any more. Switching to the expert mode means that the complete

functionality offered by the control has to be triggered programmatically.

Hint: Saving the document can still be triggered via the save functionality

offered by the control.





Figure 148: OfficeControl: Expert mode


It is not mandatory to define any context elements related to the OfficeControl

UI element.

Defining the UI and Data Binding

The OfficeControl UI element can be added to any container UI element as a sub


The value of the property activateInPlace decides whether the control will be

embedded in the browser page ( ABAP_TRUE ) or if the related office application

is started and the document is displayed by this application ( ABAP_FALSE ).

If the document is displayed by the application, then the complete application

functionality is available. However, changes of the document can only be stored

locally.To be able to define the document to be displayed programmatically, the property

dataSource should be bound to a context attribute of type XSTRING.

The name of the document is defined by the property documentName. This

property can be bound to a context attribute of type STRING.

documentType defines the type of document that may be displayed by the control.

Allowed values are ms_word , ms_excel , star_writer , and star_calc.





The property enableReadWrite is deprecated and should thus not be used any

more. The value of property showDecoration has no impact on the result.

To switch on the expert mode, the property expertMode has to be set to

ABAP_TRUE .

The size of the control area can be defined by setting the properties height and

width accordingly (percent or pixels).

The property visible is used to display / hide the control.

Hint: In the standard mode, the document is closed automatically if

visible is set to none. Changes that have not been saved yet get lost.

In addition, a new document is created if the data source attribute contains

in invalid value or if the value is initial.

Hint: The OfficeControl UI element is only active when the visible

property is set to visible. Setting height and width to 0 does not deactivate

the control.

Figure 149: OfficeControl: Defining the UI and data binding





Figure 150: OfficeControl: Standard mode - creating a new document

Events

The OfficeControl UI element supports two events, Close and Save. For

documents being displayed in the standard mode, these events are triggered as

follows:

To replace the document displayed by the UI element, the value of the data source

attribute has to be changed by the application. The information about the next

document to be displayed is transported to the control with the next response. Next,

the control checks, whether the document to be replaced has been changed or not.

If the document has not been changed, the control closes the document and fires

the event Close. A new round trip to the server - triggered by the control - occurs.

Again, the information about the next document to be displayed is transported

back to the control. This time the control opens the new document.





Figure 151: OfficeControl: Standard mode - replacing an unchanged

document

If the document has been changed, but the user forgot to save the document using

the control's save functionality, the control saves the document automatically. Next, the control fires the event Save. The related request contains the saved

version of the document actually displayed. This version of the document is then

saved in the context. As a result the saved version of the document is displayed

again.





Figure 152: OfficeControl: Standard mode - trying to replace an unsaved

document

If the document has been changed and the user has saved the document the process

is identical to replacing an unchanged document.

If the user saves a document via the control's save functionality, the behavior does

not depend on the mode. In the standard and in the expert mode the control fires

the event Save. The actualized version of the document is subsequently stored in

the related context attribute.





Figure 153: OfficeControl: Standard mode / Expert mode - saving a changed

document

For documents being displayed in the expert mode, the application has to instruct

the control to open, close, save, or create a document. A new document can only

be loaded if the document actually displayed has been closed before.

If the application advises the control to close an unchanged or saved document,

the control closes the document and it fires the event Close.

If the application advises the control to close an unsaved document, the control

saves the document before closing it. In addition the control fires the event Save.

After having loaded a document, changes in respect to the data source attribute

content do not affect the document displayed by the control.

If actions have been assigned to the related UI properties onClose and onSave,

the application can react on these events. Besides the id of the OfficeControl UI

element, no information can be extracted from the interface parameter WDEVENT .





Accessing the Control Functionality in Expert Mode

To switch on the expert mode, the property expertMode has to be set

to ABAP_TRUE . In order to be able to access the control's functionality

programmatically, the reference to the method handler of the OfficeControl UI

element has to be determined. This is done as follows:

1. In the hook method WDDOMODIFYVIEW( ), the reference to the

OfficeControl UI element has to be determined.

2. The public attribute _METHOD_HANDLER of this UI element reference has

to be casted to the an interface reference variable of type IF_IOS_FACTORY .

3. IF_IOS_FACTORY provides methods to create proxy classes describing the

documents functionality and the control environment and methods to change

the document settings. These methods have to be accessible in different

methods of the view controller. Thus, the interface reference obtained in thelast step should be stored as a controller attribute.

4. Opening, closing, creating or saving a document in the expert mode is only

possible via a proxy object that describes the document actually displayed

by the control. The reference to this object is derived from the method

handler by calling the method GET_DOCUMENT_PROXY( ). This method

returns a reference variable of type IF_IOS_DOCUMENT . For performance

reasons, this reference should only be determined once and the result should

be stored as a controller attribute.

5. The control environmental can be accessed via a document proxy of type

IF_IOS_ENVIRONMENT . The reference to this object is derived from

the method handler by calling the method GET_ENVIRONMENT( ). For performance reasons, this reference should only be determined once and the

result should be stored as a controller attribute.

6. In addition, the interface IF_IOS_FACTORY contains methods to create

special proxys for Microsoft Word and Microsoft Office documents and

methods to set document properties.





Figure 154: OfficeControl: Expert mode - get reference to method handler

Figure 155: OfficeControl: Expert mode - get reference to document proxy





Figure 156: OfficeControl: Expert mode - trigger control functions / store

document

Integrating BI Web Templates based on BEx Web

Applications

Web Templates that are based on BEx Web Applications can be embedded in Web

Dynpro applications by means of the BIApplicationFrame UI element. Various

attributes can be set for a Web template. When using the BIApplicationFrame UI

element, these parameters are set as properties of the UI element.

Technically, the Web Template is integrated using an iFrame in the generated

HTML page. Thus, the Web Template is accessed by sending an extra

HTTP-Request and the parameters are passed as a query string.





Figure 157: BIApplicationFrame


It is not mandatory to define any context elements related to the

BIApplicationFrame UI element.

Defining the UI and data binding

The BIApplicationFrame UI element can be defined as a sub element of any

container UI element. There are no aggregations for the BIApplicationFrame.

Most of the UI element properties are related to parameters of the Web Template.

These parameters will not be discussed here since they require a deeper knowledge

of the BI technology. The following parameters belong to this category:

dataMode, dataProviderStateName, dataProviderStateType, debug , meltVariables,

sessionId , stateless, suppressSystemMessages, suppressWarnings, templateId ,

URL, usePersonalization, variablesClear , variableScreen, and variant .

Web Dynpro specific UI element properties allow to set the width (width) and

the height (height ) occupied by the UI element. The value of property enabled

does not affect the result, visible can be used to toggle the visibility. Finally, the

property server is used to define the host name and port of the server that offers

the Web Template. The value has to be defined according to the following pattern:

<host>.<domain>:<port>. The URL that is created from this value depends on

the server type offering the Web Template. Thus, the property serverType has to

be set to ABAP or Java.





Accessing the Web Template Functionality programmatically

It is possible to access a number of functions related to the Web Template from

the source code of the view controller embedding the Web Template. This is

possible by methods provided by the UI element's method handler. Details about

determining the reference to the UI element's method handler can be found in the

section about the Table UI element (filtering, sorting) or in the section about the

OfficeIntegration UI element (expert mode). The method handler functionality

available for the BIApplicationFrame UI element is described by the interface

IF_WD_BI_APPLFRAME_METHOD_HNDL.





Lesson Summary

You should now be able to:• Embed forms (in the context of SAP Interactive Forms by Adobe) and static









Unit Summary NET312

Unit Summary








Related Information






found in the sub section named Integration Category.


ABAP demo applications are contained. Demos dealing with UI elements in


Special demos dealing with the integration of PDF documents or SAP

interactive forms by Adobe begin with WDR_TEST_ADOBE.

Special demos dealing with the integration of office documents begin with

IOS_TEST .




NET312 Course Summary

Course Summary


• Use the complete functionality of the complex UI elements DateNavigator,

PhaseIndicator, RoadMap, TableView, and Tree

• Define the layout using the UI elements ContextualPanel,

HorizontalContextualPanel, NavigationList, MultiPane, and TabStrip

• Define graphics based on the UI elements BusinessGraphics, GeoMap,

ValueComparison, and ProgressIndicator

• Integrate other technologies using the UI elements Interactive Form,

BIApplicationFrame, OfficeControl, and FileUpload




Course Summary NET312




Index

AActions, 10Active Component

Framework (ACF), 261

BBIApplicationFrame, 284BusinessGraphics, 217

Chart Designer , 227Chart types, 217Context, 218Context - simplifications,

220UI definition, 222UI definition -

simplifications, 224

C

Chart Designer , 227Container elements, 4Context binding, 6Context change log, 118Context paging, 48, 85ContextualPanel, 42

DData binding, 6DateNavigator , 187Dynamically changing the UI,

14

EEvents, 10

FFileUpload, 265FreeContextualArea, 44

GGeoMap, 238

Defining geo objects, 241

HHorizontalContextualPanel,

38Context, 38

IIGS, 216InteractiveForm, 260

Interactive scenario, 271Offline scenario, 263Print scenario, 267Scenarios, 262

Internet Graphics Service(IGS), 216

IntroductionActions, 10Container elements, 4Context binding, 6

Data binding, 6Dynamically changing the

UI, 14Events, 10Layout managers, 5UI element hierarchy, 2WdDoModifyView, 16

LLayout managers, 5

M

MultiPane, 45Context paging, 48

N NavigationList, 33

Context, 33

OOfficeControl, 274

Expert mode, 275




Index NET312

Expert mode functionality,282

Standard mode, 274PPhaseIndicator , 193ProgressIndicator , 243

RRecursion node, 33, 38, 170RoadMap, 196

SSAP Interactive Forms by

Adobe, 260

TTable, 79

Colors, 114Context change log, 118Context paging, 85Design, 83Editable, 116Editable - Context change

log, 118Editable - Input checks,

117Filter data sets, 95Grouping columns, 92Grouping rows, 92Header , 90Hierarchical, 130Horizontal scrolling, 86Popins, 106Row selection, 88Sort data sets, 100Toolbar , 90Totals and subtotals, 121

Vertical scrolling, 85TabStrip, 51Tray, 54Tree, 159

containing leafs, 162

containing leaf s and subnodes, 163

containing recursivelyrepeated structures, 170

Tree Table, 130

UUI element hierarchy, 2UI elements

BIApplicationFrame, 284BusinessGraphics, 217ContextualPanel, 42DateNavigator , 187FileUpload, 265

FreeContextualArea, 44GeoMap, 238HorizontalContextual-

Panel, 38InteractiveForm, 260MultiPane, 45

NavigationList, 33OfficeControl, 274PhaseIndicator , 193ProgressIndicator , 243RoadMap, 196

Table, 79TabStrip, 51Tray, 54Tree, 159ValueComparison, 245ViewSwitch, 44

VValueComparison, 245ViewSwitch, 44

W

WdDoModifyView, 16ZZero Client Installation (ZCI),

261




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.