Saturday, January 25, 2014

Build Web Dynpro Applications using MVC Approach

Building WebDynpro Applications using MVC Approach
SAP Web Dynpro ABAP,webdynpro tutorial using Model View Controller (MVC) Approach,webdynpro MVC is the approach to develop ABAP web dynpro applications using Model,View and Controller. 

Model consist of business logic to implement business functionality. View is the user interface, the users can operate the system using views. Controller acts as a mediator between the Model and the Controller. Here in this post we are going to provide how to develop abap web dynpro applications using MVC approach. Refer this post for more details on sap web dynpro. Click on read more to read this article.


How to Build Web Dynpro Applications using MVC Approach


Model View Controller (MVC) Approach, is the approach to develop ABAP web dynpro applications using Model,View and Controller. Model consist of business logic to implement business functionality. View is the user interface, the users can operate the system using views. Controller acts as a mediator between the Model and the Controller. Here in this post we are going to provide how to develop web dynpro applications using MVC approach. Refer this post for more details.


Design approach for decoupling presentation and application logic within a ABAP Web Dynpro application.


abap-webdynpro-mvc-architecture

Model:
*Application data definition
*Connection to business functionality

View: 
*Visualization of application  data

Controller: 
*Event handling
*Application data update
*Control flow definition

Every Web Dynpro application is structured according to the Model View Controller programming model:

● The model forms the interface to the back end system and thus enables the Web Dynpro application access to data.

● The view is responsible for the representation of the data in the browser.

● The controller lies between the view and the model. The controller formats the model data to be displayed in the  

Web Dynpro ABAP Component Architecture


SAP Web Dynpro uses principles of MVC paradigm


webdynpro-abap-component-architecture

•Controller handle the user input and steers the application
•Views define the layout
•Model holds and provide the business logic 

The component controller acts as a component wide controller. Program logic related to only a certain view (for example, checking user input) should be coded in the related view controller. 

Usage declarations between the controllers allow you to access the context data and methods of the declared controller (used controller).

A view controller can not be declared as a used controller for other controllers, since this would violate good programming (MVC programming paradigm).

Business logic should not be part of the Web Dynpro component, but should be defined outside of the component to have high re usability. 

It is preferable that ABAP classes be used to encapsulate the related source code.

Custom controllers are optional controllers that must be defined by the developer.

These controllers can be used to modularize the component content. For example, custom controllers can act as local controllers for some views, or they can be used to encapsulate the logic related to a certain model class (business logic).  

This allows you to reduce the content of the component controller by populating sub-functions.


Web Dynpro Components


Web Dynpro Component contains

webdynpro-component

•Windows

•Views
–UI elements
–Layout

•Controllers
–Context Data
–Eventing
–Methods
–Attributes

•Component Interface
–Interface Controller
–Interface View


Web Dynpro components allow structuring complex Web applications and developing reusable, interacting entities. This enables the nesting of large application sections.


Web Dynpro components are containers for other entities related to the UI and the Web Dynpro program.


Entities related to the UI are windows and views. The layout of a view represents a rectangular part of a page displayed by the client (for example, a browser).


The view contains UI elements such as input fields and buttons.


The complete page sent to the client can be set up by only one view, but can also be a combination of multiple views.


The possible combinations of views and flow between the views is defined in a window.


A window can contain an arbitrary number of views.


A view can be embedded in an arbitrary number of windows.


The Web Dynpro source code is located in Web Dynpro controllers.


The hierarchical storage for the global variables of controllers is called the context.

Component Interface

Defining View Layout

abap-webdynpro-view-layout









UI Element Categories
Various categories of UI element are supported

abap-webdynpro-ui-elements


Each UI element object is represented as an abstract class that is independent of any client presentation layer.

View and View Controller
View
Contains the UI element
Defines the Layout
UI elements mapped to Context nodes

abap-webdynpro-view-controller

View Controller
Stores Data in Context
Methods access context data and Model layer
Supply functions fill context nodes
Actions for event handling

Windows and Nested Views

