Process Flow

Use

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

First call DO_INIT.
Then call DO_INITATTRIBUTES.
Then call DO_REQUEST.

With a main controller, DO_REQUEST takes care of both input and output processing.
- Input processing
  
  The browser request is sent directly to the top-level controller. This dispatches the input to the subcontrollers. Service function DISPATCH_INPUT is available for this.
  
  DISPATCH_INPUT reads the form fields from the request and dispatches them to the subcontroller. 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 does not belong to one of the subcomponents must be processed using method DISPATCH_INPUT in the main controller. The following methods are called:
  - DO_HANDLE_DATA
  - DO_HANDLE_EVENT
  - DO_FINISH_INPUT
  These three methods are called by the parent controller only with the form fields for the current controller.
- 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
  
  At output, DO_REQUEST executes the following tasks:
  - Determines whether data must be fetched from the model or from the global attributes.
  - Fetches the table with the object keys from the top-level controller.
  - Creates a view.
  - Sets the correct attributes for the view.
  - 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 subcontrollers. 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)

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.

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

Page Input (DO_HANDLE_EVENT)

Note

Note that only a subcontroller 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_HANDLE_INPUT is displayed in the following graphic:

Page Input (DO_FINISH_INPUT)

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 subcontrollers. On the other hand, the Messages 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 subcontrollers. 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.

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 subcontrollers that belong to it. Every subcontroller can query its parent controller for the COMP_ID of each additional subcontroller.