Using the ALV Views List Viewer in Web Dynpro for ABAP

The ALV component contains the following views, which you can use as required:

•TABLE
This is the central ALV view. To display the ALV output, you require this view.
The TABLE view is the container in which the ALV output is displayed. It is a fundamental part of the ALV component. You cannot, therefore, change the layout.

•SERVICE
This view contains the Settings dialog box with which the user can make changes to the settings for column display, sorting, filtering, and so on.
By default, the view is displayed above the ALV output when the user chooses the Settings hyperlink in the toolbar. You use this view when you want to display the dialog box elsewhere on the screen.

Inserting a TABLE View

You require the TABLE view if you want to display an ALV output in your application.

You can insert the TABLE view in various ways:

•You insert it directly into a window of your application.

In this case, you cannot display any another element on the screen except for the ALV output.

•You insert it into a cell of a view set in your application.

•You generate a UI element of the type ViewContainerUIElement in the position you want in one of the views. You then insert the TABLE ALV view into this UI element.

Objects of the ALV Configuration Model List Viewer in Web Dynpro, Integration of ALV

The following main areas are available for configuring your ALV output:

•Table settings

The data for the Table UI element includes the structure of the application data as well as the technical fields that determine the appearance or function of the ALV output. You can define, for example, whether the ALV output is to be displayed with a simple, two-dimensional table or as a hierarchy with a leading hierarchy column.

•Field settings

The fields describe the data that is used in the ALV output. The name of a field corresponds to the name of an attribute in the context node: All field objects are automatically generated from the specifications that you made in the context node. As a result, every attribute in the context node has a representative with the same name in the ALV configuration model.
By connecting the internal data table to the context node you fulfill all the prerequisites to start your application with ALV. You can sort the data with statements from your application, filter it, or perform applications. All these functions (ALV services) are essentially field object methods. You cannot, however, display the data yet. To do this, you need columns.

•Column settings

The column objects are visible elements that define the ALV output. The columns have the same names as the corresponding field objects and attributes in the context node. The column object contains settings as to whether and how the data for the field of the same name is displayed in the ALV output. If you do not want to display the values of the field, you can delete the corresponding column object.
You use the column settings to manage a list of all the column objects (the columns for the Table UI elements).

•Standard function settings

ALV provides a number of functions. The following list shows the most important of these standard ALV functions:

• ALV services: Sorting, filtering, aggregating (calculations), as well as the option to make all the necessary settings for these services.

• Settings you can provide for editable ALV output, such as inserting and deleting rows.

• Exporting the ALV output to Microsoft Excel or generating a print version in PDF format.

All these standard functions are accessible using the relevant UI elements. You can hide or show these UI elements by using the standard function settings.

•Application-specific function settings

You can define as many functions as you want in your application and provide suitable UI elements to the user with which he or she can then run these functions.


As an application developer, you can configure all these areas. You can use a complete object model for object-oriented ABAP programming to do this. You can use it to change the ALV output, if necessary. There is an interface class for each of the areas listed here. They are implemented by the central class CL_SALV_WD_CONFIG_TABLE (see Class Diagram).

All the classes that are required for the configuration of the ALV output can be found in the system in the package SALV_WD_CONFIG.

Getting the ALV Configuration Model List Viewer in Web Dynpro for ABAP

To make the ALV configuration model available, you use, for example, a method from class IWCI_SALV_WD_TABLE in WDDOINIT. You choose one of the following methods:
...

● GET_MODEL

The system returns a complete ALV configuration model with all column objects and field objects.

This is the default variant. The method does not have any parameters.

● GET_MODEL_EXTENDED
The system returns all field objects (as above), but only returns column objects when required.
If, for example, you want to manage a large number of field objects but you only want to display a few columns, create the field objects first and later generate the column objects you require to display the content.

Parameter S_PARAM from method GET_MODEL_EXTENDED (type IF_SALV_WD_TABLE=>S_TYPE_PARAM_GET_MODEL) consists of the DEFAULT_COLUMNS field: This enables you to specify whether the column objects are to be generated or not.

