1) Wat is component controller & parts of component controller?

Controllers are the active parts of a Web Dynpro application. They define how the
user can interact with the Web Dynpro application. The data that a controller can
access is defined in the corresponding context. Different instances of controllers
and contexts exist within a Web Dynpro application. Controllers contain the source
code of a Web Dynpro application; they hold the context data and care for event
handling and navigation. Any programming of flow logic requires the knowledge of
how controllers are defined and what kind of entities they offer.
Controller Types
There are four types of controllers in an ABAP Web Dynpro component. These
different controller types differ in the entities they are composed of:-
1. Component controller:-
There is only one component controller per Web Dynpro component. This is a global
controller, visible to all other controllers. The component controller drives the
functionality of the entire component. This controller has no visual interface. The
lifetime of the component controller equals the lifetime of the component. When
starting a Web Dynpro application, the component controller is instantiated by the
Web Dynpro runtime
2. Custom controllers
Custom controllers are optional. They have to be defined at design time and can be
used to encapsulate sub-functions of the component controller. Multiple custom
controllers can be defined in a component. Custom controllers are instantiated
automatically by the Web Dynpro framework and the instantiation order is
undefined; therefore, the coding in a custom controller should make no assumptions
about the existence of any other custom controller. The instantiation of a custom
controller is delayed until the first method of the controller is called. Custom
controller instances cannot be deleted explicitly.
3. Configuration controller
This is a special custom controller. It is only necessary if the corresponding
component implements special configuration and personalization functionality. Only
one configuration controller may exist in any component. Any other controller can
access the configuration controller, but the configuration controller cannot access
any other controller. This controller is instantiated as the first controller of the
component. It lives as long as the component lives.
4. View controllers
Each view consists of the layout part and exactly one view controller. This controller
cares for view-specific flow logic, like checking user input and handling user actions.
The instantiation of a view controller is delayed until the first method of the
controller is called. The lifetime of a view controller can be controlled by the views
properties. If framework controlled is selected, the view instance will be deleted
with the component. If when visible is selected, the view instance is deleted as soon
as the view no longer belongs to the view assembly.
5. Window controllers
Each window has exactly one window controller. This controller can be used to care
for the data passed via the inbound plugs when being reused as a child controller.
Methods of this controller can be called from the inbound plug methods of the
window. The instantiation of a window controller is delayed until the first method of
this controller is called. This is done by starting a Web Dynpro application or by
embedding the related interface view in the parent component's window. Window
controller instances cannot be deleted explicitly.
At runtime, all controller instances are singletons in respect to their parent
component.
This is also true for view controllers; thus, embedding a view in a view assembly
more than one time is not allowed. The global data of a controller is stored in
hierarchical data storage, the controller context. This context and the methods
defined in a controller are private unless another controller explicitly declares the
usage of this controller. However, a view controller cannot be declared as a used
controller, so the context data and the methods of a view controller are always
private.
Common Controller Entities:-
Each controller has its own context. The context root node already exists. All other
nodes and attributes have to be defined statically or by source code. For all
controllers, there exist methods that are called by the Web Dynpro framework in a
predefined order. These are called hook methods. Depending on the controller type,
there are different hook methods available. At least two hook methods are
contained in all controller types. These methods are processed only once during the
lifetime of a controller instance: when a controller instance is created (wddoinit( ))
and when a controller instance is deleted (wddoexit( )). 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 two predefined
attributes, which are used to access the functionality of the controller (WD_THIS)
and of the context (WD_CONTEXT). For information to be shared between different
controllers, one controller must declare the use of another controller. This is done
on the Properties tab of the controller that needs to access another controller. The
most frequent requirement for this kind of data sharing is when we wish to create a
mapped context node or we wish to access another controller's instance methods.
We may not specify the name of a view controller as a used controller, as this would
violate good MVC design principles. A view controller should be written such that it
is responsible for nothing more than the display of data and user interaction. A view
controller is not responsible for generating the data it displays; that is the role of a
custom controller. Business logic, such as function modules, BAPIs, or methods in
helper classes can be accessed from the methods of all controllers.
Special Entities of Component/Custom Controllers:-
For both component and custom controllers, events can be defined with arbitrary
parameters. Any method of any other controller (also view and window controllers)
can register to these events if this method is defined as an event handler method. A
typical use of such events is the invocation of processing in a view controller after
processing in the component controller has been completed. This can be achieved
when a method in the view controller subscribes to an event raised by the
component controller. Using our design time declarations, the Web Dynpro
framework will automatically manage the definition, triggering, and handler
subscription to such events for us. If two or more methods subscribe to the same
event, the order in which they will be executed is undefined. Only the component
controller has additional standard hook methods. These are processed directly
before the navigation requests are processed (wddobeforenavigation( )) and after
all views of the view assembly to be sent have been processed
(wddopostprocessing( )).Attributes, methods, context elements, and events can be
marked as interface elements. These elements are then exposed to other
components by means of the interface controller.
Special Entities of View Controllers:-
A view controller is a visual building block of a Web Dynpro component and is
designed to handle all aspects of data display and user interaction. 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. Using
the generic name <Outbound plug> for an outbound plug, its declaration will cause
a method to be generated in the view's component controller, called
FIRE<Outbound plug>PLG. This method is only visible for the Web Dynpro
framework; it is not visible to the developer. An inbound plug is the navigation
event handler that can be registered to a navigation request. Using the generic
name <Inbound plug> for an inbound plug, its declaration will cause a method to
be generated in the view's component controller, called
HANDLE<Inbound plug>.A static registration of an inbound plug (method
HANDLE<Inbound plug>) to the navigation event raised by an outbound plug
(method FIRE<Outbound plug>PLG) is called a navigation link. Navigation links are
not part of a view but are defined in a window embedding the view. Thus, in
different windows, the event registration can be defined differently. An action links
a client-side event to an event handler method defined in the corresponding view
controller. When defining an action having the name <Action>, an event handler
method (ONACTION<Action>) is automatically generated. If a view will be replaced
as a result of a client event, the related outbound plug can be fired in this action
event handler method. There are two special hook methods found in view controller:
wddobeforeaction( ) is processed if a client event is fired in any view. Before the
action event handler methods are processed, thewddobeforeaction( )_methods are
executed for all views that are part of the last view assembly: _wddomodifyview( ) is
a method that allows us to programmatically manipulate the layout of the view. This
event can be used to define the UI dynamically. In addition to the standard
attributes of all controllers, a view controller has a reference to the component
controller of its component: WD_COMP_CONTROLLER. This reference can be used to
access functionality related to the component controller. It is used when accessing
messages or when calling a method declared in the component controller.
Special Entities of Window Controllers:-
Window controllers are very similar to view controllers. Technically, it is like a view
controller without a UI (view layout). All views that are to be displayed when using a
Web application have to be embedded in the window that is referred to by the
application or the calling component. The Web Dynpro window contains the
structure of all views to be displayed and the navigation links defining the possible
view assemblies. Each Web Dynpro window contains outbound plugs and inbound
plugs, like views. We can use the plugs to set up cross-component navigation. To
expose the plugs to the component interface, select the property Interface for each
plug. These plugs will then be part of the related interface view. The window
controller also has the special attribute WD_COMP_CONTROLLER, which holds the
reference to the component controller.

