There would be scenarios, where we would require Pop-up confirmation's based on certain actions. In order to achieve this kind of functionality, we would need to call the pop-ups manually and handle the po-up button functionality accordingly. To make the life easy, FPM framework provides the pop-up's functionality through the interface method – NEEDS_CONFIRMATION. Just populate the pop-up text and create an instance of the class CL_FPM_CONFIRMATION_REQUEST passing this pop-up text. You can control the process flow based on the pop-up’s action. Like if user clicks on “Ok” button the interface method – PROCESS_EVENT gets executed, in case if the user clicks on “Cancel” button the interface method – PROCESS_EVENT won’t get executed. I decided to write a blog to illustrate this feature.
Create a WD Component implementing the interface – IF_FPM_UI_BUILDING_BLOCK -
Create an OIF based WD Application using Application Creation Tool (which automatically creates the respective Application Configuration and Component Configurations-IDR and OIF) -
For test purpose, let’s create 3 buttons (Default, Refresh and Save) in the IDR component configuration -
Getting back to the WD Comp, I managed to handle these events using the PROCESS_EVENTS method as shown below –
* get message manager
data lo_api_controller type ref to if_wd_controller.
data lo_message_manager type ref to if_wd_message_manager.
lo_api_controller ?= wd_This->Wd_Get_Api( ).
CALL METHOD lo_api_controller->GET_MESSAGE_MANAGER
RECEIVING
MESSAGE_MANAGER = lo_message_manager
.
* Based on Event ID – Perform the appropriate action
CASE IO_EVENT->MV_EVENT_ID.
WHEN 'FPM_SAVE'.
* report message
CALL METHOD lo_message_manager->REPORT_SUCCESS
EXPORTING
MESSAGE_TEXT = 'Save action processed' .
WHEN 'FPM_REFRESH'.
* report message
CALL METHOD lo_message_manager->REPORT_SUCCESS
EXPORTING
MESSAGE_TEXT = 'Refresh action processed' .
WHEN 'FPM_DEFAULT'.
* report message
CALL METHOD lo_message_manager->REPORT_SUCCESS
EXPORTING
MESSAGE_TEXT = 'Default action processed' .
ENDCASE.
The pop-ups can be created from the FPM’s interface method - NEEDS_CONFIRMATION. This method is called before the PROCESS_EVENT method, based on the user action, the PROCESS_EVENT method is called accordingly i.e. if user clicks on CANCEL button in the pop-up, the PROCESS_EVENT method is never called. You have an option to display the pop-up text as per the event (the Save button and Refresh buttons illustrates the same – You would have to populate the Pop-up text into an internal table, and create an instance of the class – CL_FPM_CONFIRMATION_REQUEST passing this popup text), Also you have the default pop-up option where if we have to set the export parameter EO_CONFIRMATION_REQUEST to CL_FPM_CONFIRMATION_REQUEST=>GO_DATA_LOSS.
DATA : lo_instance type ref to cl_fpm_confirmation_request,
lt_popup_text TYPE STRING_TABLE,
ls_popup_text TYPE STRING.
CASE io_event->MV_EVENT_ID.
WHEN 'FPM_SAVE'.
CLEAR : lt_popup_text[], ls_popup_text.
ls_popup_text = 'You have just clicked on Save button.'.
APPEND ls_popup_text to lt_popup_text.
CREATE OBJECT lo_instance
EXPORTING
it_confirmation_text = lt_popup_text.
eo_confirmation_request = lo_instance.
WHEN 'FPM_REFRESH'.
CLEAR : lt_popup_text[], ls_popup_text.
ls_popup_text = 'You have just clicked on Refresh button.'.
APPEND ls_popup_text to lt_popup_text.
CREATE OBJECT lo_instance
EXPORTING
it_confirmation_text = lt_popup_text.
eo_confirmation_request = lo_instance.
WHEN 'FPM_DEFAULT'.
eo_confirmation_request = cl_fpm_confirmation_request=>GO_DATA_LOSS.
WHEN OTHERS.
ENDCASE.
You may test this application to see the following results –
Default pop-up
6 Comments
