The entry could vary, depending on whether it is part of path declaration/definition, or being used to capture the processing for an event source.

Path association:

There are schemes that would associate a handler class with a path. For such schemes this field would be used to capture the path.

Example: /createInvoice.

The actual path specification could vary with platform or with specific configuration, when such configurations are permitted.

NOTE When referencing the path definition, in the rest of specification, it is the event id attribute that should be used and not the path. Example of such reference could be found in the navigation-path descriptor. The id is used instead of the path that could be long and could contain slashes.

Event Source to Handler Mapping:

Although, the descriptor allows the association of paths with handler, its primary usage involves the capture of event sources, and the handling of the events that they invoke. For this, the entry here is the handler object, and the method within it that would be invoked. The method could be optional, if there were a default.

The entry would be as shown below.

            {object-id.callMethod}

The object being any object that is declared with the behavior of the define type.

When path association is used, the event id of the path association definition or declaration would be used instead of the object-id. This is necessary because with this scheme, there is no runtime id provided for the handler object, it is reachable through the provided path definition.

Thus this specification reduces to the following:

            {<action path identity>.callMethod}

Depending on the path association scheme, which is configurable on some platform, associated method might be defined along with the handler-class. There also could be a default method. In these cases, it might suffice to specify the <event id of path decl.> without any method.

Direct: there are cases where the action would forward directly to a page, without any method invocation. In such cases, the call-type attribute, described below, would be designated as "direct". This attribute would be left blank, and the path recorded against the event-id, in the navigation-path descriptor. 

Method Binding

The representation of the handler is usually in the form of method binding; that is the object and method {object.method) that handles the event would be represented here.

The object would be a backing bean, and the method within would be the handler. The object itself would be defined in a behavior descriptor, like any other object exposed to the view tier.

For the value change and action event, there are attributes provided for JSF components that would reflect the handler. (actionaListener or valueChangeListener)

	<h:commandButton value="Next" actionListener="#{wizard.nextPage}"/>

Handler class that provides the anonymous handler is represented in the hander-class specification. This is an alternate means of representation; handler class and handler entries are mutually exclusive.

The information provided above pertains to all events. There is a particular aspect that pertains to action events only.

Whereas other listener events handlers always return void, action events always return a string. This string is used by the navigation rule to determine the next page to navigate to, if such rules are set. Common result strings are success, failure, back, next, etc. A null string would imply, returning to the page that started the invocation.

Navigation result

In place of the handler expression, a literal string could be provided in the specification that represents a result.

If such literal string, or binding that returns such string is specified, the entry goes into JSF component action attribute as shown below.

	<h:commandButton value="Next" action="next"/>