Java 最大的 GWT 陷阱？

Biggest GWT Pitfalls?

提问by agartzke

I'm at the beginning/middle of a project that we chose to implement using GWT. Has anyone encountered any major pitfalls in using GWT (and GWT-EXT) that were unable to be overcome? How about from a performance perspective?

我正处于我们选择使用 GWT 实施的项目的开始/中期。有没有人在使用 GWT（和 GWT-EXT）时遇到过无法克服的主要陷阱？从性能的角度来看呢？

A couple things that we've seen/heard already include:

我们已经看到/听到的一些事情包括：

• Google not being able to index content
• CSS and styling in general seems to be a bit flaky

• 谷歌无法索引内容
• CSS 和样式总体上似乎有点不稳定

Looking for any additional feedback on these items as well. Thanks!

寻找有关这些项目的任何其他反馈。谢谢！

采纳答案by rustyshelf

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:

我首先要说我是 GWT 的忠实粉丝，但是确实存在许多陷阱，但我们能够克服大部分（如果不是全部）：

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.

问题：编译时间长，随着项目的增长，编译它所需的时间也会增加。我听说过 20 分钟编译的报告，但我的平均约为 1 分钟。

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:

解决方案：将您的代码拆分为单独的模块，并告诉 ant 仅在更改时构建它。此外，在开发过程中，您可以通过仅针对一个浏览器进行构建来大幅加快编译时间。您可以通过将其放入您的 .gwt.xml 文件来完成此操作：

<set-property name="user.agent" value="gecko1_8" />

Where gecko1_8 is Firefox 2+, ie6 is IE, etc.

其中 gecko1_8 是 Firefox 2+，ie6 是 IE，等等。

---

---

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.

问题：托管模式非常慢（至少在 OS X 上）并且与您在编辑 JSP 或 Rails 页面等内容并在浏览器中点击刷新时获得的“实时”更改不符。

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.

解决方案：您可以为托管模式提供更多内存（我通常为 512M）但它仍然很慢，我发现一旦您对 GWT 足够好，您就停止使用它。您进行了大量更改，然后只为一个浏览器编译（通常需要 20 秒的编译时间），然后在浏览器中点击刷新。

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.

更新：使用 GWT 2.0+，这不再是问题，因为您使用新的“开发模式”。这基本上意味着您可以直接在您选择的浏览器中运行代码，因此不会损失速度，而且您可以触发/检查它等。

http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM

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

问题：GWT 代码是 java，对 HTML 页面的布局有不同的心态，这使得采用 HTML 设计并将其转换为 GWT 变得更加困难

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.

解决方案：您再次习惯了这一点，但不幸的是，将 HTML 设计转换为 GWT 设计总是比将 HTML 设计转换为 JSP 页面之类的操作要慢。

---

---

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

问题：GWT 需要一些了解，而且还不是主流。这意味着大多数加入您的团队或维护您的代码的开发人员必须从头开始学习

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.

解决方案：GWT 是否会腾飞还有待观察，但如果您是一家可以控制招聘人员的公司，那么您始终可以选择了解 GWT 或想要学习 GWT 的人。

---

---

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.

问题：与 jquery 或纯 javascript 之类的东西相比，GWT 是一把大锤。它需要更多的设置才能实现，而不仅仅是包含一个 JS 文件。

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.

解决方案：将 jquery 之类的库用于适合这些任务的更小、更简单的任务。当您想在 AJAX 中构建真正复杂的东西时，或者您需要通过 RPC 机制来回传递数据时，请使用 GWT。

---

---

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.

问题：有时为了填充您的 GWT 页面，您需要在页面首次加载时进行服务器调用。当您获取所需数据时，用户坐在那里观看加载符号可能会很烦人。

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:

解决方案：在 JSP 页面的情况下，您的页面在变成 HTML 之前已经由服务器呈现，因此您实际上可以在那时进行所有 GWT 调用，并将它们预加载到页面上，以便即时加载。详情请看这里：

Speed up Page Loading by pre-serializing your GWT calls

通过预先序列化您的 GWT 调用来加速页面加载

---

---

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?

我从来没有遇到过任何 CSS 样式我的小部件的问题，开箱即用，自定义或其他方式，所以我不知道你所说的陷阱是什么意思？

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.

至于性能，我一直发现一旦编译的 GWT 代码很快，而且 AJAX 调用几乎总是比刷新整个页面要小，但这并不是 GWT 真正独有的，尽管如果你使用你得到的原生 RPC 数据包JAVA 后端非常紧凑。

