We have seen designing the view constituent of the MVC application design that generates XSD in the blog Unleashing ABAP Webdynpro for generating XSD in SAP XI-Episode 1 and control constituent in the blog Unleashing ABAP Webdynpro for generating XSD in SAP XI-Episode 2.Read through the blogs if you haven’t yet. Iam sure you will understand it very well as I structured the way I hunted while developing my WebDynpro Application. With this blog the entire MVC design of Webdynpro in SAP XI NW 2004S is complete that makes me relax from scripting protracted blogs.
We have seen the design of UI elements, Context Structures, Associating events for user actions and binding them to the UI elements. Here we see how we can use these structures as an interface between model and the view. In short the application logic of the illustration. We take the same illustration of generating XSD when user inputs database table and presses the FETCHXSD button.
Before we march ahead further it is worth understanding the usage of default attributes and methods that are automatically generated while designing the view and control constituent of the MVC application. We use this info while modelling the illustration. You can see them by double clicking the INITIALVIEW and navigating to the attributes and methods Tab on the right hand pane. The usage of the attributes and methods of the view is clearly depicted below.
The logic of generating a XSD from the database table name is already revealed in the blog Generate XSD . In the old blog the application code is embedded in an RFC but here we use the same logic in the method FETCH_XSD_ABAPTAB of the INITIALVIEW.
1.Create Application Logic Method FETCH_XSD_ABAPTAB :
Create the method FETCH_XSD_ABAPTAB by clicking the method tab of layout and pressing the insert button. FETCH_XSD_ABAPTAB uses i_abap_table_name as an importing parameter and E_XSD as an exporting parameter. This is the application/modelling logic that is used for converting ABAP Table name into XSD.
2.Link Application Logic Method FETCH_XSD_ABAPTAB to User Event Method ACTION2FETCH_XSD:
Now we have link the view and model. The application logic has to be triggered only when the input table name is fed by the user and FetchXSD button is pressed. So the application logic method FETCH_XSD_ABAPTAB is triggered only when the event ACTION2FETCH_XSD that is created previously in the control constituent is triggered.
Go to Action tab on the right hand pane of the InitialView and open the ACTION2FETCH_XSD event method for writing the source code. Alas! Before we write the source code we have create a temporary context node attribute TEMP_CNODE for the view INITIALVIEW to get and set context attributes at the runtime.
After creating the attribute paste the source code given below and save the event method ACTION2FETCH_XSD.
Source Code Extract:
I don’t like to fish for a person but rather teach how to fish which will be beneficial for the person in a long run. So by just giving the source code to the reader he can just create this application. But I want him to create more applications. Now let me explain the source code extract and the usage of API’s.
Before we understand the usage let us memorize the context structure created in the episode. We had created 2 context structures for input and output in the Episode 2.
1. Nodes : TABLE_DUMP, XSD_DUMP.
2. Attributes : DBTAB_NAME , DBXSD_NAME.
Source Code explantation: Explanation for Lines (1-3):
DATA TAB_NAME TYPE DCXMLTYPNM-TABNAME.
DATA E_XSD TYPE STRING.
WD_THIS->TEMP_CNODE = WD_CONTEXT->get_child_node( name = 'TABLE_DUMP' ).
Local data TAB_NAME and E_XSD for the event method ACTION2FETCH_XSD is created to get and set the context attributes at the runtime when user presses the FetchXSD button. WD_THIS is a reference pointing to the current view where event handler method is triggered. WD_CONTEXT is another reference pointing to the context of the current view. Line3 gets the reference to the context node TABLE_DUMP. WD_THIS->TEMP_CNODE contains the node reference to TABLE_DUMP.
Explanation for Lines (4-5):
WD_THIS->TEMP_CNODE->GET_ATTRIBUTE (EXPORTING name = 'DBTAB_NAME’ IMPORTING value = TAB_NAME).
CALL METHOD FETCH_XSD_ABAPTAB (EXPORTING I_ABAP_TABLE_NAME = TAB_NAME IMPORTING E_XSD = E_XSD ).
Line 4 fetches attribute value DBTAB_NAME of the node TABLE_DUMP.Line 6 passes the attribute value DBTAB_NAME to the application logic method FETCH_XSD_ABAPTAB. Local variable E_XSD contains the resultant XSD that is passed back by the application logic method FETCH_XSD_ABAPTAB.
Explanation for Lines (6-8) :
CLEAR WD_THIS->TEMP_CNODE.
WD_THIS->TEMP_CNODE = WD_CONTEXT->get_child_node (name = 'XSD_DUMP’).
CALL METHOD WD_THIS->TEMP_CNODE->SET_ATTRIBUTE
EXPORTING
VALUE = E_XSD
NAME = 'DBXSD_NAME'.
Line 6 deletes the object node reference pointing to TABLE_DUMP.Line 7 sets temporary context node reference to XSD_DUMP.Line 8 uses the node reference of line 7 to set the context attribute DBXSD_NAME from the resultant XSD of the application logic method FETCH_XSD_ABAPTAB.
Simple Code! Isn’t it? Imagine writing a traditional module pool for this! Save and embed the view onto a window and follow the same procedure for creating and testing like any other WebDynpro Application. Please don’t ask me to jot even that down here.
3 Comments
