Posted: Sat Jan 19, 2008 11:47 pm Post subject: A new approach to ALV Programming ( ALV Object Model )
A new approach to ALV Programming
Author: Poornanand Mandalika
ALV Programming has undergone a major change over the last couple of years. First we had the function module approach - where the data to be displayed is passed to a function module like REUSE_ALV_LIST_DISPLAY. Then with the introduction of the OO concepts in 46C we had classes like CL_GUI_ALV_GRID and CL_GUI_ALV_TREE which changed ALV Programming quite a bit. Most (almost all ?) ABAPers today use these classes to program their ALV.
If you were asked to name one improvement to this approach based on classes, what would that be? I would say that it is still a bit painful to create a screen and put a custom control container and then place this ALV Grid in that , all by myself. Especially when I want to create some test programs to answer the questions in the ABAP Forum ! Wouldn't it be great if I could worry less about these and concentrate more on imporving the functionality of my ALV Grid?
This is precisely what you can do from Basis 640. You can now program an ALV in various modes (Fullscreen, Regular and List Mode), all using a single class (and without even having to create a screen ! ).
So without further ado, let me introduce you what's called the ALV Object Model. Now, what's that ?
ALV Object Model is an object-oriented encapsulation of the existing tools, presenting a simplified unified and object-oriented API to the application developer.
It makes migration of applications to the Web Dynpro easier.
ALV tools with the same data model can be used via the same API -
List Based ALV, Fullscreen ALV, ALV Grid using simple tables can now be programmed using the same OM class CL_SALV_TABLE.
Hierarchical ALV can be programmed using the OM class CL_SALV_HIERSEQ_TABLE.
Tree ALV can be programmed using the OM class CL_SALV_TREE.
Here's a small example program which illustrates the simplicity of this new approach - Here are the Data Declarations for this program-
Code:
REPORT ZALV_OBJECTMODEL_TEST.
DATA : dyntab TYPE STANDARD TABLE OF dntab,
wa_dyntab TYPE dntab,
dref TYPE REF TO data,
i_fcat TYPE lvc_t_fcat,
wa_fcat TYPE lvc_s_fcat,
tab_name TYPE ddobjname VALUE 'SPFLI',
gr_table TYPE REF TO cl_salv_table.
FIELD-SYMBOLS : <newtab> TYPE table.
We shall first create an internal table dynamically (this technique has already been discussed in some of the earlier weblogs) and populate it with the data from the table SPFLI.
Code:
START-OF-SELECTION.
CALL FUNCTION 'NAMETAB_GET'
EXPORTING
langu = sy-langu
tabname = tab_name
TABLES
nametab = dyntab. "dyntab now contains the field names
* FILLING THE CATALOG OF NEW DYNAMIC INTERNAL TABLE
LOOP AT dyntab INTO wa_dyntab.
wa_fcat-fieldname = wa_dyntab-fieldname.
wa_fcat-ref_field = wa_dyntab-fieldname.
wa_fcat-ref_table = wa_dyntab-tabname.
APPEND wa_fcat TO i_fcat .
ENDLOOP.
* CREATING A POINTER (FIELD SYMBOL) TO THE INTERNAL TABLE
CALL METHOD cl_alv_table_create=>create_dynamic_table
EXPORTING
it_fieldcatalog = i_fcat
IMPORTING
ep_table = dref.
ASSIGN dref->* TO <newtab>.
* SELECT the data from the table SPFLI. If you want a
* different table, then just use a different value
* than SPFLI in the data declarations part. Or better
* still, use a PARAMETERS to take the name of the
* table name as input from the selection-screen.
SELECT *
FROM (tab_name)
INTO TABLE <newtab>
UP TO 25 ROWS.
Now all you have to do is to call a method of the class CL_SALV_TABLE to display your grid.
Code:
* Instead of if_salv_c_bool_sap=>false, you can pass the
* value if_salv_c_bool_sap=>true to this method to
* see your ALV as a list.
TRY.
CALL METHOD cl_salv_table=>factory
EXPORTING
list_display = if_salv_c_bool_sap=>false
IMPORTING
r_salv_table = gr_table
CHANGING
t_table = <newtab>.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
All product names are trademarks of their respective companies. SAPNET.RU websites are in no way affiliated with SAP AG. SAP, SAP R/3, R/3 software, mySAP, ABAP, BAPI, xApps, SAP NetWeaver and any other are registered trademarks of SAP AG. Every effort is made to ensure content integrity. Use information on this site at your own risk.