You now have all the objects needed to configure the ALV output as required.

You can specify a new internal data table for the ALV output at a later stage. To do this, use method SET_DATA. However, by using this method you also automatically delete the entire ALV configuration model with all fields and column objects. To make the configuration model available again to the new data table, use method GET_MODEL or method GET_MODEL_EXTENDED.

Class Diagram List Viewer in Web Dynpro, Integration of ALV

The object model for the ALV configuration model consists of the following classes and interfaces:

This class diagram has been simplified. Some superclasses have been omitted. You can find the exact structures in the system in package SALV_WD_CONFIG.

Archiving Workbench SAP Transaction Code

AFX_WB AFX_WORKBENCH Archiving Workbench

AuC Assignment of Dist. Rule SAP Transaction Code

AIAB SAPMA15B AuC Assignment of Dist. Rule

C AM Maint. list vers. gen. line it SAP Transaction Code

AIAO SAPMV76A C AM Maint. list vers. gen. line it

Display Dist. Rule Allocation SAP Transaction Code

AIAZ SAPMA15B Display Dist. Rule Allocation

Block Asset Master Record SAP Transaction Code(TCode)

AS05 SAPLAIST Block Asset Master Record

Web Dynpro ABAP

Purpose

Web Dynpro for ABAP or Web Dynpro for ABAP (WD4A, WDA) is the SAP standard UI technology for developing Web applications in the ABAP environment. It consists of a runtime environment and a graphical development environment with special Web Dynpro tools that are integrated in the ABAP Workbench (SE80).

Web Dynpro offers the following advantages for application developers:

● The use of declarative and graphical tools significantly reduces the implementation effort

● Web Dynpro supports a structured design process

● Strict separation between layout and business data

● Reuse and better maintainability by using components

● The layout and navigation is easily changed using the Web Dynpro tools

● Stateful applications are supported – that is, if the page is changed and the required data remains intact so that you can access it at any time throughout the entire application context.

Note that stateless applications are not possible.

● Automatic data transport using data binding

● Automatic input check

● User interface accessibility is supported

● Full integration in the reliable ABAP development environment

The concept of Web Dynpro ABAP is identical with Web Dynpro Java and offers more or less the same functions.

The documentation for Web Dynpro for ABAP is divided into the following main sections:

Documentation Structure

Section	Content
Web Dynpro for ABAP Configuration	Configuration settings in the system
Web Dynpro Architecture	Platform-independent information about Web Dynpro Introduction to the terminology
Web Dynpro ABAP: Development in Detail	Basics Cross-component programming Dynamic programming Further concepts
Web Dynpro ABAP Administration	Web Dynpro trace tool ICM tracing HTTP browser tracing Logging
Tutorials	Introductory tutorials using the example of a flight information application.
Security Aspects in Web Dynpro for ABAP	ICF and logon procedures
Reference	Overview of the tools contained in ABAP Workbench UI elements Classes and interfaces
FAQ	FAQs, problem cases, reactions and solutions

You can find information about which browsers SAP supports for Web Dynpro ABAP under http://service.sap.com/pam. See also SAP Notes 981710 and 1001411.

Integration

You can integrate a Web Dynpro ABAP application as a favorite into your Easy Access menu: Creating Favorites.

You can define a Web Dynpro ABAP application as a parameter transaction: Creating Parameter Transactions for Web Dynpro Applications.

Restrictions

Previous UI technologies, such as ITS, cannot be used in combination with the new technology in Web Dynpro ABAP.

If you want to integrate an ITS-based application into a Web Dynpro ABAP application, use the Link UI element or an exit/suspend plug (see also Display an Interface View) in a WDA application.

For more information on limitations for Web Dynpro ABAP, see SAP Note 1098009.

Additional Information

For more information about Web Dynpro ABAP, see the SDN:

The Web Dynpro ABAP Knowledge Center is a collection of information about various aspects of Web Dynpro ABAP.

A large number of Web Dynpro colleagues from around the world participate in the Web Dynpro forum, providing input on Web Dynpro ABAP questions.

