ZK Developer's Reference/Event Handling/Event Firing

Overview

Events are usually fired (aka., triggered) by a component (when serving the user at the client). However, applications are allowed to send events too.

There are three ways to trigger an event: post, send and echo.

Post an Event

Posting is the most common way to trigger an event. By posting, the event is placed at the end of the event queue, while events stored in the event queue is processed one-by-one in first-in-first-out order. Each desktop has one event queue and all events are handled sequentially.

To trigger an event, you could invoke Events.postEvent(String, Component, Object). For example,

Events.postEvent("onClick", button, null); //simulate a click

In additions to post an event to the end of the event queue, you could specify a priority with Events.postEvent(int, String, Component, Object). By default, the priority is 0. The higher the priority the earlier an event is processed.

Notice that the invocation returns after placing the event to the event queue. In other words, the event won't be processed unless all other events posted earlier or with higher priority are processed.

Send an Event

If you prefer to trigger an event to a component directly and process it immediately without going thru the event queue, you could use Events.sendEvent(String, Component, Object) to trigger the event.

Events.sendEvent("onMyEvent", component, mydata);

Notice that the sendEvent method won't return until all handlers and listeners registered for this event has been processed. Also notice that the event handlers and listeners are invoked directly without starting any event thread (even if the event thread is enabled).

Echo an Event

Echoing is not really a way to trigger an event. Rather, it is a way to delay the posting of an event, until all events are processed, the response is sent back to the client, and a request is received.

More precisely, the event being echoed won't be queued into the event queue. Rather, it causes ZK to send back a special response that will cause the client to send back a request immediately. Furthermore, the request will then trigger the event at the server.

In other words, the event won't be processed in the current execution. Rather, it is processed in the following request when the event is echoed back from the client.

   Events.echoEvent("onMyEvent", component, mydata);

Prompt the User before Doing a Long Operation with Event Echoing

Event echoing is useful for implementing a long operation. HTTP is a request-and-response protocol, so the user won't see any feedback until the request has been served and responsed. Thus, if the processing of a request takes long to execute, the user has no idea if the request is being process, or he doesn't, say, click the button successfully. The user usually tends to click again to ensure it is triggered, but it only causes the server much slower to response.

The better approach is to send back some busy message to let the user know what happens, and then process the long operation. It can be done easily with event echoing.

For example, assume the long operation is called doLongOperation, then:

<window id="w" width="200px" title="Test echoEvent" border="normal">

 <attribute name="onLater">
 doLongOperation(); //take long to execute
 Clients.showBusy(null, false); //done
 </attribute>

 <button label="Echo Event">
 <attribute name="onClick">
 Clients.showBusy("Execute...", true); //show a busy message to user
 Events.echoEvent("onLater", w, null); //echo an event back 
 </attribute>
 </button>

</window>

Better Feedback with Button's autodisable

With event echoing, it might still take hundreds milliseconds to have the busy message, especially with the slow connection. The feedback to user can be further improved by use of Button.setAutodisable(String). For example,

  <button label="Echo Event" autodisable="self">
...

Then, the button will be disabled automatically when it is pressed, and enabled automatically when the request has been served.

---