什么是启动GWT应用程序的正确方法？

Question

1. 我是否设计了基本的骨架HTML并从那里开始，通过java代码插入组件和动作？

2. 通过使用java代码设计细节，计划将整个东西构建为java程序吗？

3. 还是有更好的方式我不知道？

除此之外，维护代码有多容易或复杂？

我是GWT的新手，我知道非常基础。

提前感谢您的意见。

Answer 1

我在GWT / Seam项目工作一年后的见解。我假设没有现有的网站意味着你可以从头开始。如果有，我建议您尊重您的遗产并通过有选择地将GWT小部件插入现有html页面的特定位置来进行改进（更多细节here）。

我们的开发过程大致可以通过以下步骤进行总结（反馈循环，站立会议以及此类遗漏，您知道这笔交易）：

1. 功能请求：包含高级所需功能的描述

2. Wire Frames：一个高级用户界面，给人以第一印象，即如何向最终用户提供功能以及如何将其集成到现有应用中（没有任何铃声和口哨声）

3. 最终设计：我们的设计师创建的新功能的最终扩展UI（仅限Photoshop，没有html骨架，没有css）

4. 实施和测试：我将专注于实施并描述一年内的变化情况

我们使用GWT 1.6启动了我们的项目，但缺少UiBinder的任何支持。所以决定是1）使用GWT构建我们应用程序的整个客户端（即java代码）或2）使用JSF构建我们的页面（因为我们使用Seam）并使用GWT小部件扩展它们。我们决定采用第二种选择，主要是因为我们喜欢将大部分状态推送给客户并让他们进行处理的想法。在Java开发方面做得很好，我们在java开发方面有着强大的背景。

实现业务逻辑完全没有问题。我们花费最多时间的是构建UI：编写页面布局并在Java中设置样式非常耗时且容易出错。最终的html（基于第3步的设计）和GWT小部件之间的差距太大了。

切换到UiBinder是我们在发布GWT 2.0时迈出的第一步。由于我们不得不重新编写大部分客户端代码，因此我们还调整了MVP pattern。之后，生产力得到显着提升：一个开发人员正在实施业务逻辑（主要是MVP的演示者部分），而另一个开发人员正在忙于构建视图部分（.ui.xml和小部件）。 Unit testing也变得更加容易，因为主要功能现在在演示者部分很好地分开（并且GWTTestCase是过去的一部分）。

我们目前正在做的下一个主要步骤是从我们自己的MVP实现切换到更精细的实现（即gwt-platform）。这个决定背后的基本原理：DI通过GIN（依赖关系清晰，代码变得更清晰），对浏览器历史的良好支持（我们不顾一切地忽略它 - 一个巨大的错误！），代码拆分支持，异步调用的命令模式等等。

经过一年的经验，我的结论是：使用UiBinder作为UI部分，并寻求一个干净的MVP架构。学习曲线可能很陡峭但走在同一条道路上，所以很多GWT开发人员都会花费你更多的时间。

......我的2美分：）

Answer 2

我的建议是从思考你的界面开始。它将如何发展，最重要的是它将如何发挥作用。考虑一下您的应用将为其用户解决的问题，以及如何通过最少的点击和滚动来实现这一点。对你的界面进行原型设计，UiBinder对此很有好处，然后通过事件处理程序和服务调用开始使它活跃起来。

最简单的方法是实现一个功能，然后构建一个适合该实现的接口，但是你最终会得到一些不太好用的东西。您可能也想考虑您的数据模型/数据库模式，但不要像许多其他开发人员那样陷入构建笨重的CRUD应用程序的陷阱。

GWT代码是相当可维护的，当然比根据我的经验构建一个没有它的跨平台webapp更为可靠。您应该查看google-gin和gwt-mvp，它们有助于保持代码模块化并易于测试。