Since I started blogging again this year, I have been concentrating on two kinds of posts: 1) detailed technical posts such as those in the “event-driven” self-tutorial I’m currently doing on the SAP-delivered component WDR_TEST_UI_ELEMENTS: Part 6a of Event-Driven Tutorial on WDABAP Component WDR_TEST_UI_ELEMENTSIf 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.2) posts which comment on the current SAP mise en scene, e.g:SAP: The Pied Piper of Walldorf?"The Single Secret Will Still Be Man" (ee cummings) Sometimes, however, it is necessary and worthwhile to combine these two kinds of posts, particularly when some detailed technical matter bears on a more general question that is worth discussing and presumably of interest to the SDN community. This post is one of these "combined" posts. On the one hand, I want to talks about Apache Struts/M2 and SAP WebDynpro/MVC, and whether these two paradigms are enough, in and of themselves, to guarantee proper separation of business from presentation logic On the other hand, I want to illustrate my own answer to this "general" question by discussing the more detailed queston of whether the SAP-delivered component WDR_TEST_UI_ELEMENTS does or does not do enough to separate business and presentation logic. (Before continuing, I do want to mention that I was prompted to write this post after attending the TechEd Sessions CD107 and CD108 mentioned above. It was worth the price of admission just to be reminded, for example, that SAP Views are JAVA JSP's, that SAP View Controllers are JAVA Action Form Beans, and that SAP Component Controllers are JAVA Action Beans.) Anyway, some readers familiar with the SAP-delivered component WDR_TEST_UI_ELEMENTS may be scratching their heads and asking themselves the question: what could this component possibly have to do with the question of separating business from presentation logic? After all, WDR_TEST_UI_ELEMENTS is a "techie" component that has nothing to do with "business logic" of the familiar kind, e.g. the "business logic" we find in ERP or CRM or SRM applications. The answer to this queston is: the WDR_TEST_UI_ELEMENTS does have "business logic" in it: logic related to the business area of UI ELEMENTS - their associated attributes and events. Just as SAP's customers are in vertical sectors which require them to deal with traditional business elements such as material numbers, vendor numbers, base prices, cost elements, etc. SAP is in a vertical sector that requires it to deal with business elements specific to the business area of software development. And these days, the business area of software development certainly includes the business logic of UI elements. (If you don't agree with the above paragraph, pleaes take another moment to think about it - I promise I'm not wrong about this.) So, proceeding under the assumption that WDR_TEST_UI_ELEMENTS is, in fact, a specialized kind of business application component that has to deal with the business logic of UI ELEMENTs, the question arises whether WDR_TEST_UI_ELEMENTS does a good enough job of separating business from presentation logic. And the answer to this question is no. In my opinion, the presentation logic of WDR_TEST_UI_ELEMENTS consists in nothing more than the presentation of a detail view selected from an element of a tree view which itself has been selected from a tray view. But if one reads thru Parts 1-6a of my tutorial on this component, one will immediately see all the many places in which this presentation logic has been mixed with business logic within the methods belonging to the component itself, or to its supporting classes CL_WDR_ALL_IN_ONE_UTILS and CL_WDR_ALL_IN_ONE_UI_ELEM. In particular: - in the method which adds trays to the tray view, there is code which makes decisions on which trays to be added based on business properties of different UI libraries and elements; - in the method which adds links to trays, there is code which again makes decisions based on business properties of different UI libraries and elements; - in the method which adds nodes to a given tree-view, there is code which again makes decisions based on business properties of different UI libraries and elements. And it is precisely because of this interpenetration of business and presentation logic that I felt it was important to do a tutorial on WDR_TEST_UI_ELEMENTs - to show that underneath all the apparent complexity of this component is a very simple tray-tree-detail navigation model that can be used over and over again for many purposes. So, if one agrees with what I've said so far, one must also agree with the inescapable concusion that: even when paradigms such as Apache Struts/M2 and SAP WebDynpro/MVC are used within savvy software development companies such as SAP, these paradigms can be violated at will by these companies' own developers. And here's the really interesting question that arises from this conclusion: Can violations of these two "separation" paradigms be eliminated by requiring developers to work "model-down" in tools such as SAP's Visual Comoser rather than in traditional development environments such as SAP's Developer Studio or the ABAP WebDynpro editor of SE80? Why is this question interesting? Because it raises an even more interesting set of questions: Could a component with the same exact functionality as WDR_TEST_UI_ELEMENTS be developed "model-down" in Visual Composer at the present time, and if so, how much code would still have to be written after the model has forward-generated as much code as it can? If not, does SAP envision a time when Visual Composer will be up to this task? If so, how far out in the future? If I were an IT manager charged with making the decision of whether my company should take the Enterprise SOA journey with SAP, these are certainly the questions I'd be asking my counterparts at SAP.
