Modeling Web Dynpro Components 

A Web Dynpro component is a reusable entity consisting of views and controllers. Web Dynpro components can be reused as a whole or simply be used to structure a Web Dynpro application. In the documentation on the J2EE Technologies in the SAP Web Application Server, the Developer’s Guide introduces Web Dynpro Components under Developing Web Applications in the Introduction to the Web Dynpro Programming Model.

In this phase, you identify the content of Web Dynpro components, especially the behavior within the Web Dynpro components. Besides the views and custom controllers, you define their methods, events, and context elements. In addition, you determine the data and control flow within each Web Dynpro component in this step. The data flow is modeled by a labeled edge between the Web Dynpro entities concerned; the edge identifies the context to be mapped. The control flow, too, is modeled by a labeled edge between the Web Dynpro entities concerned; the edge identifies either method calls or the events used between the Web Dynpro components. You can visualize this with the Web Dynpro component diagram. The Web Dynpro component diagram strongly resembles the Data Modeler, but it offers more modeling options. In contrast to the Data Modeler, the Web Dynpro component diagram not only models context mappings, but also method calls and events used. This is the reason why we could not use the Data Modeler to create the Web Dynpro component diagrams below. The Web Dynpro component diagrams for the Web Dynpro components Flights and ItemSearch from our example look like this:

 

 

Which Views Make Up the Web Dynpro Components?

The display of a Web Dynpro component is defined by the views it contains. Every view is a part of the UI of a Web Dynpro component. Within a Web Dynpro component to be developed, you should therefore specify UI elements that can be encapsulated in views.

The view is a visual representation of UI elements that belong together with regards to content and that serve a specific purpose (for example, the entry of search criteria or the output of search results). Complex Web Dynpro components usually consist of multiple views. Within a Web Dynpro component, you can also embed interface views of other Web Dynpro components. Interface views are special views that determine the visual aspects of a Web Dynpro component; however, they can be embedded just like normal views.

In the Web Dynpro component diagram, a view is symbolized by a rectangle carrying the name of the view.

Example

In the Web Dynpro component ItemSearchComp, which is used for the flight search, you can identify the following views:

·        SimpleSearchView : Entry option for simple flight search criteria

·        AdvancedOptionsView: Entry option for advanced flight search criteria

·        SearchResultsView : Table of flights found

·        SearchResultDetailsView : Detailed information on the selected flight in the table

Which Custom Controllers are Used in the Web Dynpro Components?

Custom controllers contain the data, methods, events, and event handlers (special methods used to determine the reactions to events) you cannot assign to a particular view, because they concern several views or fulfill a more global task.

In the Web Dynpro component diagram, a custom controller is symbolized by a rectangle carrying the name of the custom controller.

Example

In our example, FlightCust is a custom controller responsible for managing the flight data; it provides several views (SimpleSearchView, AdvancedOptionsView, SearchResultsView, SearchResultDetailsView) with data.

Which Methods and Events are Defined Within the Web Dynpro Components?

Within a Web Dynpro component, you define methods, events, event handlers (special methods used to determine the reactions to events), and actions (special events the user triggers via UI elements). At this stage, you do not specify the location of the method or event definition. You only specify that a specific method or event exists for a Web Dynpro component. In the next step, you decide to which controller to assign the methods and events.

Example

In our example, the Web Dynpro component ItemSearchComp needs the following methods and events to perform a flight search:

...

·        A method getFlights that determines all flights that meet the previously selected criteria. This method is called in an event handler of action SearchAction and triggers the flight search.

·        A method getFlightDetailsthat determines the details to a selected flight. This method is called in an event handler of action SelectedFlightAction.

·        A method informFlightsCompthat signals to the Web Dynpro component FlightsComp that the user exits the flight search. This method is called by an event handler of action AvailabilityWantedAction and signals that the user is interested in the availability of the selected flight.

·        An event EndOfItemSearchEvent, triggered in method informFlightsComp to inform the Web Dynpro component FlightsComp that the Web Dynpro component ItemSearchComp has been exited.