In Web Dynpro ABAP Wiki you can find material from the Web Dynpro forum FAQs, HowTos, and other frequently referenced materials, useful links, tips, and so on.

In the Web Dynpro weblogs, you can find all blogs published to date on the topic of Web Dynpro (ABAP and Java). Here there are also excellent demonstration videos about diverse Web Dynpro ABAP topics.

If creating an error message for Web Dynpro ABAP in component BC-WD-ABA, see the checklist in Note 938809.

Web Dynpro Architecture

Definition

Web Dynpro is the SAP NetWeaver programming model for user interfaces (UIs).

The Web Dynpro model is based on the Model View Controller 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 is available both in the Java and the ABAP development environment. Platform-specific information is available under:

Web Dynpro for Java

Structure linkWeb Dynpro for ABAP

Structure
Metamodel Concept

Web Dynpro provides support for developing Web representation of a business application. You use specific tools to describe the properties of a Web Dynpro application in the form of Web Dynpro metadata. The necessary source code is then generated automatically and executed at runtime. In addition to the events offered by the framework, you can also define your own events for a Web Dynpro application. However, the event handling must always be programmed in separate source code areas which are executed automatically when the event is triggered at runtime.

In Web Dynpro, each user interface is always made up of the same basic elements. These elements of the metamodel can be statically declared using Web Dynpro tools.

It is also possible to implement elements of the metamodel at runtime and to change them or reintegrate them at runtime. Using these implementations, you can make any changes or enhancements to a user interface that has been created by declarative methods by generating new interface structures at runtime.

This means that you can combine declarative processes and the implementation of source code.

Graphical Development Tools

To support this declarative concept, both the SAP NetWeaver Developer Studio and the ABAP Workbench contain a range of Web Dynpro tools. You can therefore generate a large proportion of a Web Dynpro application using the tools provided, without having to create your own source code. This applies to the following parts of the application:

· Data flow between the front end and back end

· Layout of the user interface

· Properties of user interface elements

The Web Dynpro tools enable you to create source text areas manually within generated source texts. These areas are not changed if the source code is regenerated.

Separation of Business and Application Logic

Using Web Dynpro enables a clear separation of business logic and display logic. A Web Dynpro application runs on the front end and has local or remote access to the back end system via a service. This means that the display logic is contained in the Web Dynpro application, while the business logic and the persistence of the business objects run in the back end system. The following options are currently available for connecting Web Dynpro applications and the back-end system:

· An interface generated using adaptive RFC, through which BAPIs of an SAP system can be called

· An interface for calling Web services

· A self-generated interface

The source code required for connecting the Web Dynpro application can be generated from a UML definition of the Web Dynpro interface. A UML definition can be imported into the Web Dynpro tools as an XML file.

Conversion of the Model-View-Controller Programming Model

Every Web Dynpro application is structured according to the Model View Controller programming model:

· The model forms the interface to the back end system and thus enables the Web Dynpro application access to data.

· The view is responsible for the representation of the data in the browser.

· The controller lies between the view and the model. The controller formats the model data to be displayed in the view, processes the user entries made by the user, and returns them to the model.

Web Dynpro Component

Definition

A Web Dynpro component is a reusable entity. It summarizes all components that are required as part of this programming unit for an executable Web Dynpro application.

The Web Dynpro component concept offers a number of advantages:

● Structuring of the programming

● Creation of easily manageable application blocks

● Reusability of whole components

● Decoupling of software projects in both time and space

The Web Dynpro component contains any number of windows and views and their corresponding controllers. Additional Web Dynpro components can also be referenced.

The creation of a Web Dynpro component is always mandatory, since the existence of the Web Dynpro window and the views and controllers that it contains is linked to the existence of the component itself. Communication between the elements of two Web Dynpro components and their call by a user is implemented using the component interfaces, so it does not make sense to consider the individual parts of the component separately.

A Web Dynpro component can embed other Web Dynpro components, and correspondingly a Web Dynpro component can be embedded in any other Web Dynpro components. This communication also takes place over the component interfaces.

Lifetime of a Web Dynpro Component

