simplejee 入門級j2ee開源項目

# re: qooxdoo 0.6rc1 發(fā)布了 2006-08-23 09:03 sun123

to 一農(nóng)
你現(xiàn)在開始用0.6作了嗎？我看了一下demo，好像覺得比先前的版本慢了，特別是at-a-glance，好慢阿。
還有那個api打開也很慢。
table 確實做的不錯，還沒來得及細(xì)細(xì)琢磨。
還有你知道國內(nèi)還有哪些網(wǎng)頁討論qx的嗎？  回復(fù)  更多評論   

# re: qooxdoo 0.6rc1 發(fā)布了 2006-08-23 09:18 一農(nóng)

@sun123
速度上我沒太注意，那個api打開慢，我想主要是內(nèi)容多。
我現(xiàn)在新的項目打算使用0.6來做，并且已經(jīng)把原來使用0.5x的一個頁面改為了0.6的庫，除了類名上的轉(zhuǎn)換，其他有少許改動。還有些細(xì)節(jié)問題，現(xiàn)在還沒來得及細(xì)看。
文中我說其api的doc好用，現(xiàn)在看也不全是，原來的時候，看一個類，在一個頁面上可以同時看到該類本身和其父類的所有屬性和方法，但現(xiàn)在要一層層的點，感覺反倒不如之前了。:)

我還沒找到國內(nèi)討論qx的地方，本來想給Ajax中國論壇聯(lián)系一下，開個qx的版，但看了一下Ajax中國經(jīng)營的不太理想。  回復(fù)  更多評論   

# re: qooxdoo 0.6rc1 發(fā)布了 2006-08-23 09:19 一農(nóng)

不過你可以到國外的
http://www.nabble.com/Javascript-f15545.html
做些相關(guān)的了解  回復(fù)  更多評論   

# re: qooxdoo 0.6rc1 發(fā)布了 2006-09-15 01:00 一農(nóng)

有不少同仁詢問關(guān)于qooxdoo和json-rpc-java的相關(guān)問題，這里做些說明：

1、qooxdoo的官方網(wǎng)站是qooxdoo.org，上面有demo，很多，你可以下載后在本機(jī)查看。對于ajax，dojo，yui也要多關(guān)注，dojo受支持程度更好些。最近我在使用jquery，感覺非常好，推薦了解。
2、qooxdoo和json-rpc-java沒什么必然的聯(lián)系，json-rpc-java就是一種web rpc，如果你只做java的話，建議看看dwr就可以了。另外qooxdoo本身也有rpc模塊，是基于json-rpc的。  回復(fù)  更多評論   

# re: qooxdoo 0.6rc1 發(fā)布了 2006-09-26 10:00 oasis

我自己的一個試驗性質(zhì)的網(wǎng)站，用qooxdoo 0.6做的前臺UI。
http://www.aurora-x.net
把我以前用傳統(tǒng)B/S做的一些冬冬，慢慢的轉(zhuǎn)換到這個框架下，邊摸索邊使用，呵呵。

IE下渲染速度慢以及消耗資源大，這是IE6實現(xiàn)的問題，在IE7的測試版中，這種情況已得到明顯改善，和FireFox 1.5差不多了。

qooxdoo在0.6引入了namespace這一點非常重要，是將來能得到成熟應(yīng)用的關(guān)鍵。

它的custom build能力很好玩，不過居然使用make來做build，估計這年頭做web開發(fā)的人沒有幾個有在*nix下寫C程序的經(jīng)歷吧？ :-D

完整的qx.js雖然有1M大，用gzip壓縮過后有150K，這樣后臺用Apache + mod_deflate還算可以。

我寫的程序里后端用Java + org.json包構(gòu)建所需的JSON對象，因為一般我的程序也會提供Web Service接口，所以還會采用Java + AXIOM來生成DOM對象。所以我在這方面就不用什么框架了，沒有什么特別的方便性，還不如自己這樣來的靈活。

  回復(fù)  更多評論   

# re: qooxdoo 0.6rc1 發(fā)布了 2006-09-26 15:18 originxu

用NativeWindow,每開一頁會有8-10M內(nèi)存遞增,但是用Window,顯示開發(fā)起來太困難,困難得有些不敢想象,特別是開發(fā)比較大的系統(tǒng),關(guān)鍵是它怎么實現(xiàn)國際化呢?  回復(fù)  更多評論   

