Component Configuration and GUIBB Method Implementation
GET_DEFINITION( ):
The field selection has to be defined by a RTTI description of type
CL_ABAP_STRUCTDESCR which is returned to the framework via the exporting parameter EO_FIELD_CATALOG.
Figure 87: Defining field catalog
For each of the fields contained in the field catalog, properties have to be set and returned via the exporting parameter ET_FIELD_DESCRIPTION. If a field should be available during the configuration process, its visibility has to be set to CL_WD_UIELEMENT=>E_VISIBLE-VISIBLE. Other properties are defined in the ABAP Dictionary structure FPMGB_S_FORMFIELD_DESCR.
Hint: Some of the properties set in the method GET_DEFINITION( ) may be adjusted at runtime from the method GET_DATA( ) via the exporting parameter CT_FIELD_USAGE. These properties - described by the ABAP DDIC structure FPMGB_S_FIELDUSAGE - are: READ_ONLY, MANDATORY, ENABLED, LABEL_TEXT, HELP_TEXT, LINK, VISIBILITY, and FIXED_VALUES.
Figure 88: Setting form field properties (1)
Figure 89: Setting form field properties (2)
In order to assign the form fields to field groups, these field groups need to be defined first. This is also done in method GET_DEFINITION( ). Here, the exporting parameter ET_SPECIAL_GROUPS is used to inform the framework about the internal group names and the names displayed in the configuration editor.
Figure 90: Defining field groups
After having defined which form fields are to be displayed in which group, the form field properties can be configured:
• The form field has to be marked in the hierarchy view.
• The following properties can then be configured: The type of UI element (Display Type), the visibility of the label (Label Visibility), and the label text (Text - this will overwrite the text obtained from the ABAP DDIC).
• Additional properties do depend on the type of UI element used to display the form field.
• If the client side event related to the form field should related to an action, the button Assign Action has to be clicked. All bindable actions are displayed by a dialog box popping up.
Figure 91: Configure form field properties
The actions displayed by the dialog box need to be defined in the method
GET_DEFINITION( ). Here, the exporting parameter ET_ACTION_DEFINITION is used to inform the WD runtime.
Figure 92: Define list of actions that may be assigned to form fields After having configured all form field properties, this component configuration can be saved and the configuration process is finished.
Runtime Aspects: INITIALIZE( )
At runtime, the methods GET_PARAMETER_LIST( ), INITIALIZE( ), and GET_DEFINITION( ) are processed once for each feeder class instance. Typically, the method INITIALIZE( ) encapsulates the code to:
• get the references to the FPM service object
• get additional references to the IDR service object and the floorplan specific service object
• instantiate the central data object (or get the reference to the object if it has been initialized before)
• create an instantiate of the assistance class
• initialize global attributes of the feeder class instance
• store parameter values provided by the interface parameter IT_PARAMETER
available and the references to the corresponding service objects can not be determined. Thus, the related source code sections may only be processed if the FPM service object can be determined.
Hint: Parameter values set via configuration can only be accessed in the method INITIALIZE( ).
Figure 93: Method INITIALIZE( )
Runtime Aspects: FLUSH( )
The method FLUSH( ) is the first method processed for the GUIBB displayed before navigation. The following aspects should be handled by this method:
• check for changes of the form field values
• actualize global data of feeder class instance and central data object.
Figure 94: Method FLUSH( )
Runtime Aspects: PROCESS_EVENT( )
The method PROCESS_EVENT( ) is the second method processed for the GUIBB displayed before navigation. The following aspects should be handled by this method:
• identify the FPM-Event triggered by the user or by the application programmatically
• handle FPM-Event
• inform WD runtime if event handling failed
• send messages to inform user about success of event handling
If the event handling was not successful, the WD runtime can be informed by setting the exporting parameter EV_RESULT accordingly. In this case, the method AFTER_FAILED_EVENT( ) will be processed before navigation takes place.
Messages can be defined by calling the appropriate methods of the FPM message manager. However, each message can also be defined by appending a structure containing the message details to the exporting parameter ET_MESSAGES.
Figure 95: Method PROCESS_EVENT( )
Runtime Aspects: GET_DATA( )
The method GET_DATA( ) is the first method processed for the GUIBB displayed after navigation. The following aspects should be handled by this method:
• check if the data to be displayed by the form has been changed programmatically
• check if the properties of the form fields have to be modified
• check if the action usage has to be adapted
• in each of the cases inform the WD runtime about the changes
If the data to be displayed has been changed programmatically, the current data has to be exported to the GUIBB via the changing parameter CS_DATA. In addition the exporting parameter EV_DATA_CHANGED has to be set to ABAP_TRUE.
Figure 96: Method GET_DATA( ) - change form data
If the properties of the form fields have to be modified, the new form field properties have to be exported to the GUIBB via the changing parameter CT_FIELD_USAGE.
In addition the exporting parameter EV_FIELD_USAGE_CHANGED has to be set to ABAP_TRUE.
Figure 97: Method GET_DATA( ) - change form field properties
If the action usage has to be modified, the actualized action usage has to be exported to the GUIBB via the changing parameter CT_ACTION_USAGE. In addition the exporting parameter EV_ACTION_USAGE_CHANGED has to be set to ABAP_TRUE.
Figure 98: Method GET_DATA( ) - change action usage
Messages can be defined by calling the appropriate methods of the FPM message manager. However, each message can also be defined by appending a structure containing the message details to the exporting parameter ET_MESSAGES.
Runtime Aspects: NEEDS_CONFIRMATION( )
The method NEEDS_CONFIRMATION( ) is defined in the extension interface IF_FPM_GUIBB_FORM_EXT. This method is processed if the user clicks the CLOSE button. In this case, a data loss popup can be send to indicate that data has not been saved yet. For details, please refer to the corresponding method defined in the interface IF_FPM_UI_BUILDING_BLOCK. This is described in the previous unit.