A Web Dynpro component’s lifetime begins the first time it is called at runtime, and ends with the lifetime of the Web Dynpro application that called and thereby instantiated the component. For embedded components this means that during the lifetime of the embedded component, they are not instantiated until the moment when they are required. Their lifetime ends, however, at the same time as the embedded component when the Web Dynpro application that was originally called is ended.

It is also possible for the embedding component to create or destroy the embedded component using an appropriate API and thus control its lifetime.

Web Dynpro Component View

Definition

A view describes the layout and behavior of a rectangular area of a user interface.

Use

Every Web Dynpro application has at least one view. The layout of a view is made up of different user interface elements, which can be nested in each other. The positioning of interface elements in one view is supported by the supplied layout variants.

In addition to the visible part, the layout, a view also contains a controller and a context. The data to which the elements of the view can be bound are stored and managed in the view context, enabling them to be represented or used on the screen. The view controller can contain methods for data retrieval or for processing user input.

Multiple views can be classified in view sets.

The concept of view sets is only offered in Web Dynpro for Java.

A view also has inbound and outbound plugs so that views can connected with each other, or so that a view can be linked with an interface view. These plugs can be linked with each other using navigation links.

Empty View

The empty view is a special type of view. It is always generated automatically in a window or a view set area, provided that no view has been embedded manually. It may also be preferable to embed an empty view in a non-empty window as well. Just like a normal view, the empty view occupies a certain area of a window at runtime and can be used to hide a different view, for example, using specific controls.

When you create an empty view, an inbound plug with the default name ShowEmptyView is created.

Web Dynpro Component View Set

The concept of view sets is only offered in Web Dynpro for Java.

A view set provides a visual frame with predefined subsections into which you can embed your views at design time.

Using view sets is particularly advantageous when you design, implement, or display the user interface of a Web Dynpro application:

· Structured option to display more than one view in a screen

· Efficient support when designing user interfaces

· Possibility of using the predefined areas to make changes to the layout at a later stage

· Reuse of views within a Web Dynpro window

The Web Dynpro framework provides the following preconfigured view sets:

T layout	T layout 90°	T layout 180°	T layout 270°	Grid layout	Tab strip

Displaying a view and its embedded view sets always occupies 100% of the screen display area.

However, you can define a view set and, at design time, embed an empty view in a selected area of a view set. This area is displayed as an empty area at runtime. For more information about empty views

Web Dynpro Component Plugs and Navigation Links

Navigation between different views is enabled by plugs. These can be divided into inbound and outbound plugs. While inbound plugs define the possible starting points of a view, the outbound plugs of a view can be used to call a subsequent view. Plugs are part of the controller of a view. They are always assigned to exactly one view.

Since interface views behave exactly the same as views with regard to navigation, the properties described below also apply to interface views.

· Several views are generally embedded in a Web Dynpro window. Therefore, it is necessary to qualify one view as the view that is displayed first of all when a window is called. This view is assigned the Default property. The subsequent navigation structure is then created using this view.

The entering of a view using an inbound plug always causes an event handler method to be called. This is why an event handler method (whose use is optional) is automatically generated for every inbound plug. In this case, the inbound plug itself represents the event to be handled.

If a view is flagged as the default view in a window, it is not called using the inbound plug.

To navigate from one view to another, each outbound plug from the first view must be linked with an inbound plug of the second view with the help of a navigation link.

· Exactly one navigation link can originate from one outbound plug, although this can lead to a series of target views. The arrangement of these target views is not qualified, which means that all target views are controlled at the same time.

· In contrast, an inbound plug can be controlled by several outbound plugs.

Information about which plugs are connected with each other is not contained in the individual views. This information is stored separately in navigation.

By implementing the navigation you create a static, potential connection between two views of a Web Dynpro application. You thus define the view sequence for when the Web Dynpro application is executed. You must define a navigation link for each possible view change.

Web Dynpro Window

Definition

A window is used to combine several Views and View Sets (the concept of view sets is only offered in Web Dynpro for Java). A view can only be displayed by the browser if it has been embedded in a window. A window always contains one or more views, which are connected by navigation links. One of these views, or a view set, is specified as the start view and is displayed the first time the window is called.

