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.

SEAM Enhancements

The event descriptor entries have equivalents within the attributes of the component tag that implement the source element. As demonstrated with the basic JSF components, the event handlers, parameters, etc. have place holders in the component attributes, or nested components within.

Seam expands the event handling to what is termed event orchestration, most of which use the page.xml configuration file. The facilities involve 1) Page Events, 2) Page Parameters, 3) Page Security, 4) Event Security and 5) Standard AJAX components. These are covered below.

Page Event

Whereas some frameworks have page events, JSF does not. Page events like PageLoad event, allows for events that must precede the loading of the page. Even non-component based platforms like Struts, have means of forcing an action to precede the loading of the page.

The specification of page action is as shown below.

The representation of the current page in the event descriptor is exclamation mark, and the event associated with the page is shown in the handler column.

The implementation would be reflected in the page.xml file for the application, or specific page.xml file for the page, which would have a name in this format view-id.page.xml. For our examples we would use the latter, which does not require specifying the view-id in page element, but on the file name.

The result of the specification shown in the descriptor above would be reflected in the configuration file as shown below.

<page action="#{categories.load}">

</page>

or

<page>
      <action execute="#{categories.load}">
</page>

In the page declaration, a page could be specified as an included page. This would be reflected in the descriptor as shown below.

For such a page, it would be meaningless to prescribe a page action, since it is the including page that would be controlling the actions.

Page Parameters

The need for the page parameters comes from the fact that JSF has a robust facility for post back, like object attributes population, conversion and validation, which does not apply to first time navigation to the page. What Seam provides is facility that could determine what HTML input to expect, either as form field or query string. Some of the facilities provided for post back fields could then be applied to these sets of parameters.

The specification of such parameters would be as follows.

NOTE: It should be noted that for compact specification these page event related attributes could be specified on the same line, however they are not related. As we shall see, their implementations are independent.

The parameters entry is specified as named item, which is stored in the parameters descriptor as shown below.

The implementation is shown below:

<page>
      <parameter name="type" value="#{category.type}">
</page>

If the page call-type is include, the parameters would not be in the page.xml, again the including page would be in control of the parameters passing.

The parameters implementation would be provided by the page that includes the page.

For discussion on the including pages and passing parameters, see the discussions on segment include the section on segment descriptor types.

Page Security

Page security is specified as shown below.

The security specification in this descriptor entails a comma delimited list of roles. The implementation is shown below.

<page>
      <restrict>#{s:hasRole('admin') || s:hasRole(?sales?)}</restrict>
</page>

Access could be specified for all role with the asterisk "*" entry as shown below.

The implementation of this is shown below.

<page login-required="true">
</page>

This implies that authenticated users, irrespective of their roles, are allowed access. Whereas the absence of the asterisks or role declaration, would imply that login required is false.

Event Security

Seams also provide security specifications for invoking event handlers. Any event associated with event sources on the page, could have security specification.

Example is shown below.

This is an event from within the page, and not a page event as such. The implementation of this would be through annotation in the action class.

class CategoryAction {
	@restrict(#{s:hasRole('admin')})
	String save()
	{
		return doOperations();
       }
}

AJAX

Whenever a call-type of ajax is prescribed, as shown in the descriptor below, there are two potential implication. First, an AJAX aware component should be prescribed, or AJAX extender must be in use.

AJAX aware components are listed along with their standard relatives in the element descriptor overview. There is a special section on the ajax call type, which covers the extender component and the implementation of AJAX specifications.

Event and Conversation

Seam includes a conversation context, which plays a major part in presenting objects and data for specific use cases. The control of the life cycle of these conversations is normally in the scope of activities in the controller tier. Seam provided annotations for start, end, join, etc activities on invocation of action methods.

In the alternate, or along with these annotations, there is a provision for controlling the life cycle from the view. Event sources would be specified with commencement or ending of conversations. A full conversation on this is provided in the section on Events and Conversations.