CL_GUI_ALV* vs. CL_SALV*

[alejiandro_sensejl]

Hello everyone,

recently I wanted to check out the u201Cnewu201D ALV classes. I noticed soon that way are a little bit easier too handle on development side (no need of field catalogue and so on), but what are the benefits for the end user? Any way to improve usability or are they more efficient (on sort, display, etc)?

We have some huge ALV applications (trees, grids; partially with up to 5 container in a splitter container on a single screen) and we a considering some refactoring anyway. Do you think it is recommended to migrate from CL_GUI_ALV-classes to the CL_SALV-classes? Would be great to read some reasons, especially from the users' point of view!

Thanks in advance and best regards from Germany,

Alej

[matt]

SALV aren't editable.

I'd work on the principle - if it ain't broke, don't fix it. Standard ALV gives more flexibility, but I'd always start with SALV.

matt

[MarcinPciak]

Hi,

I think it is just a matter of GUI evolution. The simplier, the better. The less programing, the better. There are, however some strong disadvantages on SALV like subtotals restrictions (you can't dynamically change these) and some others. As for user perspetive I don't think it changed in some way. UI hasn't changed, functionality too.

Please refer this article [SAP List Viewer The New Programming Model in SAP NetWeaver04|https://ecohub.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/5dc3e690-0201-0010-1ebf-b85b3bed962d?overridelayout=true] it gives brief explanation and enumerates some prons and cons for this new ALV model.

Regards

Marcin

[ThomasZloch]

reg. editable SALV, votes are still open

Thomas

[alejiandro_sensejl]

Thanks for your super-fast responses!

It looks like we can't touch the old classes even if we wanted, because we need them editable in most cases...