Event Handling 

Purpose

Events are the triggers that cause the Web Dynpro runtime environment to respond to some sort of user action. Web Dynpro makes use of the following trigger types:

·       Actions

·       Events

·       Actions

In an MVC environment in which the view and controller execute on the same host, it is possible for a method within the controller to subscribe directly to an event raised by a UI element within a view.  This permits the view and the underlying controller to function in a closely coupled manner.

However, such close coupling is not possible in a web-enabled environment due to the fact that the view and controller layers are separated from each other by the stateless HTTP layer. This immediately enforces a courser level of communication granularity between client and server.

In such an environment, a client-side event raised by a UI element can only invoke server-side processing if an HTTP request/response cycle is initiated.  Web Dynpro therefore uses an event abstraction known as an “action” to cause client-side event information to the transported to the server.

Process Flow

Actions

You can think of an action as the bridge that takes the event information raised by a UI element in the client, reaches across the stateless HTTP layer and connects to the corresponding event handler in the view controller. This design approach provides the following advantages:

A level of abstraction is achieved between the UI element layer and the event handler layer in the view controller. This permits a high degree of independence between the client and the server.

If a complex UI layout requires the use of many different event handlers, a generic action can be created which is raised by a wide set of UI elements. Specific events can then be distinguished from each other by means of action parameters.

Actions are runtime objects that can be enabled and disabled dynamically.

If an action is bound to a primary UI element event, then the entire UI element is disabled when the associated action is disabled and vice versa.  An example of a primary UI element event is the onSelect event on a checkbox.

If an action is bound to a secondary UI element event, then the entire UI element is not disabled when the associated action is disabled.  An example of a secondary UI element event is the onLeadSelect event on a table.

Actions can only be defined within a view controller.

If required, the SAP NetWeaver Developer Studio will automatically create an event handler method within the view controller when an action is created.

Actions can be created at runtime, and dynamically bound to UI elements (which can also be created at runtime). However, you cannot dynamically create event handlers since this would require the creation of Java source code; which in turn, would require a dynamic alteration to the deployed code within the J2EE Engine. Such runtime modifications are not supported.

At runtime, if you choose to disable an action that is bound to a UI event, then

Another way to look at this is to consider the behaviour of the UI element when the associated action is disabled. If the entire UI element is deactivated as a result of disabling the action, then that UI element will be an evaluation candidate for a call to requestFocus().

Certain composite UI elements such as tables can trigger events which, if disabled, do not render the entire UI element disabled. For instance, a table can trigger the onLeadSelect event, but this merely indicates the user has selected a different row in the table. On contrast to this, a checkbox UI element can raise an onSelect event.

Events

Events in the Web Dynpro runtime environment are synonymous with events in the Java world. Using your design time declarations, the Web Dynpro runtime environment will automatically manage the definition, triggering and handler subscription to such events for you. You also have the additional option of dynamic event subscription at runtime.

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 defined in the component controller.

If two or more methods subscribe to the same event, then when that event is triggered, the order in which those methods will be executed is undefined.

Events can be defined in all controllers except view controllers and interface view controllers.

Web Dynpro Phase Model

When the Web Dynpro runtime environment receives a client request, it performs a standard cycle of processing phases.  Some of these processing phases are designed to handle specific actions, whilst others phases behave in a more generic manner. Within each phase, actions are processed that may cause events to be raised.  Such events are held in an event queue.  The processing of any particular phase is considered complete once its event queue is empty.

The client request processing phases are described in the following figure.