事件的監聽和處理      本章將描述事件是如何處理的 通過事件監聽器發送和提交事件做為事件接受的

補充，應用應當可以通過向事件監聽器提交和發送事件在事件監聽器之間交流。

      提交事件
通過使用類org.zkoss.zk.ui.event.Events的postEvent方法，一個事件監聽器可以提交一個事件到一個

事件隊列的隊尾。將事件放置完畢后立即返回。直到該事件之前的事件均被處理后，該事件才被進行處

理。

發送時間
       通過使用類org.zkoss.zk.ui.event.Events的sendEvent方法，一個事件監聽器可以使ZK立刻處

理一個指定的事件。直到所有的指定事件的事件監聽器都被處理了才返回。事件是在同一個線程中處理

的。

線程模型
對于每一個桌面，事件是順序處理的，所以線程模型是很簡單的。類似于開發桌面應用，你不需要去擔

心多線程。你所需要去做的是登記事件監聽器和被調用時候的處理代碼。

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

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

掛起和恢復
對于高級的應用，你可能需要掛氣一個執行知道滿足繼續執行的條件。類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);

       }

}