When in doubt, de-multiplex! (Part 5 of Dynamic RoadMap Tutorial)

[former_member181923]

At the end of Part 4 of this tutorial:

Class-Data May be Cheating, but Who Cares? (Part 4 of Dynamic Road Map Tutorial)
SAP UI Element Metadata: Gold or Fool's Gold? (Part 3 of Dynamic RoadMap Tutorial)
But how does the thermos bottle know? (Part 2 of Dynamic Road Map Tutorial)
Exposing Critical SAP Code Paths as WebDynpro(ABAP) RoadMaps: One Case Where Dynamic UI Element Gene...


we were in the middle of examining how the method

create_settings

of the class

CL_WDR_ALL_IN_ONE_UIELEM

processes

ROAD_MAP

property data in the SAP metadata table

WDY_UI_PROP_DEF

. In particular, we had reached the point in the main loop of

create_settings

where a value-set (perhaps null) has been assigned to each property of the

ROAD_MAP

UI element, and the next piece of code to execute is:

But if you look at this piece of code, an obvious question immediately arises:

On the one hand, the main loop of

create_settings

is executing only on rows of the global itab

mt_ui_prop_def

in which

library_name

is

'STANDARD'

and

definition_name

is

ROAD_MAP

. (This is because the global variables

m_library_name

and

m_definition_name

are currently set to these values.)

On the other hand, the above

"if"

executes only when

library_name

is

'DYNPRO_CONVERSION'

and

definition_name

is

'SELECT_OPTION_FIELD'

.

So the question is:

Why is this

"if"

in

create_settings

if it can never apply when

library_name

is

'STANDARD'

and

definition_name

is

ROAD_MAP ???

The answer to this question is that

create_settings

is a multi-purpose method that is called

more than once

after an

action_link

has been selected from a lefthand tray displayed by WDR_TEST_UI_ELEMENTS. In particular,

create_settings

is not only called in this flow-of-control:

onActionDISPLAY_DETAIL (method of Main view of WDR_TEST_UI_ELEMENTS)
on_display_detail (method of CL_WDR_ALL_IN_ONE_UTIL)
switch_ui_element2 (method of CL_WDR_ALL_IN_ONE_UTIL)
create (method of CL_WDR_ALL_IN_ONE_UIELEM)
create_settings (method of CL_WDR_ALL_IN_ONE_UIELEM)

It is also called multiple times by the

create

method of

CL_WDR_ALL_IN_ONE_UIELEM

in this

recursive

flow-of-control:

create (method of CL_WDR_ALL_IN_ONE_UIELEM)
create_aggregations (method of CL_WDR_ALL_IN_ONE_UIELEM)
create_aggregatee (method of CL_WDR_ALL_IN_ONE_UIELEM)
create (method of CL_WDR_ALL_IN_ONE_UIELEM)

And when

create_settings

is called by

create

in this recursive flow-of-control, it is required to process

property

data for many metadata elements other than

Road_Map

.

Because

create_settings

is this kind of multi-purpose method, it is a lot more difficult to understand than if it were just a method designed to help in the dynamic creation of

RoadMaps

. But inasmuch as

create_settings

is called by

create

with

NO

parameters, we can very easily improve the comprehensibility of

create_settings

by:

a

) copying

create_settings

to a new method "

create_settings_roadmap

";

b)

adding the following code at the very top of the original method

create_settings

:

if m_library_name = 'STANDARD'
and m_definition_name = 'ROAD_MAP'.

create_settings_roadmap( ).
exit.

endif.

c)

removing from the new method

create_settings_roadmap

all code that does not apply to the dynamic creation of

RoadMaps

.

(Readers who want to try this for themselves will first need to make local copies of the WebDynproABAP component

WDR_TEST_UI_ELEMENTS

, the class

CL_WDR_ALL_IN_ONE_UTIL

, and the class

CL_WDR_ALL_IN_ONE_UIELEM

, and then make some minor changes to these local copies. So in an "Appendix" at

the bottom of this post

, I have again listed everything that has to be done in order to make the local copies work correctly, i.e what we originally did way back Class-Data May be Cheating, but Who Cares? (Part 4 of Dynamic Road Map Tutorial).)

Once

(a-b)

have been done, it's easy to accomplish objective

(c)

by simplifying the new

create_settings_roadmap

method so that it only contains code applying to

RoadMaps

.

In particular, we can do the following:

1) Simpify this code:

to this code:

2) Simpify this code:

to this code:

3) Remove this code:

4) Simpify this code:

to this code:

5) Remove this code:

6) Simpify this code:

to this code:

When we make the changes (1-6) and re-activate, we know</b> we understand those aspects of the module <b>create_settings</b> that are relevant to <b>RoadMaps</b> because the component runs as if we didn't change anything at all.

So tomorrow, we'll take the same approach for the methods <b>create_aggregations</b> and <b>create_aggregatee</b>, which are even more multiplexed than <b>create_settings</b>.

<b>Appendix</b>

To make excecutable local copies of <b>WDR_TEST_UI_ELEMENTS</b> and its two supporting classes, here are the required steps (repeated from an earlier post for your convenience):

<b>1.  Step 1:</b>

<b>What</b>: Copy the WD-ABAP component <b>WDR_TEST_UI_ELEMENTS</b> to <b>ZWDR_TEST_UI_ELEMENTS</b>.

<b>Why?</b>: So we don't muck with SAP-delivered code.

<b>Details</b>: Use the comnponent copy function of the WD-ABAP component editor in <b> Object Navigsator (SE80)</b>.

(Don't forget to create an application for the new clone component.)

<b>2.  Step 2:</b>

<b>What</b>: Copy the two SAP-delivered classes <b>CL_WDR_ALL_IN_ONE_UTIL</b> and <b>CL_WDR_ALL_IN_ONE_UIELEM</b> to <b>ZCL_WDR_ALL_IN_ONE_UTIL</b> and <b>ZCL_WDR_ALL_IN_ONE_UIELEM</b>.

<b>Why?</b>: Because we have to change some typing and methods in these classes.

<b>Details</b>: Use the class copy function of the Class Editor (SE24) to create <b>ZCL_WDR_ALL_IN_ONE_UTIL</b> from <b>CL_WDR_ALL_IN_ONE_UTIL</b> and <b>ZCL_WDR_ALL_IN_ONE_UIELEM</b> from <b>CL_WDR_ALL_IN_ONE_UIELEM</b>

<b>3.  Step 3:</b>

<b>What</b>: Get the new clone component <b>ZWDR_TEST_UI_ELEMENTS</b> just to compile and run by making any necessary changes in types and methods.

<b>Why?</b>: To make sure that we have a firm foundation before we continue.

<b>Details</b>:

<b>3a</b>:  In the <b>Attributes</b> of the <b>Main</b> view of the clone component ZWDR_TEST_UI_ELEMENTS, change the type of the attribute <b>m_handler</b> to the new custom class <b>zcl</b>_wdr_all_in_one_utils.

<b>3b</b>: Change the <b>constructor</b> method of the new customer class zcl_wdr_all_in_one_utils so that it references the <b>init_meta_data</b> method of the <b>new</b> customer class <b>zcl_wdr_all_in_one_uielem</b>;

<b>3c</b>: In the attributes of the new custom class <b>ZCL_WDR_ALL_IN_ONE_UTIL</b>, change the type of <b>m_cur_view_element</b> to the new custom class <b>zcl</b>_wdr_all_in_one_uielem;

<b>3d</b>: in the protected section of <b>zcl_wdr_all_in_one_uielem</b>, change the type of <b>tt_me</b> to <b>zcl_wdr_all_in_one_uielem</b>;

<b>3e</b>: in the method <b>create_aggregatee</b> of the new class <b>zcl_wdr_all_in_one_uielem</b>, change the type of <b>lr_new_view_elem_helper</b> to <b>zcl</b>_wdr_all_in_one_uielem;

<b>3f</b>: in the method <b>create_container_default_aggr</b> of the new class <b>zcl_wdr_all_in_one_uielem</b> , do the same thing as in (f), i.e. change the type of <b>lr_new_view_elem_helper to zcl_wdr_all_in_one_uielem</b>;

<b>3g</b>: Make the following type changes in the method <b>init_view2</b> of the new class <b>ZCL_WDR_ALL_IN_ONE_UTIL</b>:

<font color="blue">method INIT_VIEW2.

...

  data:

...

    ui_elem_def_tmp        like line of <b>zcl</b>_wdr_all_in_one_uielem=>mt_ui_elem_def_all,

...

    ui_prop_def_tmp        like line of <b>zcl</b>_wdr_all_in_one_uielem=>mt_ui_prop_def,

...

  field-symbols:

    <ui_elem_def> like line of <b>zcl</b>_wdr_all_in_one_uielem=>mt_ui_elem_def,

    <ui_prop_def> like line of <b>zcl</b>_wdr_all_in_one_uielem=>mt_ui_prop_def,

    <ui_library>  like line of <b>zcl</b>_wdr_all_in_one_uielem=>mt_ui_library.

...</font><br><br>