InetSoft Product Information: Server-Side Report Event Handling

The advantage of client-side event handling is its high efficiency. Because all processing is done in the viewer process, no network traffic is generated. This also eliminates the need for marshalling and marshalling for object passing. However, client-side event handling is not sufficient for all situations.

Because the event to command mapping is created before the event is triggered, the mapping is static and cannot be changed when the event is generated. Sometimes it is necessary to have programming logic in place to determine what to do by checking the actual event contents. This is supported by the second stage of event processing, server-side event handling.

When an event is generated, the client-side Event Handler is always checked first to see if a mapping exists for that event. If a mapping is found for the event, the corresponding command is executed on the client and the event is considered completely processed.

If the client-side handler does not have any mapping for the event, the event is forwarded to the server. The server then sends the event to the event listener in the replet. Mouse events are never sent to the server due to their high frequency. They must be handled in the client-side event handler.

Replet events and listeners

Each listener has one method, valueChanged(). The listener method takes a parameter with the type of the event the listener handles and returns a RepletCommand object.

RequestListener listener = new RequestListener() {
public RepletCommand valueChanged(RequestEvent e) {
EventPoint item = (EventPoint) e.getSource();
//Finding the X axis label which was clicked in a chart
// chart is an object of the ChartLens class
String dstr = chart.getLabel(item.x);
....
}
};
addRepletSelectionListener("Chart1", null,
listener);
 
addRequestListener(listener);

Replet Event	Listener
RepletMenuEvent	RepletMenuListener
SelectionEvent	RepletSelectionListener
RequestEvent	RequestListener

If no listener is registered for an event, the event is discarded, except the RequestEvent. RequestEvent has a default handler in the server. If no user listener is registered for the RequestEvent, the server calls the createReport() method on the replet and sends back a Refresh command to the viewer.

The replet is responsible for checking the type (name) of the request in createReport() and performs any process appropriate for that request. The viewer will reload the pages after receiving the Refresh command and will display any changes made in the createReport() method.

Summary of Replets

A replet is an executable report. It can be parameterized to produce different types of reports. Because a replet can produce completely different reports based on parameter values, it is possible (though not recommended) for a reporting system to use only one replet to produce all reports.

Replets are organized in a hierarchical structure in the repository. Although the name of the replet resembles a file path, it has no relationship to the location of the file on the file system. Neither does it have any relationship to the package to which a replet belongs. A replet class is loaded as a regular Java class.

There are multiple entry points for parameters to be passed to a replet: replet creation time, replet initialization, user-initiated customization, or replet-initiated parameter prompting.

The BasicReplet API provides a few high-level methods for adding common interactions, such as hyper-links and popup menus. A programmer can also use the generic event handling API to add custom event handling to a replet.

Previous: Example of a Report Event Handler

Next: Browse Reports From a Web Browser