A Window is a set of all possible views that can make up a visible screen
A window can have zero or more views embedded in it
A View can have ViewContainerUIElement. This allows nesting views within a window
A ViewContainerUIelement can only display one view at a time.

abap-webdynpro-windows-nested-windows














A window defines which views are displayed in which combination and how the view combination may be changed by firing outbound plugs.
Thus, when creating a window, you define three things:
All the possible views that could exist in the components visual interface must be embedded in the window.
If multiple views must be displayed in parallel; the layout and position of these views is defined by a special view containing ViewContainerUIelements in its layout. 

This container view is embedded in the window and, inside each area defined by a ViewContainerUIelement, all possible views for this view area are embedded (nested embedding). For each ViewContainerUIelement, there is one default view displayed at startup.
The navigation links between the different views must be defined.

Context Mapping
Component Controller
Controller which is the backbone of the Web Dynpro component
Has its own Context
Contains the logic for interaction with the model (ABAP class, function modules, BAPIs, Web Services)

Context Mapping

Nodes of Component Controller context can be mapped to nodes of other contexts
Framework cares about data transport (references)

abap-webdynpro-context-mapping


The variables defined in a Web Dynpro Controller context can be referenced from other Web Dynpro controllers. This is called context mapping

This allows to share common attributes between different controllers, so copying these attributes between the controller contexts is not necessary.

The value of UI elements, that allow a user input, have to be connected to context attributes of the corresponding controller. This is called data binding.

Through data binding, an automatic data transport between the UI elements and the context attributes is established.

Combining these two concepts, the data transport between UI elements located in different views can be defined in a purely declarative way.

abap-webdynpro-component-view-controller
Mapping Relationship between Component Controller and View Controller

Context mapping allows a context node in one controller to be supplied automatically with data from a corresponding context node in another controller.

When two controllers within the same component share data through a mapig relationship, it is known as Internal Mapping.

The mapping between controller contexts located in different Web Dynpro components is known as External Mapping.


The context node that acts as the data source is known as the mapping origin node, and the context node that is mapped is known as the mapped node.

For a mapping relationship to be established, the following steps must first be performed:

A node must exist in the context of the controller acting as the mapping origin. This node need not have any declared child nodes or attributes.

The mapping origin controller must not be a view controller.

The controller containing the mapped node must declare the use of the mapping origin controller as a used controller.

Data Binding
Data binding is the means by which data is automatically transported from a view controllers context to a UI element in its layout, and visa versa.
•The Web Dynpro framework then manages the following two tasks:

–The transport of data from the context attribute to the UI element during the screen rendering process

–Repopulating the context attribute from the UI element after data has been entered by the user and the next server round trip is initiated.

abap-webdynpro-data-binding

You may not bind UI elements to context nodes or attributes defined in some other controller. UI elements are private to the view controller within which they are declared.

The data binding process decouples the UI element object from the application code within the view controller. 

Therefore, in order to manipulate UI element properties, the application code in the view controller needs only to manipulate the values of context nodes and attributes to which the UI elements are bound.

Data binding is powerful, since not only the value of a UI element can be bound to a context attribute, but other UI properties like visibility can also be bound. 

This way, UI element properties can be manipulated from the view controller by acting on context attributes.

Concepts: Web Dynpro Application
      Web Dynpro application is an entry point into a Web Dynpro component  and is the only Web Dynpro entity that can be addressed via a URL.
 
  In order to define a Web Dynpro application, you must Specify :

•Which interface view of the root component will be used; the default views) in this interface view defines the default view assembly.

•The component to be invoked; this component is then known as the root component

•Which inbound plug will act as the entry point for the nominated interface view (this inbound plug must be of type Startup)

abap-webdynpro-application


There is often (but not always) a one-to-one relationship between an interface view and an application.

In the same way that the functionality in an ABAP module pool can be accessed by defining multiple transaction codes, the functionality of a single Web Dynpro component can be accessed by defining multiple applications, each addressing a different interface view and/or a different inbound plug of the interface view.


