Certain times, there may be requirement where we need to load the required configuration based on some conditions.
For ex:
we know that one business partner can be created in any one of three groups.
INDIVIDUAL, ORGANZIATION and GROUP.
When user wants to create a customer as INDIVIDUAL category, then we need to show different screen to the user with fields like first name and last name. If he wants to create a business partner in ORGANIATION category, then we need to show him separate screen with fields like NAME_ORG1.
Here we need to show different to screens to the user based on partner category. Here each screen is nothing but a view configuration.
In these situations, we will take a help from the method DO CONFIG DETERMINATION. As name suggests it used to determine the required configuration at run time. In this method we put logic to determine correct configuration keys and then call one more method SET_CONFIG_KEYS to load the correct configuration based on the fed configuration keys.
Let us see a example.
In the ASSIGNING UI OBJECT TYPE TO CONTEXT NODE, we have created one new configuration with UI object type . Let us load that .
Here there are two configurations exist for view. If we execute directly, system will load first configuration like below. Here you can see OBJECT_ID labeled as TRANSACTIO No.
Second configuration is there with UI object type ZOBJECT_TUT. This configuration looks like below. Here OBJECT_ID labeled as CONTRACT ID.
If I execute the application , this is what I got as output.
It is loading default configuration.
Let us make it to load second configuration.
Go the VIEW implementation class and look for the method DO CONFIG DETERMINATION. Redefine it.
Just activate it. Here ZOBJECT_TUT is object type that I used when defining second configuration. I am not using any sub object type here as I don’t have any sub object in the second configuration.
Test the applications once activate is done. You can see the framework will load the second configuration.
This is how we can load required configuration. This is simple example, we can use any base condition to load required configuration. We can have many configurations and can load required configuration dynamically.
We left one small concept i.e. defining sub object types. Let us again go back to the callback class created in the chapter ‘UI OBJECT TYPE AND DESIGN OBJECT’.
For ex:
we know that one business partner can be created in any one of three groups.
INDIVIDUAL, ORGANZIATION and GROUP.
When user wants to create a customer as INDIVIDUAL category, then we need to show different screen to the user with fields like first name and last name. If he wants to create a business partner in ORGANIATION category, then we need to show him separate screen with fields like NAME_ORG1.
Here we need to show different to screens to the user based on partner category. Here each screen is nothing but a view configuration.
In these situations, we will take a help from the method DO CONFIG DETERMINATION. As name suggests it used to determine the required configuration at run time. In this method we put logic to determine correct configuration keys and then call one more method SET_CONFIG_KEYS to load the correct configuration based on the fed configuration keys.
Let us see a example.
In the ASSIGNING UI OBJECT TYPE TO CONTEXT NODE, we have created one new configuration with UI object type . Let us load that .
Here there are two configurations exist for view. If we execute directly, system will load first configuration like below. Here you can see OBJECT_ID labeled as TRANSACTIO No.
Second configuration is there with UI object type ZOBJECT_TUT. This configuration looks like below. Here OBJECT_ID labeled as CONTRACT ID.
If I execute the application , this is what I got as output.
It is loading default configuration.
Let us make it to load second configuration.
Go the VIEW implementation class and look for the method DO CONFIG DETERMINATION. Redefine it.
Just add the following line to it.
Just activate it. Here ZOBJECT_TUT is object type that I used when defining second configuration. I am not using any sub object type here as I don’t have any sub object in the second configuration.
Test the applications once activate is done. You can see the framework will load the second configuration.
This is how we can load required configuration. This is simple example, we can use any base condition to load required configuration. We can have many configurations and can load required configuration dynamically.
We left one small concept i.e. defining sub object types. Let us again go back to the callback class created in the chapter ‘UI OBJECT TYPE AND DESIGN OBJECT’.