Using the do_config_determination to change a screen layout

Important methods in CRM web UI or component programming .

View Impl class methods:

DO_CONFIG_DETERMINATION : The method is for run time config determination
 to set new configuration through the method SET_CONFIG_KEY


me->set_config_keys( iv_object_type          = lv_object_type
                       iv_object_sub_type      = lv_subtype
                       iv_propagate_2_children = abap_true ).

********************************************************************

Using the do_config_determination to change a screen layout

Sometimes, you run in to a requirement where you would like to change the layout of the screen based on another field, for instance if a dropdownbox contains a certain value, you would like to show different input fields from when the dropdown box contains another value, or in some cases the existence of a value in one field might require input in another field.

There are several ways to implement this, where one of the most flexible ways is implementing the DO_CONFIG_DETERMINATION. Standard SAP does not contain many implementations of this class, but the best example is probably in component BP_HEAD in the AccountDetails view.

If you look at the code, the do_config_determination first reads the values from the typed_context.

You can of course read values directly from the context, or first retrieve them from the relations.

Then, using a simple method call, the values are sent to the config keys:

  me->set_config_keys( iv_object_type          = lv_object_type
                       iv_object_sub_type      = lv_subtype
                       iv_propagate_2_children = abap_true ).

As you can see in the BP_HEAD/AccountDetails view, the object_type and subobject_type are set. You can only use the object_type and subobject_types that are available in the system, so, in the example, SAP uses BP_ACCOUNT, INDIVIDUAL and GROUP. So, the logic to determine the object type in this case is hardcoded.

Another good example of variable configuration determination can be seen in BT126H_APPT. Here, SAP decided not to use the do_config_determination of a particular view, but to implement it in the window BT126H_APPT/MainWindow.

The downside of using the configuration determination using the object_type and object_subtype, is that while adding new configurations, the values that are available are limited to what has been defined in the hardcoded valuehelp.

If you want to be implement dynamic configuration determination independent of hardcoded objects and subobjects, you can use the field 'Component Usage'. If you move the value from a field to the component usage, you will be able to differentiate in the configuration based on the value you have entered in the screen. If the values in the screen are limited to a few values (for instance in a radiobutton, or a dropdown listbox), this could be a perfect solution to your requirement.

If you want to check whether a value is present in a field or not, do not move the exact value to the component usage, but move 'X' or 'Blank' to the field for instance. Otherwise, you would have to create configurations for all possible entries in the field.

You can set the component usage in the do_config_determination, by implementing the following statement: 

ME->CONFIGURATION_DESCR->SET_COMPONENT_USAGE( [your variable] ).

As the do_config_determination is called on every roundtrip, you can choose to force a roundtrip after changing the value in a DDLB or a radiobutton by implementing an event as described here. You do not necessarily have to implement the actual corresponding event handler, as all you want to do is force a roundtrip.

For ordinary input fields, a roundtrip is triggered upon enter.

Using this dynamic usage determination, you are able to move for instance the user status of an object to the component usage field, and then differentiate in the view configuration per status. In some cases you might have different mandatory fields for different statusses.

********************************************************************

SET_VIEW_GROUP_CONTEXT

DO_PREPARE_OUTPUT : This method prepares the output for the UI screen .
as its part of impl class the context nodes can be accessed here using the typed_context
attribute.

lr_entity_name TYPE REF TO cl_crm_bol_entity
lr_entity_name ?= typed_context-><context node name>->collection_wrapper->get_current( ).


lv_variable = lr_prospect->get_property_as_string( iv_attr_name = 'PARTNER_NO' ).
Significance of IV_FIRST_TIME
Whenever the control is transferred to the current view for the first time this parameter IV_FIRST_TIME  will get 
filled as 'X'. So this parameter is very useful ,if you want to handle any logic where you need to populate something 
whenever your view gets displayed for first time . As DO_PREPARE_OUTPUT is triggered several times within in 
a view when user performs diffent functions, IV_FIRST_TIME check can be done and your code can be made to 
run only once,thus improving the performance.