回答by Michael Neale

No major pitfalls that I haven't been able to overcome easily. Use hosted mode heavily. As you are using GWT-ext you will almost never need to touch CSS yourself unless you want to tweak the out of the box look.

没有我无法轻松克服的重大陷阱。大量使用托管模式。当您使用 GWT-ext 时，您几乎不需要自己接触 CSS，除非您想调整开箱即用的外观。

My recommendation is to use a GWT "native" widget over a library one where they are close in features.

我的建议是在功能接近的库上使用 GWT“本机”小部件。

Re search engine indexing: yes the site will not have navigable URLs normally (unless you are only adding widgets to elements of a regular web site). You can do history back/forward functionality though.

重新搜索引擎索引：是的，该站点通常不会具有可导航的 URL（除非您仅向常规网站的元素添加小部件）。不过，您可以执行历史后退/前进功能。

回答by Confusion

One major pitfall is that sometimes you need to explicitly assign an id to what ultimately becomes an HTML element to be able to use certain CSS styles. For instance: a GWT TabPanel will only do :hover over tabBarItems when the tabBar of the tabPanel has been assigned an id and you specify a :hover on that elementId.

一个主要的缺陷是，有时您需要为最终成为 HTML 元素的元素显式分配一个 id，以便能够使用某些 CSS 样式。例如：GWT TabPanel 只会在 tabPanel 的 tabBar 被分配一个 id 并且你在那个 elementId 上指定一个 :hover 时才会在 tabBarItems 上悬停。

I wrote about some other disadvantages of GWTelsewhere, but they are already covered by rustyshelfs answer :).

我在别处写过GWT 的其他一些缺点，但它们已经被 rustyshelfs 的回答所涵盖:)。

回答by Ace

I used GWT and GWT-ext together on a project a while ago. I found the experience quite smooth as web development goes, but my advice would be this:

不久前，我在一个项目中同时使用了 GWT 和 GWT-ext。我发现随着 Web 开发的进行，体验非常顺利，但我的建议是：

Don't mix GWT native widgets with EXT widgets. It's confusing as hell, since usually the names are the same (GWT.Button or GWText.Button?)

不要将 GWT 本机小部件与 EXT 小部件混合使用。它令人困惑，因为通常名称是相同的（GWT.Button 或 GWText.Button？）

One thing that happened to me that really made the code more complex than I'd like, was that I wanted a Panel that was a) dynamically updatable b) cascadable

发生在我身上的一件事确实使代码比我想要的更复杂，是我想要一个面板 a) 可动态更新 b) 可级联

GWT native panels are dynamic, Ext panels are cascadable. Solution? A GWT.VerticalPanel wrapping a GWTExt Panel... Chaos. :)

GWT 原生面板是动态的，Ext 面板是可级联的。解决方案？包装 GWTExt 面板的 GWT.VerticalPanel... 混乱。:)

But hey, it works. ;)

但是，嘿，它有效。;)

回答by JP Richardson

I'm working on a project right now that uses EXT GWT (GXT) not to be confused with GWT EXT. There is a difference, EXT GWT is the one that is actually produced by the company that wrote ExtJS the javascript library. GWT EXT is a GWT wrapper around the ExtJS library. GXT is native GWT.

我现在正在开发一个使用 EXT GWT (GXT) 的项目，不要与 GWT EXT 混淆。有一个区别，EXT GWT 是由编写 ExtJS javascript 库的公司实际生产的。GWT EXT 是一个围绕 ExtJS 库的 GWT 包装器。GXT 是原生 GWT。

Anyways, GXT is still somewhat immature and lacks a solid community that I feel GWT EXT has. However, the future is with GXT, as it's native GWT and actually developed by the company that made ExtJS. GWT EXT is somewhat crippled as the license changed on the ExtJS library, thus slowing the development of GWT EXT.

无论如何，GXT 仍然有些不成熟，缺乏我认为 GWT EXT 拥有的稳固社区。然而，未来是 GXT，因为它是本地 GWT，实际上是由制造 ExtJS 的公司开发的。由于 ExtJS 库上的许可证更改，GWT EXT 受到了一定的影响，从而减缓了 GWT EXT 的开发。

Overall, I think GWT/GXT is a good solution for developing a web application. I actually quite like hosted mode for development, it makes things quick and easy. You also get the benefit of being able to debug your code as well. Unit testings with JUnit is pretty solid as well. I haven't yet seen a great JavaScript unit testing framework that I felt was mature enough for testing an enterprise application.

总的来说，我认为 GWT/GXT 是开发 Web 应用程序的一个很好的解决方案。我实际上非常喜欢用于开发的托管模式，它使事情变得快速而简单。您还可以获得能够调试代码的好处。使用 JUnit 进行单元测试也非常可靠。我还没有看到一个很棒的 JavaScript 单元测试框架，我觉得它足够成熟来测试企业应用程序。

For more information on GWT EXT: http://gwt-ext.com/

有关 GWT EXT 的更多信息：http: //gwt-ext.com/

For more information on EXT GWT (GXT): http://extjs.com/products/gxt/

有关 EXT GWT (GXT) 的更多信息：http: //extjs.com/products/gxt/

回答by jgindin

Pitfalls that we've run into:

我们遇到的陷阱：

• While you can get a lot of mileage from using something like GWT EXT, any time you use this sort of thin veneer on top of a JavaScript library, you lose the ability to debug. More than once I've bashed my head on the desk because I cannot inspect (inside my IntelliJ debugger) what's happening in the GWT EXT table class... All you can see is that it's a JavaScriptObject. This makes it quite difficult to figure out what's gone wrong...

• Not having someone on your team who knows CSS. From my experience, it didn't matter that the person wasn't expert...it's enough that he has some good working knowledge, and knows the right terms to google when necessary.

• Debugging across browsers. Keep an eye on Out of Process Hosted Mode[1][2][3], hopefully coming in GWT 1.6... For now, you just have to get things good with hosted mode, then use the "Compile/Browse" button, where you can play with other browsers. For me, working on Windows, this means I can view my work in FireFox, and use FireBug to help tweak and make things better.

• IE6. It's amazing how different IE 6 will render things. I've taken the approach of applying a style to the outermost "viewport" according to the browser so that I can have CSS rules like:

  .my-style { /* stuff that works most everywhere */ }
  
  .msie6 .my-style { /* "override" so that styles work on IE 6 */ }
  

• 虽然您可以从使用 GWT EXT 之类的东西中获得很多好处，但是任何时候您在 JavaScript 库之上使用这种薄的单板时，您都会失去调试的能力。我不止一次地把头撞在桌子上，因为我无法检查（在我的 IntelliJ 调试器中）在 GWT EXT 表类中发生了什么......你只能看到它是一个 JavaScriptObject。这使得很难弄清楚出了什么问题......

• 您的团队中没有了解 CSS 的人。根据我的经验，这个人不是专家并不重要……只要他有一些良好的工作知识，并且在必要时知道谷歌的正确术语就足够了。

• 跨浏览器调试。密切关注进程外托管模式[ 1][ 2][ 3]，希望能在 GWT 1.6 中出现...现在，您只需要使用托管模式，然后使用“编译/浏览”按钮，您可以在其中与其他浏览器一起玩。对我来说，在 Windows 上工作，这意味着我可以在 FireFox 中查看我的工作，并使用 FireBug 来帮助调整和使事情变得更好。

• IE6。令人惊讶的是 IE 6 将呈现的东西有多么不同。我采取了根据浏览器将样式应用于最外层“视口”的方法，以便我可以拥有如下 CSS 规则：

  .my-style { /* stuff that works most everywhere */ }
  
  .msie6 .my-style { /* "override" so that styles work on IE 6 */ }
  

Finally, make sure you use an editor that helps you. I use IntelliJ -- it's got lots of GWT smarts. E.g., If I try to use a class that isn't handled by the JRE emulation, it lets me know; if I specify a style for a widget, and I haven't defined that style yet, the code gets the little red squiggly... Or, when looking at the CSS, it will tell me when I've specified conflicting attributes in a single rule. (I haven't tried it yet, but I understand that version 8 has even better GWT support, like keeping the "local" and "async" RPC interfaces and implementations in sync.)

最后，确保您使用对您有帮助的编辑器。我使用 IntelliJ——它有很多 GWT 智能。例如，如果我尝试使用 JRE 仿真未处理的类，它会通知我；如果我为小部件指定了样式，而我还没有定义该样式，则代码会变成红色的小波浪线……或者，在查看 CSS 时，它会告诉我何时指定了冲突的属性单一规则。（我还没有尝试过，但我知道版本 8 有更好的 GWT 支持，比如保持“本地”和“异步”RPC 接口和实现同步。）

回答by ykaganovich

We've had a very hard time marrying our GWT codebase with HTML web templates that we got from a web designer (static HTML pages with specific div ids that we wanted GWT to manage). At least back when we used it, we couldn't get GWT to integrate with parts of our website that were not coded in GWT. We had it working eventually, but it was a big hack.

我们很难将我们的 GWT 代码库与我们从 Web 设计师那里获得的 HTML Web 模板（我们希望 GWT 管理的具有特定 div id 的静态 HTML 页面）结合起来。至少在我们使用它时，我们无法让 GWT 与我们网站中未使用 GWT 编码的部分集成。我们最终让它工作了，但这是一个很大的问题。

回答by Steve Buikhuizen

I second the comment from ykagano, the biggest disadvantage is losing the V in MVC. Although you can separate the true ui class from the rest of your client side code, you cannot easily use an HTML page generated by a graphic/web designer. This means you need a developer to translate HTML into java.

我支持 ykagano 的评论，最大的缺点是在 MVC 中丢失了 V。尽管您可以将真正的 ui 类与客户端代码的其余部分分开，但您无法轻松使用图形/网页设计师生成的 HTML 页面。这意味着您需要开发人员将 HTML 翻译成 Java。

Get a wysiwyg ui editor, it will save you lots of time. I use GWTDesigner.

获得一个所见即所得的 ui 编辑器，它将为您节省大量时间。我使用 GWTDesigner。

The biggest upside of GWT is being able to forget about cross browser issues. Its not 100% but takes almost all that pain away. Combined with the benefit of hosted mode debugging (as opposed to Firebug which is excellent but not the same as a java debugger) it gives the developer a huge advantage in generating complex ajax apps.

GWT 的最大优点是能够忘记跨浏览器问题。它不是 100% 但几乎消除了所有的痛苦。结合托管模式调试的优势（与 Firebug 不同，Firebug 非常出色但与 Java 调试器不同），它为开发人员提供了生成复杂 ajax 应用程序的巨大优势。

Oh and its fast at runtime, especially if you use a gzip filter.

哦，它在运行时很快，特别是如果你使用 gzip 过滤器。

回答by Steve Buikhuizen

Slightly off-topic, but the #gwt channel on irc is very helpful, in-case you have a persistent problem.

有点跑题，但 irc 上的 #gwt 频道非常有用，以防您遇到持续性问题。

回答by Miguel Ping

I'll add some points to the ones already mentioned:

我将在已经提到的内容中添加一些要点：

• Databinding/validation. GWT doesn't have a databinding/validation support out of the box, although there are some projects on this area starting to emerge. You'll find yourself writing alot of this:

• 数据绑定/验证。GWT 没有开箱即用的数据绑定/验证支持，尽管该领域的一些项目开始出现。你会发现自己写了很多这样的：

TextField fname, faddress;
...
fname.setText(person.getName());
faddress.setText(person.getAddress());
...

• Lazy loading. Since gwt is on the client side, lazy loading is really not an option. You'll have to design your RPCs and Domain Objects carefully in order to
  • send all your object data that is needed
  • avoid eager fetching all of your data
  • You'll have also to make sure that you will not send proxies/non serializable objects. hibernate4gwtcan help you with these points.
• UI design. It is harder to visualize an UI in java (Panels, Buttons, etc) than in html.
• History support. GWT does not ship with a History subsystem, nor does it ship with any subsystem for nice urls or statefull bookmarking. You'll have to roll your own (although it has support for History tokens, which is a start). This happens with all AJAX toolkits AFAIK.

• 懒加载。由于 gwt 在客户端，因此延迟加载确实不是一种选择。您必须仔细设计您的 RPC 和领域对象，以便
  • 发送所有需要的对象数据
  • 避免急切地获取所有数据
  • 您还必须确保不会发送代理/不可序列化的对象。hibernate4gwt可以帮助您解决这些问题。
• 界面设计。在 java（面板、按钮等）中可视化 UI 比在 html 中更难。
• 历史支持。GWT 不附带历史子系统，也不附带任何用于漂亮 url 或有状态书签的子系统。你必须自己推出（尽管它支持历史令牌，这是一个开始）。所有 AJAX 工具包 AFAIK 都会发生这种情况。

IMHO, GWT is missing a framework that has out of the box support for all of the issues mentioned on this 'thread'.

恕我直言，GWT 缺少一个框架，该框架对这个“线程”中提到的所有问题都有开箱即用的支持。