※ 引述《PsMonkey (痞子軍團團長)》之銘言： : GWT 完全不是 server centric : 當然，我有可能是錯的 : 不過人家 ZK 是這樣講的，有問題請找該篇文章作者 : http://www.zkoss.org/smalltalks/gwtZk/ : 至於 TonyQ 文章中，其他我覺得很奇怪的部份 : 就不敢班門弄斧了 Zzzz Server Centric的概念下，Browser端只有UI的呈現與事件註冊，任何收到的事件該如何 處理都是將資訊送回Server端『請示』Business Logic。可以說在這樣的架構底下， Browser完全是Server端的線控人偶，除了將User的『輸入』與『行為』確實的通報 Server端以外不會有其他邏輯。 優缺點我想TonyQ有講過了，就不再贅述。 那麼，在這樣的定義下，GWT到底要不要算是Server Centric的Framework呢？ 我的答案是：GWT不是一個純Server Centric的Framework，但它可以支援Server Centric的開發概念。 對GWT的開發者來說，如果他在採用GWT開發App的時候有意識到Bean物件在Client 與 Server間Marshaling UnMarshaling的問題，並決定要盡可能的把所有的邏輯與驗證往 Server端挪，Client端的所有事件處理都只有『把資訊往後端送』這樣的邏輯，那麼這 就會是一個Server Centric的Ajax Web App架構。 事實上，如果Trace Vaadin這個GWT Base Framework的程式碼就會看見這樣的設計概念。 Vaadin基本上就是用GWT JSNI去包裹自家團隊過去開發的 IT Mill Toolkit，然後在 Server端完全以Java Server端技術寫出包裹Client端UI元件的Stub，使得開發人員在 使用Vaadin時，可以達到『在Server端直接操作該Stub等於操作了Client端UI』的效果。 以下是個人關於Vaadin的分析： Vaadin的策略雖然帶進了很多Server Centric的好處，但是同時原本GWT的優點：使用 Java Programming去直接對BrowserHTML結構、Style與JS行為去精細控制的能力，反而 被Framework本身給遮蓋掉了。 如果不對Vaadin hook在JSNI下的JS做解析，並瞭解Vaadin的GWT Widget Wrapping的 Lifecycle，要對Vaadin 做出來的Web Application做客製化會是很頭疼的事。 基於我個人對於好的 Framework的定義來看Vaadin： 1. MIPS 設計守則 3 : "make common case fast" 一個好的Component Set就是一個好的 Common UI Cases，我想這點是好是壞，一向 見人見智，Vaadin平心而論還ok。 2. 好狗不擋路，Don't get in my way。 它擋到了，當我希望寫GWT Client Java，然後要令它與Vaadin的東西合作時，Vaadin 的表現不好，不夠GWT也不算是Pure Client JS。 : ==== : 題外話..... : 我覺得會想走 server centric 的人一定是瘋了 : 是說，我也覺得喜歡寫 JavaScript 的人也一定是瘋了 [被拖走] 更瘋狂的東西還有著呢。 有人當初能想像HTML與Browser會從『文章內容排版並透過超連結與其他網頁建立關聯 的標籤語言與播放裝置』變成『De facto的Geniric Internet Application 執行平台』 嗎？ 2000年寫Web的人有想到Javascript的Interpreter有一天要支援JIT、動態語言解析分枝 預測、VM化、並準備開始要支援GPU加速好為3D library的實現做準備？ 而更令人鬱症發作的是，以上令人興奮的進展常常被企業需求加個但書： 『要支援IE6喔』 統統都軟掉了。 -- 我所信仰的科學是一種謙卑的理性，承認自身的無知與渺小才能觀察到世界在我們貧 弱的知覺上留下來的痕跡。 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 123.194.160.60