??? 本來是計劃讓團隊內的同事一起總結使用qooxdoo的使用經驗和困難，然后寫些關于使用qooxdoo的總結供大家參考，但因為項目的原因到現在也沒有時間辦這件事情，所以打算還是零零碎碎的寫一點是一點，亂就亂了，今后再整理。另外最近發現其實國內還是有不少人關注和使用qooxdoo的，所以立馬寫下這個帖子拋磚引玉。
1、qooxdoo基本信息??? qooxdoo帶有XHR的封裝，但其主要的還是WEB UI，提供了類似桌面程序的窗口小部件。
??
http://m.tkk7.com/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方法也不是按照字母順序進行排序的。這個福星高照兄也提到了。