GWT UiBinder - 基于网格的 CSS 样式
我想问是否有人有将基于网格的 CSS 系统（960 或类似）与 GWT uibinder 应用程序集成的经验。
我们的应用程序是使用 GWT 2.1、UIBinder 和最新的 GWT CSS 功能完成的，这些功能非常适合使用，并使我们能够拥有模块化且灵活的样式系统。我们的设计团队已经返回了带有相应网格 css 文件的 HTML 布局，我们应该将它们与我们的 GWT 代码集成。
如果我们要将网格样式集成到我们的 uibinder xml 文件中，我们必须使用具有正确网格类名称的 div 来包装所有 GWT 小部件。
就我个人而言，我不喜欢将完全独立的网格 CSS 关注点与模块化 uibinder 系统混合在一起的想法，但我确实了解网格系统可以提供的好处。
有什么意见或经验吗？这两种方法的优点和缺点？
I would ask if anyone has had experience in integrating a grid based CSS system (960 or similar) with a GWT uibinder application.
Our application is done with GWT 2.1, UIBinder and the latest GWT CSS capabilities, which have been really great to work with and enabled us to have a modular and flexible styling system. Our design team has returned a HTML layout with the corresponding grid css files and we are supposed to integrate them with our GWT code.
If we were to integrate the grid styles into our uibinder xml files we would have to wrap all our GWT widgets with divs with the right grid class names.
Personally I don't like the idea of mixing a completely separate grid css concern with the modular uibinder system, but I do understand the benefits the grid system can provide.
Any opinions or experiences? Pros and Cons for either approach?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我们发现自己处于类似的境地，我们的应用程序是围绕 gwt、MVP 和 uibinder 构建的。这对于开发人员来说是件好事，但对于设计师来说却并非如此。一开始，我们给了他们我们的应用程序 + css 的 html 快照，并要求他们设计它。他们不喜欢这样。当客户希望他们的设计师完成定制设计时，这变成了一场噩梦。
问题是简单地将小部件包装在 div 中就足够了吗？我们的设计师提供了自定义按钮、表格、链接等。强制 gwt 小部件看起来像设计是一项艰巨的任务。
所以我们所做的是：
用以 html 为中心的应用程序设计替换了以 gwt 为中心的应用程序设计。这意味着我们避免在代码中生成 html。我们使用经典的 html+JS+jQuery 方法，只是我们用 gwt 代替 JS，用 gwtQuery 代替 jQuery。我们只使用几个 gwt 小部件。相反，在视图中，我们使用 gwtQuery 来复制和扩展设计器提供的示例 html。 GwtQuery 可以外部化：所有选择器都可以放入一个（或多个） ）外部接口，如果设计发生变化（客户想要更改，甚至引入他们的设计），则 html 和 gwt 的交集都集中在一个位置。
为了我们的目标，放弃了 gwt 2.2 mvp（活动、地点）自己的，它是 gwt 2.1 mvp 架构的简化版本。我们不再需要添加 2 个新类并更新其他类（地点、分词器、更新地点工厂）来获得新地点。
We found ourselves in a similar position, having the app built around gwt, MVP and uibinder. This is great for developers, but it turned out to not be so great for designers. At the begining we gave them a html snapshot of our app + css and asked them to design it. They did't like this. It became a nightmare when customers wanted custom designs done by their designers.
The question is will simply wrapping you widgets in div be enough? Our designer provided custom buttons, tables, links, etc.. It was quite a task to force gwt widgets to look like the design.
So what we did was:
Replaced gwt-centric app design with html-centric one. This means we avoid generating html in code. We use classic html+JS+jQuery apporach, just instead of JS we have gwt and instead jQuery we use gwtQuery. We use only a few gwt widgets. Instead, in out Views we use gwtQuery to copy&expand example html that designer provided. GwtQuery can be externalized: all selectors can be put in one (or many) external interfaces, if a design changes (customers want changes or even bring in their designs) this intersection of html and gwt is all in one place.
Ditched gwt 2.2 mvp (activities, places), for our own which is a simplified version of gwt 2.1 mvp architecture. We no longer have to add 2 new classes and update others (place, tokenizer, update place factory) to have a new place.