MVC (model view controller) framework for ABAP part 2

Reports with class

In MVC (model view controller) framework for ABAP part 1 you can find the “starter kit” for a framework you can use to create applications that are using dynpros and CFW controls that the framework is able to control. In this second part I will introduce only one further class that can be used for report programming. In my daily work, I am using this report very frequently as a template for new ones.

The demo application

Just like the demo application in the first part, the application contains the framework class that you can extract to a public class for reusing the code.

Application screen You can upload the screen 0001 from the file attached. Other than in the first part, we do not need a subscreen here. All we need is an empty screen that is able to carry the docking container in which we will place an ALV with the result list.

Selection screen controller The selection screen is controlled by the new class ZCL_MVCFW_CON_SELSCR. The controller derives from the class ZCL_MVCFW_CON_DYNPRO and extends it only with two methods

How it works

In order to get everything to work, a few steps are necessary. Let’s go through it step by step.

Selection screen interface To simplify the passing of selection screen parameters between the classes, I use always a local interface that contains a structured type with all input elements from the selection screen

You can see that I use the same names for the components as for the selection screen elements:

Global data Some global variables are indispensible:

INITIALIZATION Here the main controller is instantiated. After that, the get_con_dynpro method is called to create a controller for the actual dynpro, which is the selection screen.

PAI The PAI event of a selection screen is at selection-screen, so we call the PAI of the screen controller, which is a framework method that does the following:

1. Ask the main controller to fetch the screen data.

Therefore, the method get_screen_data of the main controller must be redefined:

As you see, the data is stored in an attribute of the main controller. This can be useful, if you want to react to user inputs during PBO, i.e. switching on/of field attributes and so on.

2. Invoke the PAI of the super class, which will compare all component values from the screen with the stored ones in the memory of the framework class ZCL_MVCFW_DYNPRO and call PAI_FIELD_CHANGE on change of values.

START-OF-SELECTION The method run of the selection-screen controller is called.

RUN The control is passed to the main controller (run_program), where the main logic of the report begins to work.

Batch/Online processing As you can see in run_program, there are two branches, one for background processing and one for online. The online branch is similar to the demo in part 1. For the batch processing, a list has to be created instead of calling a screen. Therefore, a list controller has been added to the program, which we derive from the generic CFW controller.

Of course we do not have any CFW control here. But the framework class can be used even without container. In method refresh the output is coded. In this case, I use CL_SALV_TABLE to produce an output list.

Some notes: 

I some of my use cases, I use more than one model class because of complexity of the application. In this case, it comes handy to declare common used data types in the interface lif_report.