| overview |
The concept of a selection screen variant is something that most SAP users have come to expect, yet this feature is unavailable in standard Web Dynpro. Below is the next in a series of posts detailing how to bring this necessary feature back to Web Dynpro. Start here to see the full requirements.
Start your development by creating a new Web Dynpro component named ZES_SELOPT_VARIANT. This WD component will have a public interface with a few methods used to initialize the report name and selection screens. It will have one main window that contains three buttons (by default): Get Variant, Save Variant, and Delete Variant. 
In the Web Dynpro component, we’ll need to use two instances of the Web Dynpro ALV component:
| Comp. Use | Component | Description |
| ALV1 | SALV_WD_TABLE | List of existing selection screen variants for this Web Dynpro application) |
| ALV2 | SALV_WD_TABLE | List of fields assigned to this set of selection screens. |
In the Component Controller, add the following context nodes:
Node: TEXT stores the values of various labels used through the component.
Node: IN stores values that are bound to various screen elements throughout. This elements in this node could have used a little more structure – maybe split out by view - given the time.
Node: VARIANT_LIST is a table of variants associated with the REPORT_NAME assigned when the component is initialized.
Node: VARIANT_FIELDS holds a table of fields associated with the currently selected (or newly created) variant.
Node: FIELD_PARAMS is a single-line structure that holds the values selected by the user from view V_ASK_PARAMETERS that are used to help determine dynamic dates (more later).
One additional attribute is required on the Component Controller: M_CLEAR_MSGS. This value will be set at each *first* display of the W_GET_VARIANT and W_SAVE_VARIANT windows in order to prevent ‘required field’ warnings from being shown to the user. The MO_GET_WINDOW is not used. It was added as part of an attempt to get the W_GET_VARIANT window to auto-close when a row is selected.
I added the following events to the Component Controller:
The following methods were added as part of the Web Dynpro Component interface in order of importance:
SET_REPORT_NAME: Here we’re simply setting the the context node element to remember the value.
1: METHOD set_report_name . " PLM8034
2: 3: DATA: lo_nd_in TYPE REF TO if_wd_context_node.
4: DATA: lo_ni_in TYPE REF TO if_wd_context_node_info.
5: lo_nd_in = wd_context->get_child_node( name = wd_this->wdctx_in ).
6: lo_ni_in = lo_nd_in->get_node_info( ).
7: 8: lo_nd_in->set_attribute( EXPORTING: name = 'REPID'
9: value = i_report_name ).
10: me->refresh_variant_list( ).
11: 12: ENDMETHOD.
It’s also important to know what the REFRESH_VARIANT_LIST routine is doing. It’s called when the report name is set in addition to a couple of other important times. This retrieves a list of variants from the transparent table created for storing the variants for the report name indicated above. It binds this list to the VARIANT_LIST context node.
1: METHOD refresh_variant_list . " PLM8034
2: 3: DATA: lo_nd_in TYPE REF TO if_wd_context_node.
4: DATA: lo_ni_in TYPE REF TO if_wd_context_node_info.
5: lo_nd_in = wd_context->get_child_node( name = wd_this->wdctx_in ).
6: lo_ni_in = lo_nd_in->get_node_info( ).
7: 8: DATA: l_repid TYPE repid.
9: lo_nd_in->get_attribute( EXPORTING: name = 'REPID'
10: IMPORTING: value = l_repid ).
11: 12: DATA: lt_variants TYPE TABLE OF zes_wdvari,
13: ls_variant LIKE LINE OF lt_variants.
14: SELECT prog_name vari_name vtext protected
15: ename edat etime aename aedat aetime16: INTO CORRESPONDING FIELDS OF TABLE lt_variants
17: FROM zes_wdvari
18: WHERE relid = 'WD'
19: AND prog_name = l_repid.
20: 21: DATA: lo_nd_list TYPE REF TO if_wd_context_node.
22: DATA: lo_ni_list TYPE REF TO if_wd_context_node_info.
23: lo_nd_list = wd_context->get_child_node( name = wd_this->wdctx_variant_list ).
24: lo_ni_list = lo_nd_list->get_node_info( ).
25: 26: lo_nd_list->bind_table( lt_variants ).
27: 28: ENDMETHOD.
APPEND_SELOPT_SCREEN: Add the value supplied to the list of selection screens to process later when getting/saving the variant.
1: METHOD append_selopt_screen . " PLM8034
2: APPEND i_selopt_screen TO wd_assist->selopt_screens[].
3: ENDMETHOD.
SHOW_BUTTONS: Show/hide Get/Save/Delete buttons (untested)
1: METHOD show_buttons . " PLM8034
2: 3: DATA: lo_nd_in TYPE REF TO if_wd_context_node.
4: lo_nd_in = wd_context->get_child_node( name = wd_this->wdctx_in ).
5: 6: lo_nd_in->set_attribute( EXPORTING: name = 'VISIBLE_BTN_GET'
7: value = i_btn_get ).
8: lo_nd_in->set_attribute( EXPORTING: name = 'VISIBLE_BTN_SAVE'
9: value = i_btn_save ).
10: lo_nd_in->set_attribute( EXPORTING: name = 'VISIBLE_BTN_DELETE'
11: value = i_btn_delete ).
12: 13: ENDMETHOD.
GET_VARIANT_NAME: Get variant name chosen by user (untested)
1: METHOD get_variant_name . " PLM8034
2: 3: DATA: lo_nd_in TYPE REF TO if_wd_context_node.
4: lo_nd_in = wd_context->get_child_node( name = wd_this->wdctx_in ).
5: 6: lo_nd_in->get_attribute( EXPORTING: name = 'VARIANT_NAME'
7: IMPORTING: value = r_result ).
8: 9: 10: ENDMETHOD.
The WDDOINIT method is called immediately at initialization. First, I’m initializing the list of ‘dynamic date’ routines used later for DATS fields. Then I’m setting the labels for various controls used through the views based on logon language. Finally, I indicate that the MAIN view should show all three buttons by default.
1: METHOD wddoinit . " PLM8034
2: 3: wd_assist->init_varivar_table( ).
4: 5: DATA: lo_nd_text TYPE REF TO if_wd_context_node.
6: lo_nd_text = wd_context->get_child_node( name = wd_this->wdctx_text ).
7: 8: DATA: l_text TYPE string.
9: 10: l_text = wd_assist->get_text( '001' ).
11: lo_nd_text->set_attribute( EXPORTING: name = 'GET'
12: value = l_text ).
13: 14: l_text = wd_assist->get_text( '002' ).
15: lo_nd_text->set_attribute( EXPORTING: name = 'SAVE'
16: value = l_text ).
17: 18: l_text = wd_assist->get_text( '003' ).
19: lo_nd_text->set_attribute( EXPORTING: name = 'OK'
20: value = l_text ).
21: 22: l_text = wd_assist->get_text( '004' ).
23: lo_nd_text->set_attribute( EXPORTING: name = 'CANCEL'
24: value = l_text ).
25: 26: l_text = wd_assist->get_text( '005' ).
27: lo_nd_text->set_attribute( EXPORTING: name = 'PROTECTED'
28: value = l_text ).
29: 30: l_text = wd_assist->get_text( '006' ).
31: lo_nd_text->set_attribute( EXPORTING: name = 'PARAM1'
32: value = l_text ).
33: 34: l_text = wd_assist->get_text( '007' ).
35: lo_nd_text->set_attribute( EXPORTING: name = 'PARAM2'
36: value = l_text ).
37: 38: me->show_buttons( ).
39: 40: ENDMETHOD.
Okay that gets a real good start on the Component Controller. In truth there are quite a few more methods on this object that we’ll get into a little later. These methods are called by user-events, but were placed at the Component Controller level, because it already had access to the shared Context nodes we created above.
| overview |
No comments:
Post a Comment