As I've mentioned before, the SAP-delivered WD-ABAP component WDR_TEST_UI_ELEMENTS embodies an extremely useful pattern: display of a detail view from a tree view from a tray view. The tray view (on the left-hand side of the window) and the tree-view (on the right-hand side of the window) permit you to segregate a single hierarchy into two hierarchies - one which displays a tree with root at depth 0 down to a tree of maximal depth 2 (this is the tray view on the left), and another which displays a tree as deep and broad as you want (this is the tree view on the right.) Furthermore, the tree>detail navigation shows you how to link a tree to table (for example), without encountering the limitation on the table-carrying properties of recursion nodes that one finds in the TreeWithTable implementation in WDR_ TEST-EVENTS. The problem with WDR_TEST_UI_ELEMENTS, on the other hand, is that it is a curious mixture of specific and generic functionality. As one delves into the mechanics of this component, one finds that one is dealing with a multiplicity of view element classes (e.g. CL_WD_BUTTON) that are invoked to permit dynamic view generation in the detail view. And therefore, if one wants a fully generic tray>tree>detail component, one has to figure out how to separate out the generic functionality of WDR_TEST_UI_ELEMENTS from its specific functionalities related to the properties of classes such as CL_WD_BUTTON, etc. (I realize it might be easier to read the documentation and write one's own component, but if one goes this route, one cannot take the opportunity to learn all the tricks of the trade from the folks who wrote WDR_TEST_UI_ELEMENTS - this is a very elegant module that can teach you a lot about WD-ABAP "inadvertently ", i.e. you're looking at it to see how to do one thing and in the process you learn how to do three other things at the same time.) So, I'm embarking on the development of an "experiential" tutorial which will teach myself (and anyone else who is interested) how to break WDR_TEST_UI_ELEMENTS in order to learn from it). My goal is to use this component as a model for developing a component that does the following. In the left-hand tray view, three kinds of libraries will be displayed: a) a Logical DataBase (LDB) tray; b) a Report Set tray (RS); c) a Miscellaneous (MI) Tray. When the LDB tray is opened, the component will display (as links) the names of several logical databases that SAP delivers. When the Report Set tray is opened, the component will display (as links) several GS01 Report Sets that happen to have been created at the site I'm currently at. When the MI tray is opened, the component will display (as links) the names of various procedural trees that one can use to achieve certain functional objectives in SAP, e.g. pre-fetching belnrs by kostl by going from CSKS to COEP to COBK, or going from project to activity via project > WBS element(s) > Networks > Activities. (There must be literally hundreds of these procedural trees that represent the combined knowledge of SAP developers and developers in the SDN community - when I'm done building the component, I will ask SDN to make this aspect of it public on SDN so folks can see exactly what procedural trees should be used to accomplish various functional objectives.) When a link in the LDB tray is selected, the component will display the tree of the LDB in the tree view on the right. When a node of this tree is selected, the component will display some interesting information about the node in the detail (middle view) of the component, e.g. the name of the LDB program module that contains the PUT events for. When a link in the Report Set tray is selected, the component will diplsay the tree of the Report Set in the tree view on the right. When a MAXIMAL node of this tree is selected, it will display the leaves of this node in the detail (middle) view as a table. When a link in the MI tray is selected, the component will display a procedural tree in the tree view on the right, e.g. Project > WBS Element (Tree) > Network > Activity. When a node of this tree is selected, the component will display some interesting information about the node in the detail (middle) view, e.g. the "hook" to the next level of the procedural tree. As a first step toward developing this component, custom metadata must obviously be loaded into customer Z-versions of the SAP-delivered tables wdy_ui_library and wdy_ui_elem_def. For example, the three kinds of trays in the new component must be added as three new libraries in the Z-version of wdy_ui_library, etc. (Note! we want to load all the SAP data from wdy_ui_library into zwdy_ui_library and all the SAP data from wdy_ui_elem_def into zwdy_ui_elem_def, and only then add our custom metadata to these tables. The reason for this will be obvious from the discussion below.) But to access these Z-versions of wdy_ui_library and wdy_ui_elem_def from our new component, we must first: d) make a z-copy of the SAP-delivered class cl_wdr_all_in_one_utils and declare this customer class "zcl_wdr_all_in_one_utils" as the type of m_handler in the attributes of the Main view of the new component; e) make a z-copy of the SAP-delivered class cl_wdr_all_in_one_uielem, and change the constructor method of the new customer class zcl_wdr_all_in_one_utils so that it references the init_meta_data class of the new customer class cl_wdr_all_in_one_uielem; f) change the init_meta_data method of the new customer class cl_wdr_all_in_one_uielem so that it selects from the z-tables zwdy_ui_library and zwdy_uielem_def. (These are the ones we created to store the new metatadat we need for the component, as well as the original metadata.) Once we've completed (d-f) above, we're ready to try and run the new component and see where it breaks first. If we're smart enough not to have changed the type declarations that are based on the SAP-delivered tables zwdy_ui_library and zwdy_uielem_def, the new component should run fine on the SAP-delivered trays and links, but blow up when a link in one of our trays is selected And as we see what blows up, we'll learn what else has to be "z'd "in order to accomplish our end-result. Of course, it's possible that the new component won't even activate correctly. I can't see up front why this should be the case - the three new libraries should appear as three new trays in the tray view produced by the new component, and the items in these libraries should properly appear as links in the appropriate trays. But this depends on the amount of proactive cross-checking the SAP compiler does during activation - and it will be interesting to see whether the compiler does detect problems because, for example, the items in our new libraries don't have "runtime_classes". Whether we run successfully or not after (d-f), we will learn a lot about WD-ABAP - if we run successfully, we will learn the kinds of lazy copying tricks we can get away with, and if we don't we will learn the kinds of these tricks that we can't get away with. To be continued ...
