事件無疑是AJAX應用中最重要的部分，EXT將事件分為了兩種：自定義事件與瀏覽器事件。

自定義事件
按字面意思就是用戶自己定義的事件，這個事件通常與組件相關。并且需要用戶根據組件的狀態自己觸發。相關的類Ext.util.Observable 、Ext.util.Event（Observable.js）。Ext.util.Observable是所有組件（component）的父類，它使得所有的組件都可以任意的添加自定義事件，它的events屬性對事件進行維護，這些事件實際都是Ext.util.Event對象，Ext.util.Event對象里的listeners屬性對與該事件相關的處理器進行維護。Observable給所有的子類提供了一個統一的接口來發布事件以及管理事件，這一特性對于組件來說是至關重要的。

瀏覽器事件
即傳統意義上的鼠標單擊、移動等等事件，這些事件是由瀏覽器根據用戶的動作自己觸發的，與頁面元素緊密關聯。相關的類Ext.Element 、Ext.EventManager、Ext.EventObject、Ext.lib.Event 。Element包含了常見的DOM方法和屬性，提供一個快捷的、統一的、跨瀏覽器的接口，內置了常用的DOM節點的動作，并且是跨瀏覽器的定位的位置、大小、動畫、拖放等等。對事件的處理，Element實際將這一處理委托給了EventManager，由EventManager對頁面所有的瀏覽器事件進行管理，例如增加事件處理器、移除事件處理器等等，另外EventManager還定義了幾個很重要的方法：onDocumentReady、onWindowResize、onTextResize。其中onDocumentReady尤為重要，通常在頁面需要通過它來啟動我們的AJAX程序，它會在頁面document渲染完畢而圖片等還未下載時調用我們的啟動函數。至于EventObject，它則是對原始的瀏覽器事件進行了封裝，提供給事件處理器一個統一一致的事件接口。Ext.lib.Event呢？EventManager的很多功能其實是調用它完成的，它的listeners、unloadListeners維護著所有的事件處理器。 正在翻譯《Enterprise AJAX》，附錄里介紹到OPENAJAX HUB，google相應的中文資料很少，所以就把譯文貼出來：）

OpenAjax Hub（“Hub”）主要用來處理Web應用開發者需要在同一個應用中同時使用多個AJAX運行庫的情況。它提供標準的JavaScript，當被包含在AJAX驅動的Web應用里時，它使得多個AJAX工具包能夠在同一個頁面里一起協同工作。

AJAX應用開發者在開發中的需求往往存在著巨大的差異，這導致了如今市場上存在超過200個各種各樣的AJAX產品，同時這些產品的架構和特性也存在巨大的差異。對一些開發者來說，他們認為開發中最重要的因素是找到一個能提供與后端服務器強大集成能力的AJAX工具包。

而對其他一些開發者來說，最重要的因素則是能否應用特殊的客戶端組件（例如，富數據網格組件或交互式的圖表組件）。結果，AJAX生態系統發展到現在，開發者在大部分時間里都能找到滿足他們每個特殊需求的AJAX工具包，但是也存在問題，他們往往必須在同一個Web應用里混合和匹配使用多個AJAX工具包才能滿足所有的需求。 

Hub應用的一個重要場合是門戶和內容糅合，這里，應用開發者創建一個頁面，頁面里松散組裝預先包裝好的應用組件。Hub實際上是保證這些AJAX驅動的應用組件能夠使用多個不同的AJAX工具包創建。

主要特性：Hub 的發布/訂閱管理器

Hub的主要特性是它的發布/訂閱管理器（“pub/sub管理器”）。 pub/sub管理器允許內容糅合的一個部分能夠傳播其他應用組件所訂閱的事件。例如，假設存在一個日歷組件，該組件允許用戶能夠選取一個特定的日期。內容糅合里可能存在多個UI組件，這些組件都需要根據新選擇的日歷日期而更新它們的視覺外觀。在這種情況下，日歷組件將發布一個“新日歷日期”的事件，而其他可視化組件將訂閱這個事件。因此，pub/sub管理器的通用消息的優點是給由不同AJAX工具包所構建的組件之間提供了一個關鍵的集成機制。

