Difference between CL_SALV_TREE and CL_GUI_ALV_TREE?

[aabhas_wilmar]

Hello Experts!

I would like to know the clear difference in terms of advantages and disadvantages of using either CL_SALV_TREE or CL_GUI_ALV_TREE.

I understand both provide object oriented approach to create ALV trees in a container and fullscreen mode. Few forums suggest that it is not possible to use CL_SALV_TREE for drag and drop features, but that is NOT my concern.

I want to create an ALV tree with hierarchy which would sum-up few columns and will have few icons and colored cells.

Both the classes are good enough to meet the objective, so which one would be best to implement?

No links please, I have gone through all the blogs and threads.

Thanks,

Aabhas

[former_member215870]

Hi,

The SALV class is a new class that implement the ALV. With this class you are not create a custom screen and a container to dock the ALV there. With the CL_GUI_ALV_xxx family of classes you were oblige to implement the screen and the container. This is not a good OO approach becouse you were not create a global class that will raise an ALV. A solution was to implement the class into a Function Group. The new class has come to solve this problem and implement inside this logic.

Rich Heilman has post a very interesting paper by the name "ALV Object Model u2013 Simple 2D Table u2013 Event Handling". This explain the concept of the SALV. If you understand this you will catch and the SALV tree logic (its the same).

The principles of the new OO model is a CLASS-METHOD factory, that build the inner logic.

Basically, I am using the CL_GUI_ALV_xxx becouse I know this better than the new class.

code example:

-

---

data: ispfli type table of spfli.

data: xspfli type spfli.

data: gr_table type ref to cl_salv_table.

data: gr_selections type ref to cl_salv_selections.

start-of-selection.

select * into corresponding fields of table ispfli from spfli up to 100 rows.

call method cl_salv_table=>factory importing r_salv_table = gr_table changing t_table = ispfli.

• Set up selections.

gr_selections = gr_table->get_selections( ).

gr_selections->set_selection_mode( 1 ). "Single

• Display

gr_table->display( ).

-

---

With regards

George

[naimesh_patel]

I would choose the CL_SALV_TREE, if it meets all the requirements. It needs less coding to generate the ALV Tree. Design perspective, you code would be more Object Oriented by using CL_SALV_TREE over CL_GUI_ALV_TREE.

Check the program SALV_DEMO_TREE_SIMPLE for reference.

Regards,

Naimesh Patel

[aabhas_wilmar]

Thanks guys!

I would go by CL_SALV_TREE as I understand from your posts that it is newer and advanced.

However, I am not closing the thread expecting more answers. I don't understand the fact that if CL_SALV_TREE is advanced and incorporates the functionality of CL_GUI_ALV_TREE then why does it have few restrictions over CL_GUI_ALV_TREE?

I would have expected it to be a hybrid version which has all the functionality of CL_GUI_ALV_TREE as well as added features.

Any more comments are welcome.

Thank you,

Aabhas

[aabhas_wilmar]

When using CL_SALV_TREE is it possible to set aggregate function for one column as TOTAL and for other as AVERAGE?

If yes, please suggest the method...

Thanks,

Aabhas

[aabhas_wilmar]

Hi Everyone,

Figured out how to perform aggregate functions... here it is:

DATA: lr_aggregations TYPE REF TO cl_salv_aggregations.
  lr_aggregations = gr_tree->get_aggregations( ).
  lr_aggregations->clear( ).

  TRY.
      lr_aggregations->add_aggregation( columnname  = 'BKJOB'
                                        aggregation = if_salv_c_aggregation=>total ).
      lr_aggregations->add_aggregation( columnname  = 'CNJOB'
                                        aggregation = if_salv_c_aggregation=>total ).
      lr_aggregations->add_aggregation( columnname  = 'AVCAP'
                                        aggregation = if_salv_c_aggregation=>total ).
    CATCH cx_salv_not_found cx_salv_data_error cx_salv_existing. 
  ENDTRY.

It seems to be mandatory for aggregate column to be of DEC or INT type, haven't checked if it works with NUMC. In such cases it might pick the mean value.

Not sure if it is a drawback or bug (will post another thread), if we try to perform aggregate for a parent node which had STYLE for an item, the STYLE is not considered after aggregation!

(Closing the thread)

Thanks,

Aabhas