If a house is well-built, its details can be readily rearranged (DynamicRoadMaps:Part 8)
In Part 7 of this tutorial: “Complex-looking” code is sometimes the “simplest” (Dynamic RoadMaps:Part 6) “Complex-looking” code is sometimes the “simplest” (Dynamic RoadMaps:Part 6) 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 Generation Might Be the Right Way to Go we learned how to change the RoadMap display of the SAP-delivered component WDR_TEST_UI_ELEMENTS so that it looks like this: Figure A: instead of this: Figure B: What we now want to do is accomplish the objectives stated in SAP UI Element Metadata: Gold or Fool’s Gold? (Part 3 of Dynamic RoadMap Tutorial) of this tutorial: Objectives 1a-b: When the Document Numbers by Cost Center link is selected from the lefthandside Programming Trees tray, we want the initial righthandside navigation tree to look like this: Figure C: and the middle display to look like this: Figure D: (Note that no RoadMap is displayed at this point.) Objective 2: Then, when a lower-level node is selected from the righthand side navigation tree, e.g. the task “2.1 Construct object number for each cost center”, we want the middle display to show a RoadMap with more detail on this task, like this: Figure E: To accomplish Objectives 1a-b and 2, it will not be enough just to modify existing code “in-place” – we will have to move some things around in the methods of our local copy ZCL_WDR_ALL_IN_ONE_UIELEM. The reasons why we have do move some things around are as follows. First, it should be clear from Parts 1-7 of this tutorial that the original methods of CL_WDR_ALL_IN_ONE_UIELEM are designed so that the nodes of the righthand side navigation tree are chosen according to the items we are selecting as we build the type of UI Element chosen from the tray-links on the left. (For example, if we choose the RoadMap link on the left, then the righthand tree displays the items involved in building a RoadMap.) But in our local copy ZCL_WDR_ALL_IN_ONE_UIELEM, the tree we build on the right will be built from a metadata table that has nothing to do with UI Elements. And therefore, we will have to remove the “tree-building” logic out of the create_settings, create_aggregations and create_aggregatee methods and into the create method of our local copy ZCL_WDR_ALL_IN_ONE_UIELEM (or some method called by the create method.) Second, when the action-link Document Numbers by Cost Center is chosen, we don’t want any RoadMap to display right-away – just the navigation tree on the right (as shown in Figure “D”. So we will also have to move our logic for building RoadMaps out of the create_settings, create_aggregations and create_aggregatee methods of our local copy ZCL_WDR_ALL_IN_ONE_UIELEM and into the on_select_view_element method (or some method called by this method.) (By placing our RoadMap code in this method, we are guaranteed that the existing navigation logic of the original component CL_WDR_ALL_IN_ONE_UIELEM will correctly tell us what lower-level node has been selected from the navigation tree on the right, and what RoadMap we want to build for this node.) Details on the above will be presented in Part 9 of this tutorial, but right now, it’s more important to understand the general approach that has to be taken to modify the original component, and that’s why the summary of this approach is presented above. Note: what we will do in Part 9 of this tutorial is very similar to what we did in Parts 5-10 of the preceding tutorial on CL_WDR_ALL_IN_ONE_UIELEM: Learning what you don’t need is as important as learning what you do (Parts 10b-c) of “Event-Driven” Tutorial on WDR_TEST_UI_ELEMENTS) As James Carville said to Bill Clinton in 1992: “It’s the indices, stupid” (Part 10a of “Event-Driven” Tutorial on WDR_TEST_UI_ELEMENTS) An Archaeological “Dig” into SAP Metadata (Part 9 of “Event-Driven” Tutorial on WD-ABAP Component WDR_TEST_UI_ELEMENTS) When Presentation and Business Logic are Jumbled, Even Minor Housekeeping is Trickier Than It Should Be (Part 8 of Event-Driven Tutorial on WDR_TEST_UI_ELEMENTS) Sieving Presentation from Business Logic When the Business Application Area is Software Development (Part 7 of “Event-Driven” Tutorial on SAP-Delivered WDABAP Component WDR_TEST_UI_ELEMENTS) Apache Struts/M2 and SAP WebDynpro/MVC: Can these paradigms alone guarantee separation of business and presentation logic? (Part 6b of Tutorial on WDR_TEST_UI_ELEMENTS) Part 6a of Event-Driven Tutorial on WDABAP Component WDR_TEST_UI_ELEMENTS If you’ve written something in SAP from scratch, you (probably) haven’t bothered to understand what someone else has already done (Part 5 of “Event-Driven” Tutorial on WD-ABAP Component WDR_TEST_UI_ELEMENTS) So readers who really have a serious interest in this stuff should review these posts and particularly the material having to do with the create_lgcldb_tree, create_lgcldb_nodes, and fill_lgcldbs_trays methods: what these do and where they have been placed.