Entering content frame

Process documentation Modeling Web Dynpro Windows Locate the document in its SAP Library structure

A Web Dynpro window is a container into which you can embed any number of views and view sets. You use view sets to divide the Web Dynpro window into individual areas; you can nest view sets any way you like. Both Web Dynpro windows and view sets can contain views. The browser can display a view only after it was embedded either directly into a window or indirectly into a view set. Web Dynpro windows are used exclusively for display purposes; they always contain one or more views or view sets, provided that the Web Dynpro component has a UI. However, it is possible for a Web Dynpro component to have no UIs and, therefore, no Web Dynpro windows. You can use navigation links to interlink the individual views. In the documentation on the J2EE Technologies in the SAP Web Application Server, the Developer’s Guide introduces Web Dynpro Windows under Developing Web Applications in the Introduction to the Web Dynpro Programming Model.

In this phase, you identify the appearance and the behavior of the Web Dynpro components with regard to the user. Besides the arrangement of the views, the navigation between the views, the view layouts, you use this phase to determine the binds between UI elements and contexts or actions. Use the Web Dynpro window diagram for an overview of the view arrangement and the navigation between the views. The Web Dynpro windows diagram strongly resembles the Navigation Modeler, but it offers more modeling options. Unlike the Navigation Modeler, the Web Dynpro windows diagram not only models the navigation links, but also labels the outbound plugs with the names of the methods that trigger the navigation. This is the reason why we could not use the Navigation Modeler to create the Web Dynpro window diagrams below. The Web Dynpro window diagrams for the Web Dynpro components Flights and ItemSearch from our example look like this:

 

This graphic is explained in the accompanying text

 

 

This graphic is explained in the accompanying text

 

How Should the Views Be Arranged?

You can divide a Web Dynpro window into view areas using view sets in which you embed the views. You can insert multiple views into a view area. However, only one of them is active at runtime. To determine the arrangement of the view sets and views of a Web Dynpro window, use the Navigation Modeler of the window.

The views should enable the user of the application to solve a particular task. The user must usually work through a series of subtasks to solve a specific task and these subtasks are often interrelated. Therefore, you should assign the subtasks to individual views and make sure that the view arrangement is intuitive. The user should always know the current location and the next steps to be executed. The intuitive view arrangement is crucial for the efficient work of the user.

Example

In our example, the Web Dynpro window for the Web Dynpro component FlightsComp consists of a view set with two vertically arranged cells. The upper cell contains the StatusView, which shows the status of the flight booking. The lower cell contains the interface views of the used Web Dynpro components needed for flight booking (ItemSearchInterfaceView, ItemAvailabilityInterfaceView, CustomerDetailsInterfaceView, PurchaseOrderInterfaceView, ContractConfirmationInterfaceView).

In our example, the Web Dynpro window for the Web Dynpro component ItemSearchComp consists of a view set with four vertically arranged cells. The upper cell contains the SimpleSearchView for the simple flight search. Initially, the second cell contains an empty view. If the user requests an advanced flight search, this cell displays the AdvancedOptionsView. The third cell displays the flights that meet the search criteria within the SearchResultView. Initially, the lowest cell is empty. After the user selects a flight, detailed information about this flight is displayed in the SearchResultDetailsView.

What Navigation Options Exist Between the Views?

You model the navigation between two views using a navigation link that points from an outbound plug to an inbound plug. A navigation link between two views means that, while the Web Dynpro application is running, the user can navigate from one view to the other. Inbound plugs define the possible entry points of a view. Outbound plugs enable navigation to another view. An outbound plug of a view can trigger the outbound navigation links, so that after triggering the navigation link, the respective inbound plugs become visible. Implicitly, the remaining views in the same view area become invisible. Plugs are part of the controller of a view. They are always assigned to exactly one view. This can be an interface view, for example. For each inbound plug an event handler method is automatically generated; the method is called as soon as the respective view is activated.

Using the Navigation Modeler, the application developer determines the sequence in which the views can be used while the Web Dynpro application is running. In addition, in the Web Dynpro window diagram, the developer labels the outbound plugs with the names of the methods that trigger the navigation.

Example

In our example, the sequence of the views for the Web Dynpro component FlightsComp is defined as follows:

The StatusView is always visible within the Web Dynpro component FlightsComp. After launching the application, in the bottom cell the ItemSearchInterfaceView is initially visible. The event handler of action AvailabilityWantedAction deactivates the ItemSearchInterfaceView and activates the ItemAvalabilityView, so that after searching for flights and selecting the desired flight, the user now sees which seats are available and can select a free seat. The same applies for the other navigation links. The handler of event EndOfContractConfirmationEvent, which is executed when exiting the Web Dynpro component ContractConfirmationComp, reactivates the ItemSearchInterfaceView to allow the user to start a new flight search.

In the Web Dynpro component ItemSearchComp, the sequence of the views was determined as follows:

While the flight search is running, the user can navigate from the View SimpleSearchView to the AdvancedOptionsView, using a navigation link that is triggered within the event handler of action AdvancedOptionsAction. Triggering event AdvancedOptionsAction once more, makes the AdvancedOptionsView invisible again. The SearchResultsView, on the other hand, is always visible within the Web Dynpro component ItemSearchComp. After selecting a flight, the event handler of action SelectedFlightAction activates the SearchResultDetailView in the bottom cell and makes it visible. If the user executes a new search, the event handler of action SearchAction replaces the SearchResultDetailView with an empty view.

Which UI Elements are Contained in the Views?

The UI elements contained in a view determine its appearance. Depending on the task of the view in a Web Dynpro application, you must select the relevant UI elements from the categories below. The documentation on the J2EE Technologies in the SAP Web Application Server documents in the Reference Manual under Structure linkWeb Dynpro UI Element Reference Guide the UI elements provided by Web Dynpro.

 

Category

User Interface Elements

Adobe

InteractiveForm

OfficeIntegration

OfficeControl

BusinessGraphics

BusinessGraphics, GeoMap

Simple Standard

Button, Caption, CheckBox, CheckBoxGroup, DropDownByIndex, DropDownByKey, FileDownload, FileUpload, HorizontalGutter, IFrame, Image, InputField, InvisibleElement, Label, LinkToAction, LinkToURL, ProgressIndicator, RadioButton, RadioButtonGroupByIndex, RadioButtonGroupByKey, TextEdit, TextView, ToolBarButton, ToolBarDropDownByIndex, ToolBarDropDownByKey, ToolBarInputField, ViewContainerUIElement

Complex Standard

DateNavigator, RoadMap, TabStrip, Table, Tree

Container Standard

Group, ScrollContainer, TransparentContainer, Tray

Pattern

MessageArea

 

Example

In our example, the SimpleSearchView (as shown in the screen capture of the corresponding View Designer below) consists of three label UI elements (for the departure city “From:“, the arrival city “To:“ and the departure date ”Date:“), of three input fields (for the departure city, the arrival city and the departure date), and two pushbuttons (for advanced search options: ”Open Advanced Search Options“ and for starting the flight search: ”Search!“):

 

This graphic is explained in the accompanying text

 

How Should the UI Elements of a View Be Arranged?

You use the View Designer to arrange the UI elements within a view. If you haven’t done so before, you should in this phase start to use the usability style guide. Therefore, at this point we only give an overview of a few important cirteria designed to help you with developing simple, supportive, and intuitive applications.

·        Simple applications:

¡        Use the smallest possible number of UI elements that require input by the user

¡        Only offer a small number of navigation options to avoid confusing the user

¡        Have only a few or no dependencies between data and views

·        Supportive applications:

¡        Support the user in executing his or her tasks without requiring much training

¡        Allow the user to return to the previous page

¡        Provide the user with input help

·        Intuitive applications:

¡        Are as self-explanatory and easy to handle as possible

¡        Are easy to understand

¡        Do not require extensive instructions or documentation

Example

The screen capture above shows the layout of the SimpleSearchView created in the View Designer.

To Which Context Elements are the UI Elements Bound?

You can either set the bindable properties of the UI elements directly to a fixed value in the respective property window or you can bind them to a context element from the corresponding view context. If desired, you can use the Data Modeler to map the bound view context elements to other context elements or bind them to a model. The documentation on the J2EE Technologies in the SAP Web Application Server documents in the Reference Manual under Structure linkWeb Dynpro UI Element Reference Guide the bindable properties of all UI elements.

Example

For the “From“ InputField of the SimpleSearchView of our example, in the corresponding properties window (see below), the value property was bound to the context element BapiFlightGetList.Destination From.City:

 

This graphic is explained in the accompanying text

 

For the “Date“ InputField of the SimpleSearchView of our example, the value property was bound to the context element BapiFlightGetList.DateRange.Low.

To Which Actions are the UI Elements Bound?

You must bind the actions of a view defined in the view controllers to the respective UI elements of this view. You can do this in the Properties window of the UI element.

Example

For the “Search“ pushbutton of the SimpleSearchView of our example, we bound in the corresponding Properties window (see below) the onAction property to the action SearchAction:

This graphic is explained in the accompanying text

 

For the “Open Advanced Search Options“ pushbutton of the SimpleSearchView of our example, we bound the onAction property to the action AdvancedOptionsAction.

  

  

 

Leaving content frame