ABAP Web Dynpro Training Material

Web Dynpro for ABAP Web Dynpro for ABAP
ABAP Web Dynpro Course Contents - 1

Description : n this course you will explore the various concepts and practical
examples related to ABAP Web Dynpro
Course Contents :
ModuIe 1 - Theory
ABAP Web Dynpro Architecture
Technical Features
Main Benefits
ModuIe 2 - Introduction
Web Dynpro Development
Web Dynpro Component Architecture
Web Dynpro Components
Views Windows and U Elements
Defining View Layout
Layout Types
U Element Categories
ModuIe 2a - Exercise
ntroductory example
ModuIe 3
Controller and Context
Controller Types
Controller Entities
ModuIe 4
View Controller and View Context
Context Node Elements
Component Controller
Populating "Table control
ModuIe 5
Node Cardinality
Node Cardinality
ModuIe 6
Context mapping between views
Navigation
Context Node at Design Time
Navigation
ABAP Web Dynpro Course Contents - 2
ModuIe 7
$upply Function of a Context Node
$upply Function
ModuIe 8 - Exercise
Messages and Error Handling
ModuIe 9
Dynamic Programming
Dynamic Programming
Adding U elements
Changing properties of U elements
ModuIe 10
Web Dynpro Component nterface
Creating a Web Dynpro Component
nterface Definition
ModuIe 11
Adaptation of Web Dynpro Applications
Adaptation of Web Dynpro Applications - Configuration Controllers
ModuIe 12 - Exercise
Window Controllers
ModuIe 13 - Exercise
ntegrating a PDF Form in a Web Dynpro Component
ModuIe 14 ModuIe 14 ModuIe 14 - - - Exercise Exercise Exercise
Working with Dialog Boxes Working with Dialog Boxes Working with Dialog Boxes
nput Help nput Help nput Help
Portal ntegration Portal ntegration Portal ntegration
Business Graphs Business Graphs Business Graphs
ABAP Web Dynpro Web Dynpro Architecture
Definition
Web Dynpro is the $AP NetWeaver programming model for user interfaces (Us).
The Web Dynpro model is based on the ModeI View ControIIer paradigm, and
has the following features that build on the classic dynpro model:
Clear separation of business logic and display logic
Uniform metamodel for all types of user interfaces
Execution on a number of client platforms
Extensive platform independence of interfaces
Web Dynpro's main goal is to enable application developers to create powerful web
applications with minimum effort using descriptive tools in a structured design
process.
Web Dynpro uses a declarative, language-neutral meta model for defining a user
interface.
ABAP Web Dynpro TechnicaI Features
Web Dynpro provides technical features for
nternationalization
Flicker-free interaction
Clean separation of business logic and the U. This is achieved through a modified
implementation of the Model View Controller (MVC) design paradigm.
ABAP Web Dynpro Main Benefits - 1
ABAP Web Dynpro Main Benefits - 2
ABAP Web Dynpro Web Dynpro DeveIopment
ABAP Web Dynpro Web Dynpro Component Architecture
ABAP Web Dynpro Web Dynpro Components
ABAP Web Dynpro Views Windows and UI EIements
ABAP Web Dynpro Defining View Layout
ABAP Web Dynpro Layout Types
Flow Layout Left to right, across the screen
Grid Layout Arranged by number of columns (e.g.
colCount = 4)
Matrix Layout Number of columns not fixed. Each
element can be specified for which row
and which column.
Need to specify new row items.
(MatrixHeadData)
Row Layout Row by row.
Need to specify new row items.
(RowHeadData)
ABAP Web Dynpro UI EIement Categories
ABAP Web Dynpro Exercise
Introductory ExampIe
Learn to create views, and familiarize yourself with various U elements
ABAP Web Dynpro ControIIer and Context
ABAP Web Dynpro ControIIer Types
Component ControIIer
There is only 1 component controller per Web Dynpro component.
The component controller drives the functionality of the entire component.
This controller has no visual interface.
Custom ControIIers
These are optional.
They have to be defined at design time.
Multiple custom controllers can be defined in a component
Configuration ControIIer
This is a special custom controller, used for configuration and personalization functionality.
View ControIIers
Each view consists of the layout part and exactly 1 view controller.
This controller cares for view-specific logic, like checking user input and handling user actions
Window ControIIers
Each window has exactly 1 window controller
This controller can be used to care for the data passed via the inbound plugs
Methods of this controller can be called from the inbound plug methods of the window.
ABAP Web Dynpro ControIIer Entities - 1
Common ControIIer Entities
1. Methods
1. Standard Hook methods - For all controllers, there exist methods that are
called in a predefined order by the Web Dynpro framework.
2. Instance methods - Can be defined using the Methods tab
2. Attributes not related to the value or property of U elements can be declared
using the Attributes tab. These attributes are then visible in all methods of this
controller.
There are 2 predefined attributes:
WD_TH$ Used to access functionality of the controller
WD_CONTEXT - Used to access functionality of the context
3. Properties For information to be shared between different controllers, one
controller must declare the use of another controller.
ABAP Web Dynpro ControIIer Entities - 2
SpeciaI Entities of Component/Custom ControIIers
Events can be defined with arbitrary parameters. Any method of any
controller can register to these events if this method is defined as an event
handler method.
SpeciaI Entities of View ControIIers
Navigation PIugs - For navigation to take place between different Web
Dynpro view controllers, special navigation events and navigation event
handlers have been created. These are called Navigation Plugs.
A navigation event is raised when an outbound plug is fired.
An inbound plug is the navigation event handler that can be registered to a
navigation request.
SpeciaI Entities of Window ControIIers
Navigation PIugs
ABAP Web Dynpro Hook Methods
Method Name AppIicabIe To Function
WDDONT Component
Controller and View
Controller
nitialization Method of Controller
WDDOPO$TPROCE$$N
G
Component
Controller
Prepare Output
WDDOBEFORENAVGAT
ON
Component
Controller
Error Handling Before Navigation
Through Application
WDDOAPPLCATON$TA
TECHANGE
Component
Controller
Handling for $uspending and
Resuming an Application
WDDOBEFOREACTON View Controller Method for Validation of User
nput
WDDOMODFYVEW View Controller Method for Modifying the View
Before Rendering (Refresh)
WDDOEXT Component
Controller and View
Controller
Cleanup Method of Controller
ABAP Web Dynpro Process FIow during data transfer
ABAP Web Dynpro Process FIow of event handIing
ABAP Web Dynpro Component ControIIer-1
Each component has its own Component Controller
The Component Controller has its own context
Context nodes of the component controller can be mapped to nodes with similar
structure of other controller contexts e.g. view controllers
This allows the distribution of data between different views and controllers
Mapped nodes automatically contain the same data without copying because they
hold references to one source
The Component Controller also contains methods for central tasks of the
component, for example methods which encapsulate all interaction to the underlying
business logic
The model which represents the business logic can be a AP based on ABAP
Objects, BAPs, RF$ or function modules
f an application consists of several WD components the interaction of one WD
component to a used sub component is also done via the Component Controller
n a typical example the Component Controller contains a method to retrieve data
from the model and context nodes which are filled by these methods
The context nodes of the Component Controller are mapped to the context nodes
of the view controller which are bound to visible U elements
The component controller provides data and processing logic that it should be
possible to display or change for all views of a component.
t has three interfaces:
Interface IF_<controIIer_name> for coding within the controller
Interface IG_<controIIer_name> for cross-controller coding within the current
component.
Interface IWCI_<component_name> for cross-component coding. On the ABAP
language level it represents the interface controller
ABAP Web Dynpro View ControIIer and View Context
The view controller contains the event handlers which steer the behavior of the
view, for example:
nitialization events which are called when a view is displayed for the first time
Action handlers which are triggered by U elements like a button click or drop
down list box selection
n general the coding of the controller methods access the context data and not the
U elements directly.
Each view has its own view controller
The view controller has its context for
the data which is used by the view
Context nodes and attributes can be
bound to U elements
ABAP Web Dynpro Context Node EIements
PopuIate "TabIe" ControI
Problem: Create a table control and populate it with data for the carrier specified in the input
field.
ABAP Web Dynpro Node CardinaIity
The number of elements in a node collection can be controlled using the property known
as cardinality.
This property is actually the combination of two values that, taken together, define the
maximum and minimum number of elements the node collection may contain at runtime.
The two values are the:
Cardinality Minimum: 0 or 1
Cardinality Maximum: 1 or n
There are four permutations for these values (specified as <min>..<max>):
For those nodes that have their cardinality minimum set to 1, then the node collection will
be instantiated such that it already contains a single, empty element. This element is
known as the default element.
For those nodes however, that have their cardinality minimum set to 0, the node will be
instantiated with an empty collection. The Web Dynpro developer must write the code to
first create and then insert the first element into the collection.
0..1 ero or one elements permitted
0..n ero or more elements permitted
1..1 One and only one element permitted
1..n One or more elements permitted
Node CardinaIity
n the example above, for the node
1. Change the cardinality to 0..n and do not write any code to fill the table
2. Change the cardinality to 1..n and do not write any code to fill the table
3. Change the cardinality to 0..1 and do not write any code to fill the table
4. Change the cardinality to 1..1 and do not write any code to fill the table
5. Change the cardinality to 0..n and write code to fill the table
6. Change the cardinality to 0..1 and write code to fill the table
ABAP Web Dynpro Attributes
Attribute Reference to Reference VariabIe of type
WD_CONTEXT controller context F_WD_CONTEXT_NODE
WD_TH$ local interface F_COMPONENTCONTROLLER
F_<MY_CU$TOM_CONTROLLER>
F_<MY_VEW>
F_<MY_WNDOW>
WD_COMP_CONTROLLER View Controller G_COMPONENTCONTROLLER
ABAP Web Dynpro Context mapping between views
The mapping of context nodes can also be used to transport data from one view
controller to another view controller.
n this case the context nodes of both view controllers are mapped to the same
context node of the component controller.
ABAP Web Dynpro Navigation between views-1
ABAP Web Dynpro Navigation between views-2
Outbound PIugs
Calling an outbound plug method causes a navigation event to be raised.
Navigation events are special, asynchronous events that are placed into a
navigation queue.
Only when all the outbound plugs have been called by all the views in the current view
assembly, will the Web Dynpro Framework enter its navigation processing phase.
Outbound plugs should be named according to the action that caused navigation away
from the current view.
Inbound PIugs
nbound plugs are special event handler methods that subscribe to navigation events
raised when outbound plugs are fired.
nbound plug methods are called only when the navigation queue is processed.
This will only take place once all the views in the current view assembly have fired their
outbound plugs and no validation errors have occurred that would cause navigation to be
cancelled.
nbound plugs should be named according to the reason for which the view being
displayed.
Links
Outbound and inbound plugs are joined together using navigation links.
ABAP Web Dynpro PIugs and Navigation
Navigation
Navigate back and forth between 2 views. Also, pass values between the 2 views.
ABAP Web Dynpro SuppIy Function of a Context Node
ABAP Web Dynpro SuppIy Function of a Context Node
SuppIy Function
f the lead selection of a parent node changes, the content of sub nodes has to be
changed or filled dependent of the new content of the lead selection.
This can be done with the $upply Function which is called automatically by the
framework.
Each context node of a controller can be assigned a supply function.
This supply function is called by the runtime when the data of the context node is
used.
This is the case when a U element is to be displayed for the first time with the data of
the corresponding context, for example.
n general, the supply function is called when one or more elements of a context node
are accessed and when
the context node is not filled yet or is initial, or
the context node has been invalidated in a previous step.
ABAP Web Dynpro SingIeton
Unlike the cardinality of a node, which describes the number of possible elements
within the node, the "singleton property determines whether or not these elements
are set for all elements of the parent node (non-singleton) or for exactly one
element of the parent node (singleton).
The singleton property of a context node describes the relationship between a child
node and its immediate parent.
The current contents of a sub node can be kept or deleted if the lead selection of
the parent node changes. This is steered by the $ingleton property of the sub node.
f the sub node is declared as $ingleton the old node content is deleted and the sub
node is filled freshly via the supply function every time the lead selection of the
parent node changes, even if it changes to an element which has had the lead
selection a few clicks before.
f the sub node is declared as non-$ingleton the old sub node data is kept and
reused if the lead selection switches to the same element again without calling the
supply function again.
ABAP Web Dynpro Lead SeIection
At runtime, every child node set as a singleton contains the elements for exactly
one element of the parent node. For this purpose, one element from the set of
possible elements of the parent node must be highlighted. This is achieved by
initializing lead selection.
For each newly created context node, lead selection is initialized automatically, but
this setting can also be deactivated. However, lead selection must generally be
initialized for every context node.
Using the preset automatic initialization of lead selection:
n this case, the first eIement of a node is always assigned the lead selection
property.
Manual initialization of lead selection:
f the automatic initialization was deactivated, the lead selection must be
programmed manually. n this case it is possible to assign this property to an
element other than the first element of a node.
$upply Function
Use supply function to refresh the contents of a table depending upon the input from another
table.
Messages and Error Handling
Display a suitable message if the user enters invalid data
Custom Controllers
1. ALV
Display data in an ALV
2. Custom Controllers
ABAP Web Dynpro Dynamic Programming - 1
Dynamic programming mostly accesses objects of a component at runtime.
You can change the layout of a view within method wdDoModifyView, since the view is the
owner of the layout of a certain screen area.
For this purpose, the interface of method wdDoModifyView provides a parameter called
VEW, which is a reference to an object of type F_WD_VEW representing the instance of
a view at runtime
The following interfaces are public and can be used to modify objects:
F_WD_APPLCATON
F_WD_ACTON
F_WD_COMPONENT
F_WD_COMPONENT_U$AGE
F_WD_COMPONENT_U$AGE_GROUP
F_WD_CONTEXT
F_WD_CONTROLLER
F_WD_EVENT
F_WD_ME$$AGE_MANAGER
F_WD_OV$
F_WD_PORTAL_NTEGRATON
F_WD_VEW
F_WD_VEW_CONTROLLER
F_WD_WNDOW
F_WD_WNDOW_MANAGER
n addition to the all those different interfaces, you can also call static methods on certain public
classes:
CL_WD_UTLTY
CL_WD_DYNAMC_TOOL
CL_WD_RUNTME_$ERVCE$
The names of the classes that represent the above mentioned ViewElements are as follows:
ViewElement -> CL_WDR_VEW_ELEMENT
UElement -> CL_WD_U_ELEMENT
UElementContainer -> CL_WD_U_ELEMENT_CONTANER
Layout -> CL_WD_LAYOUT
LayoutData -> CL_WD_LAYOUT_DATA
The above classes are abstract.
$ince everything that can be placed on screen, is derived from one of those five classes, it also
offers you the opportunity to work with generic typed pointers.
f you are uncertain about the type of an U element, use the least generic typed pointer.
e.g.f you want to use a button, the class in question will be CL_WD_BUTTON
Accessing an Existing ViewElement
n order to change an existing ViewElement, a pointer can be obtained by calling the method
GET_ELEMENT of interface F_WD_VEW.
$uch a typed pointer is available within method wdDoModifyView (available within any
ViewController), as a parameter called VEW.
The following source code shows how one can obtain a pointer to the
RootUElementContainer.
data: lr_container type ref to cl_wd_transparent_container.
lr_container ?= view->get_element( `ROOTUELEMENTCONTANER` ).
Creating a ViewElement
Every ViewElement contains a method, which starts with NEW_ followed by the name of
the class without the CL_WD_.
$o for a button, the name of this method would be NEW_BUTTON.
Calling this method creates a new instance of this ViewElement.
Depending on if the current ViewElement is a Layout, LayoutData or other ViewElement,
this method has a slightly different signature.
For every Layout the interface of this method always contains at least the following parameters:
importing
id type string optional "id of the Layout
container type ref to cl_wd_uielement_container "UElementContainer to which the Layout
should be assigned
returning
control type ref to cl_wd_<name of the Layout> "the newly created Layout
For every LayoutData the interface of this method always contains at least the following
parameters:
importing
id type string optional "id of the Layout
data element type ref to cl_wd_uielement "UElement to which the LayoutData
should be assigned
returning
control type ref to cl_wd_<name of the LayoutData> "the newly created LayoutData
For all other ViewElements the interface of this method always contains at least the following
parameters:
importing
id type string optional "id of the ViewElement
view type ref to if_wd_view optional "pointer to the view
returning
control type ref to cl_wd_<name of the ViewElement> "the newly created ViewElement
All other parameters are optional and allow you to specify the following aspects of a
ViewElement upon its creation:
The values of all attributes that are not bound. For each attribute, there is a parameter that has
the same name. f an attribute is not specified, its default value will be applied.
The binding paths of all bindable attributes. They have the prefix BND_ in front of the name of
the attribute. Only meta paths are supported, which means you can not use any form of
index to node elements within such a path.
The action to which an event of this ViewElement is bound. All events have the prefix ON_.
Dynamic Programming
Adding U elements
Add "n buttons to a view dynamically.
Changing Attributes Dynamically
Toggle the visibility of the table control.
ABAP Web Dynpro Web Dynpro Component Interface
Component interface definitions allow you to generically define a uniform
interface structure and later use it in a variety of application components.
The advantage of this procedure lies in the fact that in a distributed development
the interfaces of all components that use the interface definition reliably contain a
particular set of controller elements (methods, context elements, etc.) and
interface views, which can be addressed by the developers of using
components.
The developer of a using component does not need to know which actual
implementation of the interface is used this can be determined dynamically at
runtime.
You use the Object Navigator to create and edit component interface definitions
analogous to components.
nterface Controller of a Component
Interface Definition
nterface Controller of a Component
The controller can be edited The controller can be displayed but not
edited.
Methods can be defined in the editor, but
they cannot be programmed there.
The methods are programmed only after
the impIementation of the component
interface definition in a Web Dynpro
component.
The methods can be created in the
editor of the related component
controller (see above) and then be
programmed in the ABAP editor.
The interface controller of a component interface definition and the interface
controller of a component differ in two items:
n addition to the mandatory interface controller you can add any number of
interface views to a component interface definition.
ImpIementing Component
Interface Definitions
These separately defined
component interfaces can now
be added to the implemented
interface of a component. With
the implementation of a
component interface definition in
a component, the elements of
the separately defined interface
controller are added to the
component controller of the
implemented component.
Within this implemented component, the
methods of the interface controller that have
only been defined so far can be programmed
component-specifically.
For large programming projects, this results
in a higher reusability of the interface
structures.
Besides the interface controller a
component interface definition can
contain interface views.
When implementing a
component interface
definition, these interface
views are added to the
existing views in the interface
folder of the implemented
component. The related
windows are generated and
stored in the respective folder
of the object list. They are
empty and can now be laid
out especially for the
embedding component.
The faceIess Component
t is possible to create a Web Dynpro component that has no visual interface. i.e. a
component with zero views and zero windows.
$uch a component is known as a "faceless component and is useful when a
complex unit of functionality requiring no direct user interface needs to be
encapsulated.
A good example of a faceless component is the creation of something called a
model component. This is not actually a specific Web Dynpro component type;
rather it is a standard Web Dynpro component that has been written specifically for
the task of interacting with a model object.
Very often, though not exclusively, a model component will have no visual interface,
thus also making it a faceless component.
Often, a model object could have large or complex interface. $ince model objects
are completely reusable, it does not make sense to have to re-implement the
functionality required to interact with the model object every time it is reused.
Therefore, $AP recommends that when a model object's interface requires any type
of additional processing or simplification, that the model object be encapsulated
within a component in order to be able to reuse the associated interface coding.
ABAP Web Dynpro Web Dynpro Component nterface
Create a Web Dynpro Component nterface Definition
mplement the above created nterface in a Web Dynpro Component
ABAP Web Dynpro Adaptation of Web Dynpro AppIications
The U of applications defined with ABAP Web Dynpro can be adapted in different ways and by
different user groups
There are 2 categories of application adaptation:
Configuration and Personalization
ABAP Web Dynpro Configuration
Configuration is a process by which the deveIoper can create configuration data sets
containing values for U element properties. This allows the developer to overwrite many of
the statically defined U element properties, resulting in a different look and feel of the
application.
e.g.
U elements may be set to invisible
Tables may have an alternating row color
Component configuration allows you to change properties of U elements defined in any view
of a single component.
AppIication configurations are bound to Web Dynpro applications. They define which
component configuration is used for which component in this application.
Application changes related to configuration affect every user in every client.
ABAP Web Dynpro PersonaIization
PersonaIization allows any user of the application to change the U element properties at
runtime.
These changes are very restricted.
e.g.
n case of simple U elements like TextView, only the visibility can be changed
For the Table element, the order of the columns can also be altered
Personalization is user dependent.
Customizing is the ability to personalize Web Dynpro applications for all users in a client.
$pecial authorizations are required.
ABAP Web Dynpro Adaptation Hierarchy
Configuration, Customizing and Personalization can be combined to define the final adaptation.
Changes defined by personalization overwrite the changes defined by customizing and
Changes defined by customizing overwrites the configuration adaptation
The parameters available for configuration can be set to final so that they cannot be
changed by customizing or personalization
Parameters available for customizing can be set to final so that they cannot be changed
using personalization.
ABAP Web Dynpro Adaptation Hierarchy
Adaptation of Web Dynpro Applications Configuration Controllers
1. Define Configuration for your Web Dynpro Component and Web Dynpro App to show
10 rows in the table control instead of the default 5
2. Customize your Web Dynpro App to change the label of any button
3. Personalize your Web Dynpro App to hide one of the Table control fields
Window Controllers
Depending upon the value of the parameter "p in the query string of the application URL,
either view V11 or V12 should be triggered.
Integrating a PDF Form in a Web Dynpro Component
ntegrate an interactive PDF form in a Web Dynpro component

ABAP Web Dynpro Training Material

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ABAP Web Dynpro Training Material

Uploaded by

Copyright:

Available Formats

Web Dynpro for ABAP Web Dynpro for ABAP

ABAP Web Dynpro Course Contents - 1

You might also like