使用 Google Web Toolkit (GWT) 作为成熟的 Java Web 框架有意义吗？
我对 GWT 可以作为我整个表示层的基础的可能性感兴趣。
我很想知道是否有人成功或不成功地尝试过此操作，并且可以说服或劝阻我不要尝试此操作。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
我对 GWT 可以作为我整个表示层的基础的可能性感兴趣。
我很想知道是否有人成功或不成功地尝试过此操作，并且可以说服或劝阻我不要尝试此操作。
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（7）
大约一年前我在 GWT 工作。 当时这似乎是一个好主意，但有一些警告：
话虽这么说，它似乎绝对值得一玩，而且我的经历是很久很久以前的互联网时代，特别是考虑到它现在可能更加成熟。 还值得指出的是，这是一种与大多数 MVC 框架非常不同（且令人耳目一新）的 GUI 代码开发方式，如果没有其他原因，值得一看。
我的感觉是，如果您正在构建一个图形要求非常高的高负载专业站点，GWT 可能不是一个好的选择，否则还可以。
I worked with GWT about a year ago. At the time it seemed like a great idea, with a number of caveats:
That being said,it definitely seems worth playing with, and my experiences were a long, long time ago in internet years, especially given that it's probably much more mature now. It's also worth pointing out that it's a very different (and refreshing) way of developing GUI code from most MVC frameworks, and worth a look if for no other reason than that.
My feeling is that if you're building a high-load professional site with very demanding graphical requirements GWT is probably not a good choice, otherwise ok.
您提到 GWT 将处理表示层。 您也会用 Java 做业务层吗？ 如果是这样的话，我想向您推荐 IT Mill Toolkit，它正是这样做的：这是一个工具包，使用 GWT 呈现其 GUI 组件，使您可以完全使用 Java 来完成应用程序。 我认为它试图创造的术语是“服务器驱动的 RIA”。
我有 PHP 背景，但很快就喜欢上了这个工具包。 但我最好不再多说什么，让你自己做决定。
免责声明：我确实在 IT Mill 工作，尽管这与我的观点无关。
You mentioned that GWT would handle the presentational layer. Would you be doing the business layer in Java too? If that's the case, I'd like to point you towards IT Mill Toolkit, that does exactly this: It's a toolkit that uses GWT to render its GUI components, allowing you to do your applications entirely in Java. I think the term it's trying to coin is "server driven RIA".
I come from a PHP background, but instantly came to like the toolkit. But it's probably better that I won't say anything more and let you do your own decisions.
Disclamer: I do work at IT Mill, although that's irrelevant to my opinions.
GWT 相对较新。 随着代码库的增长，编译过程往往会变得有点慢。 当我们使用它时，我们发现更复杂的小部件的布局和渲染存在许多问题，并且模拟器的行为与真实服务器完全不同。 另外，我们在从右到左的语言中使用 i18n 时遇到了麻烦……
总而言之，GWT 存在（常见的？）年轻技术的问题。 然而，它确实使某些事情变得非常容易，比如您所说的 Ajaxifying。
GWT is relatively new. The compiling process tends to get kinda slow as your code base grows. When we worked with it we found many problems with the layout and rendering of more sophisticated widgets, and the emulator acted totally different from real servers. Also, we had trouble with i18n for right-to-left languages...
All in all, GWT has (the usual?) problems of young technologies. However, it does make certain things really easy, like Ajaxifying as you named it.
我们已经为一个非常大的项目做到了这一点，只要您知道它的局限性、优点和缺点，它就可以很好地发挥作用。 有趣的是，演示文稿是我们最不麻烦的事情，因为我们只是使用 CSS 为它设置皮肤，就像任何其他 HTML 页面一样。 该项目上线了，运行完美，所以我没有抱怨。
我发现的陷阱可以在这里找到：
最大的 GWT 陷阱？
We have done this for a very large project, and as long as you know it's limitations, strengths and weaknesses it works great. Funnily enough presentation was the least of our hassles, as we just skinned it just like you would any other HTML page, using CSS. The project went live, and ran flawlessly so I have no complaints.
The pitfalls I found with it you can find here:
Biggest GWT Pitfalls?
我们开发了一个大型 HR 门户应用程序，整个表示层都是在 GWT 中完成的。 后端是Spring。 一切都运行良好，用户界面也受到了用户的好评。 非常重要的是，我们可以轻松添加新功能和维护应用程序。 我认为使用 Javascript 库做一些可比较且可维护的事情会困难得多。
您确实需要某种客户端框架，否则您最终将编写一个（就像我们所做的那样！）：我们的应用程序基于 GWT Portlet（免费且开源）。
我们使用 HTML 片段为不同部署的应用程序设置皮肤，每个“页面”的布局存储在 XML 文件中。
We have developed a large HR Portal application with the whole presentation layer done in GWT. The backend is Spring. It all works very well and the UI has been very well received by users. Very importantly it is easy for us to add new functionality and maintain the application. I think it would be much harder to do something comparable and maintainable using Javascript libraries.
You do need some sort of client side framework or you will end up writing one (as we did!): Our app is built on GWT Portlets (free and open source).
We use HTML fragments for skinning the app for different deployments and the layout of each "page" is stored in an XML file.
关于这个raible视频的一些好信息：http://raibledesigns.com/rd/entry/my_drunk_on_software_interview
some good info on about that on this raible video: http://raibledesigns.com/rd/entry/my_drunk_on_software_interview
GWT 本身是一个 UI 增强库，而不是一个框架。 如果您将其与 Google App Engine 一起使用，那么您就拥有了一个基本框架。 （这是一个不同的故事，当我查看它时，我决定不将其包含到我们的架构中）。
这是一个很棒的图书馆，我们用它做了一些引人注目的事情。 然而，由于它是一个库，它的性能取决于您的架构允许的程度。
就 ANT 而言，64 位编译器没有任何问题。
<类路径> 类路径
至于生成的代码，如果您想查看的话，它就在您的战争中。 （它也是开源的，所以你可以在那里查看。）
GWT 在编译过程中做了什么：
它为不同的浏览器集创建多个 JS 库副本（编译可能需要几分钟的原因之一），您可以根据需要添加/删除它们。 这减少了需要下载的 JS 包并提高了速度，因为它不必有那些讨厌的 if (EI) this else if (FF) that。
但是，当您进行本地调试（至少在 Eclipse 中）时，您不必等待，可以将其留给构建服务器（或者当您需要手动构建和部署（尼安德特人）时）。
GWT 的缺点。 由于它是一个 javascript 客户端（几乎纯粹），因此您不能将它用于不支持它或支持其中一个版本的事物。
因此，对于 iPad 和 iPhone 等设备，如果您不使用旨在弥补这些差距的其他库（例如 mgwt），您可能会遇到一些问题。
GWT in it's self is a UI enhancement library, not a framework. If you use it with Google App Engine you then have a basic framework. (That is a different story, and while I looked at it, I decided not to include that into our architecture).
It is a great library, we have done some spectacular things with it. As it is a library however, it is only as good as your architecture allows it to be.
As far as ANT goes no problems with a 64 bit compiler.
<java failonerror="true" fork="true" classname="com.google.gwt.dev.Compiler" dir="${dir.GWTCompile}"> <-- dir.GWTCompile is the directory containing GWT -->
<classpath> classpath
</classpath>
<jvmarg value="-${gwt.maxMem}"/>
<arg value="@{gwt.baseModule}" />
<arg value="DEBUG" />
<arg value="-strict" />
</java>
As far as the generated code, it is all there in your war if you want to look through it. (It is also open source, so you can look at it there.)
What GWT does during the compile process:
It creates several copies of JS libraries for different browser sets (One reason it can take minutes to compile), you can add/remove these as needed. This reduces the JS package that needs to be downloaded and increases the speed as it does not have to have those nasty if (EI) this else if (FF) that.
However when your doing local debug (at least in eclipse) you don't have to wait, allowing to leave that for the build server (or when you need to manually build and deploy (neanderthals)).
The downside of GWT. As it is a javascript client side (almost purely), you cannot utilize it for things that do not support it, or support one of the versions.
So for things like iPads and iPhones you can run into some issues if you don't use additional libraries designed to bridge those gaps (like mgwt).