※ 引述《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