我应该为我的新网络应用程序使用 Google Web Toolkit 吗？

Question

我想创建一个数据库支持的交互式 AJAX web 应用程序，它有一个自定义（特定类型的事件、编辑）日历系统。这将涉及相当多的 JavaScript 和 AJAX，我考虑了用于界面的 Google Web Toolkit 和用于服务器端的 Ruby on Rails。

Google Web Toolkit 可靠且良好吗？如果我选择Google Web Toolkit，可能会存在哪些隐藏风险？可以轻松地将其与服务器端的 Ruby on Rails 结合起来吗？或者我应该尝试直接使用像 jQuery 这样的 JavaScript 库？

除了一些 HTML 之外，我没有 Web 开发经验，但我是一位经验丰富的程序员（c++、java、c#），并且我只想在这个项目中使用免费工具。

Answer 1

只要您正确使用 REST，RoR 实际上是 GWT 能够很好配合的功能之一。它在 Google Web Toolkit 应用程序书中，您可以看到书中使用这种想法的演示 这里. 。这并不是说您不会遇到任何问题，但我认为绝对会提供支持。

您可以找到一个让 RoR/GWT 变得简单的简洁项目 这里 （麻省理工学院许可证）。我还没有机会尝试，但看起来已经投入了很多心思。一个问题是它看起来还没有用 2.1 Rails 进行全面测试，只是 2.0，所以您可能会遇到一些（可能是小且可修复的）错误。

Answer 2

如果您希望将 GWT 与非 Java 后端（例如 ROR、PHP 等）集成，您应该记住，GWT 1.5 现在支持 JavaScript Overlay 类型。此功能允许您编写可以映射到本机 JavaScript 对象之上的类，以便轻松地为这些对象的属性和其他扩展功能提供访问器方法。

请参阅此链接了解更多详细信息：JavaScript 覆盖类型

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

Answer 3

如果您了解 JAVA，并且有可以托管它的地方（例如 tomcat 或 glassfish 容器），我会建议您这样做，而不是使用 Ruby 作为后端。主要原因是这样您就可以共享所有对象，并使用内置的 RPC 机制。我已经在很多项目中这样做了，这可以节省大量时间，更不用说代码更不容易出错，因为您不需要将 java 对象转换为任何内容然后再转换回来。

我之前已经将 GWT 与 Rails 链接起来，使用 Rails 中的 to_json 函数，然后在 GWT 中读取 JSON。都支持了，但是比只用JAVA做后端要烦人得多。

当然，如果你有便宜的托管，那么 Java 容器几乎是不可能的，在这种情况下，我认为 Rails 将是下一个最好的选择。

Answer 4

GWT 具有非常高的质量和一个很棒的社区。但是，如果您想调整事物的外观（您会的），您确实需要了解 CSS - CSS 可以完成很多布局，就像常规 Web 一样，如果您愿意的话。像 GWT-ext 或 ExtGWT 这样的库可以提供一些帮助，因为它们具有令人惊叹的“开箱即用”外观，但需要付费（为您的应用程序提供额外的尺寸）。

Answer 5

您可以使用 GWT 用 Ja​​va 编写所有内容，并且可以将现有的第 3 方 javascript 库与其集成。这很好。不过我从来没用过 RoR，所以对此没什么可说的。

Answer 6

如果您有 Java 经验，但没有 Javascript/CSS 经验，那么 GWT 将成为您的救星（当然，除非您想学习它们）。CSS 有很多微妙的细节。花费半天时间修复仅在 IE6 中出现的 2 像素错位的情况并不罕见。

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

Answer 7

我写了一些关于 GWT 的缺点 最近。缺点主要有：对应用程序某些部分进行更改的部署周期较长，并且学习曲线相当陡峭。作为经验丰富的 Java 程序员，第二个问题应该不是什么问题，如果您使用单独的后端，第一个问题也会得到缓解（因为当您更改应用程序的“服务器”部分时，主要需要完全重新部署）。

Answer 8

GWT 是一个出色的框架，具有巨大的潜力。但请记住，它仍然很新。有一些未解决的错误确实会让您烦恼，并且通常需要丑陋的解决方法才能解决。这个社区很棒，但你迟早可能会遇到一些谷歌无法回答的问题。

但是，嘿，我说去做吧。GWT 的潜力是巨大的，我敢打赌它的未来将是光明的。

Answer 9

您绝对应该在新项目中使用 GWT（在旧项目中使用它也很容易）。

根据我的经验，学习和使用起来非常快。编译后的 JavaScript 代码比您手工编写的任何代码都要好得多，而且运行速度也很快。

另一个好处是能够调试代码（这对 javascript 来说简直就是地狱）

Answer 10

该博客收集了许多经验丰富的 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 编写网页，因此很容易用业务逻辑破坏它。不知不觉中你会引入必须避免的复杂性。

Answer 11

你也可以考虑 圣杯 （“Groovy on Rails”）它为您提供了 Rails 框架和 Java VM 的使用的好处。

Answer 12

我们的团队最近问了同样的问题，我们选择使用 GWT，特别是因为设计器插件使团队中的非 Java 专家更容易使用 GWT。无论谁做出这个选择，请注意不要使用 GWT Designer 插件！它尚未更新（显然至少一年了）以创建与 IE8 兼容的 GWT 应用程序。

我们的团队几乎完成了我们的应用程序布局，它在 Chrome、FF 和 Safari 中完美运行。然后他们在IE中爆炸了。IE 7 将加载部分页面（但不能加载复合包含），而 IE8 甚至无法加载应用程序。它只是挂了。

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

经验丰富的 GWT 用户喜欢它，但设计器插件会杀了你。