This captures all events that could originate from the page, including information on the handler objects that process these events on the server side.

It should first be noted that events involving client scripting like mouse over effects, are not captured by the event descriptors. These specifications are strictly in regard to page interactions with the server.

In short, the event descriptors capture specification on 1) all event triggers on the page, and 2) provide associations between them and their handlers on the server side.

One method of providing handlers to page events is through backing beans or code behind. In these cases, backing beans or code behind that contain these handlers, would be declared in the behavior-define descriptors, along with other objects exposed to the page. It is based one these defined objects that the method bindings used for event handling are specified in the event descriptor.

Another way to expose handler object for use on the page is by associating a URL path to the event handler. This URL path, with optional method designation, would then be specified as the handler for the event. These are rarely involving page event, but more related to action events. As such, they are referred to as action paths, and action handlers.

dWebSpec provides for both means of exposing handlers to the page.

What is available on the Struts platform is the path association/action handler scheme.

Action Definition

dWebSpec provides means for the capture of this path to handler association, as shown in the figure below.

The action path is shown as the "handler" above. This could have "/" in organizing the paths. This path would be implemented to appear like URL destination, which could be linked or navigated to, with the default extension .do appended. (/categoryData.do).

Entries in this descriptor would be used for the registration of the action definition. The entries are transformed into the action mapping, typically stored in struts-config.xml.

Action Sources Associations with their Handlers

The scheme for action definition and implementation is shown in the section above. In this section we discuss the event source association with the handler; their specification and implementation.

The event descriptor that captures the action definitions also captures how the elements on the page use such definition. However, it is easy to differentiate between such definition from the association of event sources to the event handlers. This is illustrated with the figure below.

The specification described earlier involves the action-path to handler association. The specification described here involves the usage of such action-path by elements on the page.

The id of the descriptor entry captures the identity of the specification and any unique entry would do. However, tying this to the identity of the action-path in use provide better clarity.

The event source would capture the element that triggers the event. On some platforms, it is necessary to include event types (change, select or action) along with the event source. For Struts, all that is available are action events, as such, the specification of the event type is not necessary.

The next important specification is the associated handler. This is the action path in use, and any method within it that is invoked {action-id.method}. In the absence of the method specification, it would be implied that the default method would be invoked (execute()).

Implementation

Part of the implementation includes the conversion of the source element into active components. The reference on this conversion is provided in the discussion on the element descriptor.

Although the correspondence of such types to their Struts equivalent is easy to discern, there is a particular case whereby the event-call-type could influence such mapping.

Whenever the immediate call type is specified, the html:cancel button should be used. This is the only button that would cause the bypass of the auto-population and validation scheme, thus providing the immediate effect.

Action Mapping to Event Source

The implementation of the action mapping to the event source is partially taken care of by the implementation of the enclosing form.

The representation of such form in the final code would carry the designation of action associated, which would appear as follows.

<html:form action="categoryData" />

This is covered in the discussion involving the form descriptor implementation.

As such, a submitButton would be associated with an action within the specification, which would be implemented as the action associated with the enclosing form. Apart from the conversion of the HTML input submit button to the Struts equivalent, nothing else need to be done, as far as the handler association.

This association is not automatic with the element of the button type, a javaScript submit action must be included in the "onclick" event as shown in example below:

<html:button value="Submit" onclick="self.document.forms[0].submit" /> 

This would appear unnecessary, since the use of submitButton type would achieve the same thing without the need for scripting. However, there is a restriction on the latter that would assume that all the buttons are submitting the enclosing form. Although one could introduce client scripting to change this. The on click scripting would also allow the inclusion of client validations, beyond what comes standard with the Struts Validator framework.

Method Binding

As discussed earlier, there are two issues involved in the implementation of the event descriptor specification, 1) involve action path definition, and the other 2) involve event source to handler mapping. We have determined the 1) action mapping is implemented with entries in the configuration file. Whereas 2) the effect of the event source to action mapping is reflect in the enclosing form action designation.

The handler binding is action handler part of the handler specification {action-handler.method}.

As discussed thus far, the implementation would be complete, if there were no method specification within the handler, or if the default method, execute(), were specified.

Because of the indirection involved in associating the event source with the handler, the full implementation of the method binding could be achieved in multiple ways, each having its own advantages or disadvantages.

One implementation scheme involves the following entries in the configuration file, as shown below. This definition would allow the invocation of this handler/method {createCategoryData.create) by using the path /createCategoryData.do.

What we have done, in effect, is to creat an action mapping for each handler/method combinations; this could lead to many similar definitions. This might or might not be an issue. Unfortunately there are other reasons, like different roles, validations, etc., that would require different mapping definitions for a single handler class.

There are other alternatives that could be used, that would allow using a single action mapping with multiple method binding. In selection one of these options, one must selection an action base class; the default base class is Action. The speicifications are identical, but there are multiple implementation options

POST

The implementations discussed above involve POST event. This would be the assumption based on the dependence on the submit action and form-bean.

GET

The implementations involving GET action is different. The main difference is that the parameters do not have to be form-bean, and in most cases they would involve more fine grained parameters.

As discussed earlier, the implementations of event source specifications are indirectly associated with the event source through the enclosing form. For the get events, the implementations are reflected directly in the tag for event source.

Example below is an event involving an element of type link: forms[categoryForm].elements[actionLink].

This link is handler is "categoryData", passing parameters menuList, which is defined in the parameters descriptor. For simplicity, let us assume that the define parameter involves a single key/value parameter as follows:

The implementation would be as follows:

	  <html:link action="categoryData"
		parameterId="action" parameterName="actionList">
  			Categories List
  	  </html:link>
  

If there were method selections, this would also be reflected through the parameters passed.

This example is used to contrast the post event where the action and parameters are defined in the configuration information and referred implicitly through the enclosing form. There are more discussions about specifying and implementing parameters in the discussion on the parameters descriptor.

AJAX

The recording of AJAX requests are mostly the same with the other GET request, except for the fact that the option is "ajax" is included in the event specification in the descriptor. It should be noted that an action definition could not be specified with "ajax", it is its usage (event-source to action association) that could be specified with the ajax option.

Unlike other events, AJAX could target elements or segments. When they target elements, it is usually to refresh data, which is a data mapping issue. When they target segment, it is a re-rendering issue.

For the data mapping issue, it is a matter of good practice to utilize the same data mapping for the initial rendering and the subsequent AJAX refresh.

For partial re-rendering, the specification of the target segment is captured, by reflecting the event id for the AJAX action on the target segment. For further discussion on this, refer to the segment descriptor.

For discussion on the implementation of the AJAX specification, follow the provided link.

More details are available in the attributes descriptions