Hub的pub/sub管理器提供各種各樣的先進特性，例如對事件名稱通配符的強大支持，在下面的例子里并沒有展示這個特性。

范例

讓我們假設現在有這樣一個商務智能應用，該應用使用下面的AJAX運行庫：

■ UTILS.js, 對瀏覽器的JavaScript環境提供非常有用的擴展，例如XMLHttpRequest的APIs。

■ CALENDAR.js,提供一個日歷組件

■ CHARTS.js, 提供一個圖表組件

■     DATAGRID.js,提供一個交互式的數據網格組件

該應用有一個唯一的日歷組件，用戶可以以圖表組件的形式（例如，每日情形、每周情形、每月情形和每年情形的柱狀圖）和數據網格組件的形式（例如，地方數據與全國數據，兩種數據都以用戶選擇的感興趣的列展示）選擇其中的一些數據視圖當一個新的日期在日歷組件里被選擇時，各個用戶指定的可視化組件（例如，圖表和/或數據網格組件）都需要被更新。

實現該應用的一個方法是在加載其他AJAX庫之前加載OpenAjax Hub的JavaScript。例如：

 

一些AJAX運行庫包含OpenAjax Hub，將Hub作為它們標準發布的一部分，在這種情況下，只要特定的AJAX運行期的JavaScript（譯注：這里特定的JavaScript指的就是包含OpenAjax Hub的AJAX運行庫的代碼）在其他兼容OpenAjax的運行庫之前被加載，那么則沒有必要為OpenAjax.js使用一個單獨的<script>元素。

要使應用工作，開發者需要注冊一個回調函數，當用戶在日歷組件里選擇一個新的日期時調用該函數。這個回調函數接著使用OpenAjax Hub的publish()函數傳播這個新日期事件：

 

接著開發者需要開發這樣一些代碼：所有的圖表組件和數據網格組件都要訂閱這個新日期事件，并要提供一個回調函數。各個回調函數將相應地更新特定的可視化組件：

未來支持OpenAjax Hub的工具包

OpenAjax聯盟正與工業界一起合作，達到對OpenAjax Hub的廣泛支持。一個特殊的AJAX工具包可以像下面這樣支持OpenAjax Hub：

■ AJAX工具包可以包含Hub（最好的方式）。Hub可以被小于3K的JavaScript實現，所以一些AJAX工具包簡單地捆綁Hub，將它作為它們工具包的一個標準組件。

■ 如果Hub在運行環境里可用則使用它。其他一些AJAX工具包可能決定在它們的發布中并不包含Hub，它們會檢查Hub是否早先已經被加載了，如果已經加載，它們則直接使用Hub的服務。 

■第三方的開發者可以開發適配器。對大多數工具包來說，它們可能允許第三方的開發者編寫少量的JavaScript使得自己能夠支持Hub。

當AJAX工具包包含內置對Hub的支持時，應用開發者的工作將更加容易，但是通過查找或編寫適配器的方式，Hub依然可以被那些并未實現支持Hub的工具包所使用。

其實本沒打算看這部電影來著，其實是等著德甲來著，然而，德甲還沒有開始，百無聊賴地那么一按，就看到了《火柴人》，其實如果不是尼古拉斯·凱奇我也早繼續換臺來著。

“一二三，開門”，習慣性隨著短促咳嗽而來的眨動的左眼，潔癖的讓人抓狂的種種，呵，真是個煩躁的男人。

故事開始，詐騙亦開始，中間向體育頻道換過好幾次頻道，溫吞的故事，毫無新意的詐騙過程，讓人沒有欲望。哪有什么所謂的大片好看，幾次爆炸，追車、美女，眼球已經被牢牢抓住。情況在羅伊第一次去見他的女兒時發生變化，煩躁的羅伊不停地在車里吸著煙，顫抖的夾著煙卷的手，布滿煙霧的車廂，一根接著一根的煙卷，飄忽不定找不到落腳點的眼神，看到女兒要走下定決心的追趕，立刻沒有猶豫地喜歡上這個猶豫的男人。心想，這肯定是一部充滿溫情的電影了，一定就是了。因為女兒，他的生活即將打亂，充滿生氣？抑或是雜亂？不管那種，都得改變。

生活中存在著這樣或那樣的不安，所以我總是以最大的善意來揣度電影。劇情也在向我希望的方向發展。小女孩讓父親教她去行騙，第一次行騙成功。女孩拿著騙來的300美元開心地關上車門：我們成功了！父親和她慶祝后卻讓她把錢還回去：如果不這么做，我算得上是一個父親嗎？呵，溫暖。

隨后一次更大的詐騙開始，父親也決定完成這最后一次詐騙重新開始。情節發展再次讓我大跌眼鏡：這也太easy了吧，雖然被騙的胖男人沒有像他們想象的那樣在飛機中才發現錢被調了包，而是一路追趕出來，收費站找零錢一節也確實讓心里小小激靈了一把，但整個過程非常順利，順利得讓我覺得索然無味。這應該是一個多么充滿驚險和刺激的過程啊，槍戰、追逐、飛車、心里懸疑，可惜，沒有，沒有，還是沒有，什么都沒有。應該是這樣一個激烈的過程，然后是美妙的結局：父親和女兒美滿的在一起，成功隱退，快樂的生活，然后是終場的字幕打起。應該是這樣的呵！

女兒槍響的一剎那，我的心咯噔一下：完了，導演該如何結尾呢？我再也想像不到一種合乎邏輯而又符合我心理的結局。悲劇？感人的悲劇？父女情深的悲劇？無論是哪一種，我都不愿意看到。切到體育頻道：斯圖加特3比0領先拜仁。切回來，被捕、審訊、醫生、密碼、接頭地點…這一切都意味著父親在劫難逃。作為父親，能做到就這么多了；然而，作為電影，它顯然可以做到更好-一切在打開那扇門的一剎那霍然開朗，謎底像沙子那樣刺入人的雙眼，讓人心疼，原來一切都是假的，一切都是騙局，他們欺騙了羅伊，導演欺騙了我。心里空蕩蕩的再無著落，像無人的秋千，空在那里蕩漾，像突然的人去樓空，只剩滿心的空曠。半天回味回來：哦，這是電影，并且是好萊塢的電影呢。

一年后再見，女兒離開，轉身說：“I'll see you, dad”。是的，到此為止，over。

卻還是溫暖。我更愿相信最初故事的情節是這樣的：父親詐騙，女兒到來，最初的混亂，親情，融合，改變，生活一起。可是，可是，如何處理這位父親的過去，抹不去的過去，而這個過去最直接的代表莫過于他詐騙所得來的錢財了。捐掉？這不很搞嗎？自首？你以為是中國電影？于是導演以一場更大的騙局將這些錢將父親的過去輕松的抹去了。原來是這樣。原來是這樣呵！女兒還是女兒，父親還是父親。“I'll see you, dad”。是的，沒有復仇，沒有怨恨。

好久沒有看過如此溫暖的電影了。再補充一下：很喜歡羅伊的眼睛，非常喜歡，焦慮、關愛、猶豫、彷徨、絕望、溫情。

Solr 是一個可供企業使用的、基于 Lucene 的開箱即用的搜索服務器。對Lucene不熟？那么建議先看看下面兩篇文檔：

實戰Lucene，第 1 部分: 初識 Lucene：http://www.ibm.com/developerworks/cn/java/j-lo-lucene1/

用Lucene加速Web搜索應用程序的開發：http://www.ibm.com/developerworks/cn/web/wa-lucene2/

一、 solr介紹