For reasons of clarity, in the Web Dynpro component diagrams for ItemSearchComp and FlightsComp, the methods called and events triggererd within the called method are not included. Optionally, you can include this information in the diagrams.

An appropriate event handler is automatically created for each defined action. For example, for action SearchAction an event handler onActionSearchAction is automatically created, which is called by action SearchAction and itself calls method getFlights. For action AvailabilityWantedAction, an event handler onActionAvailabilityWantedAction is automatically created, which is called by action AvailabilityWantedAction and itself calls method informFlightsComp.

In our example, the Web Dynpro component FlightsComp needs the following methods to perform a flight search:

·        An event handler handleEndOfItemSearchEvent that is called by the event EndOfSearchEvent to update the Web Dynpro component FlightsComp accordingly

·        The method initUsedComponents, which initializes at the event EndOfContractConfirmationEvent the Web Dynpro components used by the Web Dynpro component FlightsComp in order to be able to conduct a new flight search

In Which Controllers are the Methods and Events Defined Within the Web Dynpro Components?

The methods and events determined in the last step, must now be defined in a controller. The Web Dynpro programming model offers the following controller types:

 

Controller Type	Use
View Controller	This controller contains only data, methods, and events that concern the respective view.
Custom Controller	This controller contains data, methods, and events that you cannot assign to a particular view, but that concern several views or fulfill more global tasks.
Component controller	This controller contains data, methods, and events that are related to the whole Web Dynpro component and are not related to a more global task.
Component interface controller	This controller contains data, methods, and events that can be used by other Web Dynpro components.

 

Unlike the Data Modeler, the Web Dynpro component diagram also models method calls and the events used.

·        In the Web Dynpro component diagram, a method call is symbolized by an edge giving a direction; it is labeled with the name of the calling method and, optionally, with the method called in the calling method. The edge determines the call direction.

·        In the Web Dynpro component diagram, an event used and the relevant event handler are symbolized by an edge giving a direction; it is labeled with the name of the event and, optionally, with the method in which the event is triggered. The edge determines the trigger direction.

To identify these edges as part of the control flow, they are shown as dashed lines.

Example

In our example, the methods and events of the Web Dynpro component ItemSearchComp, which we determined in the last step, are defined in the following controllers:

·        The method getFlights is defined in the custom controller FlightCust, because this method determines all flights that meet the previously selected criteria and, thus, takes on a task in flight data management. The flight search is triggered via a pushbutton in the SimpleSearchView view. For this reason, action SearchAction is defined in the view controller of the SimpleSearchView.

·        The method getFlightDetails is defined in the custom controller FlightCust, because this method determines all details of a previously selected flight and, thus, takes on a task in flight data management. Determining the flight details is triggerd by a selection in the SearchResultsView. For this reason, action SelectedFlightAction is defined in the view controller of the SearchResultsView.

·        The method informFlightsComp is defined in the component interface controller of the Web Dynpro component ItemSearchComp, because this method triggers event EndOfItemSearchEvent and, thus, serves the cross-component communication between the Web Dynpro component ItemSearchComp and FlightsComp. The call of method informFlightsComp is triggered via a pushbutton in the SearchResultDetailsView . For this reason, action AvailabilityWantedAction is defined in the view controller of the SearchResultDetailsView.

·        Because the event EndOfItemSearchEvent is used for cross-component communication between the Web Dynpro components ItemSearchComp and FlightsComp, the event EndOfItemSearchEvent is also defined in the component interface controller of the Web Dynpro component ItemSearchComp.

In our example, the methods of the Web Dynpro component FlightsComp, which we determined in the last step, are defined in the following controllers:

1. Because the event handler handleEndOfItemSearchEvent updates the status of Web Dynpro component FlightsComp, this event handler is defined in the view controller of the StatusView.
2. Because the method initUsedComponents at the event EndOfContractConfirmationEvent initializes the Web Dynpro components used by FlightsComp in order to be able to perform a new flight search, this method is defined in the component controller of the Web dynpro component FlightsComp and called from within the event handler handleEndOfContractConfirmationEvent, which is – similar to the event handler handleEndOfItemSearchEvent – defined in the view controller of the StatusView.

Which Context Elements are Defined Within the Web Dynpro Components?

Context elements are used to store data. You must provide a context element for each data to be bound to a UI element. For data designed to be available in different controllers, the Web Dynpro runtime environment offers an automatic bi-directional transport service, provided the respective context structures exist in the different controllers and the respective context elements are mapped onto one another. To use this automatic bi-directional transport service, you must first create the respective context elements.

You do not yet determine the context in which to define the context elements, but you only state that certain context elements must exist for a Web Dynpro component. You can define elementary data and complex data structures. In the next step, you decide in which context to define these context elements.

Example

In our example, the flight data is read from an SAP system using function module BAPI_FLIGHT_GETLIST. For the details of a selected flight, function module BAPI_FLIGHT_GETDETAIL is used. For this reason, we need the data structures below in the Web Dynpro component ItemSearchComp:

·        BAPI_FLIGHT_GETLIST

¡        DateRange

¡        DestinationFrom

¡        DestinationTo

¡        FlightList

·        BAPI_FLIGHT_GETDETAIL

¡        FlightData

¡        AdditionalInfo

¡        Availability

In Which Controllers are the Context Elements Defined Within the Web Dynpro Components?

The context elements determined in the last step must now be defined in a context. Analogous to the different controller types, the Web Dynpro programming model offers the following context types:

 

Context Typ	Use
View context	This context contains only data that concerns the respective view.
Custom context	This context contains data that you cannot assign to a particular view, but that concerns several views or is needed for more global tasks.
Component context	This context contains data that is related to the whole Web Dynpro component and is not needed for a more global task.
Component interface context	This context contains data that can be used by other Web Dynpro components.

 

Each context belongs to a corresponding controller. To create context structures, use the Context Editor of the respective controller.

Example

In the Web Dynpro component ItemSearchComp, the data structure of the BAPI_FLIGHT_GETLIST function module is defined in the contexts of the views SimpleSearchView, AdvancedOptionsView, SearchResultView, and in the context of the custom controller FlightCust. The data structure of the BAPI_FLIGHT_GETDETAIL function module is defined in the context of the SearchResultDetailsView and in the context of the custom controller FlightCust.

Because the custom controller FlightCust takes on the management of the flight data, the structures specified above are created in the custom context. Because these structures are used for display in the views, they must also be created in the contexts of the view controllers. The figure below shows the Context Editor of custom controller FlightCust:

Which Context Elements are Bound or Mapped?

Binding to Model Elements

You should manipulate model data in a central location only to ensure efficient maintenance of the application. Custom controllers are suitable for this encapsulation. Therefore, you should only bind context elements of custom controllers to model structures. Use the Data Modeler of a Web Dynpro component for the binding.

In the Web Dynpro component diagram, the binding of a context element to a model structure is symbolized by an edge giving a direction; it is labeled with the context element to be bound. The edge determines the data flow direction.

Mapping to Custom Context Elements

If you have a custom controller hierarchy, you map view context elements to custom context elements or custom context elements to other custom context elements. To map view context elements to custom context elements or custom context elements to custom context elements, use the Data Modeler of a Web Dynpro component.

In the Web Dynpro component diagram, the mapping of a context element on another context element is symbolized by an edge giving a direction; it is labeled with the context element to be mapped. The edge points to the node to which the data is mapped.

To identify these edges as part of the data flow, they are shown as dotted lines.

You can determine the data flow by binding and mapping context elements within a Web Dynpro component. The Web Dynpro runtime environment then guarantees the automatic bi-directional transport within the application.

Example

In the Web Dynpro component ItemSearchComp, the data structure of function module BAPI_FLIGHT_GETLIST is mapped in the views SimpleSearchView, AdvancedOptionsView, SearchResultView onto the respective structure in custom controller FlightCust, which itself is bound to the relevant structure of the FlightModel. The data structure of function module BAPI_FLIGHT_GETDETAIL is mapped in the SearchResultDetailsView onto the respective structure in custom controller FlightCust, which itself is bound to the relevant structure of the FlightModel.