Day1 Foundation

Embed Size (px)

Text of Day1 Foundation

Massachusetts Institute of Technology

Web Dynpro for ABAPVolume I: FoundationBy: Hendrik Pieterse27 January 2011

AgendaPurpose Key Features Development Environment Architecture UI (User Interface) Layout Framework Event Loop Controller Hook Methods Assistance Classes Application Programming Interfaces

27 January 2011

2

PurposeForms SAP Standard for ABAP Web Applications Integrated Runtime and Graphical Development Environment Provides Application Developers the following key advantages: Declarative and graphical tools to the reduce implementation effort A structured design process Strict separation between the layout and business data Reuse and better maintainability by using components Easy to change layout and navigation using Web Dynpro tools Automatic data transport through data binding Automatic input checks User interface accessibility is supportedPrerequisites: Requires knowledge and experience with Object-Orientation (i.e. ABAP-OO)27 January 2011 3

Key features The following are the key feature of Web Dynpro for ABAP: Extensive sets of User Interface (UI) elements Support for end-user Drag and Drop (between certain UI elements) Customizable styling Floating popup windows Document Upload/Download UI elements Timed Events Adobe Flash integration Adobe Form integration Web Dynpro Code Generation Wizard Modification-free enhancements to SAP Standard code

Development environment

Architecture System Architecture is based upon the Model View Controller paradigm with: Clear separation between business logic and display logic Uniform meta model for all types of user interfaces Execution on a number of client platforms Extensive platform independence of interfaces

Architecture: MVC Model (M) Encapsulates the business rules and data Function Models, Classes, Tables, WDA Components, etc.

View (V) Visual presentation using the UI elements Present data and obtain user input Performs rudimentary input validation

Controller (C) Serves as the glue between the Model and the View Implements business logic, context-relevant input validation Controls navigation

Architecture: ComponentsA Web Dynpro component is a reusable entity, and its creation is mandatory. It summarizes all components that are required as part of a programming unit for an executable Web Dynpro application

Components implement and enforce the MVC pattern and Consist of: 1 Component Controller 1 Interface Controller 1 Interface View 0 or more Windows 0 or more Views

Windows and Views have their own private Controllers

Architecture: Component lifetimeWeb Dynpro windows, views and controllers are linked to the existence of the component itself

The lifetime of the component: Starts when first called at runtime (as required) Ends with the encapsulating application May be programmatically controlled during its lifetime

Architecture: Component re-useCross-Component communication provides the mechanism for efficient code re-use and encapsulated object design. Web Dynpro components can be referenced or directly embedded within Views

Component A can embed Component B in a View or Window This method uses the Interface View

Architecture: Component re-use

Alternatively, Component A can invoke a method exposed by Component B This method uses the Interface Controller

Architecture: ControllersControllers are the active parts of a Web Dynpro application and determine how the user can interact with the Web Dynpro application

Different instances of Controllers and Contexts exist within a Web Dynpro application

At least two object references are automatically defined as attributes for a controller: wd_context wd_this

Architecture: Controllers Each controller contains program areas in which you can insert your own source code in the following areas: Event Handlers: Executed when a view is initialized, ended, or entered, when a user interface element of a view triggers an action, or when other controllers trigger a registered event Methods: Custom functionality which can be called by other controllers Supply Functions: Executed when necessary to initialize node elements in the context

Architecture: Controllers Each view has exactly one View Controller, which processes the actions performed by the user in the view A view also has exactly one view context, which contains the data required for the view A view controller and the corresponding context exist at least as long as the view is visible in the browser. If the view is replaced by a successive view, the local data are also no longer available. However, the lifetime can also be connected to the lifetime of the surrounding component

Architecture: ControllersIn addition to view controllers, which only control the behavior of an individual view, global controllers are defined that offer more general services for all the views of a component

Architecture: Controllers Global Controllers: Each Web Dynpro component contains at least one global controller that is visible within the component for all other controllers, called the COMPONENT Controller Additional global controllers can be added in the form of Custom controllers Each Web Dynpro window defines a further global controller

Interface Controllers: Each Web Dynpro component contains exactly one interface controller This controller is a global controller that is visible also outside the component. It is thus part of the interface of a Web Dynpro component Communication from one controller to the next is achieved by calling methods from a different controller

Architecture: EventsEvents are used to communicate between controllers and enable one controller to trigger event handlers in a different controller The Component Controller can define one or more events, while one or more Views implement an event handler to listen to and react to those events Cross-component communication can be implemented using events on the Interface Controller Note: Events created in the component controller are visible only within the Component UI Elements Some UI elements, for example a Button have special events that are linked with user Actions. Actions are defined within the Views controller

Architecture: Contexts Data for a component or view is stored in the special container called the Context The Context forms a hierarchical structure - each Context has a root node, underneath which additional Nodes and Data Fields (attributes) are defined in a tree structure All elementary data types are available for the definition of attributes. This is also used for creating the value help and error messages if invalid entries are made A Node can be defined as a simple structure, or a repeating structure (table) by controlling its Cardinality

Architecture: Contexts

Hint: Think of the context as a complex structure which you can define and expand interactively (without the need for SE11)

Cardinality

Meaning The node contains only one element instance, which is instantiated automatically The node contains only one element instance, which must not be instantiated The node can contain multiple element instances (i.e. a table), of which at least one row must always be instantiated (and is instantiated automatically) The node can contain multiple element instances (i.e. a table), of which no rows have to be instantiated

1:1 0:1 1:n 0:n

Architecture: ContextsExample:

PERNR 00000007 00000037

PERSG 01 12

PERSK 01 10

ENAME Mr. James Bond Ms. Money Penny

TEL NR 555-235-0007 555-230-1000

In this example, node EMPLOYEE forms a table due to the cardinality being specified as 0..n Each row in the table has attributes PERNR, PERSG, PERSK, etc. Context nodes can specify a SUPPLY Function, which is only involved when the Node is referenced Tip: When ever possible, utilize Supply Functions to update Nodes when required (Just-In-Time)

Architecture: ContextsFramework generated type definitions Are automatically defined for each Controller to facilitate programmatic access to the context View definitions using the Controller Interface inspector

Constant for node names (not attributes)constants: wdctx_context type string value `CONTEXT`. constants: wdctx_employee type string value `EMPLOYEE`.

Architecture: ContextsFramework generated type definitions There are two data types for each Node: a Simple (non-repeating) Structure, and a Table

Consistent naming convention: Context node names always start with wdctx_ Structures always start with Element_ Tables are always plural: Elements_

types: Element_employee type PERSON, Elements_employee type standard table of Element_employee with default key.

Architecture: ContextsConventions: An instance of a Node (structure or element in the table) is referred to as an Element

Lead Selection: Each Context Node has an implicit reference to the active Element, called the Lead Selection The automatic initialization of the Lead Selection always designates the first element of a Node The UI can change the Lead Selection (e.g. user selects a specific row in a table) If a Node is nested within another, each Node contains its own Lead Selection

Architecture: ContextsData Binding: UI elements embedded in a View can be bound to the nodes and attributes in the context For example. The Table UI element allows for the presentation of (and interaction with) of a context node.

Context Mapping: Since each View contains its own Context (as does the Window and Component Controller), a useful feature is provided to allow mapping Context Node(s) from one Controller to another Context Mapping seamlessly ensures that the same data is ava