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