MVC (model view controller) framework for ABAP: Part 3

[jrgkraus]

See also:  MVC (model view controller) framework for ABAP part 1

MVC (model view controller) framework for ABAP part 2

Controlling multiple screens

Welcome back to my MVC series. To follow this blog, it is necessary that you install the classes provided in the first two parts (see links above). In part 1 you see a demo application that controls a dynpro and an ALV control. In the second part, I wrote about a report-type program that controlled a selection screen and an ALV control, but no standard dynpro fields. This time I would like to focus on standard dynpros, especially the case, when you have more than one of them.

Installing the demo application

Download the attached file and paste the content into a new report type program. Then create the main screen, which contains only one big subdynpro area (see part 1 for further explanations about the dynpro concept of the framework). After that, create the two sub dynpros 0100 and 0200 as described below. Last, I also included a popup screen 0300 which is controlled by the same framework controller type that contols also the sub dynpros.

Main screen 0001

Attributes:

Screen elements:

(create the subscreen area using the screen painter and make it as big as the whole screen)

Flow logic:

process before output.

   module pbo_0001.

   call subscreen subscreen including sy-repid gv_subdyn.

*
process after input.
   module pai_0001 at exit-command.
   call subscreen subscreen.
   module pai_0001.

Sub dynpro 0100

Attributes:

Elements:

Flow logic:

PROCESS BEFORE OUTPUT.
   MODULE pbo_0100.
*
PROCESS AFTER INPUT.
   module pai_0100.

Appearance:

Sub dynpro 0200

Copy dynpro 0100 to 0200. Then set the two input fields to "no input". Create a frame to for the data fields of the table spfli and put input fields into it. In the end, it should look like this:

Adjust the flow logic:

PROCESS BEFORE OUTPUT.
   MODULE pbo_0200.
*
PROCESS AFTER INPUT.
   module pai_0200.

Popup screen 0300

Create a modal dialog box containing the data fields of table SCARR. It should look like this:

All fields are display only. Important: use GV_OKCODE_0300 instead of GV_OKCODE:

Adjust the flow logic:

PROCESS BEFORE OUTPUT.
   MODULE pbo_0300.
*
PROCESS AFTER INPUT.
   module pai_0300.

GUI status and title

Create status 0100 with function key assignments:

Enter - ENTER

F3 - BACK

Shift+F3: EXIT (exit command)

ESC: CANC (exit command)

Copy the status to 0200 and add the following functions to the toolbar:

POPUP - Text "Carrier"

DELE - Text "Delete"

Create the status 0300 as a dialogbox status and add the function CANC to key ESC.

Last, create a titlebar MAIN with title "Sample for several dynpros"

How it works

As already discussed in part 1, there is only one main screen 0001. To switch between sub screens on the main carrier screen, the method SET_SUBDYNPRO of the framework class for the main controller is used. In the constructor of the main controller, it is set to 0100:

As you see, the method sets also the used GUI STATUS and the titlebar. All parameters are obtional, so you can use this also for setting only some of them. For example, you could call it to change the GUI STATUS only.

Managing sub dynpro flow

Each sub dynpro has its own controller (LCL_CON_DYNPRO_0100, LCL_CON_DYNPRO_0200). In the PBO and PAI modules, the controller is being fetched from the main controller and the control is being passed to the respective methods of the own dynpro controller.

Therefore, you have to redefine method CREATE_CON_DYNPRO:

On ENTER on the first screen 0100, the second screen is being called:

Note that before the new screen is called, the model is used to read the database. The values of the input fields have been passed already to the model in method PAI_FIELD_CHANGE:

Remember that PAI_FIELD_CHANGE will be called automatically from the framework as soon as the user types in something. It will be called for each field separately giving fieldname (IV_FIELDNAME) and value (IV_SOURCE) as a parameter. This method is intended also for input checks on field level.

During PBO of the main screen, then newly set MV_SUBDYNPRO will be passed to the flow logic and the new sub dynpro is being displayed in the SUBSCREEN area.

In PAI for 0200, we jump back to the last screen on user command BACK:

Exit commands must be treated by the main dynpro, so CANC, which also jumps back to sub screen 0100, but without considering inputs made. So the coding is located in the main PAI method:

Managing popups

The popup screen is managed in a similar way. But instead of setting the variable MV_SUBSCREEN, we have to use CALL SCREEN. In the 0200 user command method, the main controller is being called in order to do this:

You can place the call screen statement directly in the PAI_USER_COMMAND, if you want. But I prefer coding everything regarding the user interface flow in the main controller.

One important thing: use a different OKCODE for each popup screen you create. If you don't the OKCODE set during PAI of the popup will be processed once more in the main screen controller.

As single reaction to the user interface, we leave sthe screen on pressing the cancel button:

Conclusion

In the productive version of the framework in my company's system, there are some more controllers like one for dynamic documents (CL_DD_DOCUMENT) and one for the class I described in Using ALV to display/edit fields of a structure. Both of them are sub classes of the CFW controller class, just like the ALV controller described in part 1. I shared this basic version to inspire the reader to use it as a starting point for own developments.

All the best!

Jörg