"You found the information helpful and want to say thanks? Your donation is enough to inspire us to do more. Thanks a bunch!"

0 comments:

Post a Comment

Note: Only a member of this blog may post a comment.

Categories

ABAP (1) ABAP Interview Questions (112) ABAP Open SQL Statements (1) ABAP Syntax Rules (6) ABAP WORKBENCH (2) ABAP-Interview-Questions (52) ALE IDOC (6) ALE IDOC Interview Questions (6) ale-idoc (6) ALE-IDOC-Interview-Questions (19) ALV Interview Questions (5) ALV-Interview-Questions (22) BADI (2) BAPI (1) BAPI Interview Questions (1) BAPI-Interview-Questions (14) BDC (6) BDC Interview Questions (6) BDC-Interview-Questions (9) big data (2) big data interview questions (1) Classical Reports Interview Question (3) Classical-Reports-Interview-Questions (22) Conditional Statements (1) Cross Applications (3) Cross-Applications (14) Data Dictionary (22) Data Type Questins (1) Data types (1) Data-Dictionary (48) Data-Type-Questins (6) Dialog programming (5) Dialog Programming Interview Questions (4) Dialog-Programming (30) DOMAIN Interview Questions (1) Domain-Interview-Questions (8) Function Module (2) hadoop (2) hadoop interview questions (2) hdfs (1) IDoc Tutorials (6) Interactive Report Interview Questions (4) Interactive-Reports-Interview-Questions (22) Internal Tables (1) interview questions (1) Lock Object Interview Questions (1) Lock-Objects-Interview-Questions (10) Logical Database (1) Modularization Interview Questions (4) Modularization-Interview-Questions (25) Module Pool Programming (5) Module-Pool-Programming (39) modules in sap (1) Object Oriented ABAP (19) Object Oriented ABAP Interview Questions (15) object-oriented-abap (2) Object-Oriented-ABAP-Interview-Questions (34) OOABAP (9) Reports (14) Reports Interview Questions (9) Reports-Interview-Questions (19) RFC (1) RFC Interview Questions (1) RFC-Interview-Questions (14) RICEF (1) RICEF Objects (1) SAP (4) SAP ABAP (4) SAP ABAP Interview Questions (42) SAP ABAP Introduction (46) SAP ABAP Message Types (2) SAP BADI Interview Questions (2) SAP Basics (71) SAP Books (2) SAP Certification (1) SAP CONSULTANTS (5) SAP CRM (1) SAP ENHANCEMENTS (3) SAP EXITS (2) SAP EXITS ( SAP ENHANCEMENTS ) Interview Questions (1) SAP Free Books (1) SAP HR (2) SAP Lock Object (1) sap modules (2) SAP Open SQL Statements (1) SAP R/3 Architecture (4) SAP Search help (1) SAP Smartforms (1) SAP Smartforms Interview Questions (2) SAP Tables (5) SAP Tcodes (10) SAP Views (1) SAP Webdynpro ABAP (12) SAP Work Processors (2) SAP Workflow (3) SAP-BADI-Interview-Questions (11) SAP-Enhancements (39) SAP-Exits (39) SAP-Exits-Enhancements-Interview Questions (3) SAP-HANA (1) SAP-HANA-Interview-Questions (1) SAP-Smartforms-Interview-Questions (2) SAP-Workflow (3) Scripts (3) Scripts Interview Questions (2) Scripts-Interview-Questions (32) Search Help Interview Questions (1) Search-Help-Interview-Questions (9) Smartforms (1) Table Maintenance Generator (1) Table-Maintenance-Generator (4) Tables in SAP (2) Tables Interview Questions (3) Tables-Interview-Questions (3) Type Group Interview Questions (1) Type-Group-Interview-Questions (7) Variable Declaration (1) Views Interview Questions (1) Views-Interview-Questions (5) Webdynpro (12) what is big data (1)

Protected Blog

 
This blog is not affiliated to SAP AG |SAP is trademark of SAP AG |The information collected from various sources use information with your own risk.