NET312- UI Dev with WebDynpro for ABAP

NET312NET312: UI Development with Web

Dynpro for ABAPSAP NetWeaver

Date

Training Center

Instructors

Education Website

Participant HandbookCourse Version: 62Course 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 changedwithout prior notice.

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

Trademarks

� Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® areregistered trademarks of Microsoft Corporation.

� IBM®, DB2®, OS/2®, DB2/6000®, Parallel Sysplex®, MVS/ESA®, RS/6000®, AIX®,S/390®, AS/400®, OS/390®, and OS/400® are registered trademarks of IBM Corporation.

� ORACLE® is a registered trademark of ORACLE Corporation.� INFORMIX®-OnLine for SAP and INFORMIX® Dynamic ServerTM are registered

trademarks of Informix Software Incorporated.� UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group.� Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®,

VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarksof Citrix Systems, Inc.

� HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, WorldWide Web Consortium, Massachusetts Institute of Technology.

� JAVA® is a registered trademark of Sun Microsystems, Inc.� JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used under license for

technology invented and implemented by Netscape.� SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP

EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.comare trademarks or registered trademarks of SAP AG in Germany and in several other countriesall over the world. All other products mentioned are trademarks or registered trademarks oftheir respective companies.

Disclaimer

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

g200832833223

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

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

Type Style Description

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

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

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

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

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

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

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

2008 © 2008 SAP AG. All rights reserved. iii

About This Handbook NET312

Icons in Body TextThe following icons are used in this handbook.

Icon Meaning

For more information, tips, or background

Note or further explanation of previous point

Exception or caution

Procedures

Indicates that the item is displayed in the instructor'spresentation.

iv © 2008 SAP AG. All rights reserved. 2008

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

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

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

Unit 2: Forming the Layout ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31UI Elements used to define the Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Unit 3: Complex UI Elements... .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77The Table UI Element .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79The Tree UI Element ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159Additional complex UI Elements .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .187

Unit 4: Defining Graphics ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215The BusinessGraphics UI Element ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . .216Additional 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

Contents NET312

vi © 2008 SAP AG. All rights reserved. 2008

Course OverviewThis course explains in detail how to implement user interfaces (UIs) based onWeb Dynpro for ABAP. This includes the creation of a view's layout based on theUI element library provided with Web Dynpro for ABAP, the definition of therelated view context and the discussion of the UI element specific events.

Target AudienceThis course is intended for the following audiences:

� Developers of applications based on Web Dynpro for ABAP

Course PrerequisitesRequired Knowledge

� Web Dynpro for ABAP (NET310)

Recommended Knowledge

� It is preferable, if you have created some Web Dynpro for ABAP applicationsbefore you attend this class

Course GoalsThis course will prepare you to:

� Implement complex UIs based on Web Dynpro for ABAP

Course ObjectivesAfter 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 OverviewIn this unit, the basics about the UI creation with Web Dynpro for ABAP - asdiscussed in NET310 - are summed up.

Unit ObjectivesAfter 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 ContentsLesson: Introduction .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

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

2008 © 2008 SAP AG. All rights reserved. 1

Unit 1: Introduction NET312

Lesson: Introduction

Lesson OverviewThis lesson sums up the basic concepts related to the definition of the userinterface (UI). This includes the definition of the UI element hierarchy, definingthe UI element's properties, binding the properties to context attributes, and usingthe UI element's events.

Lesson ObjectivesAfter completing this lesson, 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

Business ExampleBefore you can start to create sophisticated UIs with Web Dynpro for ABAP, youhave to recall the basic knowledge about the definition of a view's UI elementhierarchy. You have attended the class NET310 and you remember that yourtrainer has explained all of this to you. However, that's long ago so it is good tohave a summary to look up the main topics.

Defining the UI Element HierarchyThe layout of a view consists of UI elements that are defined in a hierarchicalstructure called the UI element hierarchy. At runtime, the single UI elements arerepresented by instances of globally defined classes that describe the properties ofthe corresponding UI element. This allows to define or change the UI elementhierarchy not only statically at design time but also programmatically at runtime.

There are different types of UI elements: Some of the elements may havedependent 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 thelayout of the corresponding view. New elements can be added by drag them fromthe 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 rightmouse click on the parent element in the UI element hierarchy (displayed in theright 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 - theROOTUIELEMENTCONTAINER. This is the root for the complete UI elementhierarchy.

Container Elements and Layout ManagersContainer elements are used to arrange UI elements in a rectangular sub area ofthe view's layout. The kind of arrangement is defined by the layout manager thathas been assigned to the container element. The layout manager defines how thesub elements of the container are arranged in the rectangular area defined bythe container element.

Container elements can be nested. This means, that in a certain sub area of asurrounding 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 atransparent 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 itcontains a caption. However, in addition a menu can be assigned to thegroup. 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 shouldbe used.

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

� FlowLayout:

A FlowLayout sequentially arranges the container children. Line breaks cannot be defined.

� RowLayout:

A RowLayout sequentially arranges the container children to exactly onecolumn. Line breaks can be defined by assigning a RowHeadData object to acertain 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 automaticallyinserted when the number of columns occupied by a UI element is larger thenthe 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 bedefined by assigning a MatrixHeadData object to a certain UI element.

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



Figure 3: Layout managers - MatrixLayout

Defining UI Element Properties statically and dynamicallyIf the developer clicks on an element in the View Area or in the UI elementhierarchy, the element's properties are displayed in the lower right corner of theWeb Application Designer. UI element properties can be set statically by enteringan allowed value in the input field right of the property's name. If only predefinedvalues may be assigned to a UI element property, a value selector or a check boxappears 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 elementproperties at runtime. Most of the properties related to a UI element may bebound to a context attribute being defined in the view's context and being typedaccordingly. Properties that can be bound to context attributes have a buttondisplayed right of the property's value field. To define or change the bindingbetween a property and a context attribute, the button has to be pressed. In thedialog popping up, the corresponding context attribute has to be marked and thedialog has to be finished by pressing Enter. The binding can be deleted by openingthe 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 keyproperty (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 toa 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 propertiesenabled, 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 anadditional radio button group consisting of two radio buttons. If the upper radiobutton is selected, a direct data binding is established. This corresponds to thesituation up to ABAP SPS 11. However, by selecting the lower radio button, theproperties enabled, visible, readOnly, and state can be bound to the correspondingcontext attribute properties, respectively.



Figure 8: Code sample: Setting context attribute properties for SAP NW AS7.0 (ABAP SPS ≥ 12)

Hint: The object describing a context element at runtime contains aninstance attribute for each context attribute defined in a context node.

For ABAP SPS 12 and higher, the object contains additional instanceattributes: For each context attribute the object contains four booleaninstance attributes, the UI element properties enabled, readOnly, state,and visible may be bound to.

To read or set these additional attributes, new methods havebeen created in the interface IF_WD_CONTEXT_NODE,namely GET_ATTRIBUTE_PROPS_FOR_ELEM(), SET_ATTRIBUTE_PROPS_FOR_ELEM( ), andSET_ATTRIBUTE_PROPERTY( ).

UI Element EventsSome UI elements support client side eventing. Typically, such a client side eventis 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, clickingon the related icons to scroll, clicking on the column header to sort, clicking onthe filter icon to filter).



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

To handle the client side event, the application has to provide an appropriate eventhandler 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 isgenerated 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 theaction'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 isprocessed. Depending on the UI element, additional information about the laststate of the UI element is passed to the action handler method. This information isaccessible via the method's interface parameter WDEVENT. This parameter ispredefined 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 ofthe 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 thevalue field is generic (TYPE REF TO DATA). Thus, before a value of a certainevent parameter can be accessed, it has to be casted to a variable of the correcttype. If the correct type is a classical data type, this can be done by de-referencingthe reference variable into a field symbol using the addition CASTING (for typedfield 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 passedas an object to the event handler method. In this case, the table PARAMETERScontains a reference to an object references in the VALUE column. Then the WebDynpro runtime types the reference variables with dynamically generated typesthat are not compatible with statically available reference types defined in theclass builder. Thus a different way of de-referencing the variable value into afield symbol has to be used:

At runtime, the type of a variable can be described by an object using RTTI (runtime type information). On the other side, a RTTI type description can be usedto type variables using the addition TYPE HANDLE TO. This addition can also



be used when de-referencing a reference variable into a generically typed fieldsymbol (CASTING TYPE HANDLE TO). Thus, accessing the event parametersinvolves the following steps:

� First the dynamically created reference type of an event parameter isobtained 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 theaddition CASTING TYPE HANDLE TO <RTTI_TYPE>.

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

Hint: The procedure described above can be omitted for statically knownparameters related to the event. In this case the parameter's names (withtheir appropriate types) can be added to the action handler's interface. Atruntime, the Web Dynpro runtime does not only fill the PARAMETERStable of the interface parameter WDEVENT, but also all additionallydefined interface parameters having a name that is identical to an eventparameter.

Caution: The interface of the action handler must not contain anyparameter having a name that is different from the event parameter names.This will lead to a dump at runtime.

Dynamically changing the UIEach UI element of type <UI_ELEMENT_TYPE> (e.g. Button) is described by aglobally defined class having the name CL_WD_<UI_ELEMENT_TYPE> (e.g.CL_WD_BUTTON). The properties of any UI element are defined as instanceattributes of the related global class. All element classes are part of an inheritancetree having the class CL_WDR_VIEW_ELEMENT as its root. This root classimplements 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 elementhierarchy are instantiated. The values of the UI element properties are stored asinstance attributes of the runtime objects and the hierarchy itself is reflected bydependencies 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 relatedto a view's layout from the controller methodWDDOMODIFYVIEW( ) of thisview. The signature of this method contains the importing parameter VIEW.Calling the method GET_ELEMENT( ID = <ID> ) for this reference variablereturns the reference to the runtime object related to the UI element havingthe id <ID>. This returning parameter is typed generically (TYPE REF TOIF_WD_VIEW_ELEMENT), so calling this method is possible for all UI elementtypes. However, in order to access the attributes specific for a certain UI elementtype, the generically typed reference has to be casted to a reference variable havingthe 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 setthe values of all possible element properties. Additional methods can be usedto establish the context binding for a certain element property by providing thecontext 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 thisassignment. Thus, calling these methods for the runtime object related to a certainUI element allows to change the UI element properties - even if these propertiesare not bound to context attributes.



Figure 15: Functionality typically available for UI elements

Hint: Context binding is the preferred way to allow changing UI elementproperties at runtime. Changing UI element properties by accessing theruntime object representing the UI element directly should be restrictedto properties that are not bindable.

It is also possible to delete existing UI elements from the UI element hierarchy orto add new UI elements to the UI element hierarchy at runtime:

To delete an existing UI element from the UI element hierarchy, the followingsteps are necessary:

� First, the reference to the parent element of the UI element to be deletedhas to be determined.

� This object contains methods beginning with REMOVE_...( ) which can becalled 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, thefollowing steps are necessary:

� First of all, an instance of the class representing the UI element has to becreated. For this purpose, each UI element class contains a static methodNEW_<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 DynproApplication

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

application.

Business ExampleYou have to create a Web Dynpro application having a sophisticated UI. You knowthe Web Dynpro basics since you have taken the class NET310. Thus you begin tocreate the basic parts of the application. The exercises of the following lessonswill extend this application step by step.

The basic application displays an empty table and a button. After having pressedthe 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 todevelop.

1. Create the package ZNET312_##. Assign the application componentBC-WD, the software component HOME, and a short description.

A transport request has been created by your trainer.

Task 2:Create a Web Dynpro component, having one window and a single view embeddedin this window.

1. Create the Web Dynpro component ZNET312_INTR_## with a windowMAIN_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 theattributes of one flight.

In addition, create a method containing the code for reading the flights from thedata base and saving the flight data in the context.

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

2. Create the ordinary method GET_FLIGHTS( ). Add two optional importparameters (IV_CARRID of type S_CARR_ID and IV_CONNID of typeS_CONN_ID) to the method's interface to allow submitting the connectionkey.

In the source code, pass the connection key to the static methodREAD_FLIGHTS( ) defined in class CL_NET310_FLIGHTMODEL. Thismethod 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 importparameters. In this case, the static method READ_FLIGHTS( ) willread all flights that are stored in the data base table SFLIGHT.

Task 4:Copy the node FLIGHTS from the component controller context to the contextof 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 thecontent of the context FLIGHTS. In addition, define a button in the layout. Ifthis button is pressed, all flights should be read and stored in the context nodeFLIGHTS. Finally, optimize the layout.

1. Copy the node FLIGHTS from the component controller context to thecontext of view MAIN_VIEW and define the context mapping between thenodes.

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

3. Define a button in the layout. If this button is pressed, all flights should beread 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 DynproApplicationTask 1:Create a package that will contain all the repository objects you are going todevelop.

1. Create the package ZNET312_##. Assign the application componentBC-WD, the software component HOME, and a short description.

A transport request has been created by your trainer.

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

Task 2:Create a Web Dynpro component, having one window and a single view embeddedin this window.

1. Create the Web Dynpro component ZNET312_INTR_## with a windowMAIN_WINDOW and a view MAIN_VIEW.

a) In the navigation area of the ABAP Workbench, open the context menufor the package and choose Create→ WebDynpro→ WebDynproComponent (Interface).

b) In the dialog box, enter the name of the component, a description, thename 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 theattributes of one flight.

In addition, create a method containing the code for reading the flights from thedata base and saving the flight data in the context.

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

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 attributesCARRID, CONNID, FLDATE, PRICE, CURRENCY, PLANETYPE,SEATSMAX, and SEATSOCC.

e) Finish the dialog.

2. Create the ordinary method GET_FLIGHTS( ). Add two optional importparameters (IV_CARRID of type S_CARR_ID and IV_CONNID of typeS_CONN_ID) to the method's interface to allow submitting the connectionkey.




In the source code, pass the connection key to the static methodREAD_FLIGHTS( ) defined in class CL_NET310_FLIGHTMODEL. Thismethod 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 importparameters. In this case, the static method READ_FLIGHTS( ) willread all flights that are stored in the data base table SFLIGHT.

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

b) Enter the parameter names in the column Parameter and choose Type =Importing for both parameters. Enter Associated Type = S_CARR_IDand S_CONN_ID, respectively. Don't forget to mark the check box inthe 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 contextof 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 thecontent of the context FLIGHTS. In addition, define a button in the layout. Ifthis button is pressed, all flights should be read and stored in the context nodeFLIGHTS. Finally, optimize the layout.

1. Copy the node FLIGHTS from the component controller context to thecontext of view MAIN_VIEW and define the context mapping between thenodes.

a) Edit the context of view MAIN_VIEW.

b) Drag the node FLIGHTS from the component controller context anddrop it on the root node of the view controller context. This copies thecontext 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 WebDynpro Code Wizard to create a table displaying the content of nodeFLIGHTS.




3. Define a button in the layout. If this button is pressed, all flights should beread and stored in the context node FLIGHTS

a) Mark the ROOTUIELEMENTCONTAINER UI element in the layout ofview MAIN_VIEW.

b) Click the right mouse button to open the context menu. Select thecontext 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 thebutton 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: Callthe method GET_FLIGHTS( ) defined in the component controller.Do not export values for the interface parameters IV_CARRID andIV_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→ WebDynpro Application to create a Web Dynpro application having thename 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� Set UI element properties� Bind UI element properties to context attributes� Handle UI element events� Create and change UI element properties dynamically


Unit Summary NET312

Unit SummaryYou should now 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

Related Information

� The online documentation for SAP NetWeaver 7.0 contains an excellentsection about developing applications based on Web Dynpro ABAP.Having opened the online documentation for SAP NetWeaver 7.0 athttp://help.sap.com, enter the search term Web Dynpro ABAP. This will opena list of links pointing to the Web Dynpro section of the documentation.

� In each SAP system based on SAP NetWeaver 7.0, standard Web DynproABAP demo applications are available. The corresponding Web Dynprocomponents begin with the literal WDR_TEST, DEMO, or WDT.


http://help.sap.com

Unit 2Forming the Layout

Unit OverviewThis unit deals with UI elements that are used to structure the view's layout.The container elements Group and TransparentContainer are not discussed heresince these elements are considered to be known from NET310, the antecessorof this course.


� Implement the following UI elements: ContextualPanel,HorizontalContextualPanel, NavigationList, MultiPane, TabStrip, Tray

Unit ContentsLesson: UI Elements used to define the Layout .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

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


Unit 2: Forming the Layout NET312

Lesson: UI Elements used to define the Layout

Lesson OverviewIn this lesson, UI elements to define the layout of a view are discussed. Thisincludes the NavigationList, the ContextualPanel, the HorizontalContextualPanel,the MultiPane, the Tabstrip, and the Tray.


� Implement the following UI elements: ContextualPanel,HorizontalContextualPanel, NavigationList, MultiPane, TabStrip, Tray

Business ExampleYou would like to implement the UI elements listed above. The implementationof the basic features is feasible. However, you want to explore the completefunctionality.

OverviewThe Web Dynpro UI element library contains a number of elements that can beused to form a view's layout. The most interesting elements are discussed in thislessen.

The NavigationList provides a navigation area. The navigation elements areorganized in a tree like structure.

The HorizontalContextualPanel provides a navigation area with a two levelnavigation hierarchy. Here, the navigation elements are horizontally arrangedas 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 UIelements), and ViewSwitches (which can be used to toggle between differentstates).

TheMultiPane 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 tobe displayed can be placed on different tab pages. The user can toggle betweenseveral tab pages by clicking on a specific tab.

Finally, the Tray is a container element like a Group. However, this elementallows to toggle the visibility of its content.


NET312 Lesson: UI Elements used to define the Layout

The NavigationListThe NavigationList allows to display hierarchical organized content by means ofa tree-like structure. However, this element does not allow to define nodes thatcan be expanded and collapsed like a Tree does. Elements defined in a certainhierarchy level are displayed intended in respect to the parent navigation list item.

Figure 16: NavigationList

Defining the ContextData to be displayed by a NavigationList have to be stored in a context node ofcardinality (0:n) or (1:n). This node has to be of type non-singleton. The elementsof this first level node contain the data of the first hierarchy level displayed by theNavigationList. At least two context attributes should be created in the first levelnode: One attribute to store the text displayed by the NavigationList, the secondattribute to store a key for this navigation list item. This allows to call relatedfunctionality when the user selects a certain list item.

To be able to store data for additional hierarchy levels, a recursion node has tobe defined as a sub node of the first level context node. This recursion node hasto repeat the first level node. At runtime, this allows to define a hierarchy ofcontext 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 RuntimeA recursion node allows to define a hierarchical context structure consisting ofidentical context nodes forming a tree. However, at runtime only the collection forthe first level context nodes serving as the parent node of the hierarchical contextstructure is created automatically. The source code to build up an additionalhierarchy level consists of the following steps:

� First, the reference to an element of the parent node collection has to bedetermined.

� 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 nameare generated in the local controller interface.

� If the collection related to 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 repeatedbut starting with an element existing in a previously defined collection relatedthe recursion node.



UI Element Definition and Data BindingTo display the content of the hierarchical data structure a NavigationList has tobe defined in the view's layout. The property itemSource has to be bound tothe parent node of the hierarchical context structure. The property itemText hasto be bound to the context attribute of the parent node containing the text to bedisplayed by the list item.

The property enabled has no influence on the generated list. However, theproperty 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 ofthe complete NavigationList can be toggled using the property visible. A tool tipcan be assigned to the NavigationList by setting the property tooltip accordingly.The height of the NavigationList is optimized automatically. However, an arbitraryheight can be defined setting the property contentHeight (in pixels). If the contentcan not displayed completely, a vertical scroll bar is displayed automatically.

Hint: The property visible can not be used to hide single list items butonly the complete NavigationList UI element.

Figure 19: NavigationList: Binding UI element properties



EventsThe NavigationList supports only one event having the name Select (propertyonSelect). This event is fired if the used clicks on a selectable list item. In therelated action handler method the following informations can be extracted fromthe 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, thedata key related to the list item can be determined, so dependent functionalitycan be triggered.

Figure 20: NavigationList: Handling the event Select

AggregationsA NavigationList may contain a sub element of type ExpandableTitle. Thiskind of element allows to display a title on top of the list. If the propertyexpandable is set to ABAP_TRUE, an additional icon is displayed in the titlethat allows to expand and collapse the complete list. In this case, the propertyexpanded 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 betweenthe collapsed and the expanded state. In the action handler method, the tableWDEVENT→PARAMETERS then contains the id of the ExpandableTitle (NAME= ID) and the last state (NAME = EXPANDED).



The HorizontalContextualPanelThe HorizontalContextualPanel displays content that is organized in a hierarchicalcontext structure with up to two levels. Each element belonging to the firstlevel of this hierarchical structure is displayed as a tab. All tabs are arrangedhorizontally. Each element of the first hierarchy level may have dependent datastored in a dependent collection in the context. If the tab related to such a first levelcontext element is selected, then the single elements of the dependent collectionare displayed as links arranged horizontally on the area below the tab row.

Figure 21: HorizontalContextualPanel

Defining the ContextInformation to be displayed by tabs of a HorizontalContextualPanel has tobe stored in a context node of cardinality (0:n) or (1:n). The elements of thisfirst level node contain the data of the first hierarchy level displayed by theHorizontalContextualPanel. At least two context attributes should be created inthe first level node: One attribute to store the text displayed by the tabs of theHorizontalContextualPanel, 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 recursionnode has to be defined as a sub node of the first level context node. This recursionnode has to repeat the first level node.



Caution: Make sure that the lead selection is always set for all collectionsrelated to the HorizontalContextualPanel. This is necessary, since the leadselection defines which of the tabs (first level hierarchy) and which of thelinks (second level hierarchy) is emphasized. If the lead selection is notset 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, thenthe 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 theUI element Navigation List.

Creating the hierarchical Context Structure at RuntimeThis has also been discussed in the section about the UI element Navigation List.

Hint: In contrast to the NavigationList UI element, the node hierarchy fora HorizontalContextualPanel may consist of a maximum of two nodes.



UI Element Definition and Data BindingTo 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 bebound to the first level node of the hierarchical context structure. The propertyitemText has to be bound to the context attribute of the first level node containingthe text to be displayed by the tabs.

The property itemEnabled defines, which of the tabs (first level hierarchy) andwhich of the links (second level hierarchy) is selectable. Non-selectable itemsappear grayed out.

Hint: This is different from the NavigationList UI element. For theNavigationList UI element it is not possible to gray out non-selectable listitems.

The property itemVisible defines, which of the tabs (first level hierarchy) andwhich of the links (second level hierarchy) are visible.

Hint: For the NavigationList UI element it is not possible to hideindividual list items.