2.What is context?
Each Web Dynpro controller has exactly one hierarchically structured data store,
called the context. The structure of a context is normally defined at design time,
and can be modified at runtime (dynamically) if necessary using the associated
context API.
Data is added to a context at runtime, either by calling context interface methods or
using the context mapping mechanism. In the latter, the elements in one context,
known as nodes and attributes, point to the corresponding elements in another
context. Context mapping simplifies the task of storing data centrally in a controller
context and referencing it from any other contexts.
In a Web Dynpro Controller, the context has the following functions:
Storage location for structured data : A Web Dynpro Controller can store local data
like Java classes in normal instance variables. Using the controller context as the
storage location provides other possibilities, such as data binding (described below)
and context mapping at the declarative level.
In addition to the UI relevant data (values of UI element properties), you can also
save as many Java objects (for example of type java.lang.Object) as in a controller
context you like, which are not required directly for the user interface.
Defining UI element properties using data binding : In Web Dynpro, the properties of
UI elements are not defined by direct access to the relevant object instances in the
view controller. Instead, the UI element properties are bound to context attributes
at design time (data binding) . At runtime, a bound UI element property therefore
has the value assigned to it that is stored in the relevant context attribute. This
means that a change to a UI element property on the user interface automatically
triggers a change to the property of the corresponding context attribute, and vice
versa.
Displaying tree structures and master-detail relationships
Automatic data exchange between controllers using context mapping: Mapping
relationships can be defined between Web Dynpro controller contexts. This
determines that the mapped context does not store its data itself. Instead, the data
is stored by means of the context being referenced to another context (the data
context). Context mapping therefore works in both directions. When data changes
in one context, the data automatically changes in the other context.
Connection to the back end : A controller context can also be connected to a model
interface as the interface to the back-end layer. At runtime, the context then points
to the business data (model objects) received from the back-end system.
The following sections provide further details about the following concepts.
Declaration of controller contexts : Principles of the definition of contexts at design
time, supply functions and runtime aspects of controller contexts, singleton and
non-singleton nodes, context attributes and the use of the Java Dictionary,
calculated context attributes, recursive context nodes
Context mapping : Principles, normal context mapping, external context mapping,
restrictions, mapping recursive context nodes.

3.Explain Nodes?

4.What is cardinality?
actually cardinality is nothing but it is selection of value as well as instatiation of
node..
CARDINALITY tells the min. and max. numbers of elements a node may contain.

4 type of cardinality are there....

0:1----it behaves as not instatiated but may be created upto 1 element...
1:1-beahaves as it is instatiated but will create upto 1 element.
0:n--as it is not intatiated and will create upto nth element
1:n--as it is instatiated but will create upto nth element..

5. Wat is Component re-usage and how do we use?

A Web Dynpro component is a reusable entity. It summarizes all components that
are required as part of this programming unit for an executable Web Dynpro
application.
The Web Dynpro component concept offers a number of advantages:
· Structuring of the programming
· Creation of easily manageable application blocks
· Reusability of whole components
· Decoupling of software projects in both time and space

The Web Dynpro component contains any number of windows and views and their
corresponding controllers. Additional Web Dynpro components can also be
referenced.
The creation of a Web Dynpro component is always mandatory, since the existence
of the Web Dynpro window and the views and controllers that it contains is linked to
the existence of the component itself. Communication between the elements of two
Web Dynpro components and their call by a user is implemented using the
component interfaces, so it does not make sense to consider the individual parts of
the component separately.
A Web Dynpro component can embed other Web Dynpro components, and
correspondingly a Web Dynpro component can be embedded in any other Web
Dynpro components. This communication also takes place over the component
interfaces.

A Web Dynpro component’s lifetime begins the first time it is called at runtime, and
ends with the lifetime of the Web Dynpro application that called and thereby
instantiated the component. For embedded components this means that during the
lifetime of the embedded component, they are not instantiated until the moment
when they are required. Their lifetime ends, however, at the same time as the
embedded component when the Web Dynpro application that was originally called
is ended.
It is also possible for the embedding component to create or destroy the embedded
component using an appropriate API and thus control its lifetime

6.Wat is MVC architecture?

Model–View–Controller (MVC) is a software architecture,[1] currently considered an
architectural pattern used in software engineering. The pattern isolates "domain logic" (the
application logic for the user) from the user interface (input and presentation),
permitting independent development, testing and maintenance of each (separation of
concerns).
The model is used to manage information and notify observers when that
information changes. The model is the domain-specific representation of the data
upon which the application operates. Domain logic adds meaning to raw data (for
example, calculating whether today is the user's birthday, or the totals, taxes, and
shipping charges for shopping cart items). When a model changes its state, it
notifies its associated views so they can be refreshed.
Many applications use a persistent storage mechanism such as a database to store
data. MVC does not specifically mention the data access layer because it is
understood to be underneath or encapsulated by the model. Models are not data
access objects; however, in very simple apps that have little domain logic there is no
real distinction to be made. Active Record is an accepted design pattern which merges
domain logic and data access code - a model which knows how to persist itself.
The view renders the model into a form suitable for interaction, typically a user
interface element. Multiple views can exist for a single model for different purposes.
A viewport typically has a one to one correspondence with a display surface and
knows how to render to it.
The controller receives input and initiates a response by making calls on model
objects. A controller accepts input from the user and instructs the model and
viewport to perform actions based on that input.
An MVC application may be a collection of model/view/controller triads, each
responsible for a different UI element.
MVC is often seen in web applications where the view is the HTML or XHTML
generated by the app. The controller receives GET or POST input and decides what
to do with it, handing over to domain objects (i.e. the model) that contain the
business rules and know how to carry out specific tasks such as processing a new
subscription

What is Webdynpro?
• Web Dynpro for ABAP is SAP's new standard UI technology for developing
user interfaces in the ABAP environment.
• It combines the well-known features of a ABAP server environment, like the
transportation and change management system, security environment, test and
performance analysis tools, or remote debugging, with the rendering-independent
UI programming model.
• In the long term, Web Dynpro for ABAP will be the successor of the
traditional screen ("Dynpro") based user interface technology which is based on SAP
GUI
Architecture of Web Dynpro
• Web Dynpro is the SAP NetWeaver programming model for user interfaces
(UIs).
• 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 view, processes the user entries made by the
user, and returns them to the model.
Reference for detailed M-V-C Architecture Overview