在遗留应用程序中具有多个主机页的GWT

我正在考虑使用GWT作为现有web应用程序的前端

我无法证明一次性完全重写到100%GWT是合理的。我可能会逐渐将系统的一部分迁移到GWT。然而，为了保持一致性，我希望从第一天起就使用GWT选项卡面板、菜单栏等作为全局接口元素

作为一个实验，看看如何将系统的“遗留”部分合并，我做了以下工作

应用程序的主页模板现在在每个页面上加载一个小的“包装器”GWT模块。此GWT模块在动态生成的主机页中查找所选的div。如果找到了DIV，则会在适当的位置插入一个合适的小部件，即menuBar、tabPanel

所包含小部件的许多配置也可以作为JSON结构插入到主机页中。例如，我实现了一个适配器，它以这种方式动态地设置选项卡面板。我还添加了一些加载远程HTML等的非常简单的小部件

作为一个原型，这一切似乎工作得很好，加载速度也很快。 然而，似乎GWT应用程序实际上是设计为从单个主机页运行的，而不是数百个动态生成的主机页

有人能强调上述方法可能遇到的任何问题吗，特别是在GWT模块规模增大的情况下？我的目标是故意保持遗留包装器模块的精简。其他功能将在单独的模块中实现

---

其他人是如何以渐进的方式将GWT集成到前端的？

GWT的设计使用方式之一与您使用的方式完全相同。我们在很多应用程序中都这样做了——其中有一个GWT模块，其中包含多个“部件”，这些部件是根据页面上是否存在给定id加载的。所以我不认为你这样做会有任何问题。我们经常在新的web应用程序中使用这种方法，在这些应用程序中，我们只需要页面上的一些“小部件”，而不是用GWT编码整个应用程序

---

这不会有很大的区别，但我建议不要将GWT javascript代码放入主模板中，而只将其放在需要它的页面上。的确，如果您不运行HTTPs，它基本上是永久缓存的，但是如果该页面上实际上不需要它，那么让人们加载模块似乎是错误的。这当然取决于人们如何使用你的网站，如果他们无论如何都可能下载它，那么这不会有任何区别。

你做得对。避免尝试通过将GWT分解为多个单独的应用程序来“最小化”GWT足迹的诱惑

GWT性能的关键是尽可能少的下载并确保它们被缓存。一次加载一个250k包要比两个200k包好得多，而且由于文件越大，压缩效果越好，随着时间的增长，您确实开始获得好处

y-slow&firebug在说服自己这一点时真的很有帮助

下面的示例章节中提供了一个您可能会了解的性能技巧： 它展示了一个围绕着将GWT小部件加载到任意数量的插槽和在JavaScript变量中预填充数据的迷你体系结构。这允许您的GWT小部件加载，而不需要第二个HTTP GET来获取它们使用的数据。在实践中，我发现这是一个很好的性能提升