The visibility of the complete HorizontalContextualPanel can be toggledusing the property visible. All tabs and all links can be disabled at once bysetting the property enabled to ABAP_FALSE. A tool tip can be assigned to theHorizontalContextualPanel by setting the property tooltip accordingly.



Figure 23: HorizontalContextualPanel: Binding UI element properties

EventsThe HorizontalContextualPanel supports only one event having the name Select(property onSelect). Handling the event and extracting event related informationis identical to the procedure described for the NavigationList UI element (seecorresponding section in this lesson).

In order to emphasize the tab or link the user has selected, the lead selection hasto be set accordingly. This is typically done in the action handler related to theevent Select.

Hint: Clicking on a tab or on a link does not set the lead selection in therelated collection automatically.



Figure 24: HorizontalContextualPanel: Setting lead selection to defineemphasized tab / link

AggregationsA HorizontalContextualPanel may not have sub elements.

The ContextualPanelThe ContextualPanel serves as a container for an arbitrary number of sub elementsbeing of type NavigationList, FreeContextualArea, or ViewSwitch. Details aboutsub element types will be discussed in the sub section Aggregations



Figure 25: ContextualPanel

Defining the ContextThe content displayed by a ContextualPanel is related to its sub elements. Thusno extra context nodes and context attributes related to this element type needto be defined.

UI Element Definition and Data BindingA ContextualPanel can be defined as a sub element of any container UI elementin the view's layout. From the context menu of this UI element, sub elements oftype NavigationList, FreeContextualArea, or ViewSwitch can be added to theUI element hierarchy.

The ContextualPanel has the properties enabled, tooltip, visible, and width.Setting enabled to ABAP_FALSE will disable the complete content defined bythe sub elements.

EventsThe ContextualPanel supports only one event having the name Personalize(property onPersonalize). This can be used to manipulate the content displayedby the UI element. There is no special information provided by the interfaceparameter WDEVENT.



AggregationsThe ContextualPanel has to contain at least one of the UI elements NavigationList,FreeContextualArea, or ViewSwitch as its sub element. If necessary, an arbitrarynumber of theses element types can be combined to form the content of theContextualPanel UI element.

The NavigationList UI element has been discussed in detail before.

The FreeContextualArea UI element can be used to display any Web DynproUI element in an expandable area that may also contain an ExpandableTitle.Details about the ExpandableTitle can be found in the sub section about theNavigationList. The only properties related to the FreeContextualArea itself arethe property design to change the background color of the UI element and theproperty contentHeight, to restrict the area height (in pixels). If this property is setto 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 ina context node of cardinality (0:n) or (1:n). The binding has to be defined byassigning the path to the context node to the UI element property itemSource. Thelead selection of this node determines, which of the switches is emphasized.

Caution: Make sure, that the lead selection is always set in the contextnode related to the ViewSwitch. If the lead selection is not set, theapplication will dump at runtime.



The context node should contain at least one attribute to define the text displayedby each switch (bound to the property itemText). In addition, each switch can beenabled / disabled (property itemEnabled has to be bound to context attributeof type WDY_BOOLEAN) and each switch can be displayed / hidden (propertyitemVisible has to be bound to context attribute of type WDY_BOOLEAN).

Figure 27: ViewSwitch

The ViewSwitch supports only one event having the name Select (propertyonSelect). Handling the event and extracting event related information is identicalto the procedure described for the NavigationList UI element (see correspondingsection in this lesson).

In order to emphasize the switch the user has clicked on, the lead selection hasto be set accordingly. This is typically done in the action handler related to theevent onSelect.

Hint: Clicking on a switch does not set the lead selection in the relatedcollection automatically.

The MultiPaneThe MultiPane UI element is used to order the content of a context node in theform of a grid. Thus, the MultiPane is an alternative to the Table for displayingmultiple congeneric data sets.



Each cell of the grid is described by sub elements of the MultiPane. All gridcells have the same structure.

Figure 28: MultiPane

Defining the ContextThe content to be displayed by a MultiPane has to be stored in a context node ofcardinality (0:n) or (1:n). Defining an filling the context is identical to the casethat the data has to be displayed by a Table UI element. However, the settings ofthe Lead Selection and the settings of the Selection property are irrelevant.

UI Element Definition and Data BindingThe MultiPane UI element can be defined as a sub element of any container UIelement. The path to the context node containing the data to be displayed has toassigned 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 propertiescolCount and rowCount, respectively. By default, one column is displayed, whilethe number of rows equals the number of context elements. If the number of datasets is larger then the number of visible grid cells, the paginator elements in thefooter 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 datasource contains no elements. footerVisible can be used to hide the line containingthe 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 andheight in pixels or percent, respectively. stretchHorizontally and stretchVerticallycan be used to spread the grid cells equally across the complete space occupiedby the MultiPane.

The property paneCount influences the number of rows, that are accessible byusing the paginator functionality of the MultiPane. If paneCount is set to a valuedifferent from the initial value (-1) and rowCount is set to its initial value (-1), thenthe 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 ofthe colCount property value. The value R is then displayed in the footer as themaximum 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 isdisplayed as the first data set visible in the MultiPane (offset).

Example: If the topmost data set displayed by the MultiPane should be related tothe context element with index 11, firstVisiblePane has to be set to 10.

Finally, firstActualPane, paneCount, and firstVisiblePane can be used toimplement a technique called context paging. This technique may be used if thenumber of potentially accessible data sets is very large. In this case it is possible tostore 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 thatadditional data sets are requested (user scrolls to data sets not loaded yet), so theseadditional data sets have to be copied to the context node.

The user of the application should get the information that more data sets arepotentially 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 maximumrow number displayed by the footer are related to the number of elements storedin the corresponding context node. This can be changed by setting the propertiesfirstActualPane, 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 beaccessible by the MultiPane. If the first data set stored in the context is not thefirst data set that could be accessible, firstActualPane has to be used to definethis offset. This parameter describes, which grid cell (pane) in the MultiPaneshould display the first element stored in the context. Finally, the parameterfirstVisiblePane 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 is200000. When initializing the controller, only the data sets with index 101 to 130are stored to the context. 5 rows are displayed in 1 column.

Without adjusting firstActualPane, paneCount, and firstVisiblePane, the footerof the MultiPane will indicate that data set 1 is displayed and 30 data sets maybe displayed. However, the footer should indicate that data set 101 is displayedand 200000 may be displayed.



Figure 30: MultiPane: Context paging not implemented

After having set paneCount to 200000, the footer displays that data set 1 isdisplayed 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 isdisplayed and 200000 data sets may be displayed. However, no pane is displayedyet. To display the first data set stored in the context, the user of the applicationhas to navigate to pane with index 101.

Thus, firstVisiblePane has to be set to any number between 100 and 125, in order tosee five data sets in parallel. If the first data set stored in the context should also bethe 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 datasets demanded by the user have already been stored in the context. If thisis not the case, additional data sets have to be copied to the context.

EventsThe 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 pagingicons displayed in the footer of the UI element. In the related action handlermethod the following informations can be extracted from the interface parameterWDEVENT:

The table WDEVENT→PARAMETERS contains the id of the MultiPane(NAME = ID). The index of the pane that was displayed in the first row andthe first column when the user fired the event is provided by the parameterOLD_FIRST_VISIBLE_PANE. The index of the pane that should be displayed inthe first row and the first column when the layout is rendered next time is providedby the parameter NEW_FIRST_VISIBLE_PANE.



Caution: If context paging is implemented, the application has to checkif all data sets demanded by the user have already been stored in thecontext. The indices of these data sets can be determined from the valuesof the parameter NEW_FIRST_VISIBLE_PANE and from the UI elementproperties rowCount and colCount:

� First context element to be displayed next time has indexNEW_FIRST_VISIBLE_PANE.

� Last visible context element to be displayed next time has indexNEW_FIRST_VISIBLE_PANE + row_count * colCount.

AggregationsTo display the content of a single context element in a pane, the UI elementMultiPane has to have sub elements defined in the UI element hierarchy. Onlyone direct sub element may be defined for the MultiPane. However, this is not arestriction since this sub element may be a container element.

The TabStripThe TabStrip UI element is used to display horizontally aligned tabs. The usercan toggle between several tab pages by clicking on a specific tab. The number oftabs defined in the application may be larger then the number of tabs displayedat runtime. In this case, additional navigation elements are activated in the rightupper corner of the rendered UI element. Clicking on these icons allows to displaythe 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 bethe selected tab.

On each tab page, an arbitrary combination of UI elements can be used to definethe layout.



Figure 32: TabStrip

Defining the ContextTabStrip UI elements do not contain properties that have to be bound to contextattributes. Thus, it is not obligatory to define TabStrip-related context nodes orcontext attributes.

UI Element Definition and Data BindingThe TabStrip UI element can be defined as a sub element of any container UIelement. For each tab, an element of type Tab has to be defined as a sub elementof the TabStrip. Finally, the content displayed on each tab is defined by creatingsub elements of the corresponding Tab UI element.

The complete TabStrip and all of its sub elements can be enabled / disabled usingthe parameter enabled. If enabled is set to ABAP_FALSE, the selected tab can notbe changed by the user at runtime. The visibility of the complete TabStrip can betoggled by setting the property visible accordingly.

The height and width of the TabStrip can be defined by setting the properties heightand width, respectively (in pixels or percent). If height and width are set to valuesthat do not allow to display the complete content of a given tab, then the size ofthe TabStrip will be optimized (being exactly large enough to display the completecontent). 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 selectedtab. This can be done by setting the parameter selectionChangeBehaviour to



manual (default value auto). In this context it is meaningful to bind the propertyselectedTab to a context attribute of type string. Then, the next selected tab can bedefined 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 heightof all tabs. However, this feature is not supported for browser based clients.

Figure 33: TabStrip: Binding UI element properties

EventsThe TabStrip UI element supports only one event having the name Select (propertyonSelect). This event is triggered if the user clicks on one of the tabs or if the userselects a menu entry from the navigation menu. This event is not triggered, if theuser navigates to the previous / next tab by clicking on the appropriate icon inthe right upper corner of the TabStrip. In the related action handler method thefollowing informations can be extracted from the interface parameterWDEVENT:

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 idof the tab the user has clicked on is provided by the parameter TAB.

AggregationsThe TabStrip UI element may contain as many tabs as desired. Each tab isdescribed by a Tab UI element, which has to be created as a direct sub element ofthe 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 beenabled / disabled (property enabled), and a padding between the content and thetab 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 displayedon the tab.

Each tab may also contain a ToolBar, which is displayed on top of the relatedtab page.

Finally, each tab may contain one sub element to display the content on thetab page. However, this is not a restriction, since this sub element may be acontainer element (having an arbitrary number of dependent elements) or aViewContainerUIElement (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 areahaving 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 TrayUI element can be expanded or collapsed.



Figure 35: Tray

Defining the ContextTray UI elements do not contain properties that have to be bound to contextattributes. Thus, it is not obligatory to define Tray-related context nodes or contextattributes.

UI Element Definition and Data BindingThe 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 theTray 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 settingthe parameter enabled accordingly. If enabled is set to ABAP_FALSE, not only thecontent defined in the Tray body is disabled, but also the icons in the upper rightcorner. Thus, the Tray may not be expanded / collapsed and no function may betriggered if the Tray is disabled. The visibility of the complete Tray can be toggledby setting the property visible accordingly.

Any Button UI element defined in the Tray body can be defined as the defaultbutton by assigning the button's ID to the property defaultButton. If the user clicksin the Tray, this button will get the focus. If the user presses Enter, the eventAction (property onAction) of the default button will be fired.

The property design allows to change the color of background and border linerelated to the Tray body.



The property expanded is used to define the state (expanded / collapsed) of theTray. This property is set automatically if the used clicks on the correspondingicon in the right upper corner of the rendered UI element.

A padding between the content and the tab border can be added / deleted be settingthe property hasContentPadding accordingly.

The height and width of the Tray can be defined by setting the properties heightand width, respectively (in pixels or percent).

Finally, the setting of the property scrolling Mode defines what happens if thewidth and height of the Tray is defined in a way that the Tray body is to small todisplay the complete content.

If scrolling Mode is set to none, the Tray body will have a minimum size beingexactly large enough to display the complete content. Trying to decrease thisminimum size by setting width or height to smaller values will not change thisminimum size. If scrolling Mode is set to both, scroll bars will always be visiblein the Tray body. This is independent from the actual size of the Tray. If scrollbars should only be displayed if the Tray body is too small for the content to bedisplayed, the property scrolling Mode has to be set to auto.

Figure 36: Tray: Binding UI element properties



EventsThe Tray UI element supports only one event having the name Toggle (propertyonToggle). This event is triggered if the user expands or collapses the Tray byclicking on the related icon in the right upper corner of the UI element. In therelated action handler method the following informations can be extracted fromthe 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 theboolean parameter EXPANDED.

AggregationsThe Tray UI element can contain the following sub elements:

The Tray has to have exactly one Caption containing the text and the imagedisplayed 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 menuentries. At runtime, an additional icon is then created left of the standard icon usedto 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 arestriction, since this sub element may be a container element (having an arbitrarynumber of dependent elements) or a ViewContainerUIElement (allowing to embedother views or interface views).



Figure 37: Tray: Sub elements



Exercise 2: Implementing a NavigationListUI Element

Exercise ObjectivesAfter completing this exercise, you will be able to:� Implement a NavigationList UI element.

Business ExampleYou would like to change your application as follows:

All connections should be displayed by a NavigationList UI element. If the userclicks 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 changescan be implemented in the component you have created in your last exercise.

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

1. Copy the template component.

2. Create an application to access your component.

Task 2:In the component controller of your component create a new non-singleton contextnode having the attributes TEXT, SELECTABLE, CARRID, and CONNID andhaving a sub node of type Recursion Node.

At runtime, this context structure will be populated with the information to bedisplayed 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 notinitialized.




2. Add the attributes TEXT (type STRING), SELECTABLE (typeWDY_BOOLEAN), CARRID (type S_CARR_ID), and CONNID (typeS_CONN_ID) to the context node NAVI_LIST

3. Create a recursion node (name: NAVI_REC_NODE) as a sub nodeof NAVI_LIST. The recursion node has to repeat the structure of nodeNAVI_LIST.

Task 3:Define the algorithm to read the connection information and store the date inthe context node NAVI_LIST.

The navigation list entries on the first level hierarchy should be non-selectableand they should display the carrier ids. The navigation list entries on the secondlevel 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 typeNET310_T_SPFLI. Implement the method:

Call the static method READ_CONNECTIONS( ) of classCL_NET310_FLIGHTMODEL. Pass the internal table returnedby this method to the caller by means of the returning parameterRT_CONNECTIONS.

2. Create another method in the component controller having the nameDEFINE_NAV_LIST( ). Implement the method:

Call the method GET_CONNECTIONS( ). This will return an internal tablewith 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 shouldnot 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 collectionNAVI_REC_NODE related to this carrier id.

Hint: Use method BIND_STRUCTURE( ) defined in interfaceIF_WD_CONTEXT_NODE to create a new context element in thenode NAVI_LIST. This method will return the reference to the newcontext element.

Hint: To access the node collection NAVI_REC_NODEcorresponding to a certain carrier id, start with the context elementrelated to this carrier and access to recursion node by calling themethod GET_CHILD_NODE( )

For all connections belonging to the same carrier id, add an element to therelated collection of recursion node NAVI_REC_NODE. Set the attributeSELECTABLE to ABAP_TRUE to allow clicking on the connection entries.For these elements, set CARRID and CONNID according to the actualconnection. Concatenate the connection id, the departure city and thedestination city and assign the result to the attribute TEXT.

3. Call the method DEFINE_NAV_LIST( ) from the hook methodWDDOINIT() of the component controller

Task 4:Display the content of the node NAVI_LIST by a NavigationList UI elementdefined in the layout of view MAIN_VIEW. The Layout should consist of aPageHeader UI element, displaying the text NET312 - Exercises on top of thepage. The NavigationList (having an expandable title) should be displayed belowthe page header on the left side of the page, the flight table should be displayedbelow the page header on the right side of the page.

1. Copy the node NAVI_LIST from the component controller to the viewMAIN_VIEW and define the context mapping between the nodes (mappingorigin: component controller context).

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

3. Define the navigation list in the view's layout. The navigation list shouldcover 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 FlightConnections.




5. Correct the properties of the Table UI element. The table has to be displayedright 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 shouldbe displayed by the table. The button can be deleted.

1. Delete the button in view MAIN_VIEW.

2. Assign the actionGET_DETAILS to the event SELECT of theNavigationListUI element.

3. Extend the source code of the action handler method. Add the parameterCONTEXT_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 navigationlist item.

Get the static attributes from this context element. Change the call of thecomponent controller method GET_FLIGHTS( ): Pass the connection keyto this method.



Solution 2: Implementing a NavigationListUI ElementTask 1:If you have finished the previous exercise, you can skip this task. Then, all changescan be implemented in the component you have created in your last exercise.



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

b) Adapt the description of the new component.


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




Task 2:In the component controller of your component create a new non-singleton contextnode having the attributes TEXT, SELECTABLE, CARRID, and CONNID andhaving a sub node of type Recursion Node.

At runtime, this context structure will be populated with the information to bedisplayed 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 notinitialized.

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

b) From the context menu of the root node choose Create→ Node. Enterthe 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 Singletonis not checked.

Make sure that the check box related to the node property InitializationLead Selection is not checked.

2. Add the attributes TEXT (type STRING), SELECTABLE (typeWDY_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 theentry Create→Attribute from the context menu of this node.

3. Create a recursion node (name: NAVI_REC_NODE) as a sub nodeof NAVI_LIST. The recursion node has to repeat the structure of nodeNAVI_LIST.

a) Select the entry Create→Recursion Node from the context menu ofnode NAVI_LIST.

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




Task 3:Define the algorithm to read the connection information and store the date inthe context node NAVI_LIST.

The navigation list entries on the first level hierarchy should be non-selectableand they should display the carrier ids. The navigation list entries on the secondlevel 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 typeNET310_T_SPFLI. Implement the method:

Call the static method READ_CONNECTIONS( ) of classCL_NET310_FLIGHTMODEL. Pass the internal table returnedby this method to the caller by means of the returning parameterRT_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_CONNECTIONSin 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 nameDEFINE_NAV_LIST( ). Implement the method:

Call the method GET_CONNECTIONS( ). This will return an internal tablewith 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 shouldnot 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 collectionNAVI_REC_NODE related to this carrier id.

Hint: Use method BIND_STRUCTURE( ) defined in interfaceIF_WD_CONTEXT_NODE to create a new context element in thenode NAVI_LIST. This method will return the reference to the newcontext element.

Hint: To access the node collection NAVI_REC_NODEcorresponding to a certain carrier id, start with the context elementrelated to this carrier and access to recursion node by calling themethod GET_CHILD_NODE( )

For all connections belonging to the same carrier id, add an element to therelated collection of recursion node NAVI_REC_NODE. Set the attributeSELECTABLE to ABAP_TRUE to allow clicking on the connection entries.For these elements, set CARRID and CONNID according to the actualconnection. Concatenate the connection id, the departure city and thedestination city and assign the result to the attribute TEXT.

a) Source code see below.

3. Call the method DEFINE_NAV_LIST( ) from the hook methodWDDOINIT() of the component controller


Task 4:Display the content of the node NAVI_LIST by a NavigationList UI elementdefined in the layout of view MAIN_VIEW. The Layout should consist of aPageHeader UI element, displaying the text NET312 - Exercises on top of thepage. The NavigationList (having an expandable title) should be displayed belowthe page header on the left side of the page, the flight table should be displayedbelow the page header on the right side of the page.

1. Copy the node NAVI_LIST from the component controller to the viewMAIN_VIEW and define the context mapping between the nodes (mappingorigin: component controller context).

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

b) Drag the node NAVI_LIST from the component controller context anddrop it to the root node of the view controller context. This copies thecontext node and defined the context mapping in one step.




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

a) Edit the layout of view MAIN_VIEW.

b) From the context menu of the ROOTUIELEMENTCONTAINER chooseInsert 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 (sectionLayoutData) to 100%.

d) Make the page header the first sub element of theROOTUIELEMENTCONTAINER (drag & drop).

3. Define the navigation list in the view's layout. The navigation list shouldcover 30% of the page with and it should be displayed below the page header.

a) From the context menu of the ROOTUIELEMENTCONTAINER chooseInsert 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 attributeNAVI_LIST.SELECTABLE, bind the property itemSource to the contextnode NAVI_LIST, and bind the property itemText to the context attributeNAVI_LIST.TEXT.

d) Make the navigation list the second sub element of theROOTUIELEMENTCONTAINER (drag & drop).

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

a) From the context menu of the NavigationList UI element choose InsertHeader to create an ExpandableTitle UI element.

b) Edit the properties of theExpandableTitle 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 displayedright 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, andwidth (section LayoutData) = 70%.




Task 5:If the user clicks on a connection in the navigation list, the related flights shouldbe 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 actionGET_DETAILS to the event SELECT of theNavigationListUI element.

a) Edit the properties of theNavigationList UI element.

Select the action's name from the drop down list displayed for theNavigationList property onSelect.

3. Extend the source code of the action handler method. Add the parameterCONTEXT_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 navigationlist item.

Get the static attributes from this context element. Change the call of thecomponent controller method GET_FLIGHTS( ): Pass the connection keyto 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->define_nav_list( ).

ENDMETHOD.




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 UIElement

Exercise ObjectivesAfter completing this exercise, you will be able to:� Implement a TabStrip UI element.

Business ExampleYou would like to change your application as follows:

The Table UI element displaying the flights should be defined on a Tab of aTabStrip. 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 2:Create a TabStrip UI element in the layout of view MAIN_VIEW. The TabStripshould contains three Tab sub elements having the captions Flights, CalendarView, and Graphics View, respectively. The Table for displaying the flights shouldbe 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 thecaptions Flights, Calendar View, and Graphics View, respectively.

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




Solution 3: Implementing a TabStrip UIElementTask 1:If you have finished the previous exercise, you can skip this task. Then, all changescan be implemented in the component you have created in your last exercise.



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




Task 2:Create a TabStrip UI element in the layout of view MAIN_VIEW. The TabStripshould contains three Tab sub elements having the captions Flights, CalendarView, and Graphics View, respectively. The Table for displaying the flights shouldbe 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 chooseInsert Element to create a TabStrip UI element.

2. Add three Tab UI elements to the TabStrip. The tabs should display thecaptions Flights, Calendar View, and Graphics View, respectively.

a) From the context menu of the TabStrip UI element choose Insert Tab toadd a Tab UI element. Repeat this step two times.

b) To assign a text to a tab's caption, click on the corresponding CaptionUI 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,

HorizontalContextualPanel, NavigationList, MultiPane, TabStrip, Tray


NET312 Unit Summary

Unit SummaryYou should now be able to:� Implement the following UI elements: ContextualPanel,

HorizontalContextualPanel, NavigationList, MultiPane, TabStrip, Tray

Related Information

� The online documentation for SAP NetWeaver 7.0 contains an excellentsection about developing applications based on Web Dynpro ABAP. TheWeb Dynpro ABAP documentation contains a section named Reference.Here you can find a complete documentation of all UI elements and thecorresponding element classes. UI elements discussed in this unit can befound 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_EVENTSand WDR_TEST_UI_ELEMENTS deal with UI elements in general.


Unit Summary NET312


Unit 3Complex UI Elements

Unit OverviewUI elements that need to have other elements to be defined as sub elements inthe UI element hierarchy are termed as complex UI elements. An example wellknown from NET310 is the TableView UI element. This unit discusses all kinds ofUI elements belonging to this categorization.

In the first lesson, the TableView UI element is reviewed, the Tree UI elementis the topic of second lesson, while the remaining complex UI elements areinvestigated in the third lesson.


� 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 ContentsLesson: The Table UI Element ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Exercise 4: Table UI Element - Set Table Properties and define RowGroups .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135Exercise 5: Table UI Element - Sorting and Filtering ... . . . . . . . . . . . . . . .141


Unit 3: Complex UI Elements NET312

Exercise 6: Table UI Element - Table Popins and Cell Colors .. . . . . . .149Lesson: 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


NET312 Lesson: The Table UI Element

Lesson: The Table UI Element

Lesson OverviewIn this lesson the Table UI element is discussed in detail. This includes elementproperties and element events, grouping columns, grouping rows, filtering,sorting, using of table popins, setting the color of complete columns or singlecells, displaying subtotals and totals of numeric columns, and using cell-specificcell editors. Further topics are tree tables end editable tables.


� 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

Business ExampleThe content of a data base table has to be displayed by a table in an Web Dynprofor ABAP application. However, the wizard provided in the ABAP Workbenchdoes only allows to create very simple tables. Thus you would like to learn moreabout the Table UI element.

The Table - BasicsThe Table UI element is the most complex UI element offered by the Web Dynproframework. It contains a large number of properties and possible kinds of subelements. In the following sections the implementation of all kind of functionalityrelated 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 inthe ABAP Workbench.

Defining the ContextThe 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 nodecollection will contain an arbitrary number of elements. Each element will bedisplayed 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 displayedas cell values in the related table line.

If the node property Initialization Lead Selection is checked, then the first contextelement 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 theTable will then be highlighted.

Finally, the node's Selection property defines a proposal for the minimum andmaximum number of table lines that may be selected by the user. For each tablebound to this context node, this can be adjusted via the Table UI element propertyselectionMode (see sub section dealing with the selection of rows).

Figure 38: Table: Context definition



Defining a simple TableThe basic table in the layout is defined by a combination of at least three types ofUI elements:

� The root element is the Table UI element. The property dataSource of thiselement has to be bound to the context node containing the data.

� For each column to be displayed by the table, a TableColumn UI elementhas to be defined as a sub element of the Table.

� The content of each column is defined by a table cell editor. The cell editormay be a TextView, or a InputField, or some other UI element that can beused to output the value of a context attribute. The cell editor defines howthe content in the complete column is rendered. The UI element serving asthe cell editor has to be defined as a sub element of the TableColumn. Thekey 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 bycreating 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 typedwith an ABAP Dictionary type, then the Caption will automatically display themedium text of the related data element.

A simple table as sketched in this section can be created using the WebDynpro Code Wizard in the view's layout. In addition, the static methodCL_WD_DYNAMIC_TOOL=>CREATE_TABLE_FROM_NODE( ) can becalled from the hook methodWDDOMODIFYVIEW( ) of a view in order to createa simple table dynamically.

UI Element PropertiesThe visibility of the complete table can be toggled by setting the property visibleaccordingly. 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 fieldof 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 thenumber of visible rows is defined variable (visibleRowCount = -1) and the nodecollection is empty.

The table with can be adjusted by setting the property width accordingly (inpixels or percent).



The property fixedTableLayout allows to define each table column precisely aswide as specified by the TableColumn property width. If fixedTableLayout is set toABAP_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 columnis as wide as specified but at least as wide as the widest content in the relatedtable cell editor.

The property legendID allows to assign a Legend UI element to the Table. In thiscase, the property has to be evaluated with the legend's id. The Legend UI elementis discussed as a sub element of the DateNavigator later in this chapter.

UI Element Properties: DesignThe property design allows to choose between three different color schemes. Thevalue of this property determines the color of the cell content, the cell backgroundsand the table elements (e.g. grid, border, footer, column header). However, thevisual design does also depend on the value of the properties readOnly andenabled.

Figure 41: Table: Setting the design

The following table summarizes all possible combinations of these Table propertyvalues:



Table design - non-editable cellsdesign read_only enabled cell content cell

backgroundstandard X X standard white

X standard whiteX standard gray

standard grayalternating X X standard alternate

X standard alternateX standard gray

standard graytransparent X X standard transparent

X standard transparentX standard transparent

standard transparent

Table design - editable cellsdesign read_only enabled cell content cell

backgroundstandard X X standard white

X standard whiteX standard white

grayed out grayalternating X X standard alternate

X standard alternateX standard white

grayed out graytransparent X X standard transparent

X standard transparentX standard transparent

grayed out gray



Comparing the results displayed in the tables above, the following rules can befound:

� If readOnly is set to ABAP_TRUE, the property enabled does not influencethe visual design. Having set design to standard, all cells will have a whitebackground. For design = alternating the table line color will alternatebetween white and gray. Finally, design = transparent will result intransparent cells.

� If readOnly is set to ABAP_FALSE, the property enabled will have noinfluence on the design of non-editable cells.

Non-editable cells will have a gray background (design = standard oralternating) or transparent background (design = transparent).

� If readOnly is set to ABAP_FALSE, the property enabled will have aninfluence on the design of editable cells.

If enabled is set to ABAP_FALSE, then editable cells will have a graybackground and the content is grayed out (all designs).

If enabled is set to ABAP_TRUE, then editable cells will have a whitebackground (design = standard or alternating) or a transparent background(design = transparent).

The visibility of the table grid can be adjusted by the property gridMode. Thissetting 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 toSCROLLBAR, the elements used to initiate vertical scrolling are replacedby a vertical scroll bar.

The number of table lines can be adjusted by the property visibleRowCount. Bydefault, this property has the value 5. If this property is set to -1, all data setsstored in the context are displayed.

If the first element displayed by the table should not be related to the first elementstored in the context, the offset property visibleFirstRow can be used. The propertydisplayEmptyRows allows to omit that the table displays empty table lines. Thissituation occurs if visibleRowCount is larger then the difference between the indexof the first context element displayed by the table and the total number of elementsstored in the context.



Figure 42: Table: Vertical scrolling and context paging

To implement context paging (for details see section about the UI elementMultiPane), the properties rowCount and firstActualRow have to be adjusted. Thevalue 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 asthe total number of visible table lines. firstActualRow is used to define to whichtable line the first context element is to be related. Finally visibleFirstRow hasto be set to a value larger then firstActualRow to display the context element thatare 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 toSCROLLBAR, the elements used to initiate horizontal scrolling arereplaced 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 thetable. 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 valuelarger then 0, then additional elements appear in the table footer. These elementsallow to navigate between the scrollable columns in the table horizontally.

Hint: A Table can contain non-scrollable columns. This is defined by theproperty fixedPosition of the TableColumn UI element. All columnshaving the value left assigned to this property will appear as fixed columnsleft of the scrollable columns. All columns having assigned the valueright to the property will appear as fixed columns right of the scrollablecolumns. All other columns (having assigned the default value not fixedto the property fixedPosition) will be scrollable.

Figure 43: Table: Horizontal scrolling

If the first scrollable column displayed by the table should be different fromthe first scrollable column defined in the layout of the view, the propertyfirstVisibleScrollableCol can be used. If the id of any TableColumn is assignedto this property, only this column and the columns right of the assigned columnwill be displayed by the table.

Hint: If scrollableColCount is set to its default value (-1), it is notpossible 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 elementat lead selection. A selected element does not need to be the element atlead selection and vice versa.

Clicking on the mark column will always select / deselect therelated element. This is displayed by the light orange color. Theselected elements of a node can be obtained by calling the methodGET_SELECTED_ELEMENTS( ).

The line corresponding to the element at lead selection will be displayedin dark orange. This element is determined programmatically by callingthe method GET_ELEMENT( ).

The property rowSelectable is used to define which of the table lines may beselected by the user. Statically, this property only allows to set the selectability forall table lines to the same value. However, if the context node related to the tabledata contains an additional attribute of type WDY_BOOLEAN, and if the Tableproperty rowSelectable is bound to this context attribute, then the selectability canbe defined row by row.

Figure 44: Table: Defining selectable rows



Caution: If a context element to be displayed by the Table is defined asnon-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 propertyInitialize Lead Selection set to ABAP_TRUE. If the first element is alsodefined as a non-selectable element, the application will dump.

By default (selectionMode = auto), the lead selection is changed automatically ifthe user selects a line in the table by clicking on the mark column. However, thisautomatism can be switched off by setting the property selectionChangeBehaviourto manual (default auto). Then, clicking on any table row will neither highlightthis 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 theinterface parameter WDEVENT of the related action handler method, the indexof the table line selected by the user can be extracted (parameter ROW in tableWDEVENT→PARAMETERS).

The property selectionMode can be used to define if multiple lines may be selectedby the user and if selecting a line does also change the lead selection index. Theselection mode as defined by the context node property Selection can be alteredthis way. If selectionMode is set to none, no mark column is displayed and the linecorresponding to the element at lead selection is not highlighted.

Hint: If the user left-mouse clicks on the mark column without pressinganother key, the related table line will be selected and previously selectedtable lines will be deselected.

To select additional table lines, the user can press CTRL when left mouseclicking on the mark column.

Finally, if ALT+SHIFT is pressed when left mouse clicking on the markcolumn, then all data sets between the previously selected data set and theactually selected data set are marked.

If only one context element may be selected, then pressing CTRL orALT+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)NodepropertySelection

Table propertyselectionMode

Number ofselectabletable rows

Round triptriggered byselecting tablerow (LMC /LMC+CTRL /LMC+ALT+SHIFT)

Leadselectionindexchanged

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 FunctionalityHeader and ToolbarA Table UI element may have a title defined by a Caption UI element being a subelement of the Table. The title can display a simple text or an image. If imageand text are displayed together, the developer can decide if the image is placedleft or right of the text.

In order to offer table-dependent functionality, a ToolBar UI element canbe defined as a sub element of the Table. The ToolBar itself may contain acombination 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 thetoolbar. If too many tool bar elements are defined so all elements can not bedisplayed in a single line, the ToolBar property wrapping allows to break the toolbar 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 oftype Caption. In addition, multiple columns may have a common group headerdisplayed above the column-specific column titles. To create this common groupheader, all related columns have to be defined as sub elements of the sameTableColumnGroup UI element, while this TableColumnGroup has to be definedas a sub element of the Table. The common group header itself is defined by aCaption element that is defined as a sub element of the TableColumnGroup UIelement.

The property visible of the TableColumnGroup allows to hide / display all columnsthat depend on this column group. The property fixedPosition is used to fix allcolumns related to the column group at the left border of the table (value = left) orat 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, thesame value may appear multiple times in each of these columns. In this case it isdesirable to have each column value displayed only once (when it changes). Thissimplifies the identification of new data groups in respect to the sorting criteria.

This result can be obtained, if the property groupingValue of the relatedTableColumn UI element is set accordingly. This property can be bound to acontext attribute. Then, the cell content will only be displayed if the attribute valuechanges in respect to the previous data set. If the column content should only bedisplayed when it changed, then groupingValue has to be bound to the attributedisplayed by the table cell editor of this column.



Figure 48: Table: Defining row groups



FilteringIn order to allow filtering of the table data, the following things need to beimplemented:

� 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 tablecontent. However, it is not possible to enter any values yet.

Hint: From the interface parameterWDEVENT of the action handlermethod, only the id of the UI element that fired the event can beextracted.

� 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 attributehaving the correct type.

� Thus, a node of cardinality (1:1) containing an attribute for each filtercolumn has to be defined in the context of the corresponding view.

Result: For each column having its property filterValue bound to a relatedcontext 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 valueset has to be assigned to the related context attribute.

� Optionally, the property isFiltered of a TableColumn UI element can beused to display / hide a filter icon in the column heading. This indicatesthat the current table entries are filtered according to restrictions on valuesof this column.

To set this property dynamically, isFiltered has to be bound to a contextattribute of type WDY_BOOLEAN for each filter column.

� Thus, another node of cardinality (1:1) has to be defined in the contextof the corresponding view. For each filter column, an attribute of typeWDY_BOOLEAN has to be added keeping the information if a filter icon isto 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 installedon the application server. Up to ABAP SPS 12, the filter algorithm has to bewritten by the developer of the application. Beginning with ABAP SPS 13, thefilter algorithm is provided as a service method of a globally defined class. Bothimplementations will be discussed below.

For SAP NetWeaver Application Server 7.0 ABAP having not applied at leastABAP SPS 13 the following steps have to be implemented (typically in the actionhandler 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 afterfiltering.

There are two approaches to have all data sets available without having to readthem again from the data base while the user only sees the filtered data setsat the same time.

Approach one:

All data sets read from the data base are stored in a public component controllerattribute. Each time the user filters the data, the actual content of the context nodecontaining the data to be displayed is invalidated and refilled with data read fromthe public component controller attribute. Only those data sets are copied to thecontext, 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 nodecollection. Then the number of context elements being compatible with the filtercriteria is calculated and the Table property rowCount is set accordingly. Thismeans that the context node always contains all data sets. However, data sets notcompliant 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 ABAPSPS 13 filtering is performed by calling a service method related to the Table UIelement. Internally, this service function checks to which context node the Table isbound 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 tothe user by altering the Table property rowCount accordingly.

Hint: If the attributes related to the filter fields are of type STRING or oftype C, then logical operators may be used with the filter values. Allowedoperators are >, >=, <, <=, =, and ! (not equal). These parameters haveto be entered in front of the filter value (e.g. >=500). In addition to thelogical operators, the pattern sign * can be used as part of any filtervalue (e.g. A*).

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 appropriatemethod of this object to do the filtering.



The reference to the service object is most easily obtained in the hook methodWDDOMODIFYVIEW( ) of the related view:

� First, the reference to the runtime object describing the Table UI elementhas to be determined. This reference is returned when calling the methodVIEW->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 thisreference to a reference variable of type IF_WD_TABLE_METHOD_HNDLis necessary to access table-specific functionality.

� Finally, the reference to the service object should be stored as a controllerattribute of the related view.

To filter the data stored in the context node, the method APPLY_FILTER( ) of theservice 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 beimplemented:

� An action has to be assigned to the Table property onSort. By default, allcolumns will now display a pair of icons in their headers. Clicking on theseicons will lead to a round trip.

� If a column should not be sortable, the TableColumn property sortStatehas to be set to nonSortable.

� If a column should be displayed presorted when the view is rendered the firsttime, 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 installedon the application server. Up to ABAP SPS 12, the sort algorithm has to bewritten by the developer of the application. Beginning with ABAP SPS 13, thesort algorithm is provided as a service method of a globally defined class. Bothimplementations will be discussed below.

For SAP NetWeaver Application Server 7.0 ABAP having not applied at leastABAP SPS 13 the following steps have to be implemented (typically in the actionhandler method triggered by event Sort):

� The ID of the TableColumn the user has clicked on and the desired sortingdirection has to be determined. This information is contained by thetable 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 internaltable.

� If the table contains a mark column, the indices of the selected table linesand 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 ABAPSPS 13 sorting is performed by calling a service method related to the Table UIelement.

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 appropriatemethod of this object to do the filtering. Please refer to the last sub section fordetails 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

TablePopinsThe TablePopin allows to display detail information related to a data set (rowpopin) 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 thepopin, so popin and cell can be identified as belonging together. The UI elementTablePopinToggleCell is provided for expanding and collapsing the TablePopin.However, the visibility of a TablePopin may also be toggled by clicking on anyclickable 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 directsub element of the Table. This is done from the context menu of the Table byselecting the menu entry Insert Table Popin.

Hint: Each Table may only contain one TablePopin UI element definingthe row popin.

To define a cell popin for a cell being displayed in a certain column, a TablePopinUI element has to be created as a direct sub element of this TableColumn. This isdone by choosing the menu entry Insert Table Popin from the context menu ofthis 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 theTablePopin UI element. From the context menu of the TablePopin, only onedirect sub element can be created (menu entry Insert Content). However, this isno restriction, since the sub element can be a container element which can havean arbitrary number of sub elements.

Caution: The content of a TablePopin may not be aViewContainerUIElement, since multiple row popins may be displayed atruntime 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 inthe data node. This allows to display row-related information by multipletable 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 thebackground color of the table popin's content. hasContentPadding specifieswhether 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 lineof 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 propertyselectedPopin of the Table UI element has to be set accordingly. Each table popinhas a unique id. If this id is assigned to the property selectedPopin, the relatedtable popin is displayed below each table row. To be able to define the table popinand its visibility dependent on the table row, the property selectedPopin has tobe bound to a context attribute of type string being defined in the context nodekeeping the table data. At runtime, this context attribute can have a differentvalue for each context element. If no value is assigned to this attribute, no tablepopin will be displayed for this table line.



Figure 66: Table: Data binding required for dynamically assigning a tablepopin

Figure 67: Table: Displaying table popin



To change the visibility of a table popin, the application has to offer an associatedUI element the user can click on. All kinds of UI elements allowing to trigger around 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 inthe table cell the popin is related to. An action should be assigned to anappropriate event of this UI element, so a related action handler method isprocessed when the user clicks on the UI element. Event-related information canthen be extracted from the interface parameter WDEVENT. The internal tableWDEVENT→PARAMETERS will contain the reference to the context element(parameter CONTEXT_ELEMENT), that corresponds to the table line the user hasselected. This allows to generate related detail information.

To expand the cell popin, the id of the TablePopin has to be saved in the contextattribute, 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 cornerof the popin area may be used. Clicking on this icon will fire the popin's eventClose (property onClose). In the related action handler method the value of thecontext 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 alink in an extra table column. However, the Web Dynpro UI element library offersa special element for this purpose, the TablePopinToggleCell UI element. Thiselement is used as a table cell editor in an extra TableColumn. When the popinis closed, this UI element displays an arrow pointing right. When the popin isopened, an arrow pointing down is displayed. Opening and closing the row popinusing a TablePopinToggleCell UI element is performed automatically. This meansthat the value of the attribute, the Table property selectedPopin is bound to, doesnot need to be coded by the developer.

To create a TablePopinToggleCell, the menu entry Insert Cell Variant defined inthe context menu of a TableColumn has to be selected. In the dialog poppingup different cell variant types are offered. The first entry in the variant list is



the TablePopinToggleCell. The TablePopinToggleCell is given an identifier bysetting the property variantKey to an appropriate value. The same value has to beassigned to the property selectedCellVariant of the related TableColumn.

Hint: A cell variant is defined as a direct sub element of a TableColumnUIelement. For different purposes, different kinds of cell variants do exist:

� TablePopinToggleCell: This element is discussed in this section. Itmay be used to define a special column used to expand and collapseTablePopins displaying row-related information.

� TableSingleMarkableCell: This cell variant type may be usedto 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 acell-specific rendering of the table content. The table cell editor willbe defined as a sub element of this type of cell variant. This allowsto render different cells of the same table column differently.

� TableSummaryCell: This cell variant type may be used to definecells for displaying totals of numeric columns. The table cell editorwill be defined as a sub element of this type of cell variant. Thiskind of cell variant will be discussed in the section dealing withdisplaying totals and subtotals.

� TableSummaryHierarchyCell: This cell variant type may beused to define subtotals for numeric columns. In contrast to theTableSummaryCell, the TableSummaryHierarchyCell displays anarrow-like icon. This is used to display / hide the group of cellsthe subtotal / total is calculated for. The table cell editor will bedefined as a sub element of this type of cell variant. This kind ofcell variant will be discussed in the section dealing with displayingtotals and subtotals.

For each TableColumn, an arbitrary number of cell variants maybe defined. Each cell variant is identified by the value of itsproperty variantKey. At runtime, any of the cell variants can beselected by assigning the variants key to the TableColumn propertyselectedCellVariant. If this property is bound to an attribute defined in thetable 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 theTableColumn) is used to render the related table cell.



Clicking on a TablePopinToggleCell UI element will fire the element's eventToggle (property onToggle). In the related action handler method, row relatedinformation can be read and stored in the context.

Figure 70: Table: Defining a TablePopinToggleCell UI element

ColorsIn a Table, complete columns can be given a background color by setting theproperty cellDesign of the corresponding TableColumn accordingly. Binding thisproperty to a context attribute of type WDUI_TABLE_CELL_DESIGN allows tochange the background color of a complete TableColumn dynamically. If thecontext attribute containing the color value is part of the data node, then the colorcan be defined dependent on the row. In this case, each cell of a given columncan have an arbitrary background color.



Figure 71: Table: Defining the background color

Figure 72: Table: Defining the background color of a column



Editable TablesCell variants of type TableStandardCell can be used to offer different table celleditors for each TableColumn. Thus, at runtime each table cell may be rendereddifferently. This allows to create tables containing cells that are editable onrequest. In a typical scenario, certain cells of selected table lines may be switchedfrom text field (cell editor TextView) to input fields (cell editor InputField) if anadditional 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 inputfields the following things need to be implemented:

1. An additional context attribute has to be added to the table data node. Foreach context element this attribute will store the variant key of the cellvariant 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 addedto each TableColumn. The property variantKey has be set identically forall 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 contextattribute defined in step 1.



Incorrect data entered by the user can not checked before a round trip to theapplication server takes place. If a round trip takes place, the Web Dynpro runtimewill check whether the values entered by the user have the correct type and ifthey are compliant with the domain fixed values. If an error is found by the WebDynpro runtime for at least one of the field values, the navigation is cancelledand all error messages will be displayed on the previous view assembly. In thiscontext, incorrect field values are not passed to the related context attribute.

If application specific input checks have to be implemented, the following issueshave to be taken into account:

� The user of the application may trigger a round trip without firing an eventthat is bound to an action. This may occur if the user clicks on the markcolumn of the table or if the user scrolls in the table. In this case, inputchecks that are implemented in the hook methods WDDOBEFOREACTION(), WDDOAFTERACTION( ), or in any action handler method will not beprocessed.

� The data entered by the user is stored in the related context attributes. Thepreviously stored data is deleted and can not be restored.

� The context node and the dependent context elements do not store anyinformation that can be used at runtime to find out which data cells havebeen changed by the user.

To overcome these problems, the following implementation techniques could beapplied:

The input checks could be performed in the component controller methodWDDOBEFORENAVIGATION( ). This method is processed for each round tripjust before navigation takes place. If an error is found, a message related to theappropriate context attribute could be created. To cancel the navigation, theinterface parameter CANCEL_NAVIGATION of the message method can be setto ABAP_TRUE or the method CANCEL_NAVIGATION( ) (defined in the globalinterface 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 contextchange log could be checked. The context change log collects exact informationsabout the previous value, the actual value, the column name, the line index, andthe binding informations for all table cells changed by the user. The contextchange log can be accessed as follows:

� First, the reference to an object describing the controller context has tobe obtained from the attribute WD_CONTEXT by calling the methodGET_CONTEXT( ). The reference returned by this method is of typeIF_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 changelog as an internal table of type WDR_CONTEXT_CHANGE_LIST.

Caution: By default, reading the context change log willautomatically reset the log. However, by setting the interfaceparameter AND_RESET to ABAP_FALSE, the complete changehistory is collected by the log.

� To stop logging, the method DISABLE_CONTEXT_CHANGE_LOG( ) canbe called.

� To enable logging or to switch on logging after having switched it off, themethod ENABLE_CONTEXT_CHANGE_LOG( ) has to be called.

Hint: Do not forget to call this method before changes by the usermay take place.

� Finally, the method RESET_CONTEXT_CHANGE_LOG( ) can be called toclear the log. Logging is not disabled by calling this method.

Let's consider the case that the context change log contains the complete historyof all changes performed by the user. If a table cell has been changed multipletimes by the user, multiple entries containing all historical values for this field areaccessible from the context change log. However, only the last entry is relevant inrespect to input checks and database updates. In addition only the first entry isrelevant to roll back the changes performed by the user.

Thus, checking the user input could be implemented as follows: To find out whichcontext attributes have been changed by the user, the application can loop over theinternal table returned by the method GET_CONTEXT_CHANGE_LOG( ). Thisinternal table contains the columns ATTRIBUTE_NAME and ELEMENT_INDEXwhich 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'sname and index should be stored in an internal table. This allows to find out, ifa context attribute has already been checked before.

Hint: If you forget this check, you may get as many identical errormessages for a table cell, as there have been changes of the relatedattribute 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 attributemore than once



Figure 78: Table: Implementing input checks - get actual values for editedtable cells

Before saving the data to the data base the application has to collect all relevantinformation provided by the context change log in an internal table. If a fieldvalue 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 beidentified easily, since all changes performed by the user are serially numbered(column SEQUENCE).

Displaying Totals and SubtotalsThe Table UI element offers the possibility to display subtotals and totals ofnumeric columns. The data sets displayed by the Table can be sorted, so subtotalscan be displayed after each group of data sets having the same values in respectto 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 darkyellow. 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 doneautomatically 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 arediscussed. 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. Thistable should contain an additional column of type string. This column willbe filled with the name of the cell variant used to display the correspondingtable line.

2. The internal table has to be sorted according to the data set groups, subtotalsshould be displayed for.

3. After each data set group an additional line has to be inserted into theinternal table. This table line has to contain the sums of the numeric columnsfor this group. The cells forming the grouping criterion should contain thecorresponding values. The extra table column should be filled with the nameof the cell variant used to display this table line. All other nun-numericcells should be initial.

4. The context of the controller has to be defined. The data node should containall attributes to be displayed by the table. In addition, an attribute relatedto the extra table column has to be defined. At runtime, this attribute willcontain 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, theextra table column (containing the cell variant name) may not be displayed.

7. For each TableColumn the property selectedCellVariant has to be bound tothe context attribute containing the cell variant name.

8. For each TableColumn, a cell variant of type TableSummaryCell has to bedefined as a direct sub element. The property variantKey has to be evaluatedwith 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 definedfor each cell variant defined in the previous step. The primary property hasto be bound to the context attribute related to this column.

Hint: The definition of the cell variants and the dependent table celleditors may also be performed dynamically using the hook methodWDDOMODIFYVIEW( ).



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 datasets that is related to a subtotal table line. There are two ways to implement thisfunctionality.

The cell variant type TableSummaryCell supports the event LevelAction (propertyonLevelAction). If an action is assigned to this event, then the user may click onthe cell content to trigger a round trip. In the related action handler method, the idof the cell variant (parameter ID) and the reference to the context element relatedto the table line the user has clicked on (parameter CONTEXT_ELEMENT) areavailable 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 informationfor each group of data sets, subtotals are calculated for. Therefore, the content ofthe context is defined as follows:

1. The internal table containing all data sets and all subtotals is defined as acontroller attribute visible to the view displaying the table (e.g. a publicattribute of the component controller).

2. An extra column for saving the key of the variant that has to be used torender the subtotal lines has to be added. In addition, another columncontaining 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 booleaninformation 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 datasets of this group plus the subtotal table line are copied. For data set groupsmarked 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 actionbound to the event LevelAction, a round trip takes place. In the action handlermethod, 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 aTableSummaryCell 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, noinformation is provided about the next status of the data set group the user hasselected.

Thus a second concept exists to allow expanding / collapsing data setgroups. In this concept the cell variant TableSummaryCell is replaced by aTableHierarchySummaryCell for an arbitrary number of columns. Then, thedependent table cell editors do not only display the cell content but also an arrowbeing displayed left of the cell value. This arrow points to the right (statuscollapsed) or to the top (status expanded). The kind of arrow displayed at runtimeis defined by the property expanded of the cell variant. This property will bebound 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 informationabout 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 conceptsexplained up to now have to be extended as follows:

1. The internal table is changed in a way, that it contains a subtotal line aftereach data set group. For each data set group a different key for the cellvariant used to display the related subtotal line in the table has to be stored.

Example:

Subtotal after each connection→ Variant key SUM_CONNID. Subtotal afterall connections of same carrier→ Variant key SUM_CARRID. Total after allconnections of all carriers→ Variant key SUM_ALL.

2. In the view's layout, as many cell variants have to be added to eachTableColumn as there are different data set groups (variant keys). Each cellvariant 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 additionalUI elements, where m = number of columns and n = number ofdata set groups). Thus, defining these UI elements dynamicallyis the better way.

3. One of the cells displayed in a subtotal / total table line should be definedby a TableHierarchySummaryCell cell variant. Typically the last groupingcriterion 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 isexpanded / collapsed by clicking on the arrow displayed with the carrier.

Finally, some properties of the TableSummaryCell and of theTableHierarchySummaryCell that have not mentioned yet should be discussed.Both elements contain the property cellDesign. This property may have the valuessubtotal (light yellow) and total (dark yellow). The later property value shouldbe 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 backgroundcolor 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 propertycorresponds 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 thirdlevel.



Tree TablesTables can represent a hierarchy using the aggregation master column. The mastercolumn displays the grouping criterion (defined by the table cell editor) and anarrow-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 groupingcriterion could be displayed directly. However, it is also possible that expandingthe table content will display additional sub groups that can also be expanded andcondensed. 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 thetable content is expanded for a certain carrier, all flights of this carrier could bedisplayed. However, expanding the table content for a certain carrier could alsoresult in displaying additional master column entries for each connection number.To display the flights related to a certain connection number, the user then has toclick 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 thegrouping criteria. From the context menu of the Table UI element, the menu itemInsert Master Column has to be selected to create this column.

There are two types of master column UI elements, the TreeByKeyTableColumnUI element and the TreeByNestingTableColumn UI element. Only theTreeByKeyTableColumn 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 celleditor will be used to display the content of the master column. An optionalCaption UI element can be created as a sub element of the master column todefine the column heading.

The TreeByKeyTableColumn UI element contains the following properties:

The property Cell Design allows to define the cell background color of the mastercolumn.

childrenLoaded can be used to define if data sets related to a grouping criterionhave already been loaded. If this property is bound to a context attribute of typeWDY_BOOEAN this information can be defined differently for each data setgroup. If the user expands a group, the application has to check the value of thisattribute 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 typeWDY_BOOLEAN. At runtime, this attribute will contain the information, whichgroup 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 groupingcriterion and which context element is displayed as an actual table data set.

rowKey should be bound to a context attribute of type STRING. This attributeallows to assign a row-specific key to each context element. This is used to definethe 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 byassigning 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 relatedto the first hierarchy level displayed by the Table UI element. Dependent contextelements may be pre-loaded. However, it is also possible to load dependent dataon request (when expanding a group). If a non-leaf context element is defined asbeing collapsed (expanded = ABAP_FALSE), dependent context elements arenot 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 graphicsthe setting of the context attributes is visualized for a one level hierarchy and for amultiple 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 theproperty OnLoadChildren of the TreeByKeyTableColumn UI element.

Hint: The event LoadChildren is fired only, if the user expands a groupand the children of this group have not been loaded yet (value of contextattribute bound to UI element property ChildrenLoaded is initial). Thisflag has to be set by the application.

In the action handler method, information about the related context elementcan be extracted from the interface parameter WDEVENT. The internal tableWDEVENT→PARAMETERS contains the id of the master column (parameterID) 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 thiscontext element, depended data sets can be read and stored in the context.



Exercise 4: Table UI Element - Set TableProperties and define Row Groups

Exercise ObjectivesAfter completing this exercise, you will be able to:� Set properties of the Table UI element� Define a table header� Define row groups

Business ExampleYou would like to enhance the functionality and ergonomics of the table displayingthe flights. This includes the possibility to scroll vertically and horizontally acrossthe data and the reduction of redundant information displayed by the table. A tableheader should explain what kind of data is displayed by the table.

Template Component: NET312_LAYO_S2

Solution Component: NET312_CMPX_S1


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 copyZNET312_CMPX1_##. Assign this component to your package ZNET312_##.Create an application having the same name as your component and assign theapplication to your package, too.



Task 2:Add a header to your table. The header should display the text Flights availablefor 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 thenumber of scrollable columns to 4. Make sure that scrolling does not influencethe column widths. The carrier id and the connection number should only bedisplayed once per group of flights belonging to the same connection. Thebackground of the data rows should alternate between two colors. Instead of thestandard elements used to scroll in the table scroll bars should be displayed toallow vertical and horizontal scrolling.

1. Fix the columns related to the flight key on the left side of the table. Restrictthe 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 pergroup 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 bedisplayed to allow vertical and horizontal scrolling.

Task 4:OPTIONAL:

The number of columns displayed by the table (fixed columns + scrollablecolumns) and the number of table columns defined in the UI element hierarchyis nearly identical. Horizontal scrolling is more interesting if the number oftable columns is increased. Thus, you could append additional attributes of theDictionary structure SFLIGHT to the context node FLIGHTS and display theseattribute values by additional TableColumn UI elements.

1. Create additional attributes in the context node FLIGHTS of the componentcontroller 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 UIelements and related table cell editors to the Table UI element.

Hint: Deleting the existing table and using the wizard to createa new table is not a good idea, since all changes of UI elementproperties related to the table and its sub elements would then belost. In addition, all sub elements of the Table you have createdmanually would also be lost.



Solution 4: Table UI Element - Set TableProperties and define Row GroupsTask 1:If you have finished the previous exercise, you can skip this task. Then, all changescan be implemented in the component you have created in your last exercise.



a) Display the template component in the object tree of transaction SE80.Clicking on the component with the right mouse button will open thecomponent's context menu. Choose Copy.... Enter the name of thecomponent to be created. Press Continue.




Task 2:Add a header to your table. The header should display the text Flights availablefor 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 propertytext of the Caption UI element.

Use the drop down box related to the property imageSource in order toassign the SAP GUI Icon ICON_WS_PLANE (name displayed in iconlist: WS_PLANE) to this property.




Task 3:Fix the columns related to the flight key on the left side of the table. Restrict thenumber of scrollable columns to 4. Make sure that scrolling does not influencethe column widths. The carrier id and the connection number should only bedisplayed once per group of flights belonging to the same connection. Thebackground of the data rows should alternate between two colors. Instead of thestandard elements used to scroll in the table scroll bars should be displayed toallow vertical and horizontal scrolling.

1. Fix the columns related to the flight key on the left side of the table. Restrictthe number of scrollable columns to 4.

a) The columns related to the flight key display the carrier id, theconnection number, and the flight date. For the correspondingTableColumn UI elements set the property fixedPosition = left.

b) The number of scrollable columns is defined by the value of the Tableproperty 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 markingthe related check box.

3. The carrier id and the connection number should only be displayed once pergroup of flights belonging to the same connection.

a) For the TableColumn UI element related to the carrier id, bind theproperty groupingValue to the context attribute FLIGHTS.CARRID.

b) For the TableColumn UI element related to the connection number, bindthe 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 propertyreadOnly to ABAP_TRUE.

5. Instead of standard elements used to scroll in the table, scroll bars should bedisplayed to allow vertical and horizontal scrolling.

a) Edit the parameters of your application (tab Parameters).

b) In the column Parameters enter the name WDTABLENAVIGATION, inthe column Value enter SCROLLBAR.




Task 4:OPTIONAL:

The number of columns displayed by the table (fixed columns + scrollablecolumns) and the number of table columns defined in the UI element hierarchyis nearly identical. Horizontal scrolling is more interesting if the number oftable columns is increased. Thus, you could append additional attributes of theDictionary structure SFLIGHT to the context node FLIGHTS and display theseattribute values by additional TableColumn UI elements.

1. Create additional attributes in the context node FLIGHTS of the componentcontroller 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 usingthe Wizard→ Attributes from Components of Structure. Mark allcomponents besides the component MANDT. Finish the dialog andsave 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 UpdateMapping. Choose Yes on the next dialog(s) to add the new attributes tothe mapped node.

3. Display the content of the new context attributes by adding TableColumn UIelements and related table cell editors to the Table UI element.

Hint: Deleting the existing table and using the wizard to createa new table is not a good idea, since all changes of UI elementproperties related to the table and its sub elements would then belost. In addition, all sub elements of the Table you have createdmanually 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 attributesPAYMENTSUM, SEATSMAX_B, SEATSOCC_B, SEATSMAX_F, andSEATSOCC_F by marking the check boxes in the column Binding.

Finish the dialog.





Exercise 5: Table UI Element - Sorting andFiltering

Exercise ObjectivesAfter completing this exercise, you will be able to:� 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 ExampleYou 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 theheader of table columns. In addition the application should offer the possibility tofilter the table content.

Template Component: NET312_CMPX_S1






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 aboutoccupied seats and capacity, and the total of current bookings

1. Assign a new action (name: SORT) to the property onSort of the TableUI element displaying the flights.

2. Get the reference to the method handler of this table and store this referenceas an attribute of the view controller.




3. Call the method APPLY_SORTING( ) of the method handler when theevent Sort is fired.

4. Do not allow to sort the table content by the carrier id, the connectionnumber, the price, the currency, or the plane type.

Task 3:Implement the possibility to filter the table content by entering filter values for theflight 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 thenumber 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 ofcardinality (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 TableUI element displaying the flights.

3. For the columns displaying the flight date and the number of occupied seatsin the economy class: Bind the TableColumn property filterValue to thecorresponding attribute in the node FILTER. Set the width of the columndisplaying the flight date to 100 pixels. This will be necessary, to displaythe complete filter values by the drop down box.

4. Implement filtering: Call the method APPLY_FILTER( ) of the methodhandler if the event Filter is fired.

5. Up to now, filter values for the flight date have to be entered into an inputfield. To display a drop down box, a value set containing the allowed valueshas to be assigned to the related context attribute. The drop down box shoulddisplay three values: All dates, <act. Date, and >=act. Date. Here, act. Dateis 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 viewMAIN_VIEW encapsulating the source code to define the value set. Call thismethod from the hook method WDDOINIT( ).



Solution 5: Table UI Element - Sorting andFilteringTask 1:If you have finished the previous exercise, you can skip this task. Then, all changescan be implemented in the component you have created in your last exercise.







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 aboutoccupied seats and capacity, and the total of current bookings

1. Assign a new action (name: SORT) to the property onSort of the TableUI element displaying the flights.


b) Click on the Table UI element used to display the flights. This willdisplay 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 referenceas 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 areference variable of type IF_WD_TABLE_METHOD_HNDL .

c) Now, edit the method WDDOMODIFYVIEW( ) of the viewMAIN_VIEW.

d) Call the method VIEW->GET_ELEMENT( ). Pass the id of the TableUI element via the interface parameter ID. Cast the returning parameterto 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 attributeGO_TABLE_M_HNDL. You need to cast the reference.

f) Make sure, that the reference to the method handler is determinedonly once: Check the variable FIRST_TIME before you determine themethod handler reference.

g) Source code see below.

3. Call the method APPLY_SORTING( ) of the method handler when theevent Sort is fired.


4. Do not allow to sort the table content by the carrier id, the connectionnumber, the price, the currency, or the plane type.


b) Click on the icon left of the Table UI element to display theTableColumn UI elements.

c) Set the property sortState to notSortable for the TableColumn UIelements 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 theflight 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 thenumber 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 ofcardinality (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 chooseCreate→Node to create a new node. Enter the node's name in thecorresponding field and finish the dialog.

c) Click on the new node FILTER. From the context menu of this nodechoose Create→Attribute to create a new attribute. Enter the attribute'sname (DATE) and the type (STRING) in the corresponding fields andfinish the dialog.

d) Repeat the last step for the attribute SEATSOCC.

2. Assign a new action (name: FILTER) to the property onFilter of the TableUI element displaying the flights.


b) Click on the Table UI element used to display the flights. This willdisplay the table properties. Click on the button right of the propertyonFilter to create and assign the action FILTER.

3. For the columns displaying the flight date and the number of occupied seatsin the economy class: Bind the TableColumn property filterValue to thecorresponding attribute in the node FILTER. Set the width of the columndisplaying the flight date to 100 pixels. This will be necessary, to displaythe 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 theproperties of this column. Click on the button right of the propertyfilterValue to bind this property to the context attribute FILTER.DATE.

c) Repeat this procedure to bind the property filterValue of the columndisplaying the number of occupied seats in the economy class to thecontext attribute FILTER.SEATSOCC.

d) Finally, set the property width of the table column displaying theflight date to 100.




4. Implement filtering: Call the method APPLY_FILTER( ) of the methodhandler if the event Filter is fired.


5. Up to now, filter values for the flight date have to be entered into an inputfield. To display a drop down box, a value set containing the allowed valueshas to be assigned to the related context attribute. The drop down box shoulddisplay three values: All dates, <act. Date, and >=act. Date. Here, act. Dateis 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 viewMAIN_VIEW encapsulating the source code to define the value set. Call thismethod 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 themethod. Double click on the method's name to edit the method.

c) Starting with WD_CONTEXT, determine the reference to the nodeinfo of node FILTER. This will return a reference variable of typeIF_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 acorresponding work area as local variables.

e) Before calling the method SET_ATTRIBUTE_VALUE_SET( ), youhave to build up the value set table LT_VS. Use the CONCATENATEstatement to define the value (not visible) and the text (displayed by thedrop down box) for each table entry. You have to combine a logicaloperator and the actual date in external format.

Hint: The date has to be defined in external formatsince the filter algorithm automatically converts the filtervalue according to the type of the filter column. Use theWRITE....TO... statement to create the external format of theactual date (SY-DATUM).

f) Call the method DEFINE_FILTER_VALUES( ) from the hook methodWDDOINIT( ) 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_table_m_hndl ?= lo_table->_method_handler.

ENDIF.

ENDMETHOD.

View Controller: ONACTIONSORT( )

METHOD onactionsort .

wd_this->go_table_m_hndl->apply_sorting( ).

ENDMETHOD.

View Controller: ONACTIONFILTER( )

METHOD onactionfilter .

wd_this->go_table_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->define_filter_values( ).

ENDMETHOD.



Exercise 6: Table UI Element - TablePopins and Cell Colors

Exercise ObjectivesAfter completing this exercise, you will be able to:� Implement table popins that depend on table rows� Colorize table cells

Business ExampleYou would like to enhance the functionality and ergonomics of the table displayingthe 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 tablecolumn should be colorized according to the cell content.







Task 2:Create a table popin. This popin should be related to table rows. Expanding andcollapsing 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 facilitatedby clicking on the cross icon displayed by the table popin.

Later on, the table popin will display a business graphic. However, in this exercisethe table popin only has to display a simple text.

1. Create a table popin that is related to a table row. The table popin shoulddisplay a simple text (e.g. to be implemented later...).




2. Create and assign a new action (name: CLOSE_POPIN) to the eventonClose of the TablePopin UI element.

3. Create a new non-sortable table column being the leftmost column in thetable. Assign a text (Graph) and an icon (~Icon/VerticalBarChart) to theCaption of this TableColumn.

Define a cell variant of type TablePopinToggleCell being a sub element ofthis new table column. Give the cell variant a key (name: POPIN)

4. Create and assign a new action (name: TOGGLE_POPIN) to the eventonToggle of 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 nodecontaining the table data. In addition, the property selectedPopin of theTable UI element has to be bound to this attribute.

6. Clicking the cross-like icon in the table popin still does not close the tablepopin. This is because the action handler method related to the actionCLOSE_POPIN has not been implemented yet.

Implement the handler: The value of the attribute FLIGHTS.POPIN_NAMEhas to be cleared for the corresponding context element. The reference to thiselement is provided by the framework (parameter CONTEXT_ELEMENTstored in parameter table WDEVENT→PARAMETERS).

Task 3:Depending on the relative occupation, the cells of the table column displaying theoccupied seats in the economy class should have different background colors. Ifthe relative occupation is below 50%, the background color should be green,between 50% and 95% the cell background should be orange, above 95% thecell 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 overthe data table, set the background color according to the relative occupation




of the seats in the economy class and store the color information in theinternal table (field COLOR). Finally, copy the modified internal table backto the context node FLIGHTS.

Hint: Allowed color values are available as constantsin 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 newconnection.

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 economyclass has to be bound to the context attribute FLIGHTS.COLOR.



Solution 6: Table UI Element - TablePopins and Cell ColorsTask 1:If you have finished the previous exercise, you can skip this task. Then, all changescan be implemented in the component you have created in your last exercise.







Task 2:Create a table popin. This popin should be related to table rows. Expanding andcollapsing 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 facilitatedby clicking on the cross icon displayed by the table popin.

Later on, the table popin will display a business graphic. However, in this exercisethe table popin only has to display a simple text.

1. Create a table popin that is related to a table row. The table popin shoulddisplay 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 TablePopin to create a row popin.

c) From the context menu of the TablePopin UI element, choose InsertContent to create the popin content. Create a TextView UI element.Assign any text to the TextView UI element by setting the propertytext accordingly.




2. Create and assign a new action (name: CLOSE_POPIN) to the eventonClose of the TablePopin UI element.