# re: qooxdoo 0.6rc1 發(fā)布了 2006-09-26 15:20 originxu

如果頁面全部用js生成的話,特別是單獨的一個js文件,怎么能實現(xiàn)國際化呢?一些標(biāo)簽,如窗口標(biāo)題,  回復(fù)  更多評論   

# re: qooxdoo 0.6rc1 發(fā)布了 2006-09-26 15:28 originxu

如果生成界面時,再向后臺請求標(biāo)簽,那不現(xiàn)實,引入單獨的js,也不能實現(xiàn)國際化,放入jsp倒是可以利用struts,但不可能所有的js放入一個jsp文件啊,而且這樣和json-rpc背得有些遠(yuǎn)了,難道生成界面用jsp,具體操作用json-rpc?在java方法里動態(tài)輸出js?那有多麻煩啊,好像并沒有一個比較好的辦法解決這個問題啊,再另外引入一個中間層,比如表現(xiàn)層?  回復(fù)  更多評論   

# re: qooxdoo 0.6rc1 發(fā)布了 2006-09-27 09:22 oasis

@originxu
1、NativeWindow吃內(nèi)存是IE6的問題，你看一下我之前的回復(fù)已有說明

2、國際化有什么難的？每個語言對應(yīng)一個js，輸出html的時候根據(jù)情況包含不同語言的js即可。  回復(fù)  更多評論   

# re: qooxdoo 0.6rc1 發(fā)布了 2006-09-27 09:51 originxu

@oasis
1.選擇的問題,如果NativeWindow在內(nèi)存的消耗上沒有問題的話(通過使用IE7或FireFox1.5),似乎使用NativeWindow是更好的選擇,相比qx.ui.window.Window來說,使用qx.ui.window.Window似乎更像用c去寫操作系統(tǒng),對開發(fā)企業(yè)級系統(tǒng)來說,在沒有好的IDE支持下,應(yīng)該會比較少人愿意去寫百萬級以上的js代碼.而且還是和qx一樣,包含幾百個js文件

2.國際化問題,每個語言包含一個js文件,這是jscanlender的做法,如果資源文件太大,可能多達(dá)幾M(對大型系統(tǒng)來說,這應(yīng)該有可能吧),會否消耗太多?

3.在目前情況下,qx是否適合開發(fā)大型系統(tǒng),比如3pl系統(tǒng)?在處理大數(shù)據(jù)量上,qx是否經(jīng)得起考驗?  回復(fù)  更多評論   

# re: qooxdoo 0.6rc1 發(fā)布了 2006-09-27 10:03 originxu

@oasis
我剛進(jìn)了下你的網(wǎng)站,初次打開還是挺慢的,如果再加上自己寫的可能也是上百萬的js代碼,幾百個js代碼,那初次加載速度可能更慢了,如果用qx.ui.window.Window來模擬頁面的話,那所有的js文件,在初次加載的時候,也是全部加載的,如果再加上國際化的資源文件,那速度就更慢了,這是一個問題啊  回復(fù)  更多評論   

# re: qooxdoo 0.6rc1 發(fā)布了 2006-09-27 10:06 originxu

@oasis
在多窗口的情況下,并非buttonview實現(xiàn),  回復(fù)  更多評論   

# re: qooxdoo 0.6rc1 發(fā)布了 2006-09-27 11:28 oasis

@originxu

1、關(guān)于語言的那個問題，我想我現(xiàn)在明白你的意思了，你是說當(dāng)把一個語言下的所有資源寫在一個文件里時，加載的時候不太劃算，因為以后每個頁面只使用了其中很小的一部分。這個問題我覺得挺難回答，顯然這樣做是一種很簡明的實現(xiàn)方式，維護(hù)起來也輕松。如果要分次輸出的話，就得針對每個頁面維護(hù)一組語言資源了。另外我覺得幾兆也不算太大，用Apache+mod_deflate壓縮的話，通常對于這些文本都能獲得10:1的壓縮比的。

2、對于加載速度我沒有仔細(xì)的研究過，下載js代碼的等待，代碼庫的載入、對象的初始化，這些環(huán)節(jié)我不太清楚那個是其中的bottle neck。也可能都是，在不同的條件下會有變化。

3、我覺得用qx.ui.window.Window來模擬所有的頁面，不是個好主意，基本上我個人覺得它只起到一個對話框的功能，或者說它命名為Dialog更合適一些。真正的窗口還是瀏覽器客戶區(qū)這一塊，大部分的文章還是應(yīng)該在這里面做。

