ABAP_to_the_Future

10
ALV SALV Reporting Framework
ing the DISPLAY method. If all you want to do is show a basic report, then there is
no need to go through the process of ac tually creating a report interface. However,
in reality, 99 times out of 100 yo u want to modify the standard display in
some way, and this is why you need to have a concrete SALV-specific class that
implements your custom interface.
If you do have a concrete SALV-specific class that implements a custom interface,
then you do not call the FACTORY method of the CL_SALV_TABLE but rather create an
instance of your concrete SALV class and call a method of that to display the report.
Note
In his book Clean Code (see the “Recommended Reading” box at the end of this chapter),
Robert Martin says that a program shouldbe like a newspaper: You start off looking
at the headlines and then drill into anything you find interesting. In the following sections,
whenever there is a code sample, that sample will start off with a small routine
that calls several methods. Then each of these methods is examined in detail (which
usually involves branching off into several more methods).
Listing 10.1 shows how to call a reportusing a class that implements the common
API—in this case, your SALV class. You start off creating a local class that inherits
from the concrete SALV class so that you can redefine the APPLICATION_
SPECIFIC_CHANGES method. Next, the data to be displayed is read into an internal
table. Finally, a method of your SALV-spe cific class is called in order to display
the report. This is only about 1% more complicated than calling the FACTORY
method, but it gives you much more flexibility.
REPORT
y_monster_report_salv.
DATA: gt_monsters TYPE STANDARD TABLE OF ztvc_monsters.
PARAMETERS: p_vari TYPE disvariant-variant.
CLASS lcl_view DEFINITION INHERITING FROM zcl_bc_view_salv_table.
PUBLIC SECTION.
METHODS : application_specific_changes REDEFINITION.
ENDCLASS.
DATA :lo_view TYPE REF TO lcl_view,
ld_repid TYPE sy-repid.
START-OF-SELECTION.
SELECT *
412