摘要: 上一篇討論了關(guān)于客戶端數(shù)據(jù)處理的一些問題，以簡單的用例場景的方式描述了出來。很明顯，要想實現(xiàn)一個功能完整的Rich客戶端的話，必須能夠滿足上述用例場景的需求。能否根據(jù)這些需求做出合理的設(shè)計，是一個挑戰(zhàn)。尤其對于設(shè)計而言，不同的人有著不同的風格，而且由于背景不同，也會有不同的見解。本文中，我只是陳述出自己的一些想法和設(shè)想，更多的是希望能夠拋磚引玉，通過在這個方面的討論也能增進我的理解。呵呵。
很顯然，blog的形式更適合作為思路的介紹以及探討的平臺，而不是詳細設(shè)計的文檔。而且很明顯這一篇文章是承載不了所有的詳細設(shè)計的。我爭取把我在各個細化的方面的想法在后續(xù)的文章里面發(fā)出來。如果時間允許的話，整理出初始的文檔和代碼，建立一個小的開源項目未嘗不可（因為如此，所有的JS都是采用英文來注釋──其實還有一個原因是練習英文 :)）。這都是后話了。
閱讀全文
摘要: 關(guān)于RIA尤其是基于Ajax的RIA怕是屢見不鮮了吧？尤其是在Google推手之后，文字處理、表格處理、幻燈片放映這種看起來非常客戶端的應(yīng)用，都可以采用Ajax的技術(shù)來實現(xiàn)了。作為一個關(guān)注企業(yè)級應(yīng)用開發(fā)的技術(shù)人員，一個很自然的想法就會產(chǎn)生，是否可以采用這種技術(shù)來改進我們基于Java EE技術(shù)開發(fā)的B/S結(jié)構(gòu)的企業(yè)應(yīng)用呢？
先說有沒有必要，答案是肯定的。B/S被廣為詬病的一個問題就是降低了最終用戶的操作效率，以我的經(jīng)驗來說，用戶雖然普遍的感到基于瀏覽器的界面要漂亮得多，用鼠標操作也很直觀，但是卻實在比以前的界面復雜而且操作困難。而且每次頁面提交后的等待也實在是對工作效率的一個降低。當然，我這里也沒有必要意義列舉B/S在客戶端的缺點，實際上這個問題是被廣泛認同的。
再說可行性，可行性分為兩種：技術(shù)上的可行性以及工程開發(fā)上的可行性。
技術(shù)上的可行性就無須驗證了，Google Reader、Gmail、Google Docs的穩(wěn)定運行都是非常好的證明。
但是它是否一定適合時間要求相對比較嚴格的工程開發(fā)呢？
閱讀全文