作為 Sencha GXT 的團隊代表，我很高興宣佈 Sencha GXT 3.1 發布。在公開測試後只有一兩個月的時間，我們收到一卡車的回饋意見。我們已經解決幾個來自公開測試討論區的問題。感謝所有前期測試人員，你們的回饋意見始終是非常寶貴的。
GXT 3.1 導入了新的 Theme Builder（妝點 GXT 程式的新工具）、Neptune 這個佈景主題就是用 Theme Builder 做出來的；另外 GXT 3.1 也增加了對 GWT 2.6 的支援度。
（譯註：省略兩段純粹提供 3.1 各式連結的部份）
我大概是當完兵之後才開始用 HandlerManager 作 event bus，目的當然是降低耦合度。起手 reference 是 tkcn 的這篇《利用 HandlerManager 實作共用的 Event Bus》，然後一直以來就爽爽用，沒出啥問題、也沒想過會出問題。今天在 review 別人的 code 才知道有 SimpleEventBus，然後想知道這兩個到底有什麼差別、該用哪一個比較好？沒想到才剛打開 HandlerManager 的 source code，一開頭的 javadoc 就開始噴血：
application developers are strongly discouraged from using a HandlerManager instance as a global event dispatch mechanism.
WTF？不但不建議，而且是強烈不建議？GWT MVP 的文件都還是教用 HandlerManager 阿？
原文網址：http://www.gwtproject.org/articles/mvp-architecture.html
建立大型 application 都有其障礙，GWT application 也不例外。多個開發人員同時在一份程式碼上作業、維護既有功能，可能短時間內就會讓程式碼一團混亂。為了解決這個問題，我們導入 design pattern 來將 project 劃分出不同的責任區。
有很多 design pattern 可以選擇，例如 Presentation-Abstraction-Control、Model-View-Controller、Model-View-Presenter…… 等等。雖然每個 pattern 有其優點，不過我們發現 Model-View-Presenter（以下簡稱 MVP）架構在開發 GWT application 的效果最好。有兩個主要的原因：首先，就像其他 design pattern，MVP 會降低開發行為的耦合度，這讓多個開發人員可以同時工作。再者，MVP 會盡可能降低 GWTTestCase 的使用度。GWTTestCase 會需要 browser，但是大多數程式碼只要輕量、快速、不需要 browser 的 JRE 測試。
這個 pattern 的核心是把功能分散到各個元件，這在邏輯上是有意義的。但在 GWT 中還有一個明確的重點，是讓 View 的部份盡可能簡單，以減輕對 GWTTestCase 的依賴、降低整體的測試時間。
一旦你瞭解這個 design pattern 的原理，那麼建立以 MVP 為基礎的 application 就會直覺又簡單。我們將用一個簡單的通訊錄系統為例子，協助你聊解這些概念。這個系統可以讓使用者增加、編輯、檢視存放在 server 上的聯絡人清單。