Plugs and Window Controller

Windows have inbound and outbound plugs. For more information, refer to Window Plugs.

A window controller is assigned to each Web Dynpro window. The window controller is a global controller. It is visible by all other controllers within the component.

The concept of the window controller and window plug is not implemented for Web Dynpro Java in SAP NetWeaver 7.0.

Interface View

Each window has a uniquely assigned interface view. This interface view represents the outward view of the window. The interface view is linked with a Web Dynpro application so that the window can be called using a URL.

Furthermore, the interface view enables windows to be reused by multiple components (see also, Web Dynpro Component Interfaces). This means that in addition to all component-specific views, the interface views of windows of all components that are known by the current component (that is, for which a component use has been created) can be embedded in a window. Just like the view, the interface view has inbound plugs and outbound plugs and can be integrated in navigation structure of another window using these plugs. (See also Web Dynpro Component). These are plugs of the appropriate window that are explicitly marked as interface plugs and can therefore be provided to the interface of the component.

Each view can be displayed only once in the current window at the same time; this also applies to an interface view of a used component. It is possible, however, to declare several uses for one and the same component. In this way, you can display an interface view multiple times.

Web Dynpro Component Window Plugs

The concept of the window controller and window plug is not implemented for Web Dynpro Java in SAP NetWeaver 7.0.

Inbound Plugs and Outbound Plugs

A window has one or several inbound or outbound plugs. Using these plugs, a window can be included into a navigation chain. The concept of these plugs corresponds to the concept of the plug for a view. Each plug of a window is visible within the entire window and can be used for navigating within this window. In addition, one or several plugs can be made accessible to the component interface so that they are visible even beyond the limits of the component in question. They thus belong to the interface view of the relevant window.

The Plugs of the Interface View

If an existing plug of a window is added to the component interface, it is then part of the interface view belonging to this window (see also Interface of a Component).

These interface plugs are required whenever

● A component window is embedded in a window of another component the display at the screen is to navigate there.

● A Web Dynpro application is to be set so that it can be called.

● A Web Dynpro application is to be exited.

To call or close a Web Dynpro application using an interface plug, the relevant inbound plug must be declared as a startup plug, and the relevant outbound plug as an exit plug. You need interface inbound and outbound plugs of type Standard for component usages - that is, precisely when an outer component is being connected to an inner component.

Outbound Plugs

Outbound plugs within a window lead from the window to the inbound plug of a view. Using these outbound plugs, it is possible to start navigation within the window with different views instead of using a predefined start view. You set the control as to which outbound plug is called using the event handler method of the called interface inbound plug (see below).

Inbound Plugs

Inbound plugs within a window lead from the outbound plug of a view to the embedding window. Just like all other inbound plugs, they represent an event and thus call the event handler assigned to them. In this way, it is possible to control – within the window controller – which inner outbound plug is to be called next. In this way, you can dynamically define the sequence of the views displayed in the window.

The event handler of an inbound plug can also call an interface outbound plug, for example (see also the section entitled Plugs of the Interface View).

Web Dynpro Component Controller

Definition

Controllers are the active parts of a Web Dynpro application. They define how the user can interact with the Web Dynpro application. The data that a controller can access is defined in the corresponding context. Different instances of controllers and contexts exist within a Web Dynpro application. In addition to view controllers, which control the behavior of an individual view, there are also global controllers that offer more general services for all the views of a component.

Use

View Controller

Each view has exactly one view controller, which processes the actions performed by the user in the view. A view also has exactly one view context, which contains the data required for the view.

A view controller and the corresponding context exist at least as long as the view is visible in the browser. If the view is replaced by a successive view, the local data is also no longer available. However, the lifetime can also be connected to the lifetime of the surrounding component.

A view may be visible in the technical sense as part of a view set, although its content on the screen may be a hidden tab in the background, for example. In this case the view data is still available as before, and the view exists.

Global Controllers

Each Web Dynpro component additionally contains at least one global controller that is visible within the component for all other controllers. Once the data for this component controller has been created the first time it is accessed, the lifetime extends to cover the whole period during which the component is in use.