a) Use the button right of the event onClose to create and assign the actionto the TablePopin UI element.

3. Create a new non-sortable table column being the leftmost column in thetable. Assign a text (Graph) and an icon (~Icon/VerticalBarChart) to theCaption of this TableColumn.

Define a cell variant of type TablePopinToggleCell being a sub element ofthis new table column. Give the cell variant a key (name: POPIN)

a) From the context menu of the Table UI element, choose Insert TableColumn to create a new column. Make this column the leftmostcolumn of the Table by move it to the top of the table's sub elementlist (drag & drop).

b) Correct the properties of the new TableColumn UI element: SetfixedPosition = 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 toassign an icon to the column header. Click on the tab Icon and selectthe icon VerticalBarChart from the list.

e) From the context menu of the new TableColumn, choose Insert CellVariant to create a cell variant. In the following dialog, chooseTablePopinToggleCell 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 orderto display the table popin, the literal POPIN has to be assigned to theproperty selectedCellVariant.

4. Create and assign a new action (name: TOGGLE_POPIN) to the eventonToggle of the TablePopinToggleCell UI element.

a) Use the button right of the event onToggle to create and assign theaction 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 nodecontaining 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 isnecessary to add arbitrary attributes to the node.

c) Add a new attribute (name: POPIN_NAME, type: STRING) to thenode FLIGHTS.

d) Now edit the context of the view MAIN_VIEW. Update the contextmapping 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 bindthis property to the context attribute FLIGHTS.POPIN_NAME.

6. Clicking the cross-like icon in the table popin still does not close the tablepopin. This is because the action handler method related to the actionCLOSE_POPIN has not been implemented yet.

Implement the handler: The value of the attribute FLIGHTS.POPIN_NAMEhas to be cleared for the corresponding context element. The reference to thiselement is provided by the framework (parameter CONTEXT_ELEMENTstored in parameter table WDEVENT→PARAMETERS).

a) Edit the method ONACTIONCLOSE_POPIN( ) defined in viewMAIN_VIEW.

b) Add the import parameter CONTEXT_ELEMENT (TYPE REF TOIF_WD_CONTEXT_ELEMENT) to the signature of this method. Enterthe parameter's name in field Parameter, check the RefTo check boxand enter the interface name in field Associated Type.

c) Use the pattern functionality to create the method call for setting theattribute 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 theoccupied seats in the economy class should have different background colors. Ifthe relative occupation is below 50%, the background color should be green,between 50% and 95% the cell background should be orange, above 95% thecell 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 byselecting the context menu entry Create→Attribute of this node.

2. Create the method DEFINE_COLORS( ) in the component controller. Editthe method. Get the data table from the context node FLIGHTS. Loop overthe data table, set the background color according to the relative occupationof the seats in the economy class and store the color information in theinternal table (field COLOR). Finally, copy the modified internal table backto the context node FLIGHTS.

Hint: Allowed color values are available as constantsin 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 newconnection.

a) If the user clicks on a connection, the action handler methodONACTIONGET_DETAILS( ) is triggered in view MAIN_VIEW. Addthe 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 mappingfor node FLIGHTS (context menu entry Update Mapping).

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 economyclass has to be bound to the context attribute FLIGHTS.COLOR.





b) Click on the TableColumn UI element displaying the occupied seats inthe economy class.

c) Use the button right of the property cellDesign to bind this property tothe 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 lt_flights TYPE wd_this->elements_flights.

DATA ls_flights TYPE wd_this->element_flights.

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.







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� 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


NET312 Lesson: The Tree UI Element

Lesson: The Tree UI Element

Lesson OverviewThis lesson deals with the definition of a Tree UI element. This includes thedefinition of tree nodes and tree items in the view's layout, the definition of thecontroller context, and the definition of methods to fill the context. Here, all kindsof trees are discussed. These may consist of multiple node types and elementtypes per hierarchy level. In addition, the number of hierarchy levels may beundefined at design time.


� Create static trees� Create dynamic trees having an undefined number of hierarchy levels

Business ExampleYou would like to present the hierarchically defined content of the view's contextby a tree like structure. The user should be able to expand / collapse the tree'snodes and he should be able to select a tree item. When selecting a tree item, datarelated to this tree item should be displayed by the application.

Tree BasicsHierarchies 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 contextnode 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 usingthe UI element TreeItemType. The sub elements of any tree node can be collectedat 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 aredisplayed highlighted.



Figure 91: Tree: Simple Tree

Figure 92: Tree: Additional functionality (1)



Figure 93: Tree: Additional functionality (2)

Defining the ContextThe context structure related to a tree consists of a parent context node and anarbitrary 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 arecursion node (repeating a node structure defined at a higher hierarchy level).

UI Element Definition and Data BindingFirst, the Tree UI element is created in the UI element hierarchy. The propertydataSource allows to bind the Tree to any context node. The Tree may then displaythe 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 displayedon top of the box by setting the property titleVisible to ABAP_TRUE and byassigning 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. Thetext displayed right of the toggle icon related to this root node is defined by theproperty rootText.

defaultItemIconSource may be set to define the default icon displayed left of alltree leafs. defaultNodeIconSource may be set to define the default icon displayedleft of all tree nodes (but the root node). In both cases, a value help button allowsto select the Icon statically. Binding these properties to context attributes of typeSTRING allows to define the icons programmatically



If enabled is set to ABAP_FALSE, all tree nodes are grayed out and the actualstate can not be changed by the user.

The width of the tree and the minimum width is determined of the values of theproperties width and minHeight, respectively.

Figure 94: Tree: Defining the UI and data binding (1)

Aggregations: TreeNodeType and TreeItemTypeAfter having created the Tree UI element, sub elements of type TreeNodeType andTreeItemType have to be created in order to display the content of the context nodethat has been assigned to the Tree property dataSource.

In the most simple case, the data source does not contain sub nodes, but onlya number of context elements to be displayed as tree leafs. Then, a single UIelement of type TreeItemType (defined as a direct sub element of the Tree UIelement) 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 toany attribute of the data source node.

The TreeItemType UI element contains additional interesting properties. Theproperty design allows to emphasize the texts displayed with the tree items. If thisproperty is bound to a context attribute of type WDUI_TREE_NODE_DESIGN,then the design can be set differently for each tree item. iconSource allowsto define an icon displayed left of each tree item. This overwrites the icondefined by the property defaultItemIconSource of the Tree UI element. Finally,



if ignoreAction is set to ABAP_TRUE, then the action assigned to the propertyonAction is not triggered. The hook methods WDDOBEFOREACTION( ) andWDDOAFTERACTION( ) 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 leadselection in the related node collection.

Figure 95: Tree: Displaying leafs

Lets consider the a slightly more complicated situation. On the first hierarchylevel, the UI tree should not only display tree items, but also tree nodes that can beopened 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 thecontext. 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 subnode (N2) has to contain all context elements, that should be visualized as treenodes on the first hierarchy level of the UI tree. The tree leafs related to the nodesof the UI tree have to be stored in a non-singleton context node (N2_1), beingdefined as a sub node of context node N2.

In the view's layout, a view element of type Tree has to be created. The propertydataSource 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 tobe created as a direct sub element of the Tree. The dataSource property has to bebound 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 asa direct sub element of the Tree UI element. The property dataSource has to bebound 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 levelhierarchy. This means another UI element of type TreeItemType has to be definedas a direct sub element of the Tree UI element. Now, the property dataSource hasto 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. Bindingthe property expanded to a context attribute of type WDY_BOOLEAN, allows todefine 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 allowsto define an icon displayed left of each tree node. This overwrites the icon namedefined by the property defaultNodeIconSource of the Tree UI element. Finally,if ignoreAction is set to ABAP_TRUE, then the action assigned to the propertyonAction is not triggered (when clicking on the node's text). The hook methodsWDDOBEFOREACTION( ) and WDDOAFTERACTION( ) are also not processedby the Web Dynpro framework. However, clicking on a tree node's text will stillresult in a round trip.

Hint: Clicking on the text / icon related to a tree node will set the leadselection in the related node collection.

The concept described above can easily be extended to multiple hierarchy levelswith one or more node types per hierarchy level. For each context node having nosub nodes, one UI element of type TreeItemType has to be created to display thecontext elements as leafs in the UI tree. For each context node having sub nodes, aUI element of type TreeNodeType has to be defined in order to allow displayingand 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 notmapped to the UI element hierarchy. All TreeItemType UI elements andall TreeNodeType UI elements are defined as direct sub elements of theTree UI element. The data binding of the property dataSource defines thedependencies between nodes and leafs in the rendered tree.

EventsThe 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 boxdisplayed with the tree. Clicking on this icon will fire the event Expand. In thecorresponding action handler method, the id of the tree, the user has clicked oncan be determined from the parameter ID that is provided by the internal tableWDEVENT→PARAMETERS. The application has to care for the expansion ofthe tree nodes.

Hint: To allow expanding and collapsing a tree node dynamically, theproperty expanded of this TreeNodeType UI element has to be bound to acontext attribute of type WDY_BOOLEAN that is defined in the relatedcontext 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 relatedtree leaf (text or icon), not only a server round trip is provoked, but the hookmethods WDDOBERFOREACTION( ), WDDOAFTERACTION( ), and thecorresponding action handler method are processed. From the internal tableWDEVENT→PARAMETERS the following information can be extracted: The idof 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 theparameter PATH. Finally, the reference to the context element that is related to theselected 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 witha tree node. Technically, this property equals the TreeItem property onActiondiscussed above.

The event LoadChildren (property OnLoadChildren) is triggered, if the useropens a node. It is not triggered, if the user closes a node! If an action isassigned to this property, not only a server round trip is provoked, but the hookmethods WDDOBERFOREACTION( ), WDDOAFTERACTION( ), and thecorresponding action handler method are processed. From the internal tableWDEVENT→PARAMETERS the following information can be extracted: The idof the context node, the tree node is related to, can be extracted from the parameterID. The path to the context element that is related to the tree node is obtained fromthe parameter PATH. Finally, the reference to the context element that is related tothe tree node is provided by the parameter CONTEXT_ELEMENT.

Hint: If an action is assigned to the property onLoadChildren, thealgorithm for collecting dependent data and storing them in the contextmay be defined in the corresponding action handler method. This is ofspecial interest for trees with an dynamically defined hierarchy based onrecursion 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 repeatedcombinations of Nodes and LeafsThe tree structure can consists of a recursively repeated combination of nodes andleafs with an unknown number of hierarchy levels (e.g. the file system of a PCoperating system). In this case, the view context has to be defined in a way, that anunknown number of hierarchy levels can be created at runtime. This is realized intwo 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 hierarchylevels. In step two, a sub node of type Recursion Node has to be defined on anylevel of the context structure defined in step 1. This recursion node may repeatany statically defined node and all of its child nodes (defined in step 1). The nameof the context node to be repeated (parent node) has to be assigned to the propertyRepeated Node of the recursion node.

At runtime, the statically defined context structure related to the parent node iscloned if the recursion node is accessed the first time programmatically (e.g.method GET_CHILD_NODE( NAME = '<RECURSION_NODE>' )). The clonedstructure contains the recursion node, too. Thus cloning the context structure canbe repeated as often as desired.



Figure 102: Tree: Recursion nodes

The UI element hierarchy is defined as follows: A Tree UI element has to becreated in the view's layout. Next, for each context node containing child nodes, aTreeNodeType 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 elementhas to be created as a direct sub element of the Tree. Each of these TreeNodeTypeand TreeItemType UI elements can not only display the content of the staticallydefined context node bound to it, but also the content of the cloned context nodeshaving the same name.



Figure 103: Tree: Recursion nodes - creating UI element hierarchy anddefining data binding

Figure 104: Tree: Recursion nodes - relation between layout and contextstructure at runtime



Cloning the parent context node structure has to be triggered if the user opens a treenode that is bound to a context node being a parent of the recursion node and thisrecursion node has not been accessed yet. Thus, an action has to be assigned to theproperty onLoadChildren of this tree node. The algorithm to access to recursionnode, to read data related to the selected node and to store these data in the clonedcontext structure can then be defined in the corresponding action handler method.





Exercise 7: Displaying hierarchicalContent with a Tree UI Element

Exercise ObjectivesAfter completing this exercise, you will be able to:� Implement a Tree UI element

Business ExampleYou would like to enhance the functionality and ergonomics of your application.Now you would like to replace the NavigationList by a Tree UI element. Thisallows to hide / display the connections for each flight carrier on request.







Task 2:In order to display carriers and connections as nodes and items of a Tree UIelement, the context structure and the algorithm to fill the context structure needsto be adjusted. A first level hierarchy node has to store the names of the carriersand the information which of the context nodes are expanded / collapsed. A relatedsecond level hierarchy node has to store the texts displayed for the connectionsand the key field values for the connection.

1. Create a new node (name: NODES) in the component controller contextcontaining the attributes TEXT (type: STRING) and EXPANDED (type:WDY_BOOLEAN). This node will store the carriers. Make sure that the leadselection index will not be initialized automatically.




2. Create a new non-singleton node (name: ITEMS) as a sub node of nodeNODES in the component controller context. This new node has to containthe attributes TEXT (type: STRING), CARRID (type: S_CARR_ID, andCONNID (type: S_CONN_ID). Make sure that the lead selection indexwill not be initialized automatically.

3. Now the algorithm used to fill the context node needs to be adapted. Copythe component controller method DEFINE_NAV_LIST( ). Name the newmethod DEFINE_TREE( ).

Rewrite the source code of this method: At runtime, for each carrier a treenode has to be displayed. Expanding the tree node related to a carrier shoulddisplay 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) andLufthansa (CARRID = LH) should be collapsed when the view is displayedthe first time.

4. Replace the call of method DEFINE_NAV_LIST( ) in the componentcontroller hook method WDDOINIT( ) by the call of methodDEFINE_TREE( ).

5. OPTIONAL: Delete the context node NAVI_LIST and the controllermethod DEFINE_NAV_LIST( ).

Task 3:Replace the navigation list in the view MAIN_VIEW by a tree displaying thecontent of node NODES.

1. Copy the node NODES from the component controller context to the contextof view MAIN_VIEW and define the mapping between the nodes (mappingorigin 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 theminimum height should be 450 pixels. The root node should not be visiblebut a title should be displayed (Flight Connections). By default, the iconICON_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 asa sub element of the Tree UI element. For each context element of nodeNODES, this UI element should display a tree node. The value of theattribute NODES.TEXT should be displayed as the tree node's text. If the




context attribute NODES.EXPANDED of a given context element is set toabap_true, the related tree node should be expanded when displaying theview MAIN_VIEW the first time.

5. In order to display the tree items, create a TreeItemType UI element as asub element of the Tree UI element. For each context element of nodeITEMS, this UI element should display a tree item. The value of the attributeNODES.ITEMS.TEXT should be displayed as the tree item's text. Clickingon a tree item should result in displaying the related flights by the TableUI element.



Solution 7: Displaying hierarchicalContent with a Tree UI ElementTask 1:If you have finished the previous exercise, you can skip this task. Then, all changescan be implemented in the component you have created in your last exercise.










Task 2:In order to display carriers and connections as nodes and items of a Tree UIelement, the context structure and the algorithm to fill the context structure needsto be adjusted. A first level hierarchy node has to store the names of the carriersand the information which of the context nodes are expanded / collapsed. A relatedsecond level hierarchy node has to store the texts displayed for the connectionsand the key field values for the connection.

1. Create a new node (name: NODES) in the component controller contextcontaining the attributes TEXT (type: STRING) and EXPANDED (type:WDY_BOOLEAN). This node will store the carriers. Make sure that the leadselection index will not be initialized automatically.


b) Mark the root node. From the context menu of this node, chooseCreate→Node to define a new untyped context node (name: NODES).

c) Perform the following changes in respect to the properties of thisnew node: Set Cardinality to 0:n. Clear the check box related to theproperty 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. SetType = 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 nodeNODES in the component controller context. This new node has to containthe attributes TEXT (type: STRING), CARRID (type: S_CARR_ID, andCONNID (type: S_CONN_ID). Make sure that the lead selection indexwill 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 thenode's properties: Set Cardinality to 0:n. Clear the check box related tothe property Initialization Lead Selection. Make sure that the checkbox 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. Copythe component controller method DEFINE_NAV_LIST( ). Name the newmethod DEFINE_TREE( ).




Rewrite the source code of this method: At runtime, for each carrier a treenode has to be displayed. Expanding the tree node related to a carrier shoulddisplay 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) andLufthansa (CARRID = LH) should be collapsed when the view is displayedthe first time.

a) To copy a controller method, navigate on the tab Methods, set thecursor on the method's name and press the icon displaying two leavesand having the quick info Copy. Then press the icon right of this iconhaving the quick info Paste. In the following dialog enter the name ofthe new method and finish the dialog.

b) Double click on the method's name to edit the source code of methodDEFINE_TREE( ).

c) The algorithm consists of the following logical steps:

� Get all connections by calling the controller component methodGET_CONNECTIONS( ).

� Sort the internal table returned by this method by CARRID andCONNID.

� 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 orCARRID = LH set EXPANDED = ABAP_TRUE, for all othercarriers set EXPANDED = ABAP_FALSE.

Hint: Use method BIND_STRUCTURE( ) defined ininterface IF_WD_CONTEXT_NODE to create a newcontext element in the node NODES. This method willreturn the reference to the new context element.

� Get the reference to the node collection ITEMS related to thiscarrier id.

Hint: To access the node collection ITEMS correspondingto a certain carrier id, start with the context elementrelated to this carrier and access to dependent collectionby calling the method GET_CHILD_NODE( )




� For each connection create a context element in node collectionITEMS related to the carrier id. Set the attributes CARRID,CONNID according to the connection data and concatenateconnection number, departure city and destination to define thevalue of attribute TEXT.


4. Replace the call of method DEFINE_NAV_LIST( ) in the componentcontroller hook method WDDOINIT( ) by the call of methodDEFINE_TREE( ).


5. OPTIONAL: Delete the context node NAVI_LIST and the controllermethod 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 thecontent of node NODES.

1. Copy the node NODES from the component controller context to the contextof view MAIN_VIEW and define the mapping between the nodes (mappingorigin in component controller context).


b) Drag the node NODES from the component controller context and dropit to the root node of the view controller context. This will copy thenode structure and define the mapping in one step.

2. Delete the NavigationList UI element in the layout of viewMAIN_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 theminimum height should be 450 pixels. The root node should not be visiblebut a title should be displayed (Flight Connections). By default, the iconICON_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 tothe context node NODES.

4. In order to display the tree nodes, create a TreeNodeType UI element asa sub element of the Tree UI element. For each context element of nodeNODES, this UI element should display a tree node. The value of theattribute NODES.TEXT should be displayed as the tree node's text. If thecontext attribute NODES.EXPANDED of a given context element is set toabap_true, the related tree node should be expanded when displaying theview 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 thisproperty to the context node NODES.

c) Click on the button right of property text in order to bind this propertyto the context attribute NODES.TEXT.

d) Click on the button right of property expanded in order to bind thisproperty to the context attribute NODES.EXPANDED.

5. In order to display the tree items, create a TreeItemType UI element as asub element of the Tree UI element. For each context element of nodeITEMS, this UI element should display a tree item. The value of the attributeNODES.ITEMS.TEXT should be displayed as the tree item's text. Clickingon a tree item should result in displaying the related flights by the TableUI element.

a) From the context menu of the Tree UI element, choose Insert NodeType. In the following dialog select Type = TreeItemType.

b) Click on the button right of property dataSource in order to bind thisproperty to the context node NODES.ITEMS.




c) Click on the button right of property text in order to bind this propertyto the context attribute NODES.ITEMS.TEXT.

d) Assign the action GET_DETAILS to the property onAction of theTreeItemType UI element. Use the drop down box to select and assignthis (already existing) action.

e) Adopt the source code of this method since the key of the selected treeleaf 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.


METHOD wddoinit .

wd_this->define_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� Create dynamic trees having an undefined number of hierarchy levels


NET312 Lesson: Additional complex UI Elements

Lesson: Additional complex UI Elements

Lesson OverviewIn this lessons, interesting complex UI elements other then TableView and Treeare discussed in detail. Theses are the DateNavigator, the PhaseIndicator, andthe RoadMap.


� Implement the DateNavigator UI element� Implement the PhaseIndicator UI element� Implement the RoadMap UI element

Business ExampleYou have to enrich your Web Dynpro application by adding the elementsDateNavigator, PhaseIndicator, and RoadMap to the UI element hierarchy of aview being part of your application. However, there are so many properties andaggregations ...

The DateNavigator UI ElementThe 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 aday, on a week, or on a month in order to select dates or date ranges. He can alsonavigate to months that are actually not displayed.

Single days or day ranges can be colorized. Finally, a legend can be addedcontaining explanations for the days and day ranges that have been colorized.



Figure 105: DateNavigator

Defining the ContextCreating a context structure is not obligatory to define a DateNavigator UIelement. However, if certain dates or date ranges are to be colorized, or if anadditional legend is to be displayed, corresponding context structures need to bedefined.

To store information about the colorized days, a context node has to be createdcontaining three context attributes. At runtime, each context element definedin this node will describe one colorized day. The first attribute being of typeWDUI_DATE_MARKING_CATEGORY allows to assign each day to one of fourpossible categories. The second attribute (type WDUI_TABLE_CELL_DESIGN)can be used to change the category color. The third attribute contains the dateand 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 oftype WDUI_DATE_MARKING_CATEGORY is used to assign the legend text toone of four possible categories. The legend text is stored in a second attributeof type STRING.

Context elements related to the DateNavigator functionality will be discussed inthe next section.



UI Element Definition and Data BindingThe DateNavigator UI element can be defined as a sub element of any containerUI 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, aweek, 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 DateNavigatoris also suppressed. firstDayOfWeek defines which day will be displayed as thefirst day of any week. This property may be bound to a context attribute of typeWDUI_DAY_OF_WEEK.

firstSelectedDate and lastSelectedDate can be used to define the beginning and theend of a date range. This date range is colorized, if the property selectionModeis set to range. However, if the value of this property is single, only the dategiven by firstSelectedDate is colorized. If range is set to none, the date given byfirstSelectedDate is also not colorized. The property startsWith allows to definethe first month displayed by the DateNavigator. This property may be bound to acontext attribute of type D, so the first month can be defined programmatically.

Caution: If the value of the property startsWith is initial, the applicationwill dump.

The properties monthsPerColumn and monthsPerRow allow to define a grid. Ineach grid cell one month is displayed. Thus, the total number of months displayedby the DateNavigator is given by the product of these two integers.

Figure 106: DateNavigator: Binding UI element properties



EventsThe following events are supported by the DateNavigator UI element:

