Handy CL_GUI_ALV_GRID wrapper
CL_SALV_TABLE or CL_GUI_ALV_GRID which class is better to use in 2021 ?
Probably old abapers remember that more than decades ago that there was shift from the “old-fashioned” CL_GUI_ALV_GRID class & ‘REUSE*’ function modules towards new up-to-date & OOP style class CL_SALV_TABLE. At 2020 I decided to move backwards to CL_GUI_ALV_GRID. At the small article below I try to explain why I made that decision. And it is not related to nostalgia.
One of the reasons to use CL_SALV_TABLE was small amount of code compared to CL_GUI_ALV_GRID. Also, there was no need to create new screen & containers to display a grid. But then new syntax 7.40 was introduced and passing parameters to any method via structures & tables simplified drastically. I decided to fill a gap and just add nested screens functionality for CL_GUI_ALV_GRID.
Let’s jump to new syntax & display table data without annoying screen painter.
" Sample data SELECT * INTO TABLE @DATA(lt_flight) FROM sflight. " Create ALV & pass table NEW zcl_eui_alv( REF #( lt_flight ) )->show( ).
As I was mentioned earlier calling methods of CL_SALV_TABLE class is not the shortest and handiest available form of tuning a ALV GRID. Let’s try to pass parameters via structures (lvc_s_layo) & tables (lvc_t_fcat).
" Sample data SELECT * INTO TABLE @DATA(lt_flight) FROM sflight. " Create ALV & pass table DATA(lo_alv) = NEW zcl_eui_alv( ir_table = REF #( lt_flight ) " Set title is_layout = VALUE lvc_s_layo( grid_title = `Demo title` smalltitle = 'X' ) " Hot spot & totals by mask it_mod_catalog = VALUE lvc_t_fcat( ( fieldname = 'CONNID' hotspot = 'X' ) ( fieldname = 'SEATS*' do_sum = 'X' ) ) ). " Show in full screen lo_alv->show( ).
*No new API from my side for tuning an alv grid catalog & layout. Just small enhancements to change default field catalog (Not creating one from the scratch).
What about other parameters of CL_GUI_ALV_GRID? They are here in ZCL_EUI_ALV constructor’s parameters.
IT_TOOLBAR parameter is used mainly to avoid creating PF-STATUS. Creating it by copying was not so pleasant and fast thing to do.
The other most common used by me parameters of constructor are:
They are used with popup( ) method, which can create nested screens for “drilldown” to a sum. Usually, to check calculated sum I try to show items which were used during calculation and display one alv grid upon another one.
In code it takes just to add popup( ) method call before show( ).
The show( ) method itself accepts an handler object, which should contain event handlers of CL_GUI_ALV_GRID class.
In handlers you could get access to instance of CL_GUI_ALV_GRID via sender reference or by calling get_grid( ) of ZCL_EUI_ALV class.
Also, could change default behavior in special PAI & PBO events
Even at 2021 many reports still display a lot of information with grid controls in SAP gui. And I hope the ZCL_EUI_ALV will help you in this routine work.
Documentation to the entire EUI library https://bizhuka.github.io/eui.
EUI library located here https://github.com/bizhuka/eui. (Installation via abapgit)
A simple example will be available here SE38-> ZEUI_TEST_ALV
Have a look at this:-
İ heard about falv. Tried to use slightly different approach. The main idea was to create small wrapper on CL_GUI_ALV_GRID class without additional APİ.
All params passed via tables and structures that used in CL_GUI_ALV_GRID itself. Handlers also use standard declarations(they just called dynamicly). İ hope no additional knowledge required to use it.
I read the whole thing but still don't understand why did you decide to go with CL_GUI_ALV_GRID. 🙂
Personally, I managed to bypass it and jump from REUSE... to SALV directly. (And have you tried SALV IDA? It's mind-blowing.)
I get your point that SALV object model is more complex. E.g. changing a title for one column involves digging into the columns -> column and back. But I'd rather wrap SALV into a simpler class or a report template, to be honest. So I just don't get the advantage of the proposed solution, sorry.
Hi Jelena, thank you for your opinion about my opus
>>wrap SALV into a simpler class or a report template
I also made the same thing, but one of the reason to switch to "old" CL_GUI_ALV_GRID was that sometimes I still need editing capabilities. (using SALV for data editing is too tricky)
Another reason was that actually I decided to split option utility to separate parts with there own responsibilities. All classes not directly related to options (LOGGER, ALV, SCREEN, FILE, MEMO etc) were moved to new library. Maybe the most useful for me from the classes above is ALV
Unfortunally, for some reason, CL_SALV_TABLE has missing some features (The most important is editing functionality).
It may happen that you start with CL_SALV_TABLE and then had to refactor the whole report just for one missing tiny functionality.
In case you work with a wrapper/template, I don't see any reason to work with CL_SALV_TABLE.
Yep, agree with you. I had several cases when "suddenly" there was a need to make ALV editable after some time of usage. The most weird example of "one missing tiny functionality" was when business users insisted on introducing a new checkbox column for line selection instead of using standard "select line" ALV button 🙂 WEB GUI was not an option then, so I had either to go into tricks with SALV, or move to CL_GUI_ALV_GRID. I used the second option.
So, Birzhan Moldabayev , Shai Sinai , Nikolay Evstigneev - basically this is just for "editability" then? Well, we've just celebrated 13th International Editable SALV Day, so there is still hope. 🙂
I did manage to make some editable SALV reports (information is out there for those who seek) but I agree that it wasn't as simple as flipping the switch.