推 LPH66:推最後三行.... 09/13 05:53
推 foreverangle:看到最後三行我笑了... 09/13 21:41
推 adahsu:最後那三行很容易讓人喊出『更營養雞排』來... =.= 09/14 10:10
推 Laviathan:不是來推後面三行的，而是來推vaadin的 XD 04/09 15:33
※ 引述《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