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.
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.
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.
View and View 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.
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
•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
•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
UI Element Categories
Various categories
of UI element are supported
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
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.
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)
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.
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.
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)
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.