DO_VALIDATE_INPUT : Used for validating the data entered in the view .
its triggers when you press enter after entering the data .
Example : here we are checking if the address number is a valid address number or not .


  lv_wrapper = me->ztyped_context->zbtadmini->get_collection_wrapper( ).
  lv_size    = lv_wrapper->size( ).
  IF  lv_wrapper IS BOUND .

    lr_entity  ?= lv_wrapper->get_first( ).

    WHILE lr_entity IS BOUND.

      lv_zzfld000002 = lr_entity->get_property_as_string( 'ZZFLD000002' ).
      IF lv_zzfld000002 IS NOT INITIAL .
        CALL FUNCTION 'CONVERSION_EXIT_ALPHA_INPUT'
          EXPORTING
            input  = lv_zzfld000002
          IMPORTING
            output = lv_zzfld000002.

        SELECT SINGLE * FROM adrc INTO lv_adrc WHERE addrnumber EQ lv_zzfld000002.
        IF sy-subrc NE 0 .
          l7_msg_service = me->view_manager->get_message_service( ).
          l7_msg_service->add_message(
              iv_msg_type       = 'E'
              iv_msg_id         = 'ZBSP'
              iv_msg_number     = '008'
              iv_msg_v1         = lvsp_msg_v1 ).
        ENDIF.
      ENDIF .

      lr_entity  ?= lv_wrapper->get_next( ).

    ENDWHILE.

  ENDIF .


DO_HANDLE_EVENT : To handle events generated .
It catches the server event generated by button press or mouse click .

* Eventhandler dispatching
   CASE htmlb_event_ex->event_server_name.
*     Added by wizard
    WHEN 'ACT_STATUS_SELECTED'.                             "#EC NOTEXT
      EH_ONACT_STATUS_SELECTED( htmlb_event    = htmlb_event
                  htmlb_event_ex = htmlb_event_ex ).
*     Added by wizard
    WHEN 'SEL_RESPATCHANNEL'.                               "#EC NOTEXT
      EH_ONSEL_RESPATCHANNEL( htmlb_event    = htmlb_event
                  htmlb_event_ex = htmlb_event_ex ).
*     Added by wizard
    WHEN 'SEL_CHANNELPARTNER'.                              "#EC NOTEXT
      EH_ONSEL_CHANNELPARTNER( htmlb_event    = htmlb_event
                  htmlb_event_ex = htmlb_event_ex ).
WHEN others .
ENDCASE.

IF_BSP_WD_TOOLBAR_CALLBACK~GET_BUTTONS : To create the buttons 
Example :

  DATA: ls_button     TYPE crmt_thtmlb_button_ext.

* Done button
  ls_button-type     = cl_thtmlb_util=>gc_done.
  ls_button-on_click = 'Done'.                              "#EC NOTEXT
  ls_button-page_id  = me->component_id.
  ls_button-enabled  = abap_true.
  APPEND ls_button TO rt_buttons.

DO_FINISH_INPUT :(update soon )

DO_INIT_CONTEXT:(update soon )

ON_NEW_FOCUS:(update soon )

Component Controller impl class methods :
WD_USAGE_INITIALIZE : The method is used for data binding for the component usage .

Redefined Method WD_USAGE_INITIALIZE and added coding as follows:

   

CHECK iv_usage IS BOUND.

  CASE iv_usage->usage_name.
    WHEN 'ZJSuseCompRfC'.
        iv_usage->bind_context_node 

              ( iv_controller_type  = cl_bsp_wd_controller=>co_type_component
                                   iv_target_node_name = 'BTORDER'
                                   iv_node_2_bind      = 'BTORDER' ).
    WHEN OTHERS.
  ENDCASE.

DO_INIT_CONTEXT :(update soon )

View Context   Ctxt class :

Context class CN00....
ON_NEW_FOCUS : ON_NEW_FOCUS method is used when we create Context nodes having 
Parent-Child relationship in the BOL Model. Now imagine if the data related to the Parent node is changed,
 in such case the related child data also needs to be refreshed
Example : Any standard table view node .
    DATA: lv_collection TYPE REF TO if_bol_bo_col,
          entity        TYPE REF TO cl_crm_bol_entity.

*   get collection of dependent nodes
    entity ?= focus_bo.
    TRY.
        lv_collection = entity->get_related_entities(
               iv_relation_name = 'BTOrderItemAll' ). "Removed NoCompItems CSN: 1464311 2009
         lv_collection->set_multi_select( abap_true ).
        CATCH cx_crm_genil_model_error.
*       should never happen
        EXIT.
      CATCH cx_sy_ref_is_initial.
    ENDTRY.
    me->collection_wrapper->set_collection( lv_collection ).

GET_TABLE_LINE_SAMPLE:(update soon )