4、qooxdoo處理大數(shù)據(jù)量？你的意思是把大量的數(shù)據(jù)挪到Browser處來做？反正像Table，List這些widget經(jīng)測試存儲上萬條記錄也不會有什么性能上的影響。不過我認(rèn)為還是應(yīng)該在設(shè)計的時候在B/S兩者之間取得一個平衡，無論走哪個極端都不太好，呵呵。  回復(fù)  更多評論   

# re: qooxdoo 0.6rc1 發(fā)布了 2006-09-27 13:50 originxu

@oasis
1.關(guān)于多語言,分次載入,我的想法是能不能像ImagePreloader那樣,通過RPC提前載入一些本頁面相關(guān)的語言文本,比如說MessageResourcePreloader之類,不用靜態(tài)的js文件保存資源文件

2.如果用NativeWindow,每個頁面包含qx.js,每打開一個頁面,qx.js就要重新載入,初始化一次(不太清楚瀏覽器具體機(jī)制,不知是不是這樣),然后在新的窗口里,也要定義main之類的函數(shù),也就是每一個頁面的執(zhí)行流程都一樣

3.用qx.ui.window.Window來模擬所有的頁面,確實不太好,開發(fā)太困難了,也不好維護(hù)

4.Apache+mod_deflate倒沒怎么用,一般用tomcat,weblogic,這些好像并不能壓縮吧,

5.關(guān)于大數(shù)據(jù)量,一般不會一次性加載上萬條記錄吧？一般應(yīng)該都會分頁

６.另，不知道在哪里能夠改圖片文件的加載路徑，默認(rèn)是../../icon之類，  回復(fù)  更多評論   

# re: qooxdoo 0.6rc1 發(fā)布了 2006-09-29 10:45 originxu

原來在qx.manager.object.AliasManager里，  回復(fù)  更多評論   

# re: qooxdoo 0.6rc1 發(fā)布了 2006-09-29 14:38 一農(nóng)

1、我感覺主要的停頓是發(fā)生在代碼庫的載入、對象的初始化，所以使用NativeWindow總有些不太好，但是也如大家討論，直接使用qx模擬的window確實也有諸多問題，我自己也使用過通過xhr載入js文件的方法，來實現(xiàn)類似多文檔的方式，但效果不理想。通過封裝可以解決變量命名的問題，但我有些頁面需要直接寫一些HTML來實現(xiàn)，這些HTML里的id就要保證不重名。再就是調(diào)試的問題。雖然上述問題我也都找到了解決的方法，但仍感覺不放心，所以我現(xiàn)在還是決定使用NativeWindow的方式，這個難度較低，容易掌握，主要問題就是載入庫時的速度問題，我想應(yīng)該想辦法壓縮庫，每個頁面載入的庫，可以做些裁減。這個解決方法或許更穩(wěn)妥些。
2、國際化，用靜態(tài)js的話是比較麻煩，但既然大家抉擇使用struts+jsp可以解決國際化問題，那我抉擇可以把js當(dāng)jsp來處理嘛。隨便說說，我現(xiàn)在也沒考慮這個事情。
3、百萬級js代碼，我現(xiàn)在做的項目因為是基于qooxdoo的，所以多數(shù)頁面都是全js的，當(dāng)然限于項目的規(guī)模沒有百萬級js。但使用xhr載入js文件的話，就不存在一次性載入上百js文件的問題了。
  回復(fù)  更多評論   

# re: qooxdoo 0.6rc1 發(fā)布了 2006-09-29 15:25 一農(nóng)

我發(fā)現(xiàn)dojo的樣式是通過元素的class定義的,所以如果要修改樣式,直接在當(dāng)前頁面里重新定義這些class就可以了.
而qx的是通過元素的style來定義的,需要修改theme的相關(guān)配置,感覺和dojo相比不甚方便.
不知這個理解是否正確.  回復(fù)  更多評論   

# re: qooxdoo 0.6rc1 發(fā)布了 2006-09-30 09:12 oasis

@一農(nóng)

qooxdoo的設(shè)計者故意不讓用戶去直接操縱HTML/CSS的，他認(rèn)為盡管某些時候這樣做可能會帶來一些方便，但是有明顯的缺陷：
1、用戶必須成為HTML/CSS的專家，而當(dāng)涉及到跨瀏覽器的一致性時，這個難度就更大了。
2、局限于CSS的能力，按照作者的說法，CSS的設(shè)計初衷是修飾網(wǎng)頁而不是高級GUI界面，有不少方面是用CSS無法做到的。
3、不能支持復(fù)雜的布局

