我想创建一个由数据库支持的交互式AJAX Webapp，它具有自定义(特定类型的事件，编辑)日历系统。这将涉及很多JavaScript和AJAX，我想到了用于界面的Google Web Toolkit和用于服务器端的Ruby on Rails。

Google Web Toolkit是否可靠且良好？如果我选择Google Web Toolkit，可能会有哪些潜在的隐患？可以轻松地将它与服务器端的Ruby on Rails结合吗？还是应该尝试直接使用像jQuery这样的JavaScript库？

除了HTML，我没有网络开发方面的经验，但是我是一位经验丰富的程序员(c ++，java，c＃)，并且我只想为该项目使用免费工具。

解决方案

回答

我们可以使用GWT用Java编写所有代码，也可以将现有的第三方javascript库与其集成。这很好。不过，我从来没有使用过RoR，所以对此无话可说。

回答

如果我们有Java的经验，但没有Javascript / CSS的经验，那么GWT将是救星(当然，除非我们想学习它们)。 CSS有很多小巧的细节。花半天时间修复仅在IE6中发生的2像素不对齐的情况并不少见。

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

回答

我们还可以考虑使用Grails(" Groovy on Rails")，它为我们带来了Rails框架和Java VM使用的好处。

回答

只要我们正确使用REST，RoR实际上就是GWT可以很好地配合使用的条件之一。它在Google Web Toolkit应用程序书中，我们可以在此处使用这种想法查看该书中的演示。这并不是说我们不会有任何问题，但我认为肯定会为此提供支持。

我们可以在此处找到一个精巧的项目来简化RoR / GWT(MIT许可证)。我还没有机会尝试一下，但是似乎已经有了很多思考。有一个问题是，它似乎尚未通过2.1 Rails进行全面测试，只有2.0，因此我们可能会遇到一些(可能是次要的和可修复的)错误。

回答

如果我们了解JAVA，并且可以在某个地方托管它(例如tomcat或者glassfish容器)，那么我推荐的内容要比在后端使用Ruby多得多。主要原因是，我们可以共享所有对象，并使用内置的RPC机制。我已经在很多项目中做到了这一点，并且节省了很多时间，更不用说代码不太容易出错了，因为我们不会将Java对象转换为任何对象，然后再转换回去。

之前，我已经在Rails中链接了我的GWT和Rails，在Rails中使用了to_json函数，然后在GWT中读取了JSON。所有这些都受支持，但是它不仅仅只是在JAVA中做后端，还很烦人。

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

回答

GWT是一个高质量的社区。但是，如果我们想调整事物的外观，我们确实需要了解CSS(可以)，CSS可以完成很多布局，就像常规Web一样(如果需要)。 GWT-ext或者ExtGWT之类的库可以提供一些帮助，因为它们具有令人惊叹的"开箱即用"外观，但要付出一定的代价(应用程序的额外尺寸)。

回答

如果我们希望将GWT与非Java后端(例如ROR，PHP等)集成，请记住GWT 1.5现在支持JavaScript覆盖类型。通过此功能，我们可以编写可映射到本机JavaScript对象顶部的类，以轻松提供用于这些对象的属性和其他扩展功能的访问器方法。

有关更多详细信息，请参见此链接：
JavaScript覆盖类型

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

回答

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

回答

GWT是一个很棒的框架，具有很大的潜力。请记住，它仍然是很新的。有一些尚未解决的错误会真正使我们烦恼，并且它们通常需要丑陋的解决方法才能克服。社区很棒，但是我们迟早会遇到一些Google无法回答的问题。

但是，嘿，我说去吧。 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框架的目标)。这样一来，Web设计人员将能够利用他的可视化和艺术技巧，仅通过配置XML即可创建外观精美的网页，而不必为编程语言的复杂性而烦恼。开发人员将能够利用他们的最佳业务JAVA编写业务逻辑。

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