Parts 1-5 of this tutorial: If you've written something in SAP from scratch, you (probably) haven't bothered to understand what ... Part 4 of "Event-Driven" Tutorial on the WD-ABAP Component WDR_TEST_UI_ELEMENTS. "Procedural" Recap of What's Been Learned So Far in "Experiential" ("Event-Driven") Tutorial on WD-A... The class infrastructure of WDR_UI_TEST_ELEMENTS is exquisite for lazy cloning and change-ups. Experiential vs Procedural Tutorials: "Breaking" WDR_TEST_UI_ELEMENTS to Learn From It. have concentrated on sharing my surprise and pleasure at learning for myself how easy it is to modify what appears to be a very complex SAP-delivered WD-ABAP component, in the hopes that others will be encouraged to "dig in" and go through the same kind of "event-driven" self-tutorial using an SAP-delivered WD-ABAP component of their own choosing in order to produce a new WD-ABAP component that accomplishes some real-world objective. For that reason, I have not been clear about the real-world objective I'd like to achieve with the new WD-ABAP component that I'm building in this tutorial. That is, I've explained that I want to build a generic component for displaying a detail view from a tree-view from a tray-view, but I haven't explained why I'm choosing a detail view, tree-view, and tray-view that provides information on SAP metadata constructs such as Logical Databases, Report Sets/RW Reports, and what I call "Programming Trees". In the Tech Ed06 SDN Day presentation I gave today, I came clean on this hidden agenda, and a member of the audience asked me if I was going to blog this agenda here at the SDN blogsite itself. I told him it hadn't occurred to me, because I was focussing on the developmental "rip-off and bastardize" process itself, and not the end-result of this process. But in thinking about it, I thought maybe it might be useful to outline this agenda explicitly, so that it will be clearer why I'm doing what I'm doing as the tutorial proceeds to its conclusion. So here are the slides from my SDN Day presentation; all of the points made in these slides are certainly open to debate, but I don't think any of them can simply be "hand-waved" - not by anyone who really understands what Enterprise SOA requires and what it doesn't permit, e.g. a menu option that says "execute in background". (Well technically I guess it's true that there's no reason why you can't submit a background job from a WD-ABAP component, but it seems to me this would kind of defeat the purpose of writing a WD-ABAP component to begin with ... I mean, you never see a Google modal dialog box which says "Results of your search will be ready by 10AM tomorrow at http://etc"). 