The event DaySelect (property onDaySelect) is triggered if the user clicks on anarbitrary day. If an action is assigned to this event, the related action handlermethod is processed by the Web Dynpro framework and event specific informationcan be extracted from the interface parameter WDEVENT. The internal tableWDEVENT→PARAMETERS contains the id of the DateNavigator the user hasclicked on (parameter: ID) and the selected date (parameter: DAY).

The eventWeekSelect (property onWeekSelect) is triggered if the user clicks on anarbitrary week number. If an action is assigned to this event, the related actionhandler method is processed by the Web Dynpro framework and event specificinformation can be extracted from the interface parameter WDEVENT. Theinternal table WDEVENT→PARAMETERS contains the id of the DateNavigatorthe user has clicked on (parameter: ID), the week number (parameter: WEEK),and the year (parameter: YEAR).

The eventMonthSelect (property onMonthSelect) is triggered if the user clicks onan arbitrary month name. If an action is assigned to this event, the related actionhandler method is processed by the Web Dynpro framework and event specificinformation can be extracted from the interface parameter WDEVENT. Theinternal table WDEVENT→PARAMETERS contains the id of the DateNavigatorthe 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 theuser navigates to months actually not displayed by clicking on the correspondingicons displayed with the DateNavigator. If an action is assigned to this event,the related action handler method is processed by the Web Dynpro frameworkand event specific information can be extracted from the interface parameterWDEVENT. The internal table WDEVENT→PARAMETERS contains the id ofthe DateNavigator the user has clicked on (parameter: ID) and the date of thefirst 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 isno overlap and no gap between the months displayed before and afternavigating. However, the DateNavigator contains the property startsWith.If this property is bound to a context attribute, the navigation shift can bedefined arbitrarily.



AggregationsIf arbitrary days or date ranges are to be colorized, the DateNavigatorMark UIelement has to be used. This UI element has to be defined as a sub element of theDateNavigator. The DateNavigatorMark has the following properties:

dataSource has to be bound to a context node that contains the information aboutwhich days are to be colorized. At runtime, this node has to contain a contextelement for each day to be colorized.

The property date has to contain the date of a day to be colorized. Thus, thisproperty has to be bound to the appropriate context attribute defined in the datasource node.

The property category allows to assign a category to the marked days. Bindingthis property to an attribute of typeWDUI_DATE_MARKING_CATEGORY allowsto assign the category dynamically. If this attribute is defined in the data sourcenode, the category assignment can be defined day-specific.

Four categories do exist. Days belonging to the same category may be displayedin the same color (color depends on the category) and a common legend maybe 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 thisproperty to an attribute of type WDUI_TABLE_CELL_DESIGN allows to set thecolor dynamically. If this attribute is defined in the data source node, the semanticcolor can be defined day-specific.

Hint: The color palette used to define the background color of a table cellis identical to the color palette used to define the background of singledays in a DateNavigator.



Figure 107: DateNavigator: Colorizing days

To define a legend which is displayed in the box displayed with the calendersheets, the UI element DateNavigatorLegend has to be used. This UI element hasto be defined as a sub element of the DateNavigator.

The property dataSource has to be bound to a context node that contains thelegend information. At runtime, this node has to contain a context element foreach legend text to be displayed.

The property category has to be bound to an attribute of typeWDUI_DATE_MARKING_CATEGORY. At runtime, this attribute has to containthe category name. The corresponding color will be displayed in front of thelegend texts. If this attribute is defined in the data source node, the categoryassignment can be defined differently for each legend text.

Finally, the value of the property text is displayed as the legend's text. However, ifthis 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 datasource node. Thus, this property should be bound to attribute of type STRINGdefined in the data source node.



Figure 108: DateNavigator: Defining legend

The PhaseIndicator UI ElementThe PhaseIndicator UI element allows to visualize the single steps of a process.Each step is represented by a separate phase object. The application can definewhich of the phases is the first phase to be displayed and which phase is theactually selected phase (emphasized). Each phase can be disabled, so clicking onthe phase does not trigger a round trip to the server. For each phase a text can bedisplayed. Optionally an icon can be displayed indicating the status of the phase.Each phase can be hidden.



Figure 109: PhaseIndicator

Defining the ContextThe definition of context nodes and context elements is not mandatory toimplement a PhaseIndicator UI element.

UI Element Definition and Data BindingTo implement the phase indicator in the view's layout, the following steps arenecessary:

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 asa sub element of the PhaseIndicator UI element. Choose the corresponding entryin 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 ofthe PhaseIndicator. If this property is set to transparent, the color of the parentcontainer element will be displayed.

If the property enabled is set to ABAP_FALSE, all phases are disabled. The textsdisplayed by the phases are grayed out. In addition, clicking on a phase will nottrigger a round trip to the server any more.

If the id of a Phase or of aMultiPhase is assigned to the property firstVisiblePhase,then this phase will be the first visible phase. Phases that are defined before thefirst 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

EventsOnly one event (Select - property onSelect) is supported by the PhaseIndicatorUI element. This event is fired if the user clicks on any phase that has not beendisabled. If an action is assigned to this event, the action handler method is alsoprocessed. From the interface parameterWDEVENT, the PARAMETERS table canbe extracted. This contains the id of the PhaseIndicator (ID) and the id of thePhase / MultiPhase the user has clicked on (parameter: Phase).

AggregationsEach 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 PhaseUI element is defined by the value of the property description. If the propertyenabled is set to ABAP_FALSE the text displayed by the phases are grayed outand 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 fromnormal). A phase can be hidden by setting the property visible of the relatedPhase UI element to ABAP_FALSE.



TheMultiPhase 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 hasto be bound to the property dataSource of the MultiPhase UI element. For eachproperty of theMultiPhase that should depend on the selected phase, an additionalcontext attribute has to be defined in the data source node. These context attributeshave to be bound to the corresponding UI element properties. At runtime, eachphase is represented by a context element stored in the data source node. Thecontext element at lead selection will be displayed by theMultiPhase UI element.

Figure 111: PhaseIndicator: Defining phases (here: MultiPhase UI element)

Caution: The application will dump if non of the context elements storedin the data source node is the element at lead selection (lead selectionindex ≤ 0).

The RoadMap UI ElementThe RoadMap UI element is used to display step by step workflows. This enablesan 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 stepobject being bound to a data source node. Steps can have sub steps. Varioussymbols 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 thatadditional steps are displayed before the first visible step or after the last visiblestep, respectively.

Figure 112: RoadMap

Defining the ContextFor a statically defined RoadMap UI element, no special context elements haveto be created. However, a connected series of steps may also be visualizes by asingle MultipleRoadMapStep UI element that has to be bound to a context nodecontaining the step information. In this case, the context node should contain anumber of attributes to store the step's id (type STRING), the name displayed onthe step (type STRING), the description displayed below the step (type STRING),and the kind of the step (type WDUI_ROAD_MAP_STEP_TYPE). Dependingon the requirements it may also be necessary to add an attribute describing thestep's visibility (type WDY_BOOLEAN) and an attribute allowing to disable astep (type WDY_BOOLEAN).

UI Element Definition and Data BindingThe RoadMap UI element can be defined as a sub element of any containerelement. The following properties are of interest:

All steps may be disabled by setting the property enabled to ABAP_FALSE. Thestep, its name and description will be displayed grayed out and clicking on thestep will not result in a server round trip.



The end point design and the start point design of the RoadMap UI elementcan be defined by setting the properties startPointDesign and endPointDesignaccordingly. Depending on the selected value of these properties the user maytrigger a server round trip when clicking on the related symbols. These propertiesmay be bound to context attributes of typeWDUI_ROAD_MAP_EDGE_DESGIN.

The property selectedStep has to be evaluated with the id of the RoadMapStepto be displayed emphasized. Binding selectedStep to a context attribute of typeSTRING allows to set the selected step programmatically.

If a MultipleRoadMapStep is used to define multiple steps dynamically, the id ofthe MultipleRoadMapStep has to be assigned to selectedStep. In this case, the stepbound to the context element at lead selection will be displayed emphasized.

Figure 113: RoadMap: Defining the UI and data binding

EventsThe RoadMap UI element supports two events: LoadSteps (propertyOnLoadSteps) 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 propertyonLoadSteps, the following parameters can be extracted from the interfaceparameter WDEVENT: The parameter ID contains the id of the RoadMap UI



element the user has clicked on. The parameter AT_END contains the informationif 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 tothe property onSelect, the following parameters can be extracted from the interfaceparameter WDEVENT: The parameter ID contains the id of the RoadMap UIelement the selected step belongs to. The parameter STEP contains the id of thestep the user has clicked on.

AggregationsA single steps of a RoadMap UI element can be defined statically by adding aRoadMapStep UI element to the UI element hierarchy (as a sub element of theRoadMap UI element).

The property description allows to define a text which is displayed below thestep. The property enabled allows to disable this step (value = ABAP_FALSE).The value of the property name is displayed on the step. The property visibleallows to toggle the visibility of the step. Finally, the value of the property typeallows 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 beselected), and roundTripClosed (to be used for a parent step if sub steps arehidden).

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 multipleconnected road map steps. This allows to define parts of the road map orthe complete road map programmatically. The information of the step has tobe stored in a context node that is bound to the property dataSource of theMultipleRoadMapStep UI element. At runtime, this context node has to contain acontext 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 betweenproperty 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 RoadMapStepUI element

Hint: The steps of a RoadMap UI element may be defined by acombination of RoadMapStep and MultipleRoadMapStep UI elements.

Hint: If the user clicks on any element that is related to aMultipleRoadMapStep UI element, then the parameter STEP (availablefrom the internal table WDEVENT→PARAMETERS in the correspondingaction handler method) contains the id of the MultipleRoadMapStep UIelement. To find out which of the steps was selected by the user, theparameter CONTEXT_ELEMENT has to be examined. This elementcontains the reference to the related context element stored in the datasource node collection.





Exercise 8: Implementing a DateNavigatorUI element

Exercise ObjectivesAfter completing this exercise, you will be able to:� Implement a DateNavigator UI element

Business ExampleYou would like to enhance the functionality and ergonomics of your application.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 thedistribution of the flights along the timeline more easily. Thus you would like todisplay the flight dates by a DateNavigator UI element on the second tab. Thebackground colors used to highlight the flight dates should indicate the relativeoccupation in the economy class for each flight.










Task 2:Implement the DateNavigator UI element.

First, you have to create a context node in the component controller containingone attribute of type D. This attribute has to store the information which month isthe first month to be displayed by the date navigator. This should correlate withthe 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 DateNavigatorUI element is rendered having the property startsWith set to its initialvalue '00000000'.

Then, you have to copy this new component controller node to the viewMAIN_VIEW and map the two nodes (origin: component controller context).

Finally, you have to define the DateNavigator UI element on the second tab ofthe tab strip in order to display the flight dates. The background color used tocolorize the flight dates should be identical to the colors used in the table columndisplaying the occupied seats in the economy class. The DateNavigator shoulddisplay 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 nameDEFINE_START_DATE( ). This method has to set the attributeDATE_NAV_SETTINGS.START_DATE. The method should have an optionalinterface parameter (name: IV_START_DATE) of type D.

If a value is supplied to this parameter, this value has to be stored in thecontext attribute DATE_NAV_SETTINGS.START_DATE.

If no value is supplied to this parameter, the start date should equal the flightdate of the earliest flight related to the selected connection.

3. To initialize the attribute DATE_NAV_SETTINGS.START_DATE, call themethod DEFINE_START_DATE( ) from the hook methodWDDOINIT( ) ofthe component controller. Pass the actual date to the method.

Hint: The DateNavigator UI element can only be rendered, if thestart date has a reasonable value (not initial).




4. Every time the user selects a new connection, dependent flights are read andthe method DEFINE_COLORS( ) is processed. Make sure, that the methodDEFINE_START_DATE( ) is processed, too.

5. Copy the node DATE_NAV_SETTINGS from the component controllercontext to the context of view MAIN_VIEW. Map the copied node to thecomponent controller node DATE_NAV_SETTINGS.

6. Now create the DateNavigator UI element on the second tab of theTabStrip UI element. Bind the property startsWith to the attributeDATE_NAV_SETTINGS.START_DATE. 12 months should be displayed in 3rows. Clicking on a day should not colorize this day.

7. The last step to finalize the date navigator is to define aDateNavigatorMarking UI element as a sub element of the DateNavigatorUI element. Bind the relevant properties to the node FLIGHTS and itsattributes, respectively



Solution 8: Implementing a DateNavigatorUI elementTask 1:If you have finished the previous exercise, you can skip this task. Then, all changescan be implemented in the component you have created in your last exercise.










Task 2:Implement the DateNavigator UI element.

First, you have to create a context node in the component controller containingone attribute of type D. This attribute has to store the information which month isthe first month to be displayed by the date navigator. This should correlate withthe 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 DateNavigatorUI element is rendered having the property startsWith set to its initialvalue '00000000'.

Then, you have to copy this new component controller node to the viewMAIN_VIEW and map the two nodes (origin: component controller context).

Finally, you have to define the DateNavigator UI element on the second tab ofthe tab strip in order to display the flight dates. The background color used tocolorize the flight dates should be identical to the colors used in the table columndisplaying the occupied seats in the economy class. The DateNavigator shoulddisplay 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 tocreate the new node DATE_NAV_SETTINGS. Finish the dialog.

c) From the context menu of node DATE_NAV_SETTINGS, chooseCreate→Attribute to create the attribute START_DATE. Set Type =D and finish the dialog.

2. Define a new component controller method having the nameDEFINE_START_DATE( ). This method has to set the attributeDATE_NAV_SETTINGS.START_DATE. The method should have an optionalinterface parameter (name: IV_START_DATE) of type D.

If a value is supplied to this parameter, this value has to be stored in thecontext attribute DATE_NAV_SETTINGS.START_DATE.




If no value is supplied to this parameter, the start date should equal the flightdate 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 methodin column Method. Double-click on the method's name to edit themethod's source code.

c) Define the interface parameter. Put the parameter's name in the fieldParameter. Choose Type = Importing, Associated Type = D, and checkthe check box Opt.

d) Implement the source code:

If IV_START_DATE is initial, copy the content of node FLIGHTS toan 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_DATEas the attribute value.


3. To initialize the attribute DATE_NAV_SETTINGS.START_DATE, call themethod DEFINE_START_DATE( ) from the hook methodWDDOINIT( ) ofthe component controller. Pass the actual date to the method.

Hint: The DateNavigator UI element can only be rendered, if thestart date has a reasonable value (not initial).


4. Every time the user selects a new connection, dependent flights are read andthe method DEFINE_COLORS( ) is processed. Make sure, that the methodDEFINE_START_DATE( ) is processed, too.

a) The source code related to the selection of a new connection is storedin the action handler method ONACTIONGET_DETAILS( ). Insertthe call of method DEFINE_START_DATE( ) at the end of the sourcecode section.





5. Copy the node DATE_NAV_SETTINGS from the component controllercontext to the context of view MAIN_VIEW. Map the copied node to thecomponent controller node DATE_NAV_SETTINGS.


b) Drag the node DATE_NAV_SETTINGS from the component controllercontext and drop it on the root node of the context of viewMAIN_VIEW.

6. Now create the DateNavigator UI element on the second tab of theTabStrip UI element. Bind the property startsWith to the attributeDATE_NAV_SETTINGS.START_DATE. 12 months should be displayed in 3rows. 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 toTab in order to create a DateNavigator UI element.

d) Click on the button right of the property startsWith to bind this propertyto the attribute DATE_NAV_SETTINGS.START_DATE.

e) Set the properties monthsPerColumn = 3, monthsPerRow = 4, andselectionMode = none.

7. The last step to finalize the date navigator is to define aDateNavigatorMarking UI element as a sub element of the DateNavigatorUI element. Bind the relevant properties to the node FLIGHTS and itsattributes, respectively

a) From the context menu of the DateNavigator UI element, choose InsertSelection in order to create a DateNavigatorMarking UI element.

b) Click on the button right of the property dataSource to bind thisproperty to the node FLIGHTS.

c) Click on the button right of the property date to bind this property tothe attribute FLIGHTS.FLDATE.

d) Click on the button right of the property day_semantics to bind thisproperty to the attribute FLIGHTS.COLOR.

Result

Comp. Controller: DEFINE_START_DATE( )

METHOD define_start_date .





DATA lo_el_flights TYPE REF TO if_wd_context_element.



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.


METHOD wddoinit .

wd_this->define_tree( ).

wd_this->define_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� Implement the PhaseIndicator UI element� Implement the RoadMap UI element


NET312 Unit Summary

Unit SummaryYou should now be able to:� 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

Related Information

� The online documentation for SAP NetWeaver 7.0 contains an excellentsection about developing applications based on Web Dynpro ABAP. TheWeb Dynpro ABAP documentation contains a section named Reference.Here you can find a complete documentation of all UI elements and thecorresponding element classes. UI elements discussed in this unit can befound in the sub section named Complex Category.

� In each SAP system based on SAP NetWeaver 7.0, standard Web DynproABAP demo applications are available. Demos dealing with UI elements ingeneral are WDR_TEST_EVENTS, WDR_TEST_UI_ELEMENTS.

Special demos only dealing with the TableView UI element areWDR_TEST_TABLE and WDT_TABLE.

Special demos dealing with Tree UI element are WDR_TEST_TREE and thedemos beginning with WDT_TREE.


Unit Summary NET312


Unit 4Defining Graphics

Unit Overviewin this unit, UI elements to create presentation graphics are explained. Since theBusinessGraphics UI element is the most important one in this category, it willbe covered in an extra lesson. Other UI elements capable to define graphics aresummarized in the second lesson of this unit.


� Define the context nodes and context attributes to store the data displayed bythe 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 ContentsLesson: The BusinessGraphics UI Element.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .216

Exercise 9: Defining Presentation Graphics .. . . . . . . . . . . . . . . . . . . . . . . . . . .231Lesson: Additional UI Elements to define Presentation Graphics .. . . . . . .238

Exercise 10: Implementing the ValueComparison UI Element ... . . . .249


Unit 4: Defining Graphics NET312

Lesson: The BusinessGraphics UI Element

Lesson OverviewThe BusinessGraphics UI element can be used to display graphical illustrations ofdata and data relationships. These graphics are rendered by the Internet GraphicsService (IGS), which is an integral part of the SAP NetWeaver 7.0. Not onlya large variety of chart types is available but, in addition, these charts can beadapted using the Chart Designer.

This lesson describes in detail how to define the view's layout using theBusinessGraphics UI element and the dependent element types Category,SimpleSeries, Series, Points and NumericValues.


� Define the context nodes and context attributes to store the data displayed bythe 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

Business ExampleThe graphical representation of numerical data should be implemented by yourapplication.

Internet Graphics Service (IGS)The Internet Graphics Service (IGS) constitutes the infrastructure to enable theapplication developers to display graphics in an Internet browser with a minimumof effort. The IGS has been integrated in the different SAP UI technologies fromHTML GUI to Web Dynpro ABAP/Java and provides a server architecture wheredata from an SAP system or another source can be used to generate graphical ornon-graphical output. Until SAP Web Application Server 6.20, the IGS has beenavailable only as standalone engine. As of SAP Web Application Server 6.40, theIGS is additionally available as integral part of the SAP Web AS and will beinstalled with every SAP Web AS installation. Thus, with SAP Web AS 6.40, youhad the choice to use either the standalone or the integrated IGS. And as of SAPNetWeaver 7.0 only the integrated IGS version should be used. The integratedIGS exists on every SAP NetWeaver Application Server and is started and stoppedwith the SAP NetWeaver Application Server. However, IGS is not part of thekernel 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 RFCdestination. For the integrated IGS version, the necessary RFC destinationIGS_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 ChartDesigner. The Chart Designer is a tool that enables you to influence the propertiesof the graphical elements such as chart type, size, layout, color, and shading. Toedit BusinessGraphics UI elements the Chart Designer can be called directlyfrom the view designer.

One or multiple series of data points may be displayed by a BusinessGraphicsUI 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 onenumerical value (e.g. describing the y-value in a coordinate system), or bymultiple 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). Inaddition the point description may contain a time value (e.g. in combination witha 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 thepoints may be included.



Figure 116: BusinessGraphics

Defining the ContextTo allow storing an arbitrary number of data series, each data series consistingof an arbitrary number of data points and each data point being described by anarbitrary combination of numerical values (e.g. x, y, size) or time values, thecontext can be defined as follows:

Series node: On the first hierarchy level, a context node has to be defined tostore the series information. At runtime, a context element for each data serieshas to be created.

Point node: On the second hierarchy level, a context node (non-singleton) hasto be defined as a sub node of the series node. This node will store the pointinformations for all data series. At runtime, a separate node collection will existfor each data series. For each collection the application has to create as manycontext 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 bedefined as a sub node of the point node. This node will store the detail informationfor all data points of one series. At runtime, a separate node collection will existfor each data point. For each collection the application has to create as manycontext elements as informations are related to this data point. Each informationcan be a numerical value (e.g. x-value, y-value, size ...), or a time value (date ortimestamp).



For category-based graphic types, the descriptions of the categories has to bestored in the context, too. For this reason a separate context node should be createdon the first hierarchy level. At runtime, for each category a context element has tobe created containing the description of this category. Categories and data pointsare correlated according to their index. This means that for each data series, thedata 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 thegraphic types:

� Simplification 1: If all points of all series are described identically (e.g. bya y-value), then related attributes can be added to the point node (e.g. anattribute Y_VALUE). The value node can then be dropped.

� Simplification 2: If the number of series is known at design time, ifthis number is fix and if the graphic type used to display the data iscategory-based, then a common point node can be defined to store the pointinformation for all points of all series. For each point value of each series, anattribute 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 bestored with the point information (another attribute in the point node) and noextra category node needs to be defined.



Figure 119: BusinessGraphics: Defining the context - simplification 1





Defining the UI and Data BindingThe BusinessGraphics UI element can be added to any container element in theUI element hierarchy.

In the general case, a Series UI element is defined as a direct sub element of theBusinessGraphics UI element. This allows to display an arbitrary number of dataseries for a category based or for a non-category based graphics. The path to thecontext node containing the series information has to be assigned to the propertyseriesSource of the BusinessGraphics UI element.

Next, a single Point UI element has to be created as a direct sub element of theSeries UI element. This element is used to access the point information stored inthe context. The path to the context node containing the point information has tobe 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 accessone 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 scattergraphics). The path to the context node containing the value information has to beassigned to the property valueSource of the Point UI element.



For category based graphics, an additional Category UI element should be addedto the UI element hierarchy as a direct sub element of the BusinessGraphics UIelement. 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 propertycategorySource of the BusinessGraphics UI element.

Figure 122: BusinessGraphics: Defining the UI and data binding - generalcase (1)



Figure 123: BusinessGraphics: Defining the UI and data binding - generalcase (2)

If the context structure is simplified in respect to the general case, then the UIelement hierarchy has to be adjusted accordingly. The following discussion refersto the situations described in the sub section dealing with the context definition.

Simplification 1: The context node containing the value information is identicalto the point node. Thus the property valueSource of the Point UI element and theproperty pointSource of the Series UI element have to be evaluated identically.

Simplification 2: Depending on the complexity of the point description, twoimplementations are possible:

Case 1: The point node contains the information about one data series. However,each data point is described bymultiple values (e.g. displaying ranges by floatingcolumns - here the minimal and the maximal value of the range is stored foreach data point).

In this case, the UI element hierarchy as described for the general case is notchanged. However, the property seriesSource of the BusinessGraphics UI element,the property pointSource of the Series UI element, and the property valueSourceof the Point UI element have the same value. All of these properties have to beevaluated with the path to the context node containing the point information.

Case 2: The point node contains the information about one or multiple dataseries. 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 theBusiness GraphicsUI element. The property seriesSource of the BusinessGraphicsUI element has to be evaluated with path to the context node containing the pointinformation. The path to the context attribute containing the y-value has to beassigned to the property value of the SimpleSeries UI element.

Simplification 3: In addition to the setup discussed for simplification 2, theproperties categorySource and seriesSource of the BusinessGraphics UI elementhave to be evaluated identically.

Figure 124: BusinessGraphics: Defining the UI and data binding - displayingdata ranges (1)



Figure 125: BusinessGraphics: Defining the UI and data binding - displayingdata ranges (2)

Figure 126: BusinessGraphics: Defining the UI and data binding - displayingsimple category-based graphics



Properties of the BusinessGraphics UI ElementBesides the properties used to bind the series node and the category node, theBusinessGraphics 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 theindex 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_threeand 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 byclicking on data point or by clicking on the legend. If the property enabled is setto ABAP_FALSE, this feature is disabled.

The height and the width of the graphics can be adjusted by setting the parametersheight and width accordingly (in pixels).

By default, the IGS is connected as defined by the RFC destinationIGS_RFC_DEST. However, the property igsUrl allows to assign a different IGSby 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. Thistool is started from the context menu of the BusinessGraphics UI element (EditCustomizing).

Hint: This menu item is only available if the view is edited.

After having finished the adoption process (closing the Chart Designer by clickingon Enter), an XML file is created containing all delta information. This XML fileis 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 propertycustomizing of the BusinessGraphics UI element. If multiple customizing files doexist, 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 hasto be determined in the hook method WDDOMODIFYVIEW( ) of therelated view. The method handler for the BusinessGraphics UI element isprovided by the public attribute _METHOD_HANDLER of the elementreference. Finally, the reference to the method handler has to be casted toa reference variable of type IF_WD_BUSIN_GRAPHICS_MTD_HNDLto access the functionality specific for business graphics. This interfaceprovides the functionality to set, change and clear customizing data forthe graphics.

Properties of the Category UI ElementThe property description allows to define the text to be displayed as the categorydescription. If a value is assigned to the property eventID, then clicking on thecategory text will trigger the event Action that is related to the BusinessGraphicsUI element. If an action is assigned to the related property onAction, then thevalue of the property eventID can be accessed in the action handler method.

Properties of the Series UI ElementMultiple data series may be stored in the context node that is bound to the SeriesUI element. The properties dataBeginIndex and dataLength allow to define whichdata series is the first one to be displayed (the first data series has the index 0!) andhow many of the data series are to be displayed. The property showSelectedOnlyallows to restrict this number of data series using a different approach. If thisproperty is set to ABAP_TRUE, then only data series having the related contextelement in the series node marked as selected will be displayed.

The value of the property label is used to generate the legend displayed belowthe diagram.

It is also possible to adopt the properties of each data series separately. In orderto do this, series elements can be defined in the customizing file created by theChart Designer. Each series element is identified by its name. It allows to saveproperties related to data series (e.g. the line style, the shape, size, and color of thedata points, if a legend is to be displayed, the font, font-size, and font-color... ). Toactually use this adoption information for a certain data series, the name of theseries element defined in the customizing file has to be assigned to the propertycustomizingID of the Series UI element. Since this property may be bound toa context attribute, each data series may be displayed differently. Finally, theproperty leadSelectionCustomizingID allows to adopt the series having the leadselection set to ABAP_TRUE in a defined manner.



Properties of the Point UI ElementLabels for the single data points can be assigned to the property label of thePoint UI element. However, to display these texts, a customizing file containingthe related adoption information has to be assigned to the BusinessGraphics UIelement.

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 theBusinessGraphics UI element. If an action is assigned to the related propertyonAction, then the value of the property eventID can be accessed in the actionhandler method. Using data binding, it is possible to assign a unique value for theeventID to each data point of each data series.

It is possible to adopt the properties of each data point separately. In order todo 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 saveproperties related to data points (e.g. the shape, size, and color of the data point, ifthe label is to be displayed, the font, font-size, and font-color... ). To actually usethis adoption information for a certain data point, the name of the point elementdefined in the customizing file has to be assigned to the property customizingIDof 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 ElementsBoth 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 stringsare dates (YYYYMMDD) or timestamps (YYYYMMDD;HHMMSS orYYYYMMDD;HHMMSSZZZ).

For the NumericValue UI element, the property type is of importance. Allowedvalues are x, y, size, trendx, trendy, and chart.

trendx and trendy allow to define arrows connecting data points. The type chartallows to display a mini bar chart at the point's position. size describes the size ofthe square (default design) displayed in the diagram.



Figure 127: BusinessGraphics: Displaying trend lines and charts

Properties of the SimpleSeries UI ElementThe 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 correspondingsetter method has to be called in the hook methodWDDOMODIFYVIEW( ).

EventsThe BusinessGraphics UI element does support the event Action. This event isfired, if the user clicks on any selectable object being part of the graphics. Thismay be a category text, a legend text or a data point (a bar, a column, a point...). Ifan action is assigned to the related property onAction, the related action handlermethod is processed by the Web Dynpro framework. From the interface parameterWDEVENT of this action handler, the internal table PARAMETERS can beextracted. This internal table contains two parameters:

The id of the UI element the user has selected (Category, Series, Point, orSimpleSeries) is provided by the parameter ID. The value of the property eventIDof the selected UI element is provided by the parameter EVENT_ID.



Exercise 9: Defining PresentationGraphics

Exercise ObjectivesAfter completing this exercise, you will be able to:� Implement the BusinessGraphics UI element

Business ExampleYou would like to enhance the functionality and ergonomics of your application.In addition to the Table UI element displaying the flights on the first tab, and theDateNavigator UI element illustrating the flight dates on the second tab, youwould like to add a graphics displaying the occupied seats of all flight classes onthe third tab.


Solution Component: NET312_GRPH_S1


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 copyZNET312_GRPH1_##. Assign this component to your package ZNET312_##.Create an application having the same name as your component and assign theapplication to your package, too.



Task 2:Define a BusinessGraphics UI element on the rightmost tab of the TabStrip UIelement. 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, thisattribute has to contain the flight date in the external representation.

2. Create a new component controller method having the nameDEFINE_DATE_FORMATTED( ). For all flights, define the value ofattribute FLIGHTS.DATE_FORMATTED by this method.




3. Call the new method DEFINE_DATE_FORMATTED( ) if the user clicks ona new connection in the tree.

4. Actualize the mapping of node FLIGHTS in the context of viewMAIN_VIEW.

5. Define a BusinessGraphics UI element on the rightmost tab of the TabStripUI element. The pseudo three dimensional profile area should occupy aheight of 400 pixels and a width of 600 pixels and it should display datastored in node FLIGHTS.

6. Define the category axis displaying the formatted date of the flights. Foreach 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 PresentationGraphicsTask 1:If you have finished the previous exercise, you can skip this task. Then, all changescan be implemented in the component you have created in your last exercise.







TYPE

Task 2:Define a BusinessGraphics UI element on the rightmost tab of the TabStrip UIelement. 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, thisattribute has to contain the flight date in the external representation.


b) From the context menu of node FLIGHTS, choose Create→Attributeto create the attribute DATE_FORMATTED. Set Type = STRING andfinish the dialog.




2. Create a new component controller method having the nameDEFINE_DATE_FORMATTED( ). For all flights, define the value ofattribute FLIGHTS.DATE_FORMATTED by this method.

a) Now edit the methods of the component controller.

b) Enter the name of the new method in columnMETHODS. Double-clickon the method's name to edit the source code.

c) Copy the content of node FLIGHTS to an internal table. Loop overthe internal table. For each flight set the field DATE_FORMATTEDand modify the data set in the internal table. Finally, bind the internaltable 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 ona new connection in the tree.

a) If the user clicks on a connection displayed by the tree, the actionhandler method ONACTIONGET_DETAILS( ) is processed. Call ofthe component controller method DEFINE_DATE_FORMATTED() in this action handler method.




b) From the context menu of node FLIGHTS, choose Update Mapping.

5. Define a BusinessGraphics UI element on the rightmost tab of the TabStripUI element. The pseudo three dimensional profile area should occupy aheight of 400 pixels and a width of 600 pixels and it should display datastored in node FLIGHTS.


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 toTab and select Type = BusinessGraphics on the next dialog. Finishthe dialog.

c) Set the properties of the BusinessGraphics UI element as follows:chartType= profile_area, dimension = pseudo_three, height = 400, andwidth = 600. Do not forget to set seriesSource = FLIGHTS.




6. Define the category axis displaying the formatted date of the flights. Foreach flight class display the occupation as a function of the formatted date.

a) From the context menu of the BusinessGraphics UI element, chooseInsert Category.

b) Click on the button right of the UI element property descriptionin order to bind this property to the context attributeFLIGHTS.DATE_FORMATTED.

c) From the context menu of the BusinessGraphics UI element, chooseInsert 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 tobind this property to the context attribute FLIGHTS.SEATSOCC_F. Inaddition, define a legend text by assigning the text literal Occupiedseats in first class to the property label.

e) Repeat the last two steps to display the occupied seats in the businessclass (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 usingthe Chart Designer.

a) From the context menu of the BusinessGraphics UI element, chooseEdit Customizing to start customizing your graphics.

b) Change any settings and save your customizing data set by clickingon the Enter button.

Result

Comp. Controller: DEFINE_DATE_FORMATTED()

METHOD define_date_formatted .




DATA lv_date_formatted TYPE c LENGTH 10.



LOOP AT lt_flights INTO ls_flights.




WRITE ls_flights-fldate TO lv_date_formatted.

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

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



Lesson: Additional UI Elements to define PresentationGraphics

Lesson OverviewThis lesson deals with special UI elements that are used to define presentationgraphics. This includes the GeoMap, the ValueComparison, and theProgressIndicator.


� Implement the GeoMap UI element� Implement the ProgressIndicator UI element� Implement the ValueComparison UI element

Business ExampleTo enhance the functionality of your application you would like to integrategraphics based on the GeoMap UI element. In addition, to visualize physicalquantities (e.g. occupied seats in respect to available seats) you want to integrate aValueComparison UI element into a view's layout. Finally, the progress of yourapplication should be displayed to the user by a ProgressIndicator UI element.

The GeoMap UI ElementThe GeoMap UI element can be used to display a section of a map. The mapsection to be displayed can be defined by the application. The geographicalcoordinates are derived from the longitude and latitude values of a geographicallocation and must be entered in WGS84 format based on the reference systemWorld Geodetic System �1984 (WGS84).

The possibility to position the map and to zoom in and out can be offered to theuser. Points can be marked and a text can be displayed below the marking. Inaddition, 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 softwarecomponent that is provided by the geographical maps. This softwarecomponent, which you can use to expand the Internet Graphics Service(IGS), is not delivered with the NetWeaver Application Server ABAP. Itmust be purchased from a third-party provider. The GeoMap UI elementcannot be displayed without this complementary software component.See also SAP Note 994568

Defining the ContextIt is not mandatory to define context elements for the GeoMap UI element.Context attributes used in respect with an optional data binding of UI elementproperties 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 propertieswidth and height, respectively (in pixels). These properties can not be bound tocontext attributes. To change these properties at runtime, the GeoMap UI elementhas to be accessed directly from the view's hook methodWDDOMODIFYVIEW( ).



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 definedin decimal numbers in accordance with the Standard World Geodetic System� 1984 (WGS84).

If the map displayed by the GeoMap UI element is stretched, the proportionsbetween width and height will always be stable. Thus, the map section actuallydisplayed is defined as follows:

The longitudinal positions defined by left and right always define the westernmostand easternmost positions displayed by the map - independent of the values ofwidth and height. The arithmetic mean between the horizontal positions top andbottom will define the horizontal position displayed in the middle of the map. Thenorthernmost and the southernmost positions are then calculated from the ratiobetween the values of the properties height and width, respectively.

If geo objects are to be displayed, then the property geoObjectSource has to bebound to a context attribute of type CL_WD_GEO_OBJECT. At runtime, eachgeo object will be described by one context element. Thus, this context attributeshould be defined in a context node of cardinality 0:n to allow the definitionof an arbitrary number of geo objects.

The property moveType allows to define if the user can position the map sectiondisplayed by the UI element. If the value of this property is set to panel, controlelements are displayed on all sides of the map border.

The property zoomType allows to define, if the user can change the zoom factor. Ifthe 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 signor 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 theseproperties at runtime, the GeoMap UI element has to be accessed directly from theview's hook method WDDOMODIFYVIEW( ).

The property enabled can be set to ABAP_FALSE in order to disable the possibilityto position the map and change the zoom factor.

Caution: If an action is assigned to the event ObjectAction and the valueof property enabled is set to ABAP_FALSE, clicking on selectable geoobjects is still possible. However, the application will dump!

The property igsUrl can be used to assign the RFC destination to the IGS serverproviding the geo maps (notation: $<RFC_destination>$). If the value of thisproperty is initial, the standard destination is used. igsURL can not be bound tocontext attributes.

Finally, the values of the properties imageSource and mapSource are only visibleto the API and can thus not be changed by the application developer.



Figure 129: GeoMap: Defining the UI and data binding

EventsThe GeoMap UI element does support one event: ObjectAction. This event isfired, if the user clicks on any selectable geo object. If an action is assigned to therelated property onObjectAction, the related action handler method is processedby the Web Dynpro framework. From the interface parameter WDEVENT of thisaction handler, the internal table PARAMETERS can be extracted. This internaltable contains two parameters: The id of the GeoMap object is provided by theparameter ID. The id of the selected geo object is provided by the parameterEVENT_ID.

Defining Geo ObjectsSo-called geo objects can be positioned in the map in order to highlight specificpositions. 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. Theconstructors of all geo object classes do not have any interface parameters. Thusall 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 clickon multiple geo object, the ID should be unique, since this parameter is usedto identify which geo object was selected by the user.

� COLOR (STRING): Color of point marker, polygon, or line drown on themap. 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 is

selectable. If this parameter is set to ABAP_TRUE, the event ObjectAction isfired 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. Todisplay the image, the parameter STYLE has to be set to 04.

� POSITION (GEOPOSITION): Longitude and latitude values of ageographical location to be defined in WGS84 format. These values haveto 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), and04 (image).

The following additional properties do exist for geo objects of type lines:

� POSITIONS (GEOPOSITIONSTAB): Internal table containing as many linesas geographical locations are necessary to describe the geo object. Eachtable line is a structure (type GEOPOSITION) containing longitude andlatitude 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. Thecolor has to be defined in RGB notation (e.g. 255,151,151).

� POSITIONS (GEOPOSITIONSTAB): Internal table containing as many linesas geographical locations are necessary to describe the geo object. Each tableline is a structure (type GEOPOSITION) containing longitude and latitudevalues of a geographical location to be defined in WGS84 format. Thesevalues are stored in the fields LONGITUDE and LATITUDE of this structure,respectively. At runtime, all lines are connected and the area surrounded bythe lines is filled. The last point and the first point listed in this internaltable are automatically connected.

� TRANSPARENCY (INTEGER): Defines the degree of transparency of theMap. 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 ElementThe ProgressIndicator UI element shows how much progress an activity hasmade in the form of a horizontal bar. A user-defined text may be displayed in theprogress 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 thesource code related to a single dialog step has been completed.

Defining the ContextIt is not mandatory to define context elements for the ProgressIndicator UIelement. Context attributes used in respect with an optional data binding of UIelement properties are discussed in the next sub section.

UI Element Definition and Data BindingThe ProgressIndicator UI element can be defined as a sub element of anycontainer 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 bebound to a context attribute of type WDUI_PROG_IND_BAR_COL.

The width of the ProgressIndicator UI element is defined by the value of theproperty width (in pixels or percent). The property percentValue defines the widthof the color bar relative to the width of the surrounding box. All positive integersare allowed. If the value of this property is between 0 and 100, the width of thebox is fixed while the color bar has a relative width given by the property value. Ifthe value is larger then 100, then the color bar has a fixed width and the width ofthe 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 thebar, 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 tooltipproperty can be used to define a quick info. However, the text displayed to theuser will always be constructed from the values of the properties displayValue,percentValue, and tooltip.

Figure 132: ProgressIndicator: Defining the UI and data binding

EventsThe ProgressIndicator UI element does not support any events.

The ValueComparison UI ElementThis 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 bya ValueComparison UI element. The width of the box indicates the total numberof available seats. The width of the horizontal bar indicates how many seats maybe booked. Our carrier overbooks their flight, thus the bar exceeds the width of thebox. The bar is divided in three sections having different colors. This is used toindicate uncritical, critical, or neutral situations (e.g. to little bookings are criticaland overbooking is critical). In addition, a marker is displayed. In the contextdiscussed here, the marker is used to display the actual booking situation.



Figure 133: ValueComparison

Defining the ContextIt is not mandatory to define context elements for the ValueComparison UIelement. Context attributes used in respect with an optional data binding of UIelement properties are discussed in the next sub section.

UI Element Definition and Data BindingTheValueComparison UI element can be defined as a sub element of any containerelement. The following properties are of interest:

The maximum integer to be visualized by the ValueComparison UI element shouldbe 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 thehorizontal bar and the surrounding box, respectively. The values of theseproperties have to be provided as integers. The absolute width (in pixels) of thebox is given by <boxValue>/<maxValue>*<width>. The absolute width (inpixels) of the bar can be determined accordingly.

lowerThresholdValue and upperThresholdValue allow to define intersections ofthe horizontal bar displayed in different colors. The values have to be providedas integers. The positions of the section limits are given by the ratio betweenthese properties and the value of the property barValue, respectively. The colorof the first section (from left to right) is given by the value of the propertycolorBelowThreshold, 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 ofcolorAboveThreshold. If these properties are bound to context attributes, theseattributes have to be of type WDUI_BAR_COLOR.

The position of the marker can be adjusted by setting the property markerValueaccordingly. The marker can be displayed in black (neutral) or red (critical) byadjusting the property markerType

Finally, the text to be displayed above the box is determined by the value of theproperty text.

Figure 134: ValueComparison: Defining the UI and data binding (1)



Figure 135: ValueComparison: Defining the UI and data binding (2)

EventsThe ValueComparison UI element does not support any events.



Exercise 10: Implementing theValueComparison UI Element

Exercise ObjectivesAfter completing this exercise, you will be able to:� Implementing the ValueComparison UI element

Business ExampleYou would like to enhance the functionality and ergonomics of your application.A ValueComparison UI element should be used to illustrate the number ofoccupied seats in the economy class in respect the total seats in this class asa table popin graphic.

Template Component: NET312_GRPH_S1

Solution Component: NET312_GRPH_S2








Task 2:Define a ValueComparison UI element to illustrate the occupation in the economyclass 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 thresholdand an orange bar (color: critical) between these two values. The actualoccupation should be indicated by a marker. The threshold values shouldcorrespond to the limits used to define the background color of the table cellsdisplaying the occupied seats in the economy class.

1. In order to control the settings of the ValueComparison UI elementprogrammatically, a new context node (name: GRAPHICS_VS) has to becreated 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 UIelement.

- SEATSMAX of type SFLIGHT-SEATSMAX to define the number of seatscorresponding to the full bar length.

- SEATSOCC of type SFLIGHT-SEATSOCC to define the position of themarker.

- L_THRESHOLD of type SFLIGHT-SEATSOCC to define for whichoccupation the bar color changes from green to orange.

- U_THRESHOLD of type SFLIGHT-SEATSOCC to define for whichoccupation the bar color changes from orange to red.

3. Create a new component controller method having the nameDEFINE_GRAPHICS_DATA( ). Add an import parameter(name: IO_CONTEXT_ELEMENT) having the reference typeIF_WD_CONTEXT_ELEMENT to the method's interface. At runtime,the reference to the flight element the table popin is expanded for will besupplied to this interface parameter. Set the values of the attributes definedin node GRAPHICS_VS according to this flight.

4. Call the component controller method DEFINE_GRAPHICS_DATA( ) everytime the user expands the table popin. Pass the reference to the relatedcontext element to the interface parameter IO_CONTEXT_ELEMENT.


6. Now you can define the ValueComparison UI element in the layout of viewMAIN_VIEW. This UI element has to replace the TextView UI elementassigned 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.



Solution 10: Implementing theValueComparison UI ElementTask 1:If you have finished the previous exercise, you can skip this task. Then, all changescan be implemented in the component you have created in your last exercise.







Task 2:Define a ValueComparison UI element to illustrate the occupation in the economyclass 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 thresholdand an orange bar (color: critical) between these two values. The actualoccupation should be indicated by a marker. The threshold values shouldcorrespond to the limits used to define the background color of the table cellsdisplaying the occupied seats in the economy class.

1. In order to control the settings of the ValueComparison UI elementprogrammatically, a new context node (name: GRAPHICS_VS) has to becreated as a sub node of node FLIGHTS in the component controller context.


b) From the context menu of node FLIGHTS, choose Create→Node tocreate 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 UIelement.

- SEATSMAX of type SFLIGHT-SEATSMAX to define the number of seatscorresponding to the full bar length.

- SEATSOCC of type SFLIGHT-SEATSOCC to define the position of themarker.

- L_THRESHOLD of type SFLIGHT-SEATSOCC to define for whichoccupation the bar color changes from green to orange.

- U_THRESHOLD of type SFLIGHT-SEATSOCC to define for whichoccupation the bar color changes from orange to red.


b) From the context menu of node GRAPHICS_VS, chooseCreate→Attribute to create the attribute TEXT. Set Type = STRINGand finish the dialog.

c) Repeat the last step for each of the attributes SEATSMAX, SEATSOCC,L_THRESHOLD, and U_THRESHOLD, respectively.

3. Create a new component controller method having the nameDEFINE_GRAPHICS_DATA( ). Add an import parameter(name: IO_CONTEXT_ELEMENT) having the reference typeIF_WD_CONTEXT_ELEMENT to the method's interface. At runtime,




