我想问是否有人在将基于网格的 CSS 系统（960 或类似系统）与 GWT uibinder 应用程序集成方面有经验。
我们的应用程序是使用 GWT 2.1、UIBinder 和最新的 GWT CSS 功能完成的，这些功能非常好用，使我们能够拥有模块化和灵活的样式系统。我们的设计团队返回了一个带有相应网格 css 文件的 HTML 布局，我们应该将它们与我们的 GWT 代码集成。
如果我们要将网格样式集成到我们的 uibinder xml 文件中，我们将必须使用具有正确网格类名称的 div 来包装所有 GWT 小部件。
我个人不喜欢将完全独立的网格 css 关注点与模块化 uibinder 系统混合的想法，但我确实理解网格系统可以提供的好处。
有什么意见或经验吗？两种方法的优缺点？
【问题讨论】：
我们发现自己处于类似的位置，应用程序围绕 gwt、MVP 和 uibinder 构建。这对开发人员来说很好，但对设计师来说却不是那么好。一开始，我们给了他们我们的应用程序 + css 的 html 快照，并要求他们设计它。他们不喜欢这样。当客户希望他们的设计师完成定制设计时，这变成了一场噩梦。
问题是简单地将小部件包装在 div 中就足够了吗？我们的设计师提供了自定义按钮、表格、链接等。强制 gwt 小部件看起来像设计是一项艰巨的任务。
所以我们所做的是：
将以 gwt 为中心的应用程序设计替换为以 html 为中心的应用程序设计。这意味着我们避免在代码中生成 html。我们使用经典的 html+JS+jQuery apporach，我们使用 gwt 代替 JS，而使用 gwtQuery 代替 jQuery。我们只使用几个 gwt 小部件。相反，在 out Views 中，我们使用 gwtQuery 来复制和扩展设计器提供的示例 html。 GwtQuery 可以是externalized：所有选择器都可以放在一个（或多个）外部接口中，如果设计发生变化（客户想要更改甚至引入他们的设计），html 和 gwt 的这个交集都在一个地方。
放弃gwt 2.2 mvp（活动、地点），为我们自己的gwt 2.1 mvp architecture 简化版本。我们不再需要添加 2 个新类并更新其他类（地点、标记器、更新地点工厂）以获得新地点。
【讨论】：