You can add additional global controllers in the form of custom controllers. These also last as long as the component and the data they contain are available to all views of the component.

Every time there is a Web Dynpro window, a further global controller – the Window controller – is added to the component.

Interface Controller

Each Web Dynpro component contains exactly one component controller. This controller is a global controller that is also visible outside the component. It is thus part of the interface of a Web Dynpro component.

Communication from one controller to the next is achieved by calling methods from a different controller, or by triggering an event on which other controllers are already registered. You define these controller uses when you create a controller.

Source Code

Each controller contains program areas in which you can insert your own source code. Therefore, an Application Programming Interface (API) exists for the processing of context nodes and their attributes and data. The necessary initialization of nodes can also be executed using this API. There are further APIs available, such as the server abstraction layer for accessing the system environment, and the APIs for message handling and dynamic programming.

Controllers can contain their own source code in the following areas:

● Event handlers – these are executed when a view is initialized, ended, or entered, when a user interface element of a view triggers an action, or when other controllers trigger a registered event.

● Methods – these can be called by other controllers

● Supply functions – these are executed when necessary to initialize elements in the context

Web Dynpro Component Context

Definition

The data used in the component or in the view is stored in the context. Read-write access to this data is available using the controllers as a starting point.

Structure

The data from the contexts is managed in a hierarchical structure. Each context has a root node, underneath which the individual data fields (attributes) are stored in a tree structure. You create this tree structure according to the structure of your application.

Each node contains data fields that represent one of the following:

• An individual instance of an object type
• A table of instances.

darstellen. This property of a node is known as its cardinality. The following table summarizes the possible cardinalities for a node:

Cardinality	Meaning
1:1	The node contains only one element instance; this instance is instantiated automatically.
0:1	The node contains only one element instance; this instance must not be instantiated.
1:n	The node can contain multiple element instances of which at least one must always be instantiated (and is instantiated automatically).
0:n	The node can contain multiple element instances of which none have to be instantiated.

For more information on this property and other properties of context nodes, see Context Nodes Properties.

Recursion Nodes

Dynamic node nesting is possible within a context, creating what is called a recursion node. The node that is used for recursion is always a predecessor of the new node. The newly created recursion node is a reference to a predecessor node and therefore cannot be processed separately. Instead it takes on the structure of the node to be repeated.

The root node of a context cannot be used for a recursion.

Web Dynpro Component Context Node Properties

Cardinality of a Context Node

When a node is created in the context of a Web Dynpro component, the cardinality of the node is specified. The cardinality defines how often a node is to be instantiated at runtime – that is, how many elements of this node are available at runtime.

Cardinality

Cardinality	Description
1…1	Only one element is instantiated.
0…1	At runtime, no more than one element is instantiated, but it is also possible that no element is instantiated.
1…n	n elements can be instantiated, but at least one element must be instantiated.
0…n	Any number of elements of the context node can be instantiated.

Example

The context node Vehicle is used to describe the fleet of a car rental company. It has the cardinality 1…n and is filled from a database table. A number of attributes of this node have a specific value for each vehicle.

The database table indicates that the company owns three vehicles, each with a unique registration date and unique license plate number. Thus, to display this table in the Web Dynpro application, 3 elements of the Vehicle context node must be instantiated; the cardinality of the node must therefore be 0…n or 1…n. (If the Vehicle node is to be filled with values in the context of another function – for example, from a table of all currently available cars – the cardinality 0…n should be used since this table could be empty – that is, if all cars are rented out.)

At runtime, the Vehicle context node should contain three elements and appear as follows:

As well as these attributes, a context node can also contain additional child nodes:

For each customer of a car rental company, the two attributes “rented from” and “rented till” are listed in the context. At runtime, the context then contains the additional relevant values:

At runtime, each element of the Vehicle node contains a subnode called Customer. These subnodes can contain further elements. Thus, the Customer node of the first element of the Vehicle node (the node with the descriptive data for the red car) contains three elements in its turn, one element for each of the three stored rental procedures.

Lead Selection

The lead selection is extremely important within the nested context structure. The lead selection defines which element of the context is ultimately accessed at runtime. This behavior is easiest to explain using an example:

The UI of the example application contains a TextView element that should display the name of the customer at runtime. Without a clear regulation of the selection path for the context structure, all values of the Name attribute would be equal and it would not be possible to correctly display the name in the TextView element. For this reason, one element of the set of possible elements for the Customer node must be clearly designated. This is achieved by initializing lead selection. The automatic initialization of the lead selection always designates the first element of a node. For the above example, this means:

The lead selection is always automatically on the first element of the Vehicle node (on the node with the data for the red car). Analog to this, the lead selection is on the first element of the Customer subnode (on the element that contains the data for David Grecco).

This special way of designating elements can be depicted as follows in the runtime context.

Only if the lead selection falls on another element of the Vehicle node (as a result of user action or a program step in a method) is the corresponding element of this Customer subnode displayed in the UI element. If the lead selection is set on the second element of the Vehicle node, the customer Pierre Dubois is displayed. The lead selection of the Customer node can be varied at runtime in this way. This enables the names of all available customers to be displayed one after the other in the UI.

Automatic/Manual Initialization

Lead selection is initialized automatically for each newly created context node.

● Using the preset automatic initialization of lead selection:

In this case, the first element of a node is always assigned the lead selection property.

● Manual initialization of lead selection:

If automatic initialization was deactivated, the lead selection can be programmed manually. In this case it is possible to assign this property to an element other than the first element of a node (for example, using an index).

Singleton Property

The singleton property of the Customer context node defines that the elements of this node are instantiated only for one of the three vehicles at runtime – that is, the element that bears the lead selection. If the lead selection was initialized automatically, this is the first element of the Vehicle node. In this case, this is element 1, which contains the data on the red car.

If each customer has multiple addresses, it may be necessary to include a child node for the addresses below the Customer child node. In this manner, the data content of a root node can rapidly become very large if, at runtime, all customers are displayed with all their addresses for each vehicle of the car rental company. To limit the content of a context node at runtime, the context node can be assigned the Singleton property. As a result, the elements of the relevant node are instantiated for only one element of the parent node. This means:

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

If the Customer node in our example is set as a singleton, the context will be as follows at runtime:

The elements of the Customer child node are only available to one element of the Vehicle parent node and not to all other elements. However, if you want to instantiate the elements of the Customer node for all vehicles, you must set the singleton property for the Customer node to 'false'.

Since the root node of a context is only ever instantiated once, every node directly below the root node (in our example, Vehicle) is always automatically a singleton node.

Web Dynpro Component Data Binding and Mapping

Within the Web Dynpro architecture, the contexts of the different controllers can be linked in different ways:

● A UI element of the user interface of the view can be linked with an element of the view context.

● A mapping can be defined between two global controller contexts, or from a view context to a global controller context.

● The context of a global controller can be linked to a Web Dynpro Models.

Defining Mapping Between Two Contexts

The elements of a view context can be locally defined. In this case (depicted in the graphic below as a "Local Node"), all the contained attributes are only visible within the relevant view. When the view disappears, the attribute values are deleted.

A second option for defining context elements is to link a context node to a node of another context. The graphic above represents the definition of a mapping between the node "Node 1" from the context of View 1, and the node of the same name in the context of the component controller. Also displayed is a mapping from the node "Node 2" from the context of View 2, also to a node with the same name in the component controller context. The global context of the component controller is visible for both view controllers, and all the controllers involved have both read and write access to the contained attributes. The values for the attributes of the component controller context are contained here as long as the user does not exit the component. The values are retained even if the view that you used last is no longer displayed on the screen. It is therefore possible to transport data across different contexts within a component. A data value that, for example, has been read from an input field of the first view, can be forwarded to the context of the component controller using a suitable mapping. The value then still exists in the memory if the navigation has already led to the next view. If a corresponding mapping is already defined for the successive view, the view can then process this value.

If the value is then changed in the second view, any subsequent views for which a similar mapping is defined then find the current value in their context.

All global controller contexts (visible component-wide) can be linked to each other. A mapping can also be defined from a view context element to an element of a global context. Conversely, however, it is not possible to define a mapping to an element of a view context: An element of a view context cannot be mapped to an element of a global context. This is because the lifespan of the view context is generally shorter than that of the global controller context.

Binding a UI Element to a Context Attribute

Properties of the user interface elements contained in the view can be bound to attributes of a view context. This enables the context data to be displayed in the browser. Any user changes to the view displayed in the browser are stored in the context. Multiple properties can be bound to one context element.

Within a context, all elementary data types are available for the definition of attributes. The information stored here is also used by a Web Dynpro application for creating value help, and for creating error messages if invalid entries are made.

Defining a Binding to a Web Dynpro Model

You can also define a binding between the context of a component controller and the data of a Web Dynpro model.

Web Dynpro Component Event

The component controller allows you to create events.

Events are used to communicate between controllers and enable one controller to trigger event handlers in a different controller.

Cross-component communication can be implemented using the interface controller’s events. Events that were created in the component controller are visible within the component only.

Inbound Plugs

Inbound plugs in a view also react like an event. Therefore, when a view is called using an inbound plug, the event handler that is optionally available for the inbound plug is always called first. In this case event handling takes place within the current view controller, however.

The same applies for the inbound plugs of an interface view. In the corresponding window controller, an event handler is created. It can then be programmed further, as appropriate.

UI Element Events

Some UI elements, such as the Button element have special events that are linked with user actions. These events are predefined and have to be linked with an action at design time.

Web Dynpro Component Action

Actions for UI Element Events

Some UI elements, such as the button element, can react to a user’s interaction: Clicking on the corresponding pushbutton can trigger a handling method to be called within the view controller. Such UI elements are equipped with one or several general events that can be linked with a specific action at design time (switching to a subsequent view, for example). If such an action is created, an event handler method for this action is created automatically. In this way, you can equip a UI element event (that has been inserted several times into a view) with different actions as necessary. The event is then processed by the corresponding event handler depending on the action that is linked.

Actions can also be reused within a view. This means that an action can be linked to the events of several (or even different) UI elements.

Unlike cross-controller events, UI element events are always handled within their own view controller; there is no cross-controller communication. UI element events themselves are predefined and cannot be changed.

Interfaces of Web Dynpro Components

Each component has an interface in order to enable communication between Web Dynpro components and to enable a component to be called up by a user. This interface consists of two parts:

Interface View of a Window Contained in a Component

The interface view of a Web Dynpro window is used to link a window with a Web Dynpro application that can be called by the user.

An embedded component can also be integrated in one of the windows of the embedded component using inbound and outbound plugs. These inbound and outbound plugs are implemented as part of the respective window. The window of the embedded component can behave like a view with regard to navigation. (See also Web Dynpro Window)

The window of the inner component does not have to have graphical elements. It can also be available for the functions contained in your component controller or for contexts for the embedding component.

Interface Controller of a Component

As well as the visual part, the interface of a Web Dynpro component also has a programmatic part, the interface controller. This is visible inside and outside of the component, and performs the program side of the exchange of business data. An embedding component can also call an embedded component using this controller.

The interface controller, like the interface view, is not an independently implemented object. Instead, the visibility of methods and events of the component controller can be extended beyond the limitations of the component in question.

An additional option for data exchange between the embedding and embedded component is cross-component context mapping.

The interface of a Web Dynpro component can also be defined independently without implementation. It is therefore possible to separate the development of the Web Dynpro component and the development of one use of the Web Dynpro component. You can also create multiple interface implementations for a Web Dynpro component. For each interface, the required implementation is not selected until runtime. The interface and implementation are linked by the same name.

Web Dynpro Application

A Web Dynpro application is an application that can be called from the user interface. As an independent program unit it connects a URL that can be accessed by the user with a window in the Web Dynpro component.

The Web Dynpro application is merely linked to an interface view of a Web Dynpro by an inbound plug declared as a startup plug. It therefore contains no information whatsoever about the elements of the corresponding component or components behind the interface view.