"Complex-looking" code is sometimes the "simplest" (Dynamic RoadMaps:Part 6)

[former_member181923]

In Part 5 of this tutorial:

When in doubt, de-multiplex! (Part 5 of Dynamic RoadMap 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 saw how we could "de-multiplex" the

create_settings

method of the clone class

ZCL_WDR_ALL_IN_ONE_UIELEM

into a simpler method

create_settings_roadmap

that contains only the

create_settings

code relevant to the dynamic creation of

RoadMaps

. And therefore, we are ready to see what part of dynamic

RoadMap

creation is handled by the method

create_aggregations

, which is the

next

method called after

create_settings

by the

create

method of

ZCL_WDR_ALL_IN_ONE_UIELEM

.

But in order to see

most clearly

how

create_aggregations

is used to build

RoadMaps

dynamically, it is obvious that we'll have to "de-multiplex"

create_aggregations

in the same way that we "de-multiplexed"

create_settings

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

create_aggregations

(like

create_settings

) is

not only

called in the

initial

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_aggregations (method of CL_WDR_ALL_IN_ONE_UIELEM)

but also

in a subsequent

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 inasmuch as create_aggregations will therefore handle the properties of many other items other than RoadMaps (just like create_settings does), it is best to "de-multiplex" it using the same technique we used to "de-multiplex" create_settings:


a) copy create_aggregations to a new method "create_aggregations_roadmap";

b) add the following code at the very top of the original method create_aggregations:

c)

simplify the new method

create_aggregations_roadmap

by removing from it all code that does not apply to the dynamic creation of

RoadMaps

.


When we've done

(a-b)

and start looking at

create_aggregations_roadmap

to see where it can be simplified, the first thing we see is some code with a reference to a global itab that we haven't encountered before:

From our experience with the global itabs used by

create_settings

, we suspect that the itab

mt_ui_aggr_def

is initially loaded from the SAP metadata table

WDY_UI_AGGR_DEF

by the

init_meta_data

method of

ZCL_WDR_ALL_IN_ONE_UIELEM

. And sure enough, when we look at the

init_meta_data

method, we find this code:

To understand what this code does, consider the two rows for

ROAD_MAP

that are in the global itab

mt_ui_aggr_def

when it is read by

create_aggregations_roadmap

:

We know where one of these rows comes from, since it is the

ROAD_MAP

row in the original SAP metadata table

WDY_UI_AGGR_DEF

:

But where does the

other

row come from (the one in which the

aggregation_name

is

LAYOUT_DATA

)?

The answer to this question can be found by examining the

init_meta_data

loop which loads the table

mt_ui_aggr_def

, i.e. the loop shown above.  Inside this loop we find the code:

And inasmuch as the

super_class

and

super_class_lib

of

ROAD_MAP

are listed as

UIELEMENT

and

CORE

in the SAP metadata table

WDY_UI_ELEM_DEF

:

it is clear that this code:

will force the :

Since there are only two rows in

mt_ui_aggr_def

when

create_aggregations_roadmap

begins to execute (one row for the

LAYOUT_DATA

aggregation and one row for the

STEPS

aggregation), the main loop of this method will execute only twice. In these two passes, the method

determine_aggregatees

will

twice

create the table

lt_aggregatees

, as shown in this chart:

In particular, to find (1.1 - 1.4) from (1), 1.3.1 from 1.3, 1.4.1 from 1.4, and 2.1 from 2,

determine_aggregatees

does a "metadata inheritance chase" using the loop that executes right before the

endwhile

in this piece of code:

(You can actually verify the

super_class

and

super_class_lib

relationships used in this code by appropriate queries on

WDY_UI_ELEM_DEF

in Dictionary.)

Before continuing with the next piece of code in

create_aggregations

, it is worth noting that the items which appear in the above chart comprise the set from which items are selected for the right-hand "Hierarchy of Aggregations" displayed by

WDR_TEST_UI_ELEMENTS

for the UI Element

RoadMap

:

(We'll see tomorrow in Part 7 of this tutorial why

not all

of the items in the chart appear in the tree, e.g.

LAYOUT_DATA

,

FLOW_DATA

, etc.)

After the "aggregatees" have been determined for an item in

mt_aggr_ui_def

, the main loop of the

create_aggregations

method looks at the cardinality of this item. From the two snapshots of

WDY_UI_AGGR_DEF

rows that are shown above, we can see that the cardinality of the

LAYOUT_DATA

aggregation for

UIELEMENT

is

"0"

, whereas the cardinality of the

STEPS

aggregation for

ROAD_MAP

is

"2"

. And therefore, the

LAYOUT_DATA

aggregation processes through the

"00 or 01"

leg of the cardinality evaluation routine in

create_settings_roadmap

:

whereas the

STEPS

aggregation passes thru the

"02 or 03"

leg of this routine.

Before attempting to analyze this cardinality evaluation routine

(CER)

to see precisely what it does (which we'll do tomorrow in Part 7 of this tutorial), we can simplify this

CER

by removing all code that does

NOT

execute when the

aggegation

is

LAYOUT_DATA

or

STEPS

. Some of this "removable" code is easy to spot simply by

visual inspection

, e.g. this

"if"

in the

"00 or 01"

leg:

In less obvious cases, we can always

run the debugger

and see:

ℹ what code does/does not execute when the

"00 or 01"

leg of the

CER

processes the

LAYOUT_DATA

aggregation;

(ii) what code does/does not execute when the

"02 or 03"

leg of the

CER

processes the

STEPS

aggregation.


And if you actually perform this code-simplification process on the

create_aggregations_roadmap

method of your local copy

ZCL_WDR_ALL_IN_ONE_UIELEM

, you'll see that the following code can be safely removed.

Code Which Can Be Removed From The "00 or 01" Leg of the CER

Identified by visual inspection:

Identified by visual inspection:

Double-checked via the debugger:

Code Which Can Be Removed From The "02 or 03" Leg of the CER

Identified by visual inspection:

Identified by visual inspection:

Identified by visual inspection: