Webdynpro:

Best suited for developing abap based web applications, high

speed, low cost and standardized UIs.
Wd apps are built using declarative programming techniques
based on mvc paradigm.
Within abap worbench, there are special tools that allow you to
build an abstract representation of your application in the form
of wd meta model.
!he wd framewor allows you to place the custom code at
predefined positions within the generated code.
"rom wd app, all inds of reuse component can be addressed
directly.
Web services can be used after having generated web service
client ob#ect.
!he sap #ava connector can be used to call methods of enterprise
#ava bean located on $%&& &ngine.
It supports for internationalization, flicer free interaction,
clean separation of ui and business logic.
'upports reuse of components and data binding.
When you create a wd component following things gets created:
component controller, component interface: interface controller,
interface view, views, windows.
Ui elements are in views.
Windows contain combination of views and flow between views.
'ource code is in wd controllers.
(ierarchical storage of global variables of controllers: conte)t.
Wd component can be address in * ways:
+. Wd application.
2. When reusing the wd component: visual interface and methods.
,onte)t mapping: variables defined in conte)t can be referenced
from other wd controllers.
-ata binding: automatic data transport between ui elements and
conte)t attributes established.
,ombining these two concepts: data transport between ui
elements located in different views can be defined.
Internal mapping: two controllers within same component share
data.
&)ternal mapping: two controllers in diff components share data.
"or mapping relationship to be established following step need to
be performed:
+. .ode must e)ist in controller conte)t as mapping node, this node
need not have any child nodes or attributes.
%. /apping origin controller must not be a view controller.
*. /apped node controller must declare the use of mapping
controller as used controller.
.avigation between views:
0utbound plug1navigation event raised1asynchronous event place
in navigation queue.
Inbound plugs1special event handler methods that subscribe to
navigation event raised when outbound plugs are fired. !hey are
called only when navigation queue is processed.
.avigation lins: both plugs #oined using this.
Window is set of views.
.esting views: viewcontrolleruielement, it can display one view at
a time.
2iew assembly: subset of views visible at a time.
/0-&3 2I&W ,0.!4033&4.
/0-&3: generates the app data.
2iew: displays the app data.
,ontroller: binds user and business interaction layers and
processes.
.avigation between windows of same components is not possible.
2iew controller can5t be declared as used controller.
.,omponent controller: properties, conte)t, attributes, events,
methods.
6roperties: used controller.
,omponent interface: interface controller, interface view.
Interface controller: properties, conte)t, methods, events.
Interface view: properties, inbound plug, outbound plug.
Inbound plug: plug type: startup, standard, resume.
0utbound plug: standard, e)it, suspend.
2iew: properties, layout, inbound plug, outbound plug, conte)t,
attributes, actions, methods.
7ction: type: standard, validation independent.
/ethod type: event handler, supply function, method.
Window: properties, window, inbound plug, outbound plug, conte)t,
attributes, method.
Window and component controller have checbo) of interface,
e)posing it to public.
0nly interface view and interface controller are visible to user.
&ach time a window is created, a interface view is automatically
created which allow the window accessible from outside the
component.
Interface view only e)posed those plugs which have interface
property checed.
.o window, view, interfaces view: faceless components having no
visual interface.
Wd app is entry point and is the only entity which can be
addressed by U43. It5s associated with inbound plug called
default of type startup in the interface view.
Wd component can be addressed by multiple application with
different interface view and inbound plug.
,ontroller types:
+. ,omponent controller: + per wd component, no visual interface,
global visible to all controllers.
%. ,ustom controller: can be multiple per component, use to
encapsulate sub functions of component controller.
*. ,onfiguration controller: + per component, special custom
controller, when component implements configuration and
personalization.
8. 2iew controller: flow logic.
9. Window controller: methods of this controller can be called from
inbound plug methods of window.
7ll controllers have two hoo methods: wddoinit and wddoe)it.
6redefined attributes to access functionality of controller:
wd:this, of conte)t: wd:conte)t.
&vents defined in component and custom controller: any method
of any other controller can register to these events if this
method is defined as event handler method.
0nly component controller has additional standard hoo methods:
wddobeforenavigation and wddopostprocessing.
'pecial entities of view controller: navigation plugs.
.avigation lins are defined in window not in views.
action: lin the client side event to an event handler method
defined in view controller.
!wo special hoo methods in view controller: wddobeforeaction
and wddomodifyview.
'pecial attribute in view controller: wd:comp:controller, this is
reference to component controller.
'pecial entities of window controller:
2iews are embedded in window.
For every node you create in the context of a controller, a constant with the
name WDCTX_<node name> is automatically created in the correspondin
interface !"_<Controller_#ame> and !F_<Controller_#ame>$ !n the source code
of the controller, this constant can then %e used for the node name instead of a
strin literal.
The interface controller defines the interface of a We% Dynpro component for
the use in another component$ The methods are implemented in the
component controller$ When you set the Interface fla for
methods&events&context nodes in the component controller, these elements
are copied into the interface controller$

'ttri%ute WD_C(#T)XT is a reference to the controller context$ *eardless of
the edited controller, it is always a reference varia%le of the type
!F_WD_C(#T)XT_#(D)$ +ou can use WD_C(#T)XT and the interface methods
to edit the content of a context node in your controller method$
"et_child_node, invalidate, et_attri%ute, %ind_element are methods of
interface if_wd_context_node$
)ach controller contains a local interface which can %e accessed in the
controller$The controller attri%ute WD_THIS is a reference to this local
interface$
each local controller interface has a fixed num%er of methods that can only %e
called %y the runtime$ The application developer cannot specify when these
methods are called, %ut can modify the implementation$ The time when these
methods are called is predefined$ For a description, refer to the phase
model of We% Dynpro$
WDD(!#!T is called automatically when a controller is initiali,ed for the first
time$ For each newly created controller, these methods are empty %ut can %e
filled with source code$ These methods can contain the followin steps, for
example-
Creatin instances of help classes
!nitiali,in controller attri%utes
!f you need more attri%utes for the prorammin and these are also reference
varia%les, they can %e initiali,ed here$
Trierin authori,ation chec.s /recommended for help classes0
1ettin initial values of the controller context
!nstantiation of used components
WDD()X!T is called %y the runtime when exitin the controller and can %e used
for releasin loc.s, for example$
Dependin on the controller settins, the local controller interface also
contains the methods WDD(2)F(*)#'3!"'T!(#, WDD(4(1T4*(C)11!#", and
WDD(5(D!F+3!)W$
)ach context node of a controller can %e assined a supply function$ This
supply function is called %y the runtime when the data of the context node is
used$ This is the case when a 6! element is to %e displayed for the first time
with the data of the correspondin context, for example$
!n eneral, the supply function is called when one or more elements of a
context node are accessed and when
the context node is not filled yet or is initial, or
the context node has %een invalidated in a previous step$
!f the lead selection is chaned %y the user, the supply function can access the
new lead selection element and recalculate the values of the su%node
elements accordinly$
1upply functions can only access context data that
is contained in the correspondin parent node or
is contained in another node that is on a next7hihest level compared to the
node filled %y the correspondin supply function$
!f possi%le, avoid raisin an exception in a supply function or in a method called
%y a supply function$ 1ince supply function is often called durin renderin,
these exceptions cannot %e processed sufficiently$
'lternatives for the supply function are the method WDD(!#!T and the event
handler of the controller$
The attri%ute WD_C(54_C(#T*(88)* is a reference varia%le of the reference
type !"_C(54(#)#TC(#T*(88)* and therefore a reference to the
correspondin component controller$ This is automatically .nown to each view
controller of the component$
The runtime interfaces offer multiple methods for different prorammin
areas$ These include, for example-
'ccess to the window manaer '4! !F_WD_W!#D(W_5'#'")* for creation of
popups usin existin We% Dynpro windows
'ccess to the portal interation '4! !F_WD_4(*T'8_!#T)"*'T!(#
Context processin
Creatin messaes
The method WDD(!#!T is the initiali,ation method of the controller$ !f you
.now %eforehand that the context in your application is only filled once and
not invalidated afterwards, this method is appropriate for fillin the context$
+ou can also use this method if you want to associate the data update with an
action and transfer the update to the correspondin event handler$
The method WDD(!#!T should only %e used to fill those context nodes when it
is .nown that they must %e filled$