我想問問任何人是否有過將基於網格的CSS系統（960或類似系統）與GWT uibinder應用程序集成的經驗。GWT UiBinder - 基於網格的CSS樣式
我們的應用程序使用GWT 2.1，UIBinder和最新的GWT CSS功能完成，這些功能非常適合並且使我們擁有模塊化和靈活的樣式系統。我們的設計團隊已經返回了帶有相應網格CSS文件的HTML佈局，我們應該將它們與我們的GWT代碼進行整合。
如果我們要將網格樣式集成到我們的uibinder xml文件中，我們必須用正確的網格類名稱來包裝我們所有的GWT小部件。
就我個人而言，我不喜歡將模塊化的uibinder系統與一個完全獨立的網格css關注點混合在一起的想法，但我確實瞭解網格系統可以提供的好處。
任何意見或經驗？兩種方法的優缺點？
我們發現自己處於類似的位置，應用程序圍繞gwt，MVP和uibinder構建。這對於開發人員來說非常棒，但對於設計師來說卻不是那麼好。在開始時，我們給了他們我們app + css的html快照，並要求他們設計它。他們不喜歡這樣。當客戶想要由他們的設計師完成定製設計時，它變成了一場噩夢。
現在的問題是隻是將你的小部件封裝在div中就夠了嗎？我們的設計師提供了自定義按鈕，表格，鏈接等。強迫gwt小部件看起來像設計是一項相當艱鉅的任務。
所以，我們所做的是：
替換GWT爲中心的應用程序設計，以HTML爲中心之一。這意味着我們避免在代碼中生成html。我們使用經典的html + JS + jQuery apporach，而不是JS，我們使用gwt，而使用jQuery，我們使用gwtQuery。我們只使用幾個gwt小部件。相反，在視圖中，我們使用gwtQuery來複制&展開設計者提供的示例html。 GwtQuery可以是externalized：如果設計更改（客戶需要更改或者甚至引入設計），那麼所有選擇器都可以放在一個（或多個）外部接口中，而這個html和gwt的交集都在同一個位置。
開溝gwt 2.2 mvp（活動，地點），爲我們自己的，這是一個簡化版gwt 2.1 mvp architecture。我們不再需要添加2個新類並更新其他類（地點，標記器，更新地點工廠）以創建新地點。