solr是基于Lucene Java搜索庫的企業級全文搜索引擎，目前是apache的一個項目。它的官方網址在http://lucene.apache.org/solr/ 。solr需要運行在一個servlet 容器里，例如tomcat5.5。solr在lucene的上層提供了一個基于HTTP/XML的Web Services，我們的應用需要通過這個服務與solr進行交互。

二、 solr安裝和配置

關于solr的安裝和配置，這里也有兩篇非常好的文檔，作者同時也是 Lucene Java 項目的提交人和發言人：

使用Apache Solr實現更加靈巧的搜索：http://www.ibm.com/developerworks/cn/java/j-solr1/index.html

http://www.ibm.com/developerworks/cn/java/j-solr2/index.html

下面主要說說需要注意的地方。

Solr的安裝非常簡單，下載solr的zip包后解壓縮將dist目錄下的war文件改名為solr.war直接復制到tomcat5.5的webapps目錄即可。注意一定要設置solr的主位置。有三種方法。我采用的是在tomcat里配置java:comp/env/solr/home的一個JNDI指向solr的主目錄（example目錄下），建立/tomcat55/conf/Catalina/localhost/solr.xml文件。

     觀察這個指定的solr主位置，里面存在兩個文件夾：conf和data。其中conf里存放了對solr而言最為重要的兩個配置文件schema.xml和solrconfig.xml。data則用于存放索引文件。

     schema.xml主要包括types、fields和其他的一些缺省設置。

solrconfig.xml用來配置Solr的一些系統屬性，例如與索引和查詢處理有關的一些常見的配置選項，以及緩存、擴展等等。

上面的文檔對這兩個文件有比較詳細的說明，非常容易上手。注意到schema.xml里有一個

的配置，這里將url字段作為索引文檔的唯一標識符，非常重要。

三、 加入中文分詞

對全文檢索而言，中文分詞非常的重要，這里采用了qieqie庖丁分詞（非常不錯：））。集成非常的容易，我下載的是2.0.4-alpha2版本，其中它支持最多切分和按最大切分。創建自己的一個中文TokenizerFactory繼承自solr的BaseTokenizerFactory。

在schema.xml的字段text配置里加入該分詞器。

    完成后重啟tomcat，即可在http://localhost:8080/solr/admin/analysis.jsp

體驗到庖丁的中文分詞。注意要將paoding-analysis.jar復制到solr的lib下，注意修改jar包里字典的home。

四、 與自己應用進行集成

Solr安裝完畢，現在可以將自己的應用與solr集成。其實過程非常的簡單，應用增加數據-->根據配置的字段構建add的xml文檔-->post至solr/update。

應用刪除數據à根據配置的索引文檔唯一標識符構建delete的xml文檔-->post至solr/update。

檢索數據à構建查詢xml—>get至/solr/select/-->對solr返回的xml進行處理-->頁面展現。

具體的xml格式可以在solr網站找到。另外就是solr支持高亮顯示，非常方便。

關于中文，solr內核支持UTF-8編碼，所以在tomcat里的server.xml需要進行配置

另外，向solr Post請求的時候需要轉為utf-8編碼。對solr 返回的查詢結果也需要進行一次utf-8的轉碼。檢索數據時對查詢的關鍵字也需要轉碼，然后用“+”連接。

也許是流程做多了的緣故，所以看起程序開發來一切都是流程或者說都包含流程。個人認為大多數的企業應用（不包括特殊應用，例如文檔庫、信息資源庫、BBS等等）不過是對數據以一定的樣式展現（表單），以一定的邏輯對數據進行操作（業務規則），以及把這些處理數據的過程以一定的流程進行管理（流程）。上面三個方面分別對應著表單、業務規則和流程。程序開發中則對應于表單引擎、規則引擎和工作流引擎。而這些方面又可以統一到一個更大范疇的流程上來，所以這里有對流程驅動開發的設想。

先來看看具體的應用場景。

單表增刪改查

這是最簡單的情形，也沒有流程，對這個情形不加討論。但是這里會提到表單引擎，VB里的數據控件非常的易用，沒有PO，沒有DAO，也沒有Service，直接與數據庫字段進行綁定。我們的表單引擎也可以采用這種方式。

支持表單控件（輸入框、文本框、下拉框等）的拖拽，將整個表單與數據庫表綁定。

表單控件與數據庫字段的綁定。

單表業務+流程

比上面的情況稍微復雜一點點，也就是要在業務里引入流程，其實這也是現在工作流引擎應用最多的地方，比如說政府OA里的收文、發文。

這里只需要將表單與流程進行綁定，表單引擎的處理方式不變，依然是直接與數據庫表進行綁定。表單負責對數據庫里的業務數據進行展現，工作流則負責推動這些數據在業務意義上狀態的轉換，互不影響，并在需要的時候在自動節點上對這些數據進行相應的業務處理。

關于表單權限。這個也是表單與工作流進行綁定時所必須考慮到的問題。其實只是需要在表單引擎里引入權限角色的概念，每個角色對應于一種權限，這種權限具體說來就是表單里每個字段的可見、可編輯等等。然后在人工節點定義時指定表單權限角色即可。這樣也實現了流程與表單權限一定程度上的解耦。

其實還有一種更方便的方式，將表單直接與人工節點進行綁定，每個人工節點對應于不同的表單。

復雜一點，多表關聯的情況

復雜一點的情況是業務往往是多表的關聯。這需要對表單引擎做出擴展，讓它可以根據關聯字段對關聯表做出查詢，得到關聯表的設計結構，繼續映射。這讓我想起了ORM，這里很有FRM的意思在里面。其實對于常用的關聯查詢往往有通用的組件可用，例如根據userid渲染出用戶名，根據數據字典的id關聯渲染出相應的值，oa里的正文、附件、印章等等。

流程跨越多個業務

流程需要跨越多個業務，一個典型的流程如下：

會議審批會涉及到兩張業務表：會議室使用表，會議記錄表。在會議申請和領導審批節點，最終用戶打開的都是會議申請的表單，對應于會議記錄表，對該表進行操作。但是流程運行到會議室管理員安排會議室的節點，該節點最終用戶不僅需要看到會議申請的表單同時還要看到會議室使用情況的表單，如果有空閑的會議室，用戶登記操作會議室使用表，然后通知申請者；如果沒有空閑的會議室，則不用登記直接通知申請者。這個過程中跨越了兩個業務，分別是會議室管理和會議管理。表單在各個節點也是不同的。

這其實對工作流引擎提出了比較高的要求。例如如果流程已經結束，會議得到批準，但申請者突然有事要改變會議時間怎么辦？回退。這里的回退無疑就需要有業務的補償，例如要刪除會議室的相關記錄。

應用集成

一個流程不僅會跨越多個業務，也會跨越多個系統。這里的應用場景很多，重要的是要去其他系統抓取數據和操作數據，僅僅靠數據庫表對表單的映射滿足不了需求。

對工作流引擎做出改進，與前面相比，需要由引擎來完成對其他系統服務的調用。這里一個很重要的載體就是XML。首先要定義交換數據所用的XML scheme，然后將這個XML scheme再與表單引擎做出映射。實際執行時，工作流的自動節點會在人工節點前調用其他系統的服務，按照XML scheme將數據轉換為符合定義的XML，在緊接著的人工節點送給表單引擎，表單引擎渲染。修改數據也是同樣的過程，表單引擎將處理后的數據以XML返回，工作流再次做出轉換，調用服務的修改功能。

上面五種都是比較常見的應用場景，理想的情況下，開發方式應該是這樣的：畫出應用流程à定義流程表單à表單與數據庫進行映射à對流程進行業務仿真à完成開發。問題是這樣的：你的表單引擎是否足夠強大？表單與后臺是直接用SQL進行交互的，也就是Transaction Script模式，沒有業務對象，對于復雜業務邏輯如何處理？如何使用規則引擎來解決業務邏輯的問題？權限如何以一種AOP的方式對數據操作進行橫切？

呵呵，純屬個人YY。