ABAP_to_the_Future

10
ALV SALV Reporting Framework
Refreshing the Display Method
The code for refreshing the DISPLAY method is self-explanatory. Often, a user
action changes the data (e.g., the user chose a purchase order from a list of unreleased
purchase orders and released it, and so you want to remove the processed
item from the list).
The actual changing of the database is not the job of the view, but after the application
model makes the change, it raises a data changed event, which causes the
controller to tell th e view to call this refresh method so that the user sees the
updated values in the report.
The REFRESH method shown in Listing 10.22 (whi ch you want to call when the
report data has changed for whatever reason) is a bit meatier than the code to display
the report, but just as simple. The important thing here is to make the refresh
stable—so even though the data may change , the user’s cursor stays where it is,
which is not the default system behavior.
METHOD zif_bc_alv_report_view~refresh_display.
* Local Variables
DATA: ls_stable_refresh TYPE lvc_s_stbl.
"I am going to be a madman and suggest that when a user refreshes
"the display because data has changed, they want the cursor to
"stay where it is as opposed to jumping six pages up to the start
"of the report, which is the default behavior
ls_stable_refresh-row = abap_true.
ls_stable_refresh-col = abap_true.
mo_alv_grid->refresh( s_stable = ls_stable_refresh ).
ENDMETHOD.
Listing 10.22 REFRESH_DISPLAY Method
Future Proofing
The logical extension of the ability to wrap the SALV in the standard interface is that if
and when SAP comes up with the successor to the SALV reporting framework, all you’ll
need to do is create a new subclass that implements the generic view interface, create
implementations for each of the interface methods to deal with the specific way the
new technology will deal with each task, and then go around changing existing reports
to use the new technology at the drop of a hat—rather than having to rewrite them all.
440