发布评论
评论（24）
我现在正在开发一个使用 EXT GWT (GXT) 的项目，不要与 GWT EXT 混淆。 有一个区别，EXT GWT 实际上是由编写 ExtJS javascript 库的公司生产的。 GWT EXT 是 ExtJS 库的 GWT 包装器。 GXT 是原生 GWT。
无论如何，GXT 还是有些不成熟，缺乏我认为 GWT EXT 拥有的坚实社区。 然而，未来属于 GXT，因为它是原生 GWT，并且实际上是由制作 ExtJS 的公司开发的。 由于 ExtJS 库上的许可证发生变化，GWT EXT 受到了一定程度的削弱，从而减慢了 GWT EXT 的开发速度。
总的来说，我认为 GWT/GXT 是开发 Web 应用程序的一个很好的解决方案。 我实际上非常喜欢托管模式的开发，它使事情变得快速而简单。 您还可以获得能够调试代码的好处。 使用 JUnit 进行单元测试也非常可靠。 我还没有看到一个出色的 JavaScript 单元测试框架，我认为它足够成熟来测试企业应用程序。
有关 GWT EXT 的更多信息：
http://gwt-ext.com/
有关 EXT GWT (GXT) 的更多信息：
http://extjs.com/products/gxt/
不久前我在一个项目中同时使用了 GWT 和 GWT-ext。 我发现随着 Web 开发的进行，体验非常顺利，但我的建议是：
不要将 GWT 本机小部件与 EXT 小部件混合。 这真是令人困惑，因为通常名称是相同的（GWT.Button 或 GWText.Button？）
发生在我身上的一件事确实使代码比我想要的更复杂，那就是我想要一个面板
a) 可动态更新
b) 可级联
GWT 本机面板是动态的，Ext 面板是可级联的。 解决方案？ 包裹 GWTExt 面板的 GWT.VerticalPanel...混乱。 :)
但是，嘿，它有效。 ;)
我赞同 ykagano 的评论，最大的缺点是在 MVC 中失去了 V。 尽管您可以将真正的 ui 类与其余客户端代码分开，但您无法轻松使用图形/Web 设计器生成的 HTML 页面。 这意味着您需要一名开发人员将 HTML 翻译成 java。
获取一个所见即所得的 ui 编辑器，它将节省你大量的时间。 我使用 GWTDesigner。
GWT 最大的优点是能够忘记跨浏览器问题。 它不是 100%，但几乎消除了所有痛苦。 结合托管模式调试的优势（相对于 Firebug，Firebug 非常出色，但与 Java 调试器不同），它为开发人员生成复杂的 Ajax 应用程序提供了巨大的优势。
哦，它运行时速度很快，特别是如果您使用 gzip 过滤器。
GWT 非常简单直观。
特别是随着 UIBinder 的发布，GWT 小部件可以在 XML 中布局，然后在 Java 中进行编码。
所以如果你使用过其他Ajax或者Flash设计工具，或者Silverlight等，GWT是非常容易学习的。
主要障碍（即使不是陷阱）也是 GWT RPC。 您希望使用 GWT 的真正原因是 GWT 异步 RPC。 否则，为什么不直接依靠 css 来格式化你的页面呢？
GWT RPC 是允许服务器刷新服务器上的数据而无需刷新页面的元素。 这是股票表现监控（或美国当前的国家和公共债务或全球每秒流产的未出生婴儿数量）等页面的绝对要求。
GWT RPC 需要一些努力来理解，但只要几个小时，它就会变得清晰。
除此之外，在付出一些努力学习 GWT RPC 之后，您最终发现不能使用 JSP 作为 RPC 的服务组件，除非......我的博客上有一个关于如何使用 JSP 的 8 部分（我认为）系列作为 GWT RPC 服务程序。 然而，由于您没有寻求答案而只是提出问题，因此我将不再为我的博客做广告。
所以。 我非常相信，使用 GWT 的最大障碍/陷阱是找出如何正确部署 GWT 异步 RPC 以及如何使其能够使用 JSP 服务程序。
对于GWT 2.4，调试GWT时使用Firefox，它比使用chrome要快得多。
如果您只使用 Firefox，请考虑将此行放入您的 project.gwt.xml 文件中。
<set-property name="user.agent" value="gecko1_8" />
另外，如果您使用的是 Eclipse，请在参数 -> 下添加以下内容： VM参数：
-Xmx512m -XX:MaxPermSize=1024m -XX:PermSize=1024m
您可以划分服务器和客户端，并在参数下使用以下内容 -> 程序参数：
-codeServerPort 9997 -startupUrl http://yourserver/project -noserver
另外，为了防止刷新您的服务器每次更改时，使用 JRebel
http://zeroturnaround。 com/blog/how-to-rock-out-with-jrebel-and-google-web-toolkit-gwt/
这是一个现场演示
http://www.youtube.com/watch?feature=player_embedded&v=4JGGFCzspaY
我最近在 GWT 上做了很多工作，这就是我不得不说的：
- CSS 样式只是有时很棘手，使用 IE 中的 IE 开发工具和 Firefox 中的 firebug 来弄清楚到底发生了什么，你会得到一个清晰的结果了解需要更改哪些 css
- 您可以使用技巧让 google 对其进行索引。 一个非常著名的网站是 http://examples.roughian.com/ 在 google 上查看其评级。 一个不太出名的网站是 www.salvin.in （忍不住要提一下），我将其优化为文字：salvin主页（在google上搜索这三个词）
我对GWT-EXT不太了解，但我也相信没有必要包含第三方库。
祝你的决定好运:)
GWT 进行浏览器嗅探而不是功能检测，您的应用程序将无法在某些浏览器（特别是新浏览器）上运行，
以下是该问题的一些参考：
- google-web-toolkit 问题 2938：RFE：改进 user.agent 属性提供程序以应对 userAgent 字符串“屏蔽”
- 不再支持 Iceweasel？ - Google 文档帮助
- 针对每个浏览器的 GWT 实现
以下是对功能检测的一些参考：
获取可靠事实的最佳方法是从 gwt调查。 GWT 的最大问题之一始终是编译时间过长。 幸运的是，它正在迅速改善，因此在不久的将来不会成为一个重大问题。 另一个陷阱是 GWT 更加复杂，因为 Java 是一种更复杂的语言，每一步都会抵制不良编码人员。 另外，编译又加了一层。 例如，js 互操作需要一些样板文件。 根本问题是 GWT 的设计并不简单。 它是为极其复杂的网络应用程序从头开始设计的，整个社区始终优先考虑性能、代码质量、架构等，而不是简单的编码。
请记住，您可以随时在 GWT 中使用 js，因此如果您在 GWT 中遇到困难，请考虑使用 js。 归根结底，GWT 是 js，因此您可以在 GWT 中做任何在 js 中可以做的事情。 事实上，大多数GWT项目都使用js。 问题是 GWT 要复杂得多。 尽管如此，有时额外的复杂性还是值得的。
值得注意的是，GWT 3.0将带来巨大的改进。
GWT 是一项技术杰作。 它将客户端和服务器编程结合起来，使其成为一个连贯的应用程序——软件在“分层”之前编写的方式，以及它应该编写的方式。 它消除了不同的技能组合、团队成员之间的沟通不畅，以及整个网页设计阶段：艺术和编程。 它是最接近移动（例如 Android）开发的。 事实上，GWT 旨在生成不同的本机 UI，而不仅仅是 HTML。 尽管它需要大量的纪律来确保这种解耦 - 保持你的内层与表示无关。
您应该避免的第一个错误是使用第三方扩展，例如 EXT-GWT 又名 GXT 和 SmartGWT，我花了四年时间才意识到这一点。 开始使用他们漂亮的桌面小部件而不是投资于自己的样式是非常诱人的，但我无法说出我在 SmartGWT 中遇到了多少问题，直到我最终厌倦了。 简而言之，它将核心 GWT 功能集冻结在某个（相当过时的）级别，然后在其之上进行构建。 另请记住，如今那种轮廓分明的桌面外观和感觉看起来很愚蠢，更不用说缓慢的性能、大量的错误和兼容性功能——尤其是在移动设备上。 您希望尽可能靠近本机浏览器控件，即呈现为本机
由于移动趋势，整个用户体验变得更简单、更扁平，因此您不需要做太多事情来设计外观清晰的应用程序。 不过，如果您想要“3D”外观，也可以使用渐变。 CSS3 让一切变得简单，GWT 以优雅的面向对象方式包装它，这与原始 CSS 不同。 因此，不要因为看到 GWT Showcase 中相当丑陋的准系统控件而气馁。 GWT 团队故意不提供任何样式，因为这是开发人员的工作。
其余的几乎都是使用强类型 Java 进行的传统浏览器编程，具有漂亮简洁的 API。 但当然永远不要忘记您的代码在浏览器内部运行，因此所有调用都是异步的，例如您不能在循环中调用 GWT-RPC 方法（以填充某些列表），但如果您遇到这种情况，则需要递归链接它们情况。
有一些自称的“反模式”，例如不使用 GWT-RPC。 到目前为止，这对我来说一直很好：10年了。 简单是关键。 我不会想到为了代码的优雅和可维护性而牺牲一些边际性能。 除此之外，这不是你的瓶颈所在——数据库中。 当然要注意您向客户端发送了多少数据。
如果您无法找到现有小工具或为其设置样式 - 阅读丰富的 HTML5 元素集，您始终可以包装第三方小工具。 我用流行的 jQuery FullCalendar 做到了。 根本不是火箭科学。 其他一切（例如 Google 地图和 Google 图表）都有半官方的 GWT 包装器。
GWT 非常完美。 它没有得到足够喜爱的唯一原因是，仍然影响该行业的早期互联网采用者并不是来自计算机科学和面向对象语言，因此无法欣赏它们。 他们具有艺术（Photoshop/WordPress）或网络（Perl/Python）背景。
我们与 gwt 合作已近两年了。 我们吸取了很多教训。 我们的想法如下：
不要使用第三方小部件库，尤其是 gwt-ext。 它会破坏你的调试、开发和运行时性能。 如果您对如何发生这种情况有疑问，请直接与我联系。
使用 gwt 仅填充应用程序的动态部分。 因此，如果您与许多字段进行一些复杂的用户交互。 但是，请勿使用附带的面板。 使用现有的库存设计师提供的页面。 划出包含应用程序控件的区域。 在 onModuleLoad() 中将这些控件附加到页面。 这样您就可以使用设计器中的标准页面，并且还可以在 gwt 之外进行所有样式设置。
不要将整个应用程序构建为一个标准页面，然后动态构建所有部分。 如果你按照我在第 2 条中建议的操作，这种情况就不会发生。 如果您动态构建所有内容，则会降低中型到大型应用程序的性能并消耗大量内存。 另外，如果您按照我的建议操作，后退按钮将会很好用，搜索引擎索引等也会很好。
其他评论者也有一些很好的建议。 我使用的经验法则是像创建标准网页一样创建页面。 然后切出需要动态的部分。 将它们替换为具有 id 的元素，然后使用 RootPanel.get( id ).add( widget ) 填充这些区域。
我们遇到的陷阱：
虽然您可以通过使用 GWT EXT 之类的东西获得很多好处，但任何时候您在 JavaScript 库之上使用这种薄层，您就会失去调试能力。 我不止一次地把头撞在桌子上，因为我无法检查（在我的 IntelliJ 调试器内）GWT EXT 表类中发生了什么......您所看到的只是它是一个 JavaScriptObject。 这使得找出问题所在变得非常困难...
您的团队中没有了解 CSS 的人。 经验，这个人不是专家并不重要……只要他拥有一些良好的工作知识，并且在必要时知道谷歌的正确术语就足够了。
跨浏览器调试。 密切关注进程外托管模式[1][ 2 ][3]，希望在 GWT 1.6 中出现。 .. 现在，您只需使用托管模式让一切顺利，然后使用“编译/浏览”按钮，您就可以在其中使用其他浏览器。 对于在 Windows 上工作的我来说，这意味着我可以在 FireFox 中查看我的工作，并使用 FireBug 来帮助调整并使事情变得更好。
IE6。 令人惊奇的是 IE 6 所渲染的事物有多么不同。 我采取了根据浏览器将样式应用到最外层“视口”的方法，这样我就可以拥有如下 CSS 规则：
.my-style { /* 最适合任何地方的东西 */ } .msie6 .my-style { /* “覆盖”，以便样式在 IE 6 上工作 */ }
最后，确保您使用可以帮助您的编辑器。 我使用 IntelliJ——它有很多 GWT 智能。 例如，如果我尝试使用 JRE 模拟未处理的类，它会让我知道； 如果我为小部件指定了样式，并且尚未定义该样式，则代码会显示红色小波浪...或者，当查看 CSS 时，它会告诉我何时在 a 中指定了冲突的属性单一规则。 （我还没有尝试过，但我知道版本 8 具有更好的 GWT 支持，例如保持“本地”和“异步”RPC 接口和实现同步。）
我将在已经提到的内容中添加一些要点：
- 数据绑定/验证。 GWT 没有现成的数据绑定/验证支持，尽管该领域的一些项目已经开始出现。 您会发现自己写了很多这样的内容：
TextField fname, faddress; ... fname.setText(person.getName()); faddress.setText(person.getAddress()); ...
- 延迟加载。 由于 gwt 位于客户端，因此延迟加载确实不是一个选择。 您必须仔细设计 RPC 和域对象，以便
- 发送所需的所有对象数据
- 避免急于获取所有数据
- 您还必须确保不会发送代理/不可序列化对象。 hibernate4gwt 可以帮助您解决这些问题。
- 用户界面设计。 在 java 中可视化 UI（面板、按钮等）比在 html 中更难。
- 历史支持。 GWT 不附带历史记录子系统，也不附带任何用于漂亮 URL 或全状态书签的子系统。 您必须自己推出（尽管它支持历史令牌，这是一个开始）。 据我所知，所有 AJAX 工具包都会发生这种情况。
恕我直言，GWT 缺少一个对该“线程”中提到的所有问题提供开箱即用支持的框架。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
首先我要说的是，我是 GWT 的忠实粉丝，但是，确实有很多陷阱，但大多数（如果不是全部的话）我们都能够克服：
问题： 随着项目的增长，编译时间很长编译它所需的时间也是如此。 我听说过 20 分钟编译的报告，但我的平均约为 1 分钟。
解决方案：将代码拆分为单独的模块，并告诉 ant 仅在更改时才构建它。 此外，在开发时，您可以通过仅针对一种浏览器进行构建来大大加快编译时间。 您可以通过将其放入 .gwt.xml 文件中来实现此目的：
其中 gecko1_8 是 Firefox 2+，ie6 是 IE 等。
问题： 托管模式非常慢（至少在 OS X 上）并且与您编辑 JSP 或 Rails 页面等内容并在浏览器中点击刷新时获得的“实时”更改相差甚远。
解决方案：您可以为托管模式提供更多内存（我通常为 512M），但它仍然很慢，我发现一旦您对 GWT 足够好，您就停止使用它。 您进行大量更改，然后仅针对一个浏览器进行编译（通常需要 20 秒的编译时间），然后只需在浏览器中点击刷新即可。
更新：对于 GWT 2.0+，这不再是问题，因为您使用新的“开发模式”。 它基本上意味着您可以直接在您选择的浏览器中运行代码，因此不会损失速度，而且您可以使用 firebug/inspect 它等。
http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM
问题： GWT 代码是 java，并且对布局 HTML 页面有不同的心态，这使得采用 HTML 设计并将其转换为 GWT 变得更加困难
解决方案：您再次习惯了这一点，但不幸的是将 HTML 设计转换为GWT 设计总是比将 HTML 设计转换为 JSP 页面之类的操作慢。
问题：GWT 需要一些时间来理解，而且还不是主流。 这意味着大多数加入您的团队或维护您的代码的开发人员都必须从头开始学习
解决方案：GWT 是否会成功还有待观察，但如果您是一家控制谁的公司如果您聘用了 GWT，那么您始终可以选择了解 GWT 或想要学习 GWT 的人员。
问题：与 jquery 或普通 javascript 相比，GWT 是一把大锤。 需要更多的设置才能实现这一点，而不仅仅是包含 JS 文件。
解决方案：使用 jquery 等库来完成适合这些任务的较小、简单的任务。 当您想要在 AJAX 中构建真正复杂的东西，或者需要通过 RPC 机制来回传递数据时，请使用 GWT。
问题：有时，为了填充 GWT 页面，您需要在页面首次加载时进行服务器调用。 当您获取所需数据时，用户坐在那里看着加载符号可能会很烦人。
解决方案：对于 JSP 页面，您的页面在变成 HTML 之前就已经由服务器呈现，因此您实际上可以进行所有 GWT 调用，并将它们预加载到页面上，以便瞬时负载。 有关详细信息，请参阅此处：
通过预序列化 GWT 调用来加速页面加载
我从来没有遇到过任何 CSS 样式问题，开箱即用，自定义或其他，所以我不知道你所说的陷阱是什么意思？
至于性能，我总是发现编译后的 GWT 代码速度很快，而且 AJAX 调用几乎总是比整个页面刷新要小，但这并不是 GWT 所独有的，尽管使用本机 RPC 数据包时会得到JAVA后端非常紧凑。
I'll start by saying that I'm a massive GWT fan, but yes there are many pitfalls, but most if not all we were able to overcome:
Problem: Long compile times, as your project grows so does the amount of time it takes to compile it. I've heard of reports of 20 minute compiles, but mine are on average about 1 minute.
Solution: Split your code into separate modules, and tell ant to only build it when it's changed. Also while developing, you can massively speed up compile times by only building for one browser. You can do this by putting this into your .gwt.xml file:
Where gecko1_8 is Firefox 2+, ie6 is IE, etc.
Problem: Hosted mode is very slow (on OS X at least) and does not come close to matching the 'live' changes you get when you edit things like JSPs or Rails pages and hit refresh in your browser.
Solution: You can give the hosted mode more memory (I generally got for 512M) but it's still slow, I've found once you get good enough with GWT you stop using this. You make a large chunk of changes, then compile for just one browser (generally 20s worth of compile) and then just hit refresh in your browser.
Update: With GWT 2.0+ this is no longer an issue, because you use the new 'Development Mode'. It basically means you can run code directly in your browser of choice, so no loss of speed, plus you can firebug/inspect it, etc.
http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM
Problem: GWT code is java, and has a different mentality to laying out a HTML page, which makes taking a HTML design and turning it into GWT harder
Solution: Again you get used to this, but unfortunately converting a HTML design to a GWT design is always going to be slower than doing something like converting a HTML design to a JSP page.
Problem: GWT takes a bit of getting your head around, and is not yet mainstream. Meaning that most developers that join your team or maintain your code will have to learn it from scratch
Solution: It remains to be seen if GWT will take off, but if you're a company in control of who you hire, then you can always choose people that either know GWT or want to learn it.
Problem: GWT is a sledgehammer compared to something like jquery or just plain javascript. It takes a lot more setup to get it happening than just including a JS file.
Solution: Use libraries like jquery for smaller, simple tasks that are suited to those. Use GWT when you want to build something truly complex in AJAX, or where you need to pass your data back and forth via the RPC mechanism.
Problem: Sometimes in order to populate your GWT page, you need to make a server call when the page first loads. It can be annoying for the user to sit there and watch a loading symbol while you fetch the data you need.
Solution: In the case of a JSP page, your page was already rendered by the server before becoming HTML, so you can actually make all your GWT calls then, and pre-load them onto the page, for an instant load. See here for details:
Speed up Page Loading by pre-serializing your GWT calls
I've never had any problems CSS styling my widgets, out of the box, custom or otherwise, so I don't know what you mean by that being a pitfall?
As for performance, I've always found that once compiled GWT code is fast, and AJAX calls are nearly always smaller than doing a whole page refresh, but that's not really unique to GWT, though the native RPC packets that you get if you use a JAVA back end are pretty compact.