Welcome to SAP ABAP Interview Questions. SAP ABAP Webdynpro Component Architecture,Windows and Nested Views, MVC Architecture.
A window in ABAP Webdynpro defines which views are displayed in which combination and how the view combination may be changed by firing outbound plugs.SAP ABAP Webdynpro MVC Windows Component Architecture
Read previous article on ABAP Webdynpro Architecture, before going to read this one
Windows and Nested Views in SAP ABAP Web dynpro
A
window defines which views are displayed in which combination and how
the view combination may be changed by firing outbound plugs.
SAP ABAP Webdynpro Windows and Nested Views
Thus, when creating a window, you define three things:
All
the possible views that could exist in the component‘s 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 View Container UI elements
in its layout.
This container view is embedded in the window and, inside each
area defined by a View Container UI element, all possible views for this view
area are embedded (nested embedding).
For each View Container UI element,
there is one default view displayed at start up.
•
The navigation links between the different views must be defined. Only one view
can be displayed in the view area at a time.
Navigation links must be defined between
views in order for the contents of a view area to be replaced.
View areas can
be blanked out by creating an empty view whose inbound plug responds to an appropriate
navigation event.
View Assembly
Outbound
plugs are the triggers that cause a view area to contain a particular view. For
a given window definitions in which multiple views are embedded into view
areas, there could be many permutations of views visible.
The permutation that
is visible depends on which navigation links the user follows. The subset of
views visible at any time is known as a view assembly.
Web Dynpro Architecture: Relation between Web Dynpro Entities
Model View Controller (MVC) in Webdynpro ABAP
SAP's WebDynpro is built on the foundation of the Model View Controller (MVC)
design paradigm. MVC was originally invented by the Norwegian software designer
Trygve Reenskaug while working at Xerox PARC in the late 1970s.
The
first implementation of this design paradigm was with the release of the
Smalltalk-80 programming language. MVC was a revolutionary design paradigm
because it was the first to describe software components in terms of:
•
The functional responsibilities each should fulfill
•
The message protocols to which each component should respond
SAP
has modified and extended the original MVC specification to create the Web
Dynpro toolset.
Web Dynpro Component Architecture
Internally Visible Web Dynpro Entities
The
architecture of a Web Dynpro component can be divided into two parts: external
and internal visibility.
The
horizontal dashed line in the above figure separates the entities that are
visible from outside the component from those that are only visible from within
the component.
The
internally visible parts can further be divided into visual entities and
programming entities. Visual entities are those related to the UI, generated by
the Web Dynpro framework, and passed to the client. The internally visible
entities consist of windows and views.
A
view consists of a view layout and the corresponding view controller. The view controller
can contain navigation plugs, methods, and a context. A window embeds one or more
views and has a corresponding window controller.
A
window controller can contain navigation plugs, methods, and a context. Each
view can be embedded in multiple windows.
The
outbound plug of a window can be connected to any inbound plug of embedded views,
and the outbound plug of a view can be connected to any inbound plug of the embedding
window. However, navigation between windows of the same component is not possible.
Internally Visible Web Dynpro Entities (2)
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 cannot be declared as a used controller for other
controllers, since this would violate good programming (MVC programmingparadigm). Business logic should not be part of the Web Dynpro component, but
should be defined outside of the component to have high reusability. It is preferable
that ABAP classes be used to encapsulate the related source code.
Internally Visible Web Dynpro entities (3)
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.
Externally Visible Web Dynpro Entities
If
one Web Dynpro component (parent component) needs access to another Web Dynpro
component ( child component ) the parent component can declare the use
of the child component. A specific component usage instance is then created and
the parent component accesses the functionality of the child component via its
component interface controller.
The
only parts of a Web Dynpro component that are visible to the user, are the interface
controller and the interface view(s).
•
All WebDynpro components have only one interface controller. Via the interface
controller, data, methods, and event handlers can be exposed to other
components.
•
Interface views represent the visual interface of a Web Dynpro component. There
is a one-to-one relationship between a Window and an interface view. Each time
a window is defined, a related interface view is automatically generated, which
makes the window accessible from outside the component.
The interface view only
exposes those inbound and outbound plugs to the component user that have the interface
property checked. Methods and context data of the window are not accessible
via the related interface view.
•
If the component has no views, there is no need to have Windows. In this case,
the component will not implement an interface view. Such components having no visual
interface are known as faceless components .
Web Dynpro Application
A
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. 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. In order to define a Web Dynpro application, you must
specify:
•
The component to be invoked; this component is then known as the root component
•
Which interface view of the root component will be used; the default view(s) in
this interface view define(s) the default view assembly.
•
Which inbound plug will act as the entry point for the nominated interface view
(this inbound plug must be of type Start up)
SAP ABAP Interview Questions and Answers
SAP ABAP Webdynpro Interview Questions
"You found the information helpful and want to say thanks? Your donation is enough to inspire us to do more. Thanks a bunch!"
Posted in: 
0 comments:
Post a Comment
Note: Only a member of this blog may post a comment.