the reference to the flight element the table popin is expanded for will besupplied to this interface parameter. Set the values of the attributes definedin 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 editthe source code.

c) To define the interface parameter, enter the parameter's name in columnParameter, set Type = Importing, check the check box RefTo, and putthe reference type in column Associated Type.

d) Implement the method:

� Get the flight information from the context elementIO_CONTEXT_ELEMENT.

� Copy the number of occupied seats and the number oftotally available seats in the economy class to the contextattributes FLIGHTS.GRAPHICS_VS.SEATSOCC andFLIGHTS.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 attributeFLIGHTS.GRAPHICS_VS.TEXT.





4. Call the component controller method DEFINE_GRAPHICS_DATA( ) everytime the user expands the table popin. Pass the reference to the relatedcontext element to the interface parameter IO_CONTEXT_ELEMENT.

a) If the user expands the table popin for a certain table row, theaction handler method ONACTIONTOGGLE_POPIN( ) of viewMAIN_VIEW is processed. The reference to the related contextelement is provided by the framework as an event parameter (name:CONTEXT_ELEMENT). The information if the table popin isexpanded is provided by the event parameter EXPANDED.

b) Edit the action handler method ONACTIONTOGGLE_POPIN( ) ofview MAIN_VIEW.

c) Add the parameter CONTEXT_ELEMENT (TYPE REF TOIF_WD_CONTEXT_ELEMENT) to the list of importing parametersfor this method.

d) Add the parameter EXPANDED (TYPE WDY_BOOLEAN) to the list ofimporting 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 controllermethod DEFINE_GRAPHICS_DATA( ) and pass the eventparameter CONTEXT_ELEMENT to the importing parameterIO_CONTEXT_ELEMENT of this method.




b) Right mouse click on node FLIGHTS to open the context menu forthis node. Choose Update Mapping. This will copy the sub nodeGRAPHICS_VS to the mapped node.

6. Now you can define the ValueComparison UI element in the layout of viewMAIN_VIEW. This UI element has to replace the TextView UI elementassigned 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 elementthat has been defined as a sub element of the TablePopin UI element.




c) From the context menu of the TablePopin UI element, choose InsertContent. In the next dialog select Type = ValueComparison (key:GRAPHICAL_VALUE_CMP).

d) Use the button right of the property name to bind the followingproperties:

� barValue, boxValue, and maxValue have to be bound to theattribute 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� Implement the ProgressIndicator UI element� Implement the ValueComparison UI element


Unit Summary NET312

Unit SummaryYou should now be able to:� 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

Related Information

� The online documentation for SAP NetWeaver 7.0 contains an excellentsection about developing applications based on Web Dynpro ABAP. TheWeb Dynpro ABAP documentation contains a section named Reference.Here you can find a complete documentation of all UI elements and thecorresponding element classes. UI elements discussed in this unit can befound in the sub section named Graphic Category.

� In each SAP system based on SAP NetWeaver 7.0, standard Web DynproABAP demo applications are available. Demos dealing with UI elements ingeneral are WDR_TEST_EVENTS, WDR_TEST_UI_ELEMENTS.

A special demo dealing with the GeoMap UI element isWDR_TEST_GEOMAP.


Unit 5Integrating BEx Web Applications and

non-ABAP Technologies

Unit OverviewUI elements that allow to integrate templates based on BEx Web Applicationsand non-ABAP technologies in Web Dynpro are summarized in the integrationcategory. Here, all of these elements are discussed in detail.


� Embed forms (in the context of SAP Interactive Forms by Adobe) and staticPDF documents in Web Dynpro

� Embed Microsoft Word and Microsoft Excel files in Web Dynpro� Embed BI Web Templates based on Business Explorer (BEx) Web

Applications in Web Dynpro� Use the FileUpload UI element

Unit ContentsLesson: Integrating BEx Web Applications and non-ABAPTechnologies.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260


Unit 5: Integrating BEx Web Applications and non-ABAP Technologies NET312

Lesson: Integrating BEx Web Applications andnon-ABAP Technologies

Lesson OverviewFor Web Dynpro UIs, forms (in the context of SAP Interactive Forms by Adobe)can be embedded using the InteractiveForm UI element. BI Web Templates basedon Business Explorer (BEx) Web Applications may be embedded by means of theBIApplicationFrame UI element. Microsoft Word and Microsoft Excel documentsmay be embedded using the OfficeControl UI element. Finally, uploading a filefrom the client PC to the context of your Web Dynpro application is supportedvia the FileUpload UI element.


� Embed forms (in the context of SAP Interactive Forms by Adobe) and staticPDF documents in Web Dynpro

� Embed Microsoft Word and Microsoft Excel files in Web Dynpro� Embed BI Web Templates based on Business Explorer (BEx) Web


Business ExampleYour application has to be enhanced by integrating PDF documents, officedocuments or BEx Web Templates.

Integrating SAP Interactive Forms by AdobeThe InteractiveForm UI element can be used to integrate interactive andnon-interactive forms based on SAP Interactive Forms by Adobe, or it may be usedto embed an existing static PDF document into a Web Dynpro view.

SAP Interactive Forms by AdobeThe layout of the PDF form is designed with the Form Builder (transaction codeSFP). For efficient and straightforward development of the user interface, theAdobe LiveCycle Designer tool with editor and the Adobe UI elements has beenintegrated into the development workbench.

The required Adobe-specific standard objects are provided by a library. Thesestandard objects are subdivided into field objects and text module objects. Theyrepresent layout elements like text fields, time fields, push buttons, or checkboxes. 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 tointeract 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 forpresentations with a static content.

The field objects have a function that is similar to Web Dynpro UI elements. Theyare bound to the form context in the Designer. The form context is related tothe interface implemented by the form. The interface definition can be createdmanually (based on the ABAP Dictionary, a Smart Form document's interface, oran XML schema uploaded from the file system). However, the interface definitionmay also be derived from an XML schema that is generated at design time onthe 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 isalso the best choice for non-interactive forms.

Until now, Active Component Framework (ACF) had to be installed on thefront-end PC to use interactive forms. As of SAP NetWeaver 7.0 SPS 10, ZeroClient Installation (ZCI) allows to use interactive forms in Adobe Reader (Version8.1 or higher) without any additional plug-ins. ACF is therefore no longer requiredfor interactive forms. To define which kind of layout type is to be used, the formproperty Layout type has to be set to xACF (ACF), to ZCI (ZCI), or to standardlayout (for non-interactive forms).

Hint: SAP strongly supports to use forms that are ZCI compliant.



ScenariosIn the following, the possible scenarios of integrating PDF forms and PDFdocuments are classified:

� Offline scenario: Forms that already exist in the system (as MIME objectsin the MIME Repository), or PDF documents that are uploaded within a WebDynpro 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-enabledelements are created and edited.

Hint: SAP recommends to use interactive forms only after carefullychecking the requirements of the related application. Interactiveforms should only be used if a PDF-based form really does haveadvantages over a normal Web Dynpro view. This can include forinstance scenarios in which paper-based processes are to be replacedor complimented by an online scenario with exactly the same formlayout. Other cases can be applications where, in addition to theonline 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 samebrowser 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 oftype InteractiveForm has to be added to the UI element hierarchy of this view. AnInteractiveForm 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 elementproperties dataSource and templateSource stay initial, since the PDF is notobtained (dynamically) from a form. The values of the properties enabled andreadOnly are ignored and do not influence the result.



Figure 137: InteractiveForm: Offline scenario - defining the UI and databinding

Hint: In this scenario, the PDF document is displayed without involvingthe ADS or the ACF.

The PDF document can be retrieved from the MIME Repository bycalling the method GET(...) which is defined in the MIME RepositoryAPI. The reference to this API is returned by the method callCL_MIME_REPOSITORY_API=>GET_API( ).



Figure 138: InteractiveForm: Offline scenario - loading PDFprogrammatically

It is also possible to upload the file from a file system to the Web Dynpro contextusing a FileUpload UI element. The property data of this element type has to bebound to a context attribute of type XSTRING. After having uploaded the file, thefile content will be stored in this attribute. Optionally, the properties fileNameand mimeType can be bound to context attributes of type STRING. Then, theapplication can check from which location the file has been uploaded and if thefile has the expected MIME type. Finally, the property enabled has to be set toABAP_TRUE. Only then the path to the PDF document can be entered into theinput field related to the UI element.

The FileUpload UI element does not support events, thus submitting the data hasto be triggered by some other UI element. Typically a link or a button is used tooffer 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 attributebeing 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 scenariohave to be conducted:

The UI element property templateSource has to be evaluated with the name of theform to be embedded into the view. The property dataSource has to be bound tothe 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 maybe editable).

Hint: If the properties templateSource and dataSource are not initial, thenthe value of the property pdfSource is ignored.

Hint: If the property enabled is set to ABAP_FALSE, then the value ofthe property readOnly is ignored.

Hint: For this kind of scenario, the form can only be created if an ADSis available.

Figure 141: InteractiveForm: Print scenario - defining the UI and data binding



The following steps are necessary to assign an existing form to the InteractiveFormUI element:

1. The name of the existing form has to be assigned to the propertytemplateSource of the UI element.

2. After having pressed Enter, a popup appears asking you whether a contextstructure 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 becreated in the view's context. The property dataSource is bound to thisnode automatically.

4. If you choose No, you have to assign a context node to the propertydataSource. 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 possibletypes (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 interfaceusing forward navigation:

1. The name of a form (that does not exist yet) has to be assigned to the propertytemplateSource of the UI element.

2. After having pressed Enter, a popup appears asking you for the name of theform interface. Enter the name of an existing form interface or enter thename of the form interface to be created.

3. A button labeled Context allows to select the context node containing thedata to be transported to the form. Press this button, mark a context nodeand choose Enter.

4. Form and form interface are created automatically and the form willbe opened for editing in the Layout Designer. In addition the contextnode chosen in step 3 will be assigned to the property dataSource of theInteractiveForm UI element.

5. Now the layout of the form can be defined.

Hint: The form interface created by forward navigation will be based onan XML schema that is generated from the structure of the context nodechosen in step 3.

The form created by forward navigation will have the layout typeunknown.

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 andform does change. In this case both, the context of the Web Dynpro view and theform interface definition have to be adapted. This is performed as follows:

First the relevant Web Dynpro context has to be adjusted. Next, the Form Builderhas to be opened by double-clicking on the template's name (assigned to theproperty templateSource of the InteractiveForm UI Element). The system detectsthe context changes and adjusts the XML schema, together with the data view inForm Builder automatically.

Hint: Updating the interface definition of the form is only possible if theform 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 scenariohave 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 typeto ZCI, the form has to be updated. This is done by use of transactionSFP_ZCI_UPDATE. The changes can only be applied to activated forms.

2. To enable ZCI for forms embedded in Web Dynpro views, the forms mustcontain special scripting. The developer has to embed this scripting. This isdone 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 DynproNative Library have to be used to create the form's layout.

4. The property enabled of the UI element InteractiveForm has to set toABAP_TRUE. Now, the property readOnly can be used to enable / disable alleditable form fields.

5. The property displayType of the UI element InteractiveForm has to be set tonative (ZCI forms) or activeX (ACF forms).

6. The data entered by the user are transported to the corresponding contextstructure automatically. However, it is also possible to access the XMLrepresentation of the data entered by the user. For this purpose, the propertypdfSource has to be bound to an attribute of type XSTRING. After havingsubmitted a form, this attribute will contain the user input in XML format.

Hint: The attribute bound to property pdfSource must not be definedin the context structure bound to property dataSource.



Figure 145: InteractiveForm: Interactive scenario - special form settings



Figure 146: InteractiveForm: Interactive scenario - defining the UI and databinding

Hint: SAP recommends strongly to use forms having the layout type ZCIand form interfaces which are based on a generated XML schema.

Hint: The development and usage of interactive forms having the layouttype ZCI requires:

The Adobe Reader Version 7.x with x >= 08 being installed on the userPC (Version 8.1 if protocol HTTPs is used).

The Adobe Designer, version 7.1 SPS 1 being installed on the developerPC (only this SPS is possible).

The SAP GUI release 6.40 patch level 20 being installed on the developerPC.

After having changed the value of the form fields, these values have to besubmitted to the context of the Web Dynpro view.

This functionality can be offered by a submit button defined in the form. Forforms of layout type ZCI, this has to be a submit button defined in the WebDynpro 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 relatedproperty onSubmit, then the related action handler method is processed. Inputchecks 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 programmaticallyIt is possible to access a number of functions related to the form from thesource code of the view controller embedding the form. This is possible bycalling methods provided by the UI element's method handler. Details aboutdetermining the reference to the UI element's method handler can be found in thelesson about the Table UI element (filtering, sorting) or in the section about theOfficeIntegration UI element (expert mode). The method handler functionalityavailable for the InteractiveForm UI element is described by the interfaceIF_WD_IACTIVE_FORM_METHOD_HNDL.

Integrating Office DocumentsOffice documents of type Microsoft Word and Microsoft Excel can be embeddedin Web Dynpro views by means of the OfficeControl UI element. At runtime, theoffice document is made accessible by an ActiveX control. Thus, this techniquerequires 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 ofthe corresponding context attribute.



Figure 147: OfficeControl: Standard mode

Additional functionality can be accessed if the expert mode is switched on. Inthis case, the control settings can be manipulated programmatically. In additionmeta informations supported by the control can be read and changed. However,this also means that the control does not create, open, close, or save documentsautomatically any more. Switching to the expert mode means that the completefunctionality offered by the control has to be triggered programmatically.

Hint: Saving the document can still be triggered via the save functionalityoffered by the control.



Figure 148: OfficeControl: Expert mode

Defining the ContextIt is not mandatory to define any context elements related to the OfficeControlUI element.

Defining the UI and Data BindingThe OfficeControl UI element can be added to any container UI element as a subelement. The following properties are of interest:

The value of the property activateInPlace decides whether the control will beembedded in the browser page (ABAP_TRUE) or if the related office applicationis started and the document is displayed by this application (ABAP_FALSE).If the document is displayed by the application, then the complete applicationfunctionality is available. However, changes of the document can only be storedlocally.

To be able to define the document to be displayed programmatically, the propertydataSource should be bound to a context attribute of type XSTRING.

The name of the document is defined by the property documentName. Thisproperty 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 anymore. The value of property showDecoration has no impact on the result.

To switch on the expert mode, the property expertMode has to be set toABAP_TRUE.

The size of the control area can be defined by setting the properties height andwidth accordingly (percent or pixels).

The property visible is used to display / hide the control.

Hint: In the standard mode, the document is closed automatically ifvisible 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 containsin invalid value or if the value is initial.

Hint: The OfficeControl UI element is only active when the visibleproperty is set to visible. Setting height and width to 0 does not deactivatethe control.

Figure 149: OfficeControl: Defining the UI and data binding



Figure 150: OfficeControl: Standard mode - creating a new document

EventsThe OfficeControl UI element supports two events, Close and Save. Fordocuments being displayed in the standard mode, these events are triggered asfollows:

To replace the document displayed by the UI element, the value of the data sourceattribute has to be changed by the application. The information about the nextdocument 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 firesthe 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 transportedback to the control. This time the control opens the new document.



Figure 151: OfficeControl: Standard mode - replacing an unchangeddocument

If the document has been changed, but the user forgot to save the document usingthe control's save functionality, the control saves the document automatically.Next, the control fires the event Save. The related request contains the savedversion of the document actually displayed. This version of the document is thensaved in the context. As a result the saved version of the document is displayedagain.



Figure 152: OfficeControl: Standard mode - trying to replace an unsaveddocument

If the document has been changed and the user has saved the document the processis identical to replacing an unchanged document.

If the user saves a document via the control's save functionality, the behavior doesnot depend on the mode. In the standard and in the expert mode the control firesthe event Save. The actualized version of the document is subsequently stored inthe related context attribute.



Figure 153: OfficeControl: Standard mode / Expert mode - saving a changeddocument

For documents being displayed in the expert mode, the application has to instructthe control to open, close, save, or create a document. A new document can onlybe 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 controlsaves 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 attributecontent 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 UIelement, no information can be extracted from the interface parameterWDEVENT.



Accessing the Control Functionality in Expert ModeTo switch on the expert mode, the property expertMode has to be setto ABAP_TRUE. In order to be able to access the control's functionalityprogrammatically, the reference to the method handler of the OfficeControl UIelement has to be determined. This is done as follows:

1. In the hook method WDDOMODIFYVIEW( ), the reference to theOfficeControl UI element has to be determined.

2. The public attribute _METHOD_HANDLER of this UI element reference hasto be casted to the an interface reference variable of type IF_IOS_FACTORY.

3. IF_IOS_FACTORY provides methods to create proxy classes describing thedocuments functionality and the control environment and methods to changethe document settings. These methods have to be accessible in differentmethods 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 onlypossible via a proxy object that describes the document actually displayedby the control. The reference to this object is derived from the methodhandler by calling the method GET_DOCUMENT_PROXY( ). This methodreturns a reference variable of type IF_IOS_DOCUMENT. For performancereasons, this reference should only be determined once and the result shouldbe stored as a controller attribute.

5. The control environmental can be accessed via a document proxy of typeIF_IOS_ENVIRONMENT. The reference to this object is derived fromthe method handler by calling the method GET_ENVIRONMENT( ). Forperformance reasons, this reference should only be determined once and theresult should be stored as a controller attribute.

6. In addition, the interface IF_IOS_FACTORY contains methods to createspecial proxys for Microsoft Word and Microsoft Office documents andmethods 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 / storedocument

Integrating BI Web Templates based on BEx WebApplicationsWeb Templates that are based on BEx Web Applications can be embedded in WebDynpro applications by means of the BIApplicationFrame UI element. Variousattributes can be set for a Web template. When using the BIApplicationFrame UIelement, these parameters are set as properties of the UI element.

Technically, the Web Template is integrated using an iFrame in the generatedHTML page. Thus, the Web Template is accessed by sending an extraHTTP-Request and the parameters are passed as a query string.



Figure 157: BIApplicationFrame

Defining the ContextIt is not mandatory to define any context elements related to theBIApplicationFrame UI element.

Defining the UI and data bindingThe BIApplicationFrame UI element can be defined as a sub element of anycontainer 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 knowledgeof 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) andthe height (height) occupied by the UI element. The value of property enableddoes not affect the result, visible can be used to toggle the visibility. Finally, theproperty server is used to define the host name and port of the server that offersthe 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 onthe server type offering the Web Template. Thus, the property serverType has tobe set to ABAP or Java.



Accessing the Web Template Functionality programmaticallyIt is possible to access a number of functions related to the Web Template fromthe source code of the view controller embedding the Web Template. This ispossible by methods provided by the UI element's method handler. Details aboutdetermining the reference to the UI element's method handler can be found in thesection about the Table UI element (filtering, sorting) or in the section about theOfficeIntegration UI element (expert mode). The method handler functionalityavailable for the BIApplicationFrame UI element is described by the interfaceIF_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

PDF documents in Web Dynpro� Embed Microsoft Word and Microsoft Excel files in Web Dynpro� Embed BI Web Templates based on Business Explorer (BEx) Web



Unit Summary NET312

Unit SummaryYou should now be able to:� 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) Web


Related Information

� The online documentation for SAP NetWeaver 7.0 contains an excellentsection about developing applications based on Web Dynpro ABAP. TheWeb Dynpro ABAP documentation contains a section named Reference.Here you can find a complete documentation of all UI elements and thecorresponding element classes. UI elements discussed in this unit can befound in the sub section named Integration Category.

� In each SAP system based on SAP NetWeaver 7.0, standard Web DynproABAP demo applications are contained. Demos dealing with UI elements ingeneral are WDR_TEST_EVENTS, WDR_TEST_UI_ELEMENTS.

Special demos dealing with the integration of PDF documents or SAPinteractive forms by Adobe begin with WDR_TEST_ADOBE.

Special demos dealing with the integration of office documents begin withIOS_TEST.


NET312 Course Summary

Course SummaryYou should now 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


Course Summary NET312


IndexAActions, 10Active ComponentFramework (ACF), 261

BBIApplicationFrame, 284BusinessGraphics, 217Chart Designer, 227Chart types, 217Context, 218Context - simplifications,220UI definition, 222UI definition -simplifications, 224

CChart Designer, 227Container elements, 4Context binding, 6Context change log, 118Context paging, 48, 85ContextualPanel, 42DData binding, 6DateNavigator, 187Dynamically changing the UI,14

EEvents, 10FFileUpload, 265FreeContextualArea, 44GGeoMap, 238Defining geo objects, 241

HHorizontalContextualPanel,38Context, 38

IIGS, 216InteractiveForm, 260Interactive scenario, 271Offline scenario, 263Print scenario, 267Scenarios, 262

Internet Graphics Service(IGS), 216

IntroductionActions, 10Container elements, 4Context binding, 6Data binding, 6Dynamically changing theUI, 14Events, 10Layout managers, 5UI element hierarchy, 2WdDoModifyView, 16

LLayout managers, 5MMultiPane, 45Context paging, 48

NNavigationList, 33Context, 33

OOfficeControl, 274Expert mode, 275


Index NET312

Expert mode functionality,282Standard mode, 274

PPhaseIndicator, 193ProgressIndicator, 243RRecursion node, 33, 38, 170RoadMap, 196SSAP Interactive Forms byAdobe, 260

TTable, 79Colors, 114Context change log, 118Context paging, 85Design, 83Editable, 116Editable - Context changelog, 118Editable - Input checks,117Filter data sets, 95Grouping columns, 92Grouping rows, 92Header, 90Hierarchical, 130Horizontal scrolling, 86Popins, 106Row selection, 88Sort data sets, 100Toolbar, 90Totals and subtotals, 121Vertical scrolling, 85

TabStrip, 51Tray, 54Tree, 159containing leafs, 162

containing leafs and subnodes, 163containing recursivelyrepeated structures, 170

Tree Table, 130UUI element hierarchy, 2UI elementsBIApplicationFrame, 284BusinessGraphics, 217ContextualPanel, 42DateNavigator, 187FileUpload, 265FreeContextualArea, 44GeoMap, 238HorizontalContextual-Panel, 38InteractiveForm, 260MultiPane, 45NavigationList, 33OfficeControl, 274PhaseIndicator, 193ProgressIndicator, 243RoadMap, 196Table, 79TabStrip, 51Tray, 54Tree, 159ValueComparison, 245ViewSwitch, 44

VValueComparison, 245ViewSwitch, 44WWdDoModifyView, 16ZZero Client Installation (ZCI),261


FeedbackSAP AG has made every effort in the preparation of this course to ensure theaccuracy and completeness of the materials. If you have any corrections orsuggestions for improvement, please record them in the appropriate place in thecourse evaluation.
