Correct encapsulation between report, salv instance and user-command

perage — Sat, 17 Mar 2018 19:01:05 GMT

Hi,

I'm wondering what is the most correct way of using a MVC/encapsulation when creating a report and using CL_SALV for output and varous user-commands?

I've just created a report with two local classes; <model> and <view>, the later being the salv instance.

The model returns a table with a lot of data, which is then passed to the <view> in the report. My problem is that I don't know where to correctly put the event-handler methods as they don't have access to the instantiated <model> class where all the methods that the user-command will execute are. Also, will the event handler be able to change values in the table when called? I'm pretty sure the only thing sent into the user-command method are the rows and cols of the chosen table entry.

Hopes this is not too unclear - I'll try to illustrate with a simplified code example

Report test.

include lcl_model.
include lcl_view.

data: gt_data type lcl_model=>mty_t_data.

" Instantiate
data(go_model) = new lcl_model( ).
data(go_view) = new lcl_view( ).

" Get data

gt_data = go_model->get_data( )

" View data

go_view->output( changing ct_data = gt_data ).


=============================================
Somewhere else...
=============================================

METHOD on_user_command.

* DON'T THINK GT_DATA IS KNOWN HERE

assign gt_data[ row ] to field-sybol(<ls_data>). "row comes from u-comm


* GO_MODEL ARE NOT KNOWN HERE - refactor or instantiate new local object?

go_model->change_something( changing is_data = <ls_data> ). 



ENDMETHOD.

Re: Correct encapsulation between report, salv instance and user-command

matt — Sun, 18 Mar 2018 12:06:13 GMT

In MVC, the controller has an instance of the view and an instance of the model. The model handles everything that's to do with the application and nothing to do with the presentation to the end user. It has all the business logic. The view is your SALV instance. That leaves your controller, which handles the interactions between the model and the view. That is where your event handlers go.

In a report I have a main class. I might have another class for handling selection screen interaction, or it might be part of main. I usually allow the main class to access report global variables, like parameters, directly, but the model, never. Sometimes, for simple reports, the main class takes the role of the controller. The controller instantiates the CL_SALV_TABLE, and is the correct places for events.

It looks to me like your problem is that you're trying to make the report program itself, directly the view. That won't really work, as you can't have methods directly in it. You need your controller class.

topic Correct encapsulation between report, salv instance and user-command in Application Development and Automation Discussions

Correct encapsulation between report, salv instance and user-command

Re: Correct encapsulation between report, salv instance and user-command