本來是計劃讓團隊內的同事一起總結使用qooxdoo的使用經驗和困難，然後寫些關於使用qooxdoo的總結供大家參考，但因為項目的原因到現在也沒有時間辦這件事情，所以打算還是零零碎碎的寫一點是一點，亂就亂了，今後再整理。另外最近發現其實國內還是有不少人關注和使用qooxdoo的，所以立馬寫下這個帖子拋磚引玉。
1、qooxdoo基本信息qooxdoo帶有XHR的封裝，但其主要的還是WEB UI，提供了類似桌面程序的窗口小部件。
http://www.blogjava.net/ynstudio/archive/2006/07/23/59648.html從上面的鏈接可以看到我們開發的一個項目中的幾個截圖，也可以到其官方網看其demo.官方網站 http://qooxdoo.org/ ，在官方網站上可以看到其下載地址，有兩個文件，一個是src一個是build，所謂build就是把所有的src裡的js文件都合並到一個js文件裡，排成一行，去除注釋，從而縮小體積，但也有700多K. http://www.nabble.com/Javascript-f15545.html 是一個關於幾個javascript應用的論壇，其中就有qooxdoo的，你可以從這裡了解其動態，參與相關的討論。
2、RPC如果使用qooxdoo，而不使用XHR，那麼頁面就需要刷新，這個是麻煩的。我們本來是使用的DWR，現在使用的是經自己改造的JSON-RPC-JAVA.現在java裡似乎主要就是這兩個。其他語言的話，如。net，perl，php都有json-rpc的實現。使用了類似JSON-RPC-JAVA和dwr這樣的技術，開發模式就類似一般的C/S開發了，當然困難還是有的。
3、我們使用qooxdoo遇到的一些困難A、首先是界面的開發，雖然類似C/S的開發方式了，不再存在頁面刷新帶來的煩惱，思考問題更加直接，不需考慮參數傳來傳去，不需學習一堆的標簽，特別是對於剛接觸WEB開發的程序員，接受起來更加容易。但是界面都是使用代碼來構建的，而javascript也沒有很好的編輯工具。所以剛開始開發時還是滿痛苦的。後來有了些改觀，1、規范代碼結構，界面代碼，事件響應代碼，公用函數，歸類擺放；2、選擇更好的編輯工具，如JSEclipse，aptana等；3、使用調試工具，我認為firefox的firebug是最好的；4、盡量把邏輯放在java裡，降低界面javascript的復雜度。另外今後我們將推廣QxBuilder的使用。
B、layout的使用。對於我們這些開發人員，習慣使用table來進行布局，在qooxdoo裡只有QxGridLayout最象，但不好使用。我們開發了一些輔助方法來降低其使用難度。
C、沒有類似HTML裡的Form.使用qooxdoo加RPC其實不存在，HTML中的Form+submit的方式，但直接對fieldtext等進行操作，感覺不如form方便，所以我們開發了一個FormManager來進行輔助。
D、中文資料少，或者說基本上沒有，有的只是些轉來轉去的沒用的文字。
E、效率問題，起初為了方便開發，主頁面和其他頁面之間都是用QxNativeWindow的方式，即window.open，但由於IE的問題，以及qooxdoo 700k 的代碼，導致每打開然後關閉一個新窗口，內存以6~10M的速度遞增。這個問題的解決有兩個方案，一個是不允許同時打開兩個窗口，所有的頁面都在一個iframe裡切換，另外就是在主頁面裡使用QxWindow，但一個使用不方便，一個開發不方便。
4、排序的問題這個是福星高照兄發現的，原文如下qooxdoo默認用的是sort方法，這個方法的排序是按照字符集的順序來的關於中文排序問題，可以修改QxCompare.js，把QxCompare.byString的方法改了，倒是很簡單，改成return a.localeCompare（b）；localeCompare（）使用本地特定的順序來比較兩個字符串，語法如下：string.localeCompare（target）
參數target是要與string進行比較的字符串。
如果string小於target，則localeCompare（）返回小於0的數；如果string大於target，返回大於0的數；如果不願意改QxCompare.byString，那麼添加一個compare對象也成。
本來我以為是我用的是utf-8導致排序按照utf-8裡的漢字排序，但我測試發現，即便是純的GBK頁面，Array的sort方法也不是按照字母順序進行排序的。這個福星高照兄也提到了。