In my last post, I lamented the fact that recursion nodes do not currently repeat the table-carrying properties of the nodes they repeat. I do not recant this lament, because there is no apparent reason for this limitation. (Since the "repeated" node will itself occur multiple times in the resolved tree-structure at run-time, and each of its occurences will be properly bound to its embedded table, I see no reason why a recursion node can't be properly bound in the same way.) On the other hand, I want to report an easy work-around because the way I found this work-around illustrates how the SAP-delivered WDR_TEST_EVENTS and/or WDR_TEST_UI_ELEMENTS WD-ABAP components can successfully be used as a fastpath index to the work-around you need. After I hit the limitation on recursion nodes reported earlier, I said to myself - well - the SAP folks are smart people so there must be something they've provided that will solve this problem. But - like all good programmers, I hate reading documentation until I have to. (This is the reverse of the old saying, "Good programmers don't document - if it was hard to write, it SHOULD be hard to understand.") Plus, unless a vendor's documentation is replete with screenshots, you can't always tell from documentation if the end-result of a programming approach is what you really want or not. So I started scanning WDR_TEST_ELEMENTS/UI_ELEMENTS looking for anything related to tree structures with tables and I found a view called "TABLE_TREE_BY_KEY" which smelled suspiciously like what I needed for my work-around. Upon consulting the relevant WD-ABAP documentation (page 782, I think), I found that it referenced a separate component called "WDT_TREE_TABLE_BY_KEY", and sure enough, this was the control-structure I needed for my work-around. It was quite easy to clone this component and modify its "GENERATE_DATA" method to do exactly what I needed to do. This little saga illustrates another point as well - it is not wise to assume that SAP has provided examples of a given control structure in only one place. To the contrary, if one looks around a little, one can usually find a "simpler" example than the one that is confusing you. For example, the "supply function" of the stand-alone WDT_TREE_TABLE_BY_KEY component is much easier to understand than the "supply function" of the TABLE_TREE_BY_KEY view in the WDR_TEST_EVENTS component because the latter deals with mimes and paths and all that geeky BellLabs stuff that any self-respecting programmer has been brought up to dislike intensely. Anyway, two minor technical digressions may be useful to others out there, so I will close with them. Digression 1. In an earlier blogpost, I showed how to use SETNODE and SETLEAF to generate a control structure which will actually allow you to write your own report writer that will generate standard control-break (group by/total on) output for ANY arbitrary hierarchy that you've created in SETNODE/SETLEAF via transactions like GS01 or KAH1. (Or for that matter, for any arbitrary hierarchy you've created using any methodology at all.) If you create a custom Ztable to store the control structures you generate, you can rapidly access them from WD-ABAP "tree_table_with_key" views to load your tree strucute quickly and correctly. For example, this is all the code you need to load a "tree_table_with_key" from a custom Ztable that already has the nodes of hierarchy tagged with "Dewey Decimal" indices like 1.1, 1.1.1, 1.1.2, 1.2, etc. (Of course, if your Ztable stores more than one hierarchy, you'll need to beef-up your select a little so that it chooses nodes from the correct hierarchy.) ******************************************** method generate_data . * Note: ZSETNODE structure/table is: * ZDEWDEC: Dewey Decimal index of node in hierarchy * ZLEVEL: Level of node in hiearchy * ZMAX: Y if node is leaf, N if not * ZSUBSETNAME: name of node in hiearchy * ZSETNAME: name of parent node in hierarchy * ZRIGHTMOST: Y if node is rightmost child, N if not * ZHAVEDATA: used at runtime to tag non-rightmost nodes * that have data, so their data can be totalled upward. * Note: two alternative indices are placed on ZSUBSETNAME * and ZSETNAME, for obvious reasons. types: begin of Element_Table_Data_Source, ROW_KEY type String, PARENT_ROW_KEY type String, TREE_COLUMN_TEXT type String, TABLE_COLUMN_1_TEXT type String, TABLE_COLUMN_2_TEXT type String, EXPANDED type Wdy_Boolean, IS_LEAF type Wdy_Boolean, end of Element_Table_Data_Source, Elements_Table_Data_Source type standard table of Element_Table_Data_Source with default key. data: row TYPE Element_Table_Data_Source, lt_rows TYPE STANDARD TABLE OF Element_Table_Data_Source, rw_zsetnode TYPE zsetnode, lt_zsetnode TYPE STANDARD TABLE of zsetnode, v_mlevel TYPE i, v_cntr TYPE i. SELECT * FROM zsetnode INTO TABLE lt_zsetnode. LOOP at lt_zsetnode INTO rw_zsetnode. row-row_key = rw_zsetnode-zdewdec. IF rw_zsetnode-zlevel = 1. row-parent_row_key = ''. ELSE. SELECT SINGLE zdewdec FROM zsetnode INTO row-parent_row_key WHERE zsubsetname = rw_zsetnode-zsetname. ENDIF. row-tree_column_text = rw_zsetnode-zdewdec. row-table_column_1_text = rw_zsetnode-zsubsetname. row-table_column_2_text = rw_zsetnode-zsetname. IF rw_zsetnode-zmax = 'N'. row-is_leaf = abap_false. ELSE. row-is_leaf = abap_true. ENDIF. insert row into table lt_rows. ENDLOOP. node->bind_table( new_items = lt_rows ). endmethod. ************************************************** Digression 2. It appears from the SAP examples that row_key and parent_row_key MUST be "Dewey Decimal" ("lexicographic")indices in which the index of a parent is the leading portion in the index of all of its immediate children. Now this is a time-honored programming technique - it was documented by Seymour Ginsburg in his 1965 textbook on the mathematical theory of context-free programming languages, and when I once asked Donald Knuth who was responsible for this notion of a "Dewey Decimal tree", he said that the answer to that question is buried in the mists of time - it was such an obvious notion that no one bothered to take credit for it. But on the other hand, it's a limited programming technique which should be discouraged because it can be dangerous. For example, at a previous client engagement, I found that the client's programmers had written all kinds of ABAP based on the assumption that WBS elements were related to their WBS sub-elements lexicographically instead of using the correct SAP-provided look-up table to find the parent-child relations among WBS elements. And you can imagine what will have to happen to all that code if management decides it needs a more flexible set of naming conventions for WBS and sub-WBS elements. So, because I have seen lexicographic indices misused in this way many more times than once, I'd like to suggest that SAP change its implementation of "tree tables by key" so that parents and their childrens are explicitly related by an internal control table, rather than implicitly by lexicographic indices. That way, row_key and parent_row_key would no longer have to be artificial Dewey Decimal indices, but simply the names of nodes in your hierarchy (as they are, for example, in SETNODE and SETLEAF.) (Of course, to do an arbitrary report writer of the type mentioned above, it is still convenient to carry a Dewey Decimal node index because it allows you to chase your hierarchy rightward and upward with much less code.)
