|
| |
| |
| |
|
|
|
| Free Download SAP Netweaver Books,Projects And Int |
| Action Handlers,Administration,Analysis Process,Authentication,BI Content,Business Management,Business Planning,B2B,Composite Application,Configuration DTD,Content Administration,CPIC AND RFC,Cryptographic Functions,Customizing Activities,DynPro ABAP,Enterprise Portal,EP,ERP System,External-Facing Porta |
| Language: |
| RSS Feeds for this Blog |
|
Statistics |
| Unique Visitors: 19 |
| Total Unique Visitors: 20731 |
| Visitors Out: 139 |
| Total Visitors Out: 139 |
|
|
|
| |
|
|
| |
|
| Using Parameters to Call a Web Dynpro Application |
| 2008-03-24 13:23:15 |
Use The URL parameters of a Web Dynpro application are defined by the main component. The window of a component has one or more inbound plugs, and these may have parameters. If a parameter is defined for an inbound plug, it must be assigned a value at runtime. Usually the URL call will transfer the parameter value to the inbound plug. Alternatively, you can set a default value for this parameter in the Web Dynpro Explorer: Display Application. This will be overwritten at runtime by the value of the URL parameter. If a default parameter is defined in the application, the value is optional. If neither a default value is set, nor a URL parameter transferred, a runtime error is triggered. See also: URL of a Web Dynpro Application Procedure ... ...
|
| |
|
| Web Dynpro ABAP URLs and Namespaces |
| 2008-03-24 13:22:31 |
When you use your own Namespaces (see also Reservation of Namespaces) there are some peculiarities to note with regard to the paths in the ICF Internet service tree and in the MIME repository. When creating your own name spaces follow the rules set out in Defining Naming Conventions. Normally a Web Dynpro application is created in SE80 either in the SAP namespace using its simple name, for example, myapp, or in a customer namespace using the complex name specification, //, for example, /test40p/myapp. Accordingly, the ICF path is under both /sap/ and your own namespace, as in the examples below: Examples Application name ICF Path myapp /sap/bc/webdynpro/sap/myapp /test40p/myapp /sap/bc/webdynpro/test40p/myapp If the ICF path hierarchy in the SAP namespace (/sap/bc/...
|
| |
|
| Web Dynpro Application |
| 2008-03-24 13:21:36 |
Another important task of the window is to establish the connection between the structured view group (or at least one individual view) and a URL that can be called by the user. The window is also a unit called by a user using a Web Dynpro application. In general, only one view is displayed on the screen at a time. In the simplest case, the Web Dynpro application calls the view specified as the start view (default) within the window. The user can navigate from this start view to a subsequent view. The Web Dynpro application is an independent object in the object list of the ABAP Workbench. For more information about creating and editing an application, see the tools manual in the section Web Dynpro Application. For more information about the URL, see...
|
| |
|
| Web Dynpro ABAP Window Plugs: Startup and Exit |
| 2008-03-24 13:21:09 |
Like Web Dynpro views, each Web Dynpro window has inbound and outbound plugs. Any number of these plugs can be defined as startup or exit plugs. Startup Plug The startup plug is a special inbound plug. The Startup property, which you can define on the Inbound Plugs tab page in the window editor, declares for the inbound plug the option to instantiate a component and to start a new application. For this reason a startup plug can be used only if it is also available to the window interface. Components can be accessed by external programs using plugs that were defined as startup plugs. So if you want to create a Web Dynpro application for this interface view, only plugs that can be flagged as startup plugs can be provided for the application. Since at lea...
|
| |
|
| Navigation Between Two Views |
| 2008-03-24 13:20:35 |
All views within a window can be connected to each other using navigation links. When the user calls a Web Dynpro application, the start view is displayed first on the screen. You can trigger a specific action – for example, by clicking a button – which triggers navigation. As a consequence, the previously displayed view disappears from the screen and a second view is displayed. To set up navigation between two views, you must create an inbound plug for one view and an outbound plug for the other view. A plug is always a junction used for accessing or exiting a view. For more information on plugs and navigation links, refer to the architecture manual for Web Dynpro. For a description of the creation and maint...
|
| |
|
| Web Dynpro Window |
| 2008-03-24 13:19:49 |
The previously described simple application example contained a Web Dynpro component with one view only. In the tutorial of this documentation, the instructions include from the beginning the creation of applications with two views which are connected via navigation. This and the following chapter describe the communication between the different views of a component. Each Web Dynpro component contains at least one Web Dynpro window. All views that are to be displayed when using a Web application are embedded in this window. The window is processed in the Window Editors of the ABAP Workbench. The required navigation between the individual views can be set up in the window (see Navigation). The Web Dynpro window contains the structure of all views to...
|
| |
|
| Web Dynpro ABAP Client Implementation |
| 2008-03-24 13:19:16 |
The graphic below gives an outline of the concept of the client implementation: Depending on the rendering device selected, the central part of Web Dynpro runtime works together with a specific client implementation. If a browser is selected, the client implementation is server-side rendering (SSR). SSR then takes on the task of communicating with the client device. View elements are kept in user interface element libraries, see also Web User Interfaces. With Web Dynpro for ABAP, a browser is always used as the rendering device. Data, events, and layout information are converted on the server into HTML and JavaScript and transferred together. In the case of the browser, this is done mostly on the server; for instance, the whole layout is placed on th...
|
| |
|
| Web Dynpro ABAP Phase Model |
| 2008-03-24 13:18:44 |
Purpose This section provides information on the data transport during the request processing. The first request is not described as it only involves the reading of the metadata and the initial display of the user interface. At certain points of the phase model, application developers can influence the user interface layout themselves by programming dynamically. Process Flow The following graphic schematically shows the process flow during data transport: The process flow of event handling is shown in detail in the following graphic: Data Transport from Client to Data Container Data – for example, user input – is transported from the client to the data container. The data container is used for temporary d...
|
| |
|
| Web Dynpro ABAP Filling the Context |
| 2008-03-24 13:18:04 |
The values of the context elements play a crucial role in Web Dynpro for ABAP. Therefore, the filling and changing the context must be thoroughly planned. Depending on when the context is to be filled or updated, you can choose from the following methods. WDDOINIT The method WDDOINIT is the initialization method of the controller. If you know beforehand that the context in your application is only filled once and not invalidated afterwards, this method is appropriate for filling the context. You can also use this method if you want to associate the data update with an action and transfer the update to the corresponding event handler. The method WDDOINIT should only be used to fill those context nodes when it is known that they must be filled. T...
|
| |
|
| Web Dynpro ABAP Runtime APIs |
| 2008-03-24 13:17:28 |
The application developer can use Web Dynpro APIs as a set of interfaces for an efficient design of controller programming. APIs can be accessed in several ways. For a complete list of all classes and interfaces of the framework and the access methods, refer to the reference manual in this documentation. The runtime interfaces offer multiple methods for different programming areas. These include, for example: · Access to the window manager API IF_WD_WINDOW_MANAGER for creation of popups using existing Web Dynpro windows · Access to the portal integration API IF_WD_PORTAL_INTEGRATION · Context processing · Creating messages More areas apply when using dynamic programming. Examples: · Dynamic manipulation of the layout · Dynamic naviga...
|
| |
|
| Web Dynpro ABAP Cross-Controller Method Call |
| 2008-03-24 13:16:49 |
The Web Dynpro framework enables the application developer to develop source code beyond the controller boundaries. The example of the previous chapter Action Event Handlers is used again to explain the procedure: In the chapter Context Mapping, a cross-view context in the component controller and the required mapping for the example component have already been created. Now, the functions of the event handler of the action GO are to be transferred to a method of the component controller. Method of the Component Controller In this example, the method is called SIMPLE_GET_FLIGHTS: method SIMPLE_GET_FLIGHTS. data: INPUT_NODE type ref to IF_WD_CONTEXT_NODE, TABLE_NODE type ref to IF_WD_CONTEXT_NODE, CAR type STRING, FLIGHTS type standard table of SPFLI....
|
| |
|
| Free Methods in Application Development Web Dynpro ABAP |
| 2008-03-24 13:16:13 |
As an application developer, you can create and implement your own methods for each controller. These self-defined methods are typically used to read and edit data. These methods can be called within the controller by other methods that are also implemented by the application developer. Example In the following example, the GET_FLIGHTS method has been implemented to read data from the back end for the current controller. This data is to be used in the second method of the same controller. method GET_FLIGHTS . . . endmethod. method FILL_CONTEXT_NODE . data: FLIGHTSTRUC type SPFLI. MY_NODE type ref to IF_WD_CONTEXT_NODE. FLIGHTSTRUC = WD_THIS->GET_FLIGHTS( ). MY_NODE ...
|
| |
|
| Web Dynpro ABAP Supply Function |
| 2008-03-24 13:15:31 |
Each context node of a controller can be assigned a supply function. This supply function is called by the runtime when the data of the context node is used. This is the case when a UI element is to be displayed for the first time with the data of the corresponding context, for example. In general, the supply function is called when one or more elements of a context node are accessed and when ● the context node is not filled yet or is initial, or ● the context node has been invalidated in a previous step. Supply Functions of Singleton Nodes The supply function is especially useful in combination with singleton nodes: The values of subnode elements of the type Singleton depend on the element of the pare...
|
| |
|
| Events and Event Handlers Web Dynpro ABAP |
| 2008-03-24 13:14:24 |
You can define events for a component controller to allow cross-controller communication. These events can then be triggered using the predefined method FIRE__EVT. Once the event is triggered, the corresponding event handler is automatically called in another controller by the runtime. A usage of the component controller must be entered in the current controller to handle an event of a component controller. (The usage of the component controller within a view controller is automatically created.) The following graphic shows an example in which a method of the component controller triggers the event MY_EVENT. The event handler MY_HANDLER of a view controller responds to the event MY_EVENT, because this event of the component controller is assig...
|
| |
|
| Predefined Methods of the Local Controller Interface Web Dynpro ABAP |
| 2008-03-24 13:13:35 |
Each controller contains an additional set of methods provided by the runtime. They can be used for developing applications. You cannot change the implementation of the methods – unlike the implementation of all the other controller methods. The content of the method set depends on the controller type and its implementation state. Some of these methods are described in more detail below. Method WD_GET_API This method contains all controller types. Depending on the controller type this method returns a reference variable of the associated type to the controller. 1. Ig_Componentcontroller 2. value(Result) type ref to IF_WD_COMPONENT 3. If_“View_Name“ 4. value(Result) type ref to IF_WD_VIEW_CON...
|
| |
|
| Hook Methods: Methods Called by the Runtime Web Dynpro ABAP |
| 2008-03-24 13:10:43 |
Along with the previously mentioned application methods, each local controller interface has a fixed number of methods that can only be called by the runtime. The application developer cannot specify when these methods are called, but can modify the implementation. The time when these methods are called is predefined. For a description, refer to the phase model of Web Dynpro. WDDOINIT and WDDOEXIT The simplest examples are the methods WDDOINIT and WDDOEXIT. WDDOINIT is called automatically when a controller is initialized for the first time. For each newly created controller, these methods are empty but can be filled with source code. These methods can contain the following steps, for example: ● Creating instances of help classes ● Init...
|
| |
|
| Methods of the Local Controller Interface |
| 2008-03-24 13:09:56 |
All methods that can be changed - that is, methods that can be implemented by the application developer - are listed on the Methods tab of each controller. When double-clicking the method name, you switch to an ABAP Editor which enables you to implement the source code. In addition to the changeable methods, the local interface of each controller provides several methods which can be used but whose implementations cannot be edited by the application developer. It depends on the type and the implementation state of a controller when these methods are available in the interface. Since all methods of this group cannot be changed, they are not displayed on the Methods tab of the corresponding controller. As a part of...
|
| |
|
| Reference Variable WD_THIS and Local Controller Interface |
| 2008-03-24 13:09:14 |
Each controller contains a local interface which can be accessed in the controller. The controller attribute WD_THIS is a reference to this local interface. Depending on the controller, a reference variable is of the following type: · IF_COMPONENTCONTROLLER · IF_ · IF_ · IF_ The methods and attribute of the local controller interfaces can be accessed using these reference variables. · Included are all self-defined methods that have been created and implemented by an application developer for the current controller. Since the application developer can change the implementation, these methods are listed on the tab Methods of the Controller Editor. You switch to the ABAP editor for adding source code by...
|
| |
|
| WD_CONTEXT Reference Variable |
| 2008-03-24 13:08:39 |
WD_CONTEXT The WD_CONTEXT attribute is a reference to the root node of the context of the controller. Regardless of the edited controller, it is always a reference variable of the type IF_WD_CONTEXT_NODE. You can use WD_CONTEXT and the interface methods to edit the content of a context node in your controller method. Example The controller context contains the MY_TABLE_NODE node. You can use the INVALIDATE_TABLE_NODE method to invalidate the values of the node elements. method INVALIDATE_TABLE_NODE . data: TABLE_NODE type ref to IF_WD_CONTEXT_NODE. TABLE_NODE = WD_CONTEXT->GET_CHILD_NODE( 'MY_TABLE_NODE' ). TABLE_NODE->INVALIDATE( ). endmethod. GET_CHILD_NODE and INVALIDATE are methods of the IF_WD_CONTEXT_NODE inte...
|
| |
|
| Web Dynpro ABAP Programming Controller Methods |
| 2008-03-24 13:08:01 |
In general, attributes and methods are used to specify the processes of programs in Web Dynpro applications and to edit the data contained in the context. The previous sections, Action Event Handlers and Cross-Controller Method Call, described simple examples of these program processes. In this section, you find general information on programming using methods of the Web Dynpro framework. In addition, frequently used methods are described and illustrated by source code examples. For further information on specific controller methods, refer to Controller: Methods in the tools manual and Programming Interfaces in the reference section of this documentation. When you create a new Web Dynpro component, a component con...
|
| |
|
| Web Dynpro ABAP Context Mapping |
| 2008-03-24 13:07:22 |
Data stored in the context of the component controller can be used within a view if you link the node of the view context to the corresponding context node of the component controller. This procedure is called “defining a mapping”. For further information, refer to the chapter Data Binding and Mapping in the architecture manual for Web Dynpro. The following graphic illustrates the principle of the procedure: The context of View 1 of the example in the graphic contains two nodes below the root node: ● The node Node 1 is mapped to the node of component controller context of the same name. This means that the structure within the node matches the structure within the node of the component controller or the structure is contained in it. At a...
|
| |
|
| Web Dynpro ABAP Component Controller |
| 2008-03-24 13:06:49 |
Each Web Dynpro component contains exactly one component controller. This controller is automatically created during the component creation and contains a context, events, and methods. Unlike a view controller, the component controller is visible for all views in a component. This means, the controllers of different component views can access context elements or methods of the component controller. For this purpose, the component controller usage is automatically created for every view controller. This makes the component controller a central location for data exchange between different views of one component. The Web Dynpro framework provides the mechanism of context mapping which is a declarative tool to easily perform this data exchange. In addition, the component controller allows ...
|
| |
|
| Web Dynpro ABAP Action Event Handlers |
| 2008-03-24 13:06:17 |
If an action of a UI element is triggered on the user interface of a Web Dynpro application, the event handler of the view controller linked to this action is automatically called. In the event handler, the application developer adds the source code for the steps that will trigger the action. Examples for these steps: · Reading, editing, and resetting context elements · Calling function modules · Triggering navigation Programming From a technical point of view, an event handler differs from other controller methods only in that it also responds to the event assigned to the event handler. For programming all controller methods, you can choose from several special classes with attributes and methods used to execute the processing steps specific to Web Dynpro. The...
|
| |
|
| Web Dynpro ABAP Parameter Mapping |
| 2008-03-24 13:05:27 |
Parameter mapping is used for multiple use of actions. If you use one action for several events - for example, multiple buttons - you require unique information to specify the desired assignment. You can get this information using parameter mapping. We do not recommend that you pass the standard parameter ID (see below), because in this case, actions and UI elements cannot be clearly separated. Parameter mapping is performed by a program: DATA PARAMETERS TYPE WDR_NAME_VALUE_LIST. DATA PARAMETER TYPE WDR_NAME_VALUE. DATA data_ref TYPE REF TO data. FIELD-SYMBOLS TYPE any. " Parameters can be simple values PARAMETER-NAME = 'LINES_TO_INSERT'. PARAMETER-VALUE = '3'. PARAMETER-TYPE = CL_ABAP_TYPEDESCR=>TYPEKIND_STRING. INSERT PARAMETER INTO TABLE PARAMETERS. " Paramet...
|
| |
|
| Web Dynpro ABAP UI Element Actions |
| 2008-03-24 13:04:38 |
Several UI elements contain actions. Actions are special events and are triggered by activities of the user on the user interface of an application. Corresponding event handlers specify the subsequent processes of the application. The following example illustrates the procedure: You create an action for UI element Button. In the event handler method of this action, you specify the response of the application when the user selects the UI element Button. An action is always linked to exactly one event handler method. In some cases, however, you might want to simultaneously use the same action for multiple UI elements in a view. For more information on the required parameterization for multiple-use actions, refer to Parameter Mapping. Creating Actions ...
|
| |
|
| |
 |
