ABAP_to_the_Future

Building the WDA Application 12.2
FIELD-SYMBOLS: <ls_selections> LIKE LINE OF lt_selections.
* Package up selections for sending to controller
IF ls_select_options-monster_number NE ''.
APPEND INITIAL LINE TO lt_selections ASSIGNING <ls_selections>.
<ls_selections>-attribute_name = 'MONSTER_NUMBER'.
<ls_selections>-option
= 'EQ'.
<ls_selections>-sign
= 'I'.
<ls_selections>-low = ls_select_options-monster_number.
ENDIF.
IF ls_select_options-name NE ''.
APPEND INITIAL LINE TO lt_selections ASSIGNING <ls_selections>.
<ls_selections>-attribute_name = 'NAME'.
<ls_selections>-option
= 'EQ'.
<ls_selections>-sign
= 'I'.
<ls_selections>-low = ls_select_options-name.
ENDIF.
* Ask the friendly controller to get the data you want.
wd_comp_controller->retrieve_headers_by_attribute(
EXPORTING
it_selections = lt_selections
IMPORTING
et_monster_headers = lt_monster_headers ).
* Now, send the table data to the screen
DATA: node_monster_header_table TYPE REF TO if_wd_context_node.
* Set a link to the on-screen variable that holds the data
node_monster_header_table =
wd_context->get_child_node(
name = if_v_select_options=>wdctx_monster_header_table ).
* Send the internal table to the on-screen variable
node_monster_header_table->bind_table( lt_monster_headers ).
ENDMETHOD. "On Action Find Monsters
Listing 12.1 Reacting to FIND_MONSTERS Action
You will notice in Listing 12.1 that the view handled three of the four tasks mentioned
previously on its own, but when it came to getting the data it delegated the
task to the controller. You could have done a database SELECT right there inside
the view, even though that is “forbidd en” by SAP. However, a purist would say
that you should not execut e any business logic on the surface of the application
(the view) but instead send that request on a journey down the call stack to the
539