本章将描述事件是如何处理的 通过事件监听器发送和提交事件做为事件接受的

补充，应用应当可以通过向事件监听器提交和发送事件在事件监听器之间交流。

 1、 提交事件
      通过使用类org.zkoss.zk.ui.event.Events的postEvent方法，一个事件监听器可以提交一个事件到一个

事件队列的队尾。将事件放置完毕后立即返回。直到该事件之前的事件均被处理后，该事件才被进行处

理。

2、发送时间
       通过使用类org.zkoss.zk.ui.event.Events的sendEvent方法，一个事件监听器可以使ZK立刻处

理一个指定的事件。直到所有的指定事件的事件监听器都被处理了才返回。事件是在同一个线程中处理

的。


3、线程模型
对于每一个桌面，事件是顺序处理的，所以线程模型是很简单的。类似于开发桌面应用，你不需要去担

心多线程。你所需要去做的是登记事件监听器和被调用时候的处理代码。

       小提示：each event listener executes in an independent thread called event

processing thread.while the ZUML page is evaluated in the servlet thread.


4、挂起和恢复
对于高级的应用，你可能需要挂气一个执行知道满足继续执行的条件。类org.zkoss.zk.ui.Executions

的Wait,notify和notifyAll方法提供这些支持。


当一个事件监听器想挂起自己，它可以调用wait方法。另一个线程在应用指定的条件下可以通过调用

notify或者notifyAll来唤醒该进程。下面是一个使用这种机制的例子。

Public void doModal() throws InterruptedException{

       Executions.wait(_mutex);

}

Public void endModal(){

       Executions.notify(_mutex);

}

这样的使用类似于类java.long.object的wait,notify和notifyAll的用法。尽管如此，你还是不能使用

java.lang.Object的方法来进行挂起和恢复事件监听器的操作。否则，关联到这个桌面的所有事件处理

都将被停止。


注意，不同于java object的wait和notify方法，是否使用synchronized锁来关闭Executions的wait和

notify是可选的。在上面的例子中，我们不需要这样做，因为没有没有可能的racing condition。尽管

如此，如果存在racing condition，你可以象在java Object中使用wait和notify那样使用synchronized

block。

//thread 1

Public void request()

{

Synchronized (mutex)

{

              Executions.wait(mutex);

}

}

//thread 2

Public void process()

{

       Synchronized(mutex)

       {

              Executions.notify(mutex);

       }

}