因此，雖然qooxdoo內(nèi)部也使用CSS來渲染DOM，但是并不要求客戶程序員去直接使用它。作者對qx的定位是高級的框架，不僅僅是幾個widget那么簡單。
  回復(fù)  更多評論   

# re: qooxdoo 0.6rc1 發(fā)布了 2006-09-30 09:19 oasis

對于qx模擬的window，因為我只將它當(dāng)作對話框來使用，所以我目前感到唯一不便的是，對話框中的widget的值如何與cookie或是服務(wù)端beans中的值保持一致。這個應(yīng)該可以被大大的簡化。
  回復(fù)  更多評論   

# re: qooxdoo 0.6rc1 發(fā)布了 2006-10-09 09:33 originxu

1.還是沒有完全明白一農(nóng)具體的做法,感覺你是各種方式都在用,但最終你用的哪種呢?不知道能否詳細(xì)描述下,也給我等末進(jìn)取取經(jīng)?因為某種程度上,我感覺qooxdoo用哪種方式都有一些問題沒法解決,不是性能問題,就是開發(fā)困難,總之并沒有一個比較成熟的,能應(yīng)付開發(fā)一個完整系統(tǒng)的解決方案,我說的是比較大型的系統(tǒng),不是一個小Demo
2.使用xhr載入js文件,后臺怎么實現(xiàn)?json遠(yuǎn)程調(diào)用bean方法?還是?
3.是否完全使用json-rpc實現(xiàn),沒有用到j(luò)sp,servlet(除了json實現(xiàn)必用到的)?
4.如果完全采用json-rpc,權(quán)限怎么實現(xiàn)?
5.國際化問題,你的系統(tǒng)中好像并沒有實現(xiàn)國際化?  回復(fù)  更多評論   

# re: qooxdoo 0.6rc1 發(fā)布了 2006-10-10 15:57 一農(nóng)

@originxu
1、我現(xiàn)在做的一個正式項目就是使用的qx，已經(jīng)接近尾聲。ui使用的qx，沒有采用什么特殊的東西。我就采用最直接的新開窗口，雖然消耗資源較多，但可以忍受。另外dojo蠻好的，可以考慮一下。
2、使用xhr載入js，和后臺沒什么關(guān)系，就是為了實現(xiàn)根據(jù)需要載入js。 對，json就是調(diào)用后臺注冊給spring的bean的方法，不過json-rpc-java本身沒有直接的實現(xiàn)方法。所以對于rpc，我建議你了解dwr。
3、json-rpc是基于xhr實現(xiàn)的，是為了模擬rpc的功能。我現(xiàn)在這個項目多數(shù)的操作界面，使用了qx的界面，都是使用json-rpc來與后臺進(jìn)行數(shù)據(jù)交換。但有些功能是直接使用的常用的struts的方法。
4、這個也沒什么特別的地方。還和以前類似。因為還是請求響應(yīng)。還是上面說的，因為我用的json-rpc-java已經(jīng)不是原來的json-rpc-java了。你說提出的json-rpc的問題，我的回答估計對你也沒多少用處。還是看dwr就可以了 :-)
5、對我現(xiàn)在做的系統(tǒng)里并沒有考慮國際化的問題。如果我要做這個工作的話，我還真沒想好方法呢。如果使用struts+jsp的方式來實現(xiàn)現(xiàn)在的系統(tǒng)，有些標(biāo)準(zhǔn)的方法，但我總覺著不方便開發(fā)。現(xiàn)在拍腦袋想一下，如果是js文件里需要國際化的話，我會將需要國際化的文字加上一些特殊的標(biāo)志，然后傳遞到前臺時，像jsp一樣進(jìn)行過濾。  回復(fù)  更多評論   

# re: qooxdoo 0.6rc1 發(fā)布了 2006-10-16 23:13 weide

這個東西Dotnet下能夠使用碼？  回復(fù)  更多評論   

# re: qooxdoo 0.6rc1 發(fā)布了 2006-10-16 23:25 一農(nóng)

這個只是js庫，可以在.net下使用。
只是其中的rpc現(xiàn)在他只提供了java和php的，不過當(dāng)然你可以使用.net下的rpc。  回復(fù)  更多評論