Event Firing"

From Documentation
m
 
(15 intermediate revisions by 3 users not shown)
Line 7: Line 7:
 
= Post an Event =
 
= Post an Event =
  
Posting is the most common way to trigger an event. By posting, the event is placed at the end of the system event queue<ref>Please don't confuse it with the event queues discussed in the [[ZK Developer's Reference/Event Handling/Event Queues| event queues]] section, which are application-specific, while the system event queue is invisible to application developers.</ref>, while events stored in the system event queue is processed one-by-one in first-in-first-out order. Each desktop has one system event queue and all events are handled sequentially.
+
Posting is the most common way to trigger an event. By posting, the event is placed at the end of the system event queue<ref>Please don't confuse it with the event queues discussed in the [[ZK Developer's Reference/Event Handling/Event Queues| event queues]] section, which are application-specific, while the system event queue is invisible to application developers.</ref>. Events stored in the system event queue are processed one-by-one in first-in-first-out order. Each desktop has one system event queue and all events are handled sequentially.
  
 
To trigger an event, you could invoke <javadoc method="postEvent(java.lang.String, org.zkoss.zk.ui.Component, java.lang.Object)">org.zkoss.zk.ui.event.Events</javadoc>. For example,
 
To trigger an event, you could invoke <javadoc method="postEvent(java.lang.String, org.zkoss.zk.ui.Component, java.lang.Object)">org.zkoss.zk.ui.event.Events</javadoc>. For example,
Line 15: Line 15:
 
</source>
 
</source>
  
In additions to post an event to the end of the system event queue, you could specify a priority with <javadoc method="postEvent(int, java.lang.String, org.zkoss.zk.ui.Component, java.lang.Object)">org.zkoss.zk.ui.event.Events</javadoc>. By default, the priority is 0. The higher the priority the earlier an event is processed.
+
In addition to posting an event to the end of the system event queue, you could specify a priority with <javadoc method="postEvent(int, java.lang.String, org.zkoss.zk.ui.Component, java.lang.Object)">org.zkoss.zk.ui.event.Events</javadoc>. 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 system event queue. In other words, the event won't be processed unless all other events posted earlier or with higher priority are processed.
+
Notice that the invocation returns after placing the event in the system event queue. In other words, the event won't be processed unless all other events posted earlier or with higher priority are processed.
  
 
<blockquote>
 
<blockquote>
Line 26: Line 26:
 
= Send an Event =
 
= Send an Event =
  
If you prefer to trigger an event to a component directly and process it immediately without going through the event queue, you could use <javadoc method="sendEvent(java.lang.String, org.zkoss.zk.ui.Component, java.lang.Object)">org.zkoss.zk.ui.event.Events</javadoc> to trigger the event.
+
If you prefer to trigger an event to a component directly and process it immediately, rather than placing it in the system event queue and waiting for execution, you could use <javadoc method="sendEvent(java.lang.String, org.zkoss.zk.ui.Component, java.lang.Object)">org.zkoss.zk.ui.event.Events</javadoc> to trigger the event.
  
 
<source lang="java">
 
<source lang="java">
Line 32: Line 32:
 
</source>
 
</source>
  
Notice that the <tt>sendEvent</tt> 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).
+
<javadoc method="sendEvent(java.lang.String, org.zkoss.zk.ui.Component, java.lang.Object)">org.zkoss.zk.ui.event.Events</javadoc> won't return until all handlers and listeners registered for this event have been processed. You could image it as a method of invocation. Also notice that the event handlers and listeners are invoked directly without starting any event threads (no matter whether the event thread is enabled or not<ref>By default, the event thread is disabled. Please refer to the [[ZK_Developer's_Reference/UI_Patterns/Event_Threads|Event Threads]] section for more information.</ref>).
 +
 
 +
<blockquote>
 +
----
 +
<references/>
 +
</blockquote>
  
 
= Echo an Event =
 
= 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.
+
Echoing is a way to delay event processing until the next AU request (aka., Ajax) 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.
+
More precisely, the event being echoed won't be queued into the system event queue. Rather, it asks the client to send back an AU request immediately. Furthermore, after the server receives the AU request, the event is then posted to the system event queue for processing.
  
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 <i>echoed</i> back from the client.
+
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 <i>echoed</i> back from the client. Here is an example of using <javadoc method="echoEvent(java.lang.String, org.zkoss.zk.ui.Component, java.lang.Object)">org.zkoss.zk.ui.event.Events</javadoc>:
  
 
<source lang="java">
 
<source lang="java">
Line 46: Line 51:
 
</source>
 
</source>
  
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 processed, or he doesn't, say, click the button successfully. 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 more information, please refer to the [[ZK Developer's Reference/UI Patterns/Long Operations/Use Echo Events|Long Operations: Use Echo Events]] section.
+
Event echoing is useful for implementing a long operation. HTTP is a request-and-response protocol, so the user won't receive any feedback until the request has been served and responded. Thus, we could send back some busy messages to let the user know what has happened, and echo back an event to do the long operation. For more information, please refer to the [[ZK Developer's Reference/UI Patterns/Long Operations/Use Echo Events|Long Operations: Use Echo Events]] section.
 
 
=Version History=
 
  
{| border='1px' | width="100%"
 
! Version !! Date !! Content
 
|-
 
| &nbsp;
 
| &nbsp;
 
| &nbsp;
 
|}
 
  
 
{{ZKDevelopersReferencePageFooter}}
 
{{ZKDevelopersReferencePageFooter}}

Latest revision as of 09:50, 26 January 2024

Events are usually fired (aka., triggered) by a component (when serving the user at the client). However, applications are allowed to fire 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 system event queue[1]. Events stored in the system event queue are processed one-by-one in first-in-first-out order. Each desktop has one system 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 addition to posting an event to the end of the system 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 in the system event queue. In other words, the event won't be processed unless all other events posted earlier or with higher priority are processed.


  1. Please don't confuse it with the event queues discussed in the event queues section, which are application-specific, while the system event queue is invisible to application developers.

Send an Event

If you prefer to trigger an event to a component directly and process it immediately, rather than placing it in the system event queue and waiting for execution, you could use Events.sendEvent(String, Component, Object) to trigger the event.

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

Events.sendEvent(String, Component, Object) won't return until all handlers and listeners registered for this event have been processed. You could image it as a method of invocation. Also notice that the event handlers and listeners are invoked directly without starting any event threads (no matter whether the event thread is enabled or not[1]).


  1. By default, the event thread is disabled. Please refer to the Event Threads section for more information.

Echo an Event

Echoing is a way to delay event processing until the next AU request (aka., Ajax) is received.

More precisely, the event being echoed won't be queued into the system event queue. Rather, it asks the client to send back an AU request immediately. Furthermore, after the server receives the AU request, the event is then posted to the system event queue for processing.

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. Here is an example of using Events.echoEvent(String, Component, Object):

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

Event echoing is useful for implementing a long operation. HTTP is a request-and-response protocol, so the user won't receive any feedback until the request has been served and responded. Thus, we could send back some busy messages to let the user know what has happened, and echo back an event to do the long operation. For more information, please refer to the Long Operations: Use Echo Events section.



Last Update : 2024/01/26

Copyright © Potix Corporation. This article is licensed under GNU Free Documentation License.