Entering content frameProcess documentation Process Flow Locate the document in its SAP Library structure

Uses

The methods of class Class CL_BSP_CONTROLLER2 are used to create components as part of the Model View Controller design pattern.

Note

The whole hierarchy level is processed with every request.
The hierarchy itself is defined at output.

Process

  1. First call DO_INIT.
  2. Then call DO_INITATTRIBUTES.
  3. Then call DO_REQUEST.

With a main controller, DO_REQUEST takes care of both input and output processing.

    1. Input processing

The browser request is sent directly to the top-level controller. This dispatches the input to the sub-controllers. Service function DISPATCH_INPUT is available for this.

DISPATCH_INPUT reads the form fields from the request and dispatches them to the sub-controller. Prefixes are added to the form fields.

Note

The prefixes are written automatically for BSP elements, for example, by BSP extension HTMLB.
If, however, you have pure HTML or HTML tags, then you must add the name of the controller as a prefix to your input data. In this case, service function
GET_ID is available for adding prefixes.

All data that do not belong to one of the sub-components must be processed using method DISPATCH_INPUT in the main controller. The following methods are called:

These three methods are called by the parent controller only with the form fields for the current controller.

    1. Output processing

Determining output processes contains the output for the next page. A view is created and displayed. Depending on the status of the top-level controller, you can also set a sub-controller to inactive or create new controllers.

The process flow of the output is displayed in the following graphic:

Page Output

This graphic is explained in the accompanying text

At output, DO_REQUEST carries out the following tasks:

      1. DO_REQUEST determines whether data must be fetched from the model or from the global attributes.
      2. DO_REQUEST fetches the table with the object keys from the top-level controller.
      3. DO_REQUEST requests a view.
      4. DO_REQUEST sets the correct attributes for the view.
      5. DO_REQUEST calls the view.

Handling events

If a component contains events, DISPATCH_INPUT calls the HTMLB manager. The HTMBL manager collects the relevant information, including the ID, that is, the ID of the object that triggered the event.

DISPATCH_INPUT then calls method DO_HANDLE_DATA. DO_HANDLE_DATA is called by all controllers (that is, for all active components), that is, by the top-level controller as well as by all sub-controllers. The model class is filled with DO_HANDLE_DATA (see also Data Binding): The system transfers form fields and messages for the global messages object (see below).

Note

If your model class is based on CL_BSP_MODEL and you have defined your setter and getter methods accordingly, the form fields are filled automatically.

The process flow with DO_HANDLE_DATA is displayed in the following graphic:

Page Input (DO_HANDLE_DATA)

This graphic is explained in the accompanying text

Once DO_HANDLE_DATA has filled all data, method DO_HANDLE_EVENT is called for the controller that is responsible for the input event. This also states the event ID and the event is dispatched to the controller. DO_HANDLE_EVENT also outputs parameter GLOBAL_EVENT (a string). If the event is an HTMLB event, object HTMLB_EVENT is filled accordingly.

Note

Events are only dispatched to the relevant controller if the element ID was assigned to the HTMLB element (attribute id).

DO_HANDLE_EVENT also has access to the global messages object and can carry out additional steps if necessary. For example in the case of an error, this method can have data displayed again.

The process flow with DO_HANDLE_DATA is displayed in the following graphic:

Page Input (DO_HANDLE_EVENT)

This graphic is explained in the accompanying text

Note

Note that only a sub-controller is called here.

Method DO_FINISH_INPUT is always called (for every controller, that is, for all active components). You can use it to react to events in a component that occur in a different component. To do this, use parameter GLOBAL_EVENT, which is set in method DO_HANDLE_EVENT. Using this global event, at the end of input processing each component should know exactly which events are present and how to react to them.

The process flow with DO_FINISH_INPUT is displayed in the following graphic:

Page Input (DO_FINISH_INPUT)

This graphic is explained in the accompanying text

Global Messages

Parameter GLOBAL_MESSAGES is shared by all components. Use this parameter to handle incorrect user input, for example to display that an error occurred, or that the end date entered by the user is before the start date, and so on.

The main controller creates the global messages and forwards them to all sub-controllers. On the other hand, the Structure linkmessages object is local. If the local messages object is now filled in a controller, then you can forward this information to the global messages object and react to it using any component you like.

Controllers and Their IDs

Usually there is a main controller, a top-level view as well as different sub-controllers and additional views.

A main controller first calls CREATE_VIEW, then SET_ATTRIBUTE for the view, and then CALL_VIEW. The top level controller can also create sub-controllers. This is done using the <bsp:call> element, which has the attributes PAGE and COMP_ID. Furthermore, the embedded element <bsp:parameter> can also specify parameters for name and value.

This graphic is explained in the accompanying text

The attribute output takes place either in the view or in the top-level controller.

Note

COMPONENT_ID always identifies the controller. The COMPONENT_ID has a reference to the controllers concerned.
In method
CREATE_CONTROLLER this reference is parameter COMPONENT_ID, and in the <bsp:call> element it is attribute COMP_ID:
When a controller is created, a reference is sent to the parent controller, which has a list of all the sub-controllers that belong to it. Every sub-controller can query its parent controller for the COMP_ID of each additional sub-controller.

 

 

 

Leaving content frame