Skip to Content

Before continuing the event-driven tutorial in order to learn how the runtime classes of UI Elements are used in the construction and manipulation of the (right-hand) tree view and (middle) detail view in

WDR_TEST_UI_ELEMENTS

, I thought it would be a good idea to do a “procedural” recap tutorial summarizing exactly what had to be done in order to get new custom libraries and links to display in the (left-hand) tray view of the clone component

ZWDR_TEST_UI_ELEMENTS

. This “procedural” recap will permit readers to evaluate the pros and cons of “event-driven” vs “procedural” tutorials, and also provide a foundation for understanding how to tease out the generic functionality of

WDR_TEST_UI_ELEMENTS

from its specfic (UIElement-related)functionality, i.e. the generic functionality of this component as a pattern for displaying a detail view from a tree view from a tray view (with dynamic construction of all three views.)

In the first and second posts of the event-driven tutorial on the SAP-delivered WD-ABAP component

WDR_TEST_UI_ELEMENTS

:

Experiential vs Procedural Tutorials: “Breaking” WDR_TEST_UI_ELEMENTS to Learn From It.

The class infrastructure of WDR_UI_TEST_ELEMENTS is exquisite for lazy cloning and change-ups.

we learned what had to be done in order to get new custom libraries and links to display in the (left-hand) tray view of the clone component

ZWDR_TEST_UI_ELEMENTS

.

In particular, here’s what was done and why.

1. Step 1:

What

: Clone the WD-ABAP component

WDR_TEST_UI_ELEMENTS

as

ZWDR_TEST_UI_ELEMENTS

.

Why?

: So we don’t muck with SAP-delivered code.

Details

: Use the comnponent copy function of the WD-ABAP component editor in

Object Navigsator (SE80)

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

2. Step 2:

What

: Clone the two SAP-delivered metadata tables

WDY_UI_LIBRARY

and

WDY_UI_ELEMENTS

as

ZWDY_UI_LIBRARY

and

ZWDY_UI_ELEMENTS

.

Why?

So we can reload the original SAP-metadata into these clone tables, and also add the new data for our custom libraries and elements into these tables. (The libraries will wind up as trays and the elements as links within the trays in the cloned component

ZWDR_TEST_UI_ELEMENTS

. Note also that we want to reload the original SAP metadata in order to see if it displays correctly i.e. in order to make sure that we have not destroyed any functionality of the original SAP component – we will decide what portions of this functionality we DON’T need later on.)

Details

:

2a

: Create

ZWDY_UI_LIBRARY

and

ZWDY_UI_ELEM_DEF

from the SAP-delivered tables

WDY_UI_LIBRARY

and

WDY_UI_ELEM_DEF

via the table-copy functionality of

Dictionary (SE11)

. Don’t forget to activate.

2b

: Run this code as indicated (bottom-up) in five steps (1-5).  Remember to make your custom library names UPPER-CASE!!

REPORT Z_WDY_TO_ZWDY.

DATA:

wa_zwdyl TYPE wdy_ui_library,

wa_zwdye TYPE wdy_ui_elem_def,

i_zwdyl TYPE wdy_ui_library_table,

i_zwdye TYPE wdy_ui_elem_def_table.

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

  • Step 5:

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

wa_zwdye-library_name = ‘PRGTRS’.

wa_zwdye-definition_name = ‘BBK’.

wa_zwdye-display_name = ‘Document Numbers by Cost Center’.

wa_zwdye-runtime_class = ‘CL_WD_BBK’.

INSERT INTO zwdy_ui_elem_def VALUES wa_zwdye.

wa_zwdye-definition_name = ‘PTA’.

wa_zwdye-display_name = ‘Projects to Activities’.

wa_zwdye-runtime_class = ‘CL_WD_PTA’.

INSERT INTO zwdy_ui_elem_def VALUES wa_zwdye.

COMMIT WORK.

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

  • Step 4:

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

*wa_zwdye-library_name = ‘RPTSTS’.

*

        • GS01 PCA-CORP

*wa_zwdye-definition_name = ‘CBI’.

*wa_zwdye-display_name = ‘Balance Sheet/Income Statement’.

*wa_zwdye-runtime_class = ‘CL_WD_CBI’.

*

        • GS01 BFS-ALL

*INSERT INTO zwdy_ui_elem_def VALUES wa_zwdye.

*

*wa_zwdye-definition_name = ‘MOP’.

*wa_zwdye-display_name = ‘Manufacturing Operations’.

*wa_zwdye-runtime_class = ‘CL_WD_MOP’.

*

*INSERT INTO zwdy_ui_elem_def VALUES wa_zwdye.

*

          • 34-2 KAH3

*wa_zwdye-definition_name = ‘MMS’.

*wa_zwdye-display_name = ‘Maintenance/Mechanical Services’.

*wa_zwdye-runtime_class = ‘CL_WD_KLF’.

*

*INSERT INTO zwdy_ui_elem_def VALUES wa_zwdye.

*

*COMMIT WORK.

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

  • Step 3:

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

*wa_zwdye-library_name = ‘LGCLDBS’.

*

*wa_zwdye-definition_name = ‘KDF’.

*wa_zwdye-display_name = ‘Vendor Database’.

*wa_zwdye-runtime_class = ‘CL_WD_KDF’.

*

*INSERT INTO zwdy_ui_elem_def VALUES wa_zwdye.

*

*wa_zwdye-definition_name = ‘KKF’.

*wa_zwdye-display_name = ‘Open Item Balance Audit Trail’.

*wa_zwdye-runtime_class = ‘CL_WD_KKF’.

*

*INSERT INTO zwdy_ui_elem_def VALUES wa_zwdye.

*

*wa_zwdye-definition_name = ‘KLF’.

*wa_zwdye-display_name = ‘Historitcal Balance Audit Trail’.

*wa_zwdye-runtime_class = ‘CL_WD_KLF’.

*

*INSERT INTO zwdy_ui_elem_def VALUES wa_zwdye.

*

*wa_zwdye-definition_name = ‘KMV’.

*wa_zwdye-display_name = ‘Condition Record Selection’.

*wa_zwdye-runtime_class = ‘CL_WD_KMV’.

*

*INSERT INTO zwdy_ui_elem_def VALUES wa_zwdye.

*

*COMMIT WORK.

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

  • Step 2:

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

*wa_zwdyl-library_name = ‘LGCLDBS’.

*wa_zwdyl-display_name = ‘Logical DataBases’.

*wa_zwdyl-library_class = ‘CL_WDL_LDB’.

*

*INSERT INTO zwdy_ui_library VALUES wa_zwdyl.

*

*wa_zwdyl-library_name = ‘RPTSTS’.

*wa_zwdyl-display_name = ‘Report Sets’.

*wa_zwdyl-library_class = ‘CL_WDL_RPT’.

*

*INSERT INTO zwdy_ui_library VALUES wa_zwdyl.

*

*wa_zwdyl-library_name = ‘PRGTRS’.

*wa_zwdyl-display_name = ‘Programming Trees’.

*wa_zwdyl-library_class = ‘CL_WDL_PRG’.

*

*INSERT INTO zwdy_ui_library VALUES wa_zwdyl.

*

*COMMIT WORK.

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

  • Step 1:

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

*SELECT *

  • FROM wdy_ui_library

  • INTO TABLE i_zwdyl.

*

*LOOP AT i_zwdyl INTO wa_zwdyl.

*

  • INSERT INTO zwdy_ui_library VALUES wa_zwdyl.

*

*ENDLOOP.

*

*SELECT *

  • FROM wdy_ui_elem_def

  • INTO TABLE i_zwdye.

*

*LOOP AT i_zwdye INTO wa_zwdye.

*

  • INSERT INTO zwdy_ui_elem_def VALUES wa_zwdye.

*

*ENDLOOP.

*

*COMMIT WORK.

and change the class references in the two nested loops :

  • display the libraries

  loop at  into table mt_ui_elem_def.

endif.

  • END added 20060830</b>

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

At this point, the clone component

ZWDR_TEST_UI_ELEMENTS

will display the three new custom libraries in

ZWDY_UI_LIBRARY

as trays in the left-hand side tray view and the new custom elements in

ZWDY_UI_ELEM_DEF

as active links within these new trays. (It will, of course, also still display the SAP-delivered libraries and links, since we stuffed these into our custom metadata tables before adding our own rows to these tables – see step 2 above.)

So before continuing with the experiential/event-driven tutorial by creating real run-time classes for the new custom elements (in order to be able to correctly customize the tree view and detail view of our custom component

ZWDR_TEST_UI_ELEMENTS

), let’s stop and examine what we’ve learned from the tutorial so far.

Well, at the lowest level, what we’ve learned is how to construct a dynamic tray builder by changing up an SAP-delivered module. From the point of view of “re-usability” (a subject near and dear to the hearts of so many SDN’ers), this is certainly better than writing our own. (Does it matter if we don’t yet understand all of what’s going on “under the covers” with the controllers, etc.? I would argue no – not at this point in our progress toward getting smart in WD-ABAP.)

But at a higher level, we’ve learned some things that are much more important (in my opinion). We’ve learned:

a) What persistent metadata we need for a dynamic tray-builder (Note, for example, that we do need

runtime_classes

in the custom table

ZWDY_UI_ELEM_DEF

because these are used to build

tray_id’s

in the dynamic tray-builder, even before these runtime_classes are used to build the tree and detail views in

ZWDR_TEST_UI_ELEMENTS

. These new runtime_classes don’t have to be actually built yet, but they do have to be defined, unless we want to change the way tray_id’s are constructed for the dynamic tray-builder.)

b) exactly what code we can strip out of the SAP-delivered module and still have a dynamic tray-builder (more on this later . . .)

c) how selection of metadata (trays and links) for this dynamic tray-builder can be done in two places: i) the

init_meta_data

method of

ZCL_WDR_ALL_IN_ONE_UIELEM

; and ii) the

init_view2

method of

ZCL_WDR_ALL_IN_ONE_UTIL

. In the former, we can decide the metadata tables we want to draw on and what metadata from these tables to put in our “work” itab that we’ll use in the latter method. In this latter method, we’ve learned that we can do additonal selection on the “work” itab mt_ui_elem_def in order to control what actually winds up being displayed as the custom trays and links by

ZWDR_TEST_UI_ELEMENTS

.

But more importantly, I think, we’ve learned how to attack a given problem “experientially”:

d) we do a little study on an existing SAP-delivered component to see how it ticks at a very basic level;

e) we clone what we need to initially and then see what breaks;

f) we fix what breaks.

By going through an

event-driven

tutorial such as the one I’ve tried to create in the preceding two posts , I think a lot more can be learned than by simply running through a standrard “procedural” tutorial like that provided in this post’s “procedural recap” tutorial. What I mean by

events

are the different places the code breaks and the different attempts we make to fix it as we progress toward something that does what we want. (As can be seen from the two initial posts in this series, not all of these repair attempts are correct, and from making these faulty repairs, we can learn as much as from when we do repairs correctly the first time.)

Anyway, tomorrow’s post will take up the following questions:

g) Just because the SAP-delivered component

WDR_TEST_UI_ELEMENTS

uses real runtime classes to build its tree view and detail view, do we have to?

h) If the answer to this is “no”, then

should

we nonetheless define real runtime classes for the elements (links) that we have stored in

ZWDY_UI_ELEM_DEF

?

As will be seen, the answer to (g) and (h) are respectively “no” and “yes” (at least in my opinion), for some very interesting reasons.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply