Escolar Documentos
Profissional Documentos
Cultura Documentos
Course Contents - 1
Module 4 View Controller and View Context Context Node Elements Component Controller Module 4a - Exercise Populating Table control Module 5 Node Cardinality Module 5a Exercise Node Cardinality Module 6 Context mapping between views Navigation Context Node at Design Time Module 6a - Exercise Navigation
Description : In this course you will explore the various concepts and practical examples related to ABAP Web Dynpro
Course Contents : Module 1 - Theory ABAP Web Dynpro Architecture Technical Features Main Benefits Module 2 - Introduction Web Dynpro Development Web Dynpro Component Architecture Web Dynpro Components Views Windows and UI Elements Defining View Layout Layout Types UI Element Categories Module 2a - Exercise Introductory example Module 3 Controller and Context Controller Types Controller Entities
Course Contents - 2
Module 11a Exercise Adaptation of Web Dynpro Applications - Configuration Controllers Module 12 Exercise Window Controllers Module 13 Exercise Integrating a PDF Form in a Web Dynpro Component Module 14 Exercise Working with Dialog Boxes Module 15 Exercise Input Help Module 16 Exercise Portal Integration Module 17 Exercise Business Graphs
Module 7 Supply Function of a Context Node Module 7a Exercise Supply Function Module 8 Exercise Messages and Error Handling Module 9 Dynamic Programming Module 9a - Exercise Dynamic Programming Adding UI elements Changing properties of UI elements Module 10 Web Dynpro Component Interface Module 10a - Exercise Creating a Web Dynpro Component Interface Definition Module 11 Adaptation of Web Dynpro Applications
Definition Web Dynpro is the SAP NetWeaver programming model for user interfaces (UIs). The Web Dynpro model is based on the Model View Controller paradigm, and has the following features that build on the classic dynpro model: Clear separation of business logic and display logic Uniform metamodel for all types of user interfaces Execution on a number of client platforms Extensive platform independence of interfaces Web Dynpros main goal is to enable application developers to create powerful web applications with minimum effort using descriptive tools in a structured design process.
Web Dynpro uses a declarative, language-neutral meta model for defining a user interface.
Technical Features
Web Dynpro provides technical features for Internationalization Flicker-free interaction Clean separation of business logic and the UI. This is achieved through a modified implementation of the Model View Controller (MVC) design paradigm.
Main Benefits - 1
Main Benefits - 2
Layout Types
Flow Layout Grid Layout Left to right, across the screen Arranged by number of columns (e.g. colCount = 4)
Matrix Layout Number of columns not fixed. Each element can be specified for which row and which column. Need to specify new row items. (MatrixHeadData) Row Layout Row by row. Need to specify new row items. (RowHeadData)
UI Element Categories
Exercise
Controller Types
There is only 1 component controller per Web Dynpro component. The component controller drives the functionality of the entire component. This controller has no visual interface. Custom Controllers These are optional. They have to be defined at design time. Multiple custom controllers can be defined in a component Configuration Controller This is a special custom controller, used for configuration and personalization functionality. View Controllers Each view consists of the layout part and exactly 1 view controller. This controller cares for view-specific logic, like checking user input and handling user actions Window Controllers Each window has exactly 1 window controller This controller can be used to care for the data passed via the inbound plugs Methods of this controller can be called from the inbound plug methods of the window.
Controller Entities - 1
Common Controller Entities 1. Methods 1. Standard Hook methods For all controllers, there exist methods that are called in a predefined order by the Web Dynpro framework. 2. Instance methods Can be defined using the Methods tab 2. Attributes not related to the value or property of UI elements can be declared using the Attributes tab. These attributes are then visible in all methods of this controller. There are 2 predefined attributes: WD_THIS Used to access functionality of the controller WD_CONTEXT - Used to access functionality of the context 3. Properties For information to be shared between different controllers, one controller must declare the use of another controller.
Controller Entities - 2
Special Entities of Component/Custom Controllers Events can be defined with arbitrary parameters. Any method of any controller can register to these events if this method is defined as an event handler method.
Special Entities of View Controllers Navigation Plugs For navigation to take place between different Web Dynpro view controllers, special navigation events and navigation event handlers have been created. These are called Navigation Plugs. A navigation event is raised when an outbound plug is fired. An inbound plug is the navigation event handler that can be registered to a navigation request. Special Entities of Window Controllers Navigation Plugs
Hook Methods
Applicable To Component Controller and View Controller Function Initialization Method of Controller
Prepare Output Error Handling Before Navigation Through Application Handling for Suspending and Resuming an Application Method for Validation of User Input Method for Modifying the View Before Rendering (Refresh) Cleanup Method of Controller
WDDOAPPLICATIONSTA Component TECHANGE Controller WDDOBEFOREACTION WDDOMODIFYVIEW WDDOEXIT View Controller View Controller Component Controller and View Controller
Component Controller-1
Component Controller-2
Each component has its own Component Controller The Component Controller has its own context Context nodes of the component controller can be mapped to nodes with similar structure of other controller contexts e.g. view controllers This allows the distribution of data between different views and controllers Mapped nodes automatically contain the same data without copying because they hold references to one source The Component Controller also contains methods for central tasks of the component, for example methods which encapsulate all interaction to the underlying business logic The model which represents the business logic can be a API based on ABAP Objects, BAPIs, RFS or function modules If an application consists of several WD components the interaction of one WD component to a used sub component is also done via the Component Controller
Component Controller-3
In a typical example the Component Controller contains a method to retrieve data from the model and context nodes which are filled by these methods The context nodes of the Component Controller are mapped to the context nodes of the view controller which are bound to visible UI elements
Component Controller-4
The component controller provides data and processing logic that it should be possible to display or change for all views of a component. It has three interfaces: Interface IF_<controller_name> for coding within the controller Interface IG_<controller_name> for cross-controller coding within the current component. Interface IWCI_<component_name> for cross-component coding. On the ABAP language level it represents the interface controller
The view controller contains the event handlers which steer the behavior of the view, for example: Initialization events which are called when a view is displayed for the first time Action handlers which are triggered by UI elements like a button click or drop down list box selection In general the coding of the controller methods access the context data and not the UI elements directly.
Exercise
Problem: Create a table control and populate it with data for the carrier specified in the input field.
Node Cardinality
The number of elements in a node collection can be controlled using the property known as cardinality. This property is actually the combination of two values that, taken together, define the maximum and minimum number of elements the node collection may contain at runtime. The two values are the: Cardinality Minimum: 0 or 1 Cardinality Maximum: 1 or n There are four permutations for these values (specified as <min>..<max>):
Zero or one elements permitted Zero or more elements permitted One and only one element permitted One or more elements permitted
For those nodes that have their cardinality minimum set to 1, then the node collection will be instantiated such that it already contains a single, empty element. This element is known as the default element. For those nodes however, that have their cardinality minimum set to 0, the node will be instantiated with an empty collection. The Web Dynpro developer must write the code to first create and then insert the first element into the collection.
Exercise
1. Change the cardinality to 0..n and do not write any code to fill the table 2. Change the cardinality to 1..n and do not write any code to fill the table 3. Change the cardinality to 0..1 and do not write any code to fill the table 4. Change the cardinality to 1..1 and do not write any code to fill the table 5. Change the cardinality to 0..n and write code to fill the table 6. Change the cardinality to 0..1 and write code to fill the table
Attributes
Reference to
controller context local interface
IG_COMPONENTCONTROLLER
The mapping of context nodes can also be used to transport data from one view controller to another view controller. In this case the context nodes of both view controllers are mapped to the same context node of the component controller.
Outbound Plugs Calling an outbound plug method causes a navigation event to be raised. Navigation events are special, asynchronous events that are placed into a navigation queue. Only when all the outbound plugs have been called by all the views in the current view assembly, will the Web Dynpro Framework enter its navigation processing phase. Outbound plugs should be named according to the action that caused navigation away from the current view. Inbound Plugs Inbound plugs are special event handler methods that subscribe to navigation events raised when outbound plugs are fired. Inbound plug methods are called only when the navigation queue is processed. This will only take place once all the views in the current view assembly have fired their outbound plugs and no validation errors have occurred that would cause navigation to be cancelled. Inbound plugs should be named according to the reason for which the view being displayed. Links Outbound and inbound plugs are joined together using navigation links.
Exercise
Navigate back and forth between 2 views. Also, pass values between the 2 views.
Singleton
Unlike the cardinality of a node, which describes the number of possible elements within the node, the singleton property determines whether or not these elements are set for all elements of the parent node (non-singleton) or for exactly one element of the parent node (singleton). The singleton property of a context node describes the relationship between a child node and its immediate parent. The current contents of a sub node can be kept or deleted if the lead selection of the parent node changes. This is steered by the Singleton property of the sub node. If the sub node is declared as Singleton the old node content is deleted and the sub node is filled freshly via the supply function every time the lead selection of the parent node changes, even if it changes to an element which has had the lead selection a few clicks before. If the sub node is declared as non-Singleton the old sub node data is kept and reused if the lead selection switches to the same element again without calling the supply function again.
Lead Selection
At runtime, every child node set as a singleton contains the elements for exactly one element of the parent node. For this purpose, one element from the set of possible elements of the parent node must be highlighted. This is achieved by initializing lead selection. For each newly created context node, lead selection is initialized automatically, but this setting can also be deactivated. However, lead selection must generally be initialized for every context node. Using the preset automatic initialization of lead selection: In this case, the first element of a node is always assigned the lead selection property. Manual initialization of lead selection: If the automatic initialization was deactivated, the lead selection must be programmed manually. In this case it is possible to assign this property to an element other than the first element of a node.
Exercise
Use supply function to refresh the contents of a table depending upon the input from another table.
Exercise
Exercise
1. ALV
Display data in an ALV
2. Custom Controllers
Dynamic Programming - 1
Dynamic programming mostly accesses objects of a component at runtime. You can change the layout of a view within method wdDoModifyView, since the view is the owner of the layout of a certain screen area. For this purpose, the interface of method wdDoModifyView provides a parameter called VIEW, which is a reference to an object of type IF_WD_VIEW representing the instance of a view at runtime
The following interfaces are public and can be used to modify objects: IF_WD_APPLICATION IF_WD_ACTION IF_WD_COMPONENT IF_WD_COMPONENT_USAGE IF_WD_COMPONENT_USAGE_GROUP IF_WD_CONTEXT IF_WD_CONTROLLER IF_WD_EVENT IF_WD_MESSAGE_MANAGER IF_WD_OVS IF_WD_PORTAL_INTEGRATION IF_WD_VIEW IF_WD_VIEW_CONTROLLER IF_WD_WINDOW IF_WD_WINDOW_MANAGER
Dynamic Programming - 2
In addition to the all those different interfaces, you can also call static methods on certain public classes: CL_WD_UTILITY CL_WD_DYNAMIC_TOOL CL_WD_RUNTIME_SERVICES
Dynamic Programming - 3
The names of the classes that represent the above mentioned ViewElements are as follows: ViewElement -> CL_WDR_VIEW_ELEMENT UIElement -> CL_WD_UI_ELEMENT UIElementContainer -> CL_WD_UI_ELEMENT_CONTAINER Layout -> CL_WD_LAYOUT LayoutData -> CL_WD_LAYOUT_DATA The above classes are abstract. Since everything that can be placed on screen, is derived from one of those five classes, it also offers you the opportunity to work with generic typed pointers. If you are uncertain about the type of an UI element, use the least generic typed pointer. e.g.If you want to use a button, the class in question will be CL_WD_BUTTON
Dynamic Programming - 4
Dynamic Programming - 5
Every ViewElement contains a method, which starts with NEW_ followed by the name of the class without the CL_WD_. So for a button, the name of this method would be NEW_BUTTON. Calling this method creates a new instance of this ViewElement. Depending on if the current ViewElement is a Layout, LayoutData or other ViewElement, this method has a slightly different signature.
For every Layout the interface of this method always contains at least the following parameters: importing id type string optional "id of the Layout container type ref to cl_wd_uielement_container "UIElementContainer to which the Layout should be assigned returning control type ref to cl_wd_<name of the Layout> "the newly created Layout
Dynamic Programming - 6
For every LayoutData the interface of this method always contains at least the following parameters: importing id type string optional "id of the Layout data element type ref to cl_wd_uielement "UIElement to which the LayoutData should be assigned returning control type ref to cl_wd_<name of the LayoutData> "the newly created LayoutData For all other ViewElements the interface of this method always contains at least the following parameters: importing id type string optional "id of the ViewElement view type ref to if_wd_view optional "pointer to the view returning control type ref to cl_wd_<name of the ViewElement> "the newly created ViewElement
Dynamic Programming - 7
All other parameters are optional and allow you to specify the following aspects of a ViewElement upon its creation: The values of all attributes that are not bound. For each attribute, there is a parameter that has the same name. If an attribute is not specified, its default value will be applied. The binding paths of all bindable attributes. They have the prefix BIND_ in front of the name of the attribute. Only meta paths are supported, which means you can not use any form of index to node elements within such a path. The action to which an event of this ViewElement is bound. All events have the prefix ON_.
Exercise
Adding UI elements
Add n buttons to a view dynamically.
Component interface definitions allow you to generically define a uniform interface structure and later use it in a variety of application components. The advantage of this procedure lies in the fact that in a distributed development the interfaces of all components that use the interface definition reliably contain a particular set of controller elements (methods, context elements, etc.) and interface views, which can be addressed by the developers of using components. The developer of a using component does not need to know which actual implementation of the interface is used this can be determined dynamically at runtime. You use the Object Navigator to create and edit component interface definitions analogous to components.
The interface controller of a component interface definition and the interface controller of a component differ in two items: Interface Controller of a Component Interface Definition The controller can be edited Methods can be defined in the editor, but they cannot be programmed there. The methods are programmed only after the implementation of the component interface definition in a Web Dynpro component. Interface Controller of a Component The controller can be displayed but not edited. The methods can be created in the editor of the related component controller (see above) and then be programmed in the ABAP editor.
In addition to the mandatory interface controller you can add any number of interface views to a component interface definition.
Within this implemented component, the methods of the interface controller that have only been defined so far can be programmed component-specifically. For large programming projects, this results in a higher reusability of the interface structures.
When implementing a component interface definition, these interface views are added to the existing views in the interface folder of the implemented component. The related windows are generated and stored in the respective folder of the object list. They are empty and can now be laid out especially for the embedding component.
The faceless Component It is possible to create a Web Dynpro component that has no visual interface. i.e. a component with zero views and zero windows. Such a component is known as a faceless component and is useful when a complex unit of functionality requiring no direct user interface needs to be encapsulated. A good example of a faceless component is the creation of something called a model component. This is not actually a specific Web Dynpro component type; rather it is a standard Web Dynpro component that has been written specifically for the task of interacting with a model object. Very often, though not exclusively, a model component will have no visual interface, thus also making it a faceless component. Often, a model object could have large or complex interface. Since model objects are completely reusable, it does not make sense to have to re-implement the functionality required to interact with the model object every time it is reused. Therefore, SAP recommends that when a model objects interface requires any type of additional processing or simplification, that the model object be encapsulated within a component in order to be able to reuse the associated interface coding.
Create a Web Dynpro Component Interface Definition Implement the above created Interface in a Web Dynpro Component
Configuration
Configuration is a process by which the developer can create configuration data sets containing values for UI element properties. This allows the developer to overwrite many of the statically defined UI element properties, resulting in a different look and feel of the application. e.g. UI elements may be set to invisible Tables may have an alternating row color
Component configuration allows you to change properties of UI elements defined in any view of a single component. Application configurations are bound to Web Dynpro applications. They define which component configuration is used for which component in this application.
Personalization
Personalization allows any user of the application to change the UI element properties at runtime. These changes are very restricted. e.g. In case of simple UI elements like TextView, only the visibility can be changed For the Table element, the order of the columns can also be altered
Customizing is the ability to personalize Web Dynpro applications for all users in a client. Special authorizations are required.
Adaptation Hierarchy
Configuration, Customizing and Personalization can be combined to define the final adaptation.
Changes defined by personalization overwrite the changes defined by customizing and Changes defined by customizing overwrites the configuration adaptation
The parameters available for configuration can be set to final so that they cannot be changed by customizing or personalization Parameters available for customizing can be set to final so that they cannot be changed using personalization.
Adaptation Hierarchy
Exercise
1. Define Configuration for your Web Dynpro Component and Web Dynpro App to show 10 rows in the table control instead of the default 5 2. Customize your Web Dynpro App to change the label of any button 3. Personalize your Web Dynpro App to hide one of the Table control fields
Exercise
Depending upon the value of the parameter p in the query string of the application URL, either view V11 or V12 should be triggered.
Exercise