我应该为我的新网络应用程序使用谷歌网络工具包吗?

RoR实际上是GWT要很好地使用的东西之一,只要你正确使用REST。它在《谷歌网络工具包应用程序》一书中,你可以看到书中使用这种想法的演示 here 这并不是说你不会有任何问题,但我认为支持肯定是存在的。

您可以找到一个让RoR/GWT变得简单的整洁项目 here (MIT许可证)。我还没有机会尝试它,但看起来已经投入了大量的思考。一个问题是,它似乎还没有在2.1 Rails上进行过全面测试,只有2.0,所以你可能会遇到一些(可能是轻微且可修复的)错误。

如果你想将GWT与ROR、PHP等非Java后端集成,你应该记住GWT 1.5现在支持JavaScript覆盖类型。此功能允许您编写可以映射到本机JavaScript对象顶部的类,以便轻松为这些对象的属性和其他扩展功能提供访问器方法。

有关更多详细信息,请参阅此链接: JavaScript Overlay Types

因此,您可以通过AJAX调用从后端返回JSON编码的数据,将其解析为JavaScript对象,然后使用您创建的覆盖类通过GWT Java代码访问数据。或者,当您呈现页面时,您可以将静态配置数据呈现为JavaScript对象并通过此机制读取,而不必进行AJAX调用来获取数据。

如果你知道JAVA,并且有可以托管它的地方(比如tomcat或glassfish容器),我建议你使用Ruby作为后端。主要原因是,这样您就可以共享所有对象,并使用内置的RPC机制。我在我们的很多项目中都这样做了,这节省了大量时间,更不用说代码不太容易出错了,因为你不需要将java对象转换为任何东西,然后再转换回来。

我之前已经将GWT与Rails链接过,使用Rails中的to_json函数,然后读取GWT中的json。它都受支持,但这比用JAVA做后端要烦人得多。

当然,如果你有廉价的主机,那么Java容器几乎是不可能的,在这种情况下,我认为Rails将是下一个最好的选择。

GWT的质量很高,有一个很棒的社区。然而,如果你想调整事物的外观(你会的),你确实需要知道CSS——CSS可以做很多布局,就像普通网络一样。GWT-ext或ExtGWT等库可以提供一些帮助,因为它们具有令人惊叹的“开箱即用”外观,但价格昂贵(应用程序的额外大小)。

您可以使用GWT用Java编写所有代码,并且可以将现有的第三方javascript库与之集成。这非常好。不过,我从来没有用过RoR,所以对此我什么也不能说。

如果你对Java有经验,但对Javascript/CSS没有经验,那么GWT将是你的救星(当然,除非你想学习它们)。CSS有很多琐碎的细节。花半天时间修复仅在IE6中发生的2像素错位并不罕见。

我不确定在后端使用ROR有多容易。..我相信这是可能的,因为GWTAjax通信只是servlet。但是,它们为来回传递Java对象提供了一些非常好的功能,如果您的服务器不使用Java,则无法使用这些功能。

我写了一些 the disadvantages of GWT 最近。主要缺点是:应用程序某些部分的更改部署周期长,学习曲线相当陡峭。作为一名经验丰富的Java程序员,第二个问题应该不那么严重,如果你使用单独的后端,第一个问题也会得到缓解(因为当你更改应用程序的“服务器”部分时,主要需要完全重新部署)。

GWT是一个具有巨大潜力的优秀框架。不过,请记住,它仍然很新。有些未解决的错误可能会让你非常恼火,它们通常需要丑陋的解决方法才能克服。这个社区很棒,但你迟早会遇到一些谷歌无法回答的问题。

但是,嘿,我说去做吧。GWT的潜力是巨大的,我打赌它的未来会很光明。

您绝对应该在新项目中使用GWT(在旧项目中也很容易使用)。

根据我的经验,学习和使用它非常快。编译后的javascript代码比你手工编写的任何代码都要好得多,而且速度也很快。

另一个好处是能够调试您的代码(仅使用javascript是地狱)

这个博客有许多经验丰富的GWT用户的意见,并有一些很好的讨论点。我个人对各种UI框架都有丰富的经验。我会加上我的两分钱。让我们看看 基本的 GWT的优缺点

根本优势

GWT将web层编程引入JAVA。因此,Java的明显优势开始发挥作用。它将提供面向对象的编程。它还将提供出色的调试和编译时检查。由于它生成HTML和Javascript,因此它还可以在生成器中隐藏一些复杂性。

根本劣势

缺点始于同一句话。GWT将web层编程引入JAVA。如果你知道JAVA,你可能永远不会寻找其他语言来编写你的业务逻辑。这是自给自足和伟大的。但是,当涉及到为JAVA应用程序编写配置时。我们使用属性文件、数据库、XML等。我们从不将配置存储在JAVA类文件中。仔细想想,这是为什么?

这是因为配置是静态数据。它通常需要等级制度。它应该是可读的。它从不需要编译。它不需要JAVA编程语言的知识。简而言之,这是一场不同的球赛。现在的问题是,它与我们的讨论有什么关系?

现在,让我们考虑一个网页。你认为当我们写网页时,我们写的是业务逻辑吗?绝对不是。网页只是一种配置。它是一种分层容器和字段的配置。我们需要为将从网页捕获并显示在网页上的数据编写业务逻辑,而不是创建网页本身。

上一段作了非常有力的陈述。这将解释为什么基于HTML和XML的网页仍然是最受欢迎的。XML是商业中编写配置的最佳选择。框架必须允许网页与业务逻辑明确分离(MVC框架的目标)。通过这样做,网页设计师将能够运用他的可视化和艺术性技能,只需配置XML即可创建外观精美的网页,而无需担心编程语言的复杂性。开发人员将能够使用他们最好的商业JAVA来编写业务逻辑。

最后,让我们直接谈谈影响。GWT破坏了这一原则,因此它必然会失败。开发GWT应用程序的成本将非常高,因为您需要多技能程序员来编写网页。所需的外观和感觉将很难实现。由于不必要的编译,修改网页的周转时间将非常长。最后,由于你用JAVA编写网页,很容易用业务逻辑破坏它。不知不觉中,你会引入必须避免的复杂性。

你也可以考虑 Grails (“Groovy on Rails”),它为您提供了Rails框架和Java VM使用的好处。

我们的团队最近提出了同样的问题,我们选择使用GWT,特别是因为设计器插件使团队中的非java专家更容易使用GWT。无论谁做出这个选择,都要小心不要使用GWT Designer插件!!它还没有更新(显然至少一年了)以创建与IE8兼容的GWT应用程序。

我们的团队几乎完成了我们的应用程序布局,这些布局在Chrome、FF和Safari中运行良好。然后他们在IE中崩溃了。IE 7会加载部分页面(但不包括复合页面),而IE8甚至无法加载应用程序。它只是挂着。

设计器插件具有按钮,允许用户添加与IE不兼容的CellTable小部件(CellTable、DeckPanel、水平面板、垂直面板等)。当布局必须在没有设计师帮助的情况下用java重新完成时,这将造成极大的痛苦。

经验丰富的GWT用户喜欢它,但设计器插件会让你丧命。