隨筆分類(103)

     摘要: JSF中默認并沒有提供客戶端驗證機制，這就需要使用其他的方法來驗證，Shale已經為我們做好了，通過封裝commonsValidator，實現了非常方便易用的客戶端驗證。  閱讀全文      摘要: 前面一篇直接使用了Myfaces中的兩個Component完成了一個簡單的分頁，這里將會介紹一種On-demand loading的方法來進行分頁，僅僅在需要數據的時候加載。  閱讀全文      摘要: 對于大多數Web應用，分頁都是必不可少的功能，當然在JSF中也一樣，我在這里用兩篇文章介紹兩種方法來展示一下，如何在JSF中實現分頁。  閱讀全文      摘要: 最近一直在用JSF，遇到了一些很奇怪的事情，昨天花了點時間仔細分析了一下，找到了一個主要問題，就是JSF和JSTL之間的互操作存在著兼容性問題。  閱讀全文

       有一個多月都沒有找到太多寫程序的感覺了，雖然對Java的熱情依舊，卻總是找不到什么特別令人興奮的東西，也許是因為最近涉及的新技術太廣了吧，同時在做JSF、Spring、Hibernate三項技術，這都是過去不曾接觸過的，雖然進展還算不錯，但不時的會在不同的問題上卡殼，然后會花很多時間去找解決方法，如此反復，再好的感覺都被消磨殆盡了，或許這正是造成效率差的原因吧，查了一下最近的Log，效率很少能達到80%，再高就更沒有了，完全沒有兩個月前但哪種感覺了。當時會有比較高的效率是因為流暢的思路，加上對問題的領域比較熟悉，所以會很少碰到大的卡殼的問題，這樣心情也會好很多，能夠一蹴而就的去把問題解決。

同時想想看公司里做軟件的經驗也是，幾乎不會在一個新項目里全面的去使用一系列的新技術，因為對這些技術的不確定因素，會讓項目整體的不確定因素變的比較大，如果協調不好的話可能會導致整體的崩盤，所以在新的項目中通常是每次使用一種新技術替換原有的，其它繼續使用原有的技術，并且在項目中積累使用這種技術的經驗，通過這樣的不斷累積，變的對這種技術比較熟悉，這些積累再應用到新到項目中，會讓不確定因素會變的比較小一點，也比較容易保證軟件開發的成功。試想如果全面使用新技術的話，如果在幾個問題上卡殼了，或者有這種技術無法滿足到需求，可能會有比較嚴重的后果。

技術是需要經過一段時間的沉淀才會被廣泛使用的，無數的開源框架應證這這點，像spring，hibernate被廣泛的使用并不是在它們剛推出的時候，而是在不斷的應用中改進，并且逐步成熟的時候。現在炒的正火的Ajax，Ruby on Rails等技術并沒有大范圍的使用，也是這種原因了，雖然它們都很吸引人，但是并沒有多少經驗表明這些技術會引發多少的不確定因素，大家都在等啊，等啊，等到有人用實踐告訴我們準確答案的時候，才會是它們真正被大家接受的時候。

   昨天去逛了一下書市，當然也淘了幾本書回來，包括了一本《J2EE核心模式 2nd》，它的原版是一流棒的好書，有著Martin Fowler, Grady Booch為之寫的序，有著無數的贊譽。且不從書的翻譯質量上來說（當然對熊節這樣優秀的譯者我還是很有信心的），它的紙張就已經讓我覺得很不爽了，摸起來手感和草紙沒有兩樣，雖然為了學習，不得不買下它，但是還是感覺窩了一肚子火。

         隨便翻了幾本我桌上擺著的機械工業出版社的書，除了《Effective Java》還算湊合著，其它書的紙張都是很垃圾很垃圾的，紙張很垃圾，但是價格卻不垃圾，完全不比任何同級別的書要便宜，完全出于一種唯利是圖，一種對讀者不負責任的態度，對于這樣的出版社我們需要再用什么語言再去說它呢？

同樣看看一些其它出版社的書，至少我手頭上目前還沒有看到紙張有這么差的，我最近買了不少電子工業出版社的書，主要都是博文視點的，不光出于學習技術的需要，更是喜歡紙張光滑的手感，筆寫在上面會感覺很爽。我手頭上也有幾本國外原版的書籍，紙張質量是國內出版社遠不能及的，一本《Java2 The Complete Reference》，和《Java與模式》頁數相當，卻要厚了三分之一。聽說最近東南大學出版社引進了一批O'Reilly的影印版書籍，雖然我沒有看過，卻在書評中聽到了一些贊譽之詞，雖然價格比較高，但是紙張卻很好，給人一種舒服的感覺。去年的時候，看到有人買了本清華版的影印書，紙張也是差的沒話說，雖然清華的影印版書籍的紙張并不一貫如此，但這本書卻足以讓我的印象分大打折扣。

網上書店能經常看到對書籍翻譯質量的評價，有的會把翻譯版的書罵的一文不值，如果這本書真的是找了個外行來翻譯的話，倒也罵的應當，罵的正確。如果是外行，本來就不應該來翻譯專業的計算機書籍，可以想像把很多專業術語當成通用語來翻會是如何的搞笑。當然我也會罵那些不負責任的譯者，這種人當罵，該罵。但是有些發表評論的人就像瘋狗一樣，見人就罵，見書就罵，只要是中文的書，如果是國人編寫的，就罵編的爛，如果是翻譯的，就罵譯的爛，一律說國外的某某某書好，這樣的人，這樣的罵法，是有大腦，有邏輯判斷力的人說出來的嗎？首先，翻譯書籍就是為了解決國內大部分英文不好人的需求的，這些譯者是把國外的先進技術傳播到國內的先驅者，他們的精神是值得我們贊美的，雖然翻譯的時候不免會有一些理解和原著產生了偏差，這也是可以理解的，就像國外出的書，有的時候也會有很多的勘誤，錯誤是不可避免的，如果有錯誤就罵人家翻譯的不好，可以說罵的人本身就是有問題的。讓大家都去看原版的，這本來也不現實的，不是每一個人都能夠看的很明白，理解的很清楚，能完全看懂英文書的人畢竟是少數，就是那些建議大家去看英文書的人自己也未必能夠“看懂”吧。

     摘要: 通過一次小小的實踐，終于了解如何使用tomahawk中的tree2這個組件了，并且寫了小段程序，從xml中讀取樹的結構，生成一個tree，不過tree2不能直接和xml綁定是一個遺憾，那樣就會省不少事情了。記下一點心得，以供后來參考了。  閱讀全文

今天一天幾乎都是在與數據庫打交道，碰到過去從未想過也不曾碰到過的問題，也讓我對數據庫有了一些新的認識，新的感受，主要是兩個方面，一個是ORDER BY，一個是Batch。

情景一：有兩張表，一張有100萬條記錄，另一張有300萬條記錄。

最初的SQL是連接兩張表，并對其中一個表的非索引字段排序，并取出幾千條的數據，花費了很長的時間，最終分析得出，大部分時間花在排序上。后來去掉了ORDER BY并使用客戶端的Utils方法對已經取出的數據進行排序，查詢速度大大優化。

情景二：對取出的結果進行一定的處理，并更新其中一張表。

最初的辦法是處理一個更新一個，效率很低，最后和老員工交流經驗得到真傳，于是決定使用Batch來批量更新數據庫，效率極大的提高，有一個數量級，但是因為我本地客戶端沒有裝DB2的升級補丁，無法在客戶端更新，在服務器上更新成功。

總結，數據庫的訪問效率應該是這類系統最主要的瓶頸，多花點時間放在查詢語句和查詢策略上，有時候效率提高會很大。

         花了一個多禮拜的時間狂啃了一下JSF，完成了一個不大不小的training，其實只算是一個share了，把我學到的JSF基礎知識和這段時間的一些心得拿出來和大家分享。之前的晚上倒是緊張了一晚上沒有休息好，準備了一堆可以用的臺詞，準備了一堆可以擴展的內容，不過好多都沒有真正的用到，進度比我想像的要慢一些，只是花時間講了一下最基礎的概念：managed-bean, navigation, event, converter, validator等等了，然后做了一個事先準備好的例子，不過大家基本上都建立出了第一個JSF的應用程序，算是順利但不很圓滿的完成了任務，本來準備進一步說明的自定義JSF組件之類的就沒有時間了，算是小小的遺憾吧。

         昨天一天的時間把我上周的任務收尾，修正了一些 bug，加上了一些log信息，完成了文檔，于是便可以進行我新的學習了，主要還是Rod Johnson那本without EJB，其實大師的書已經仰慕很久了，應該說是從實際解決項目問題的角度來看J2EE，畢竟Java語言，J2EE這樣的東西都太多的一些學院派的味道，經常把一些本來可以簡單的問題弄的很復雜，用公司早期用的框架，有太多的重復代碼，很多煩瑣的配置，和一些莫名其妙的奇怪問題，但是用spring，hibernate這些從實踐中得來的東西，確實會感覺到爽，因為它們真的很好用。

         一周多一點的時間，把Mastering JSF啃下來了，雖說很多細節沒有照顧到，但是還是有了一個整體的感覺，這是我學的第二個MVC框架，終于可以把過去學struts的東西拿來比較了，看了jdon網站上那篇流傳甚廣的那篇比較兩者的文章，似乎一下明白了很多，也似乎并沒有明白，因為它們很多地方真的太像了，像的看很多東西都有種似曾相識的感覺，這樣在一定程度上減小了從struts到JSF的難度。很ASP.NET不同的是，JSF的Component是直接和JavaBean綁定的，最終直接是從JavaBean中取數據，而ASP.NET卻是直接用Component的屬性取數據，設計上來說，JSF這樣做更優雅一些，但ASP.NET這樣做似乎減小了一些入門者的進入難度，各自的設計哲學并不相同，并沒有明顯的好壞之分。只是JSF的發展時間太短，它還不成熟。

         JSF的驗證方式我也很喜歡，一個Component掛一個Validator。相比較過去在struts下使用Validator框架配置驗證來說，結構要清楚的多。

     摘要: 這幾天一直在用myfaces，遇到一個問題，使用inputDate 和 tree2 這樣的組件的時候，當開啟了一些和JavaScript相關的選項時，總是會提示JavaScript錯誤，但是卻總是找不到這些JavaScript在哪里，很納悶，昨天為了查找 tree2 的用法在網上尋覓，在 JBoss 的論壇看到了相關的問題，其實這個問題在 myfaces 的官方網站上已經有明確的說明了  閱讀全文

         看到最近Borland連續虧損兩季度的消息，突然變得有些懷念起這個曾經幾度大起大落的Borland。

         有人把Borland虧損的原因歸咎為eclipse基金會的興起，幾年前作為eclipse前身的IBM Visual Age for Java在Java IDE市場被Borland打的大敗，而Borland也自然的成為了Java IDE市場的霸主，其JBuilder產品一直是國內Java IDE市場的主流，但這兩年，Borland的表現卻變的出人意料的差，Borland再次的醞釀變革？記得上次大的變動是JBuilder2.5-3的時代，Borland將其JBuilder完全Java化，創造了Java IDE的新時代，同時也在其半年一套新產品的速度的打壓下，IBM被拖垮了，其它的一些廠商也被拖垮了，但這卻并沒有表示Borland能夠在這個霸主的位置上一直做下去，IBM又組成了Eclipse軍團，帶了大隊的人馬再度殺來，推廣的是一個完全不同意義的新的IDE，甚至可以說，這不僅僅是一個IDE了，這是一個平臺，一個新時代。同時IDE市場又闖入了許多不速之客， 2005年的Jolt中，IntelliJ IDEA拿到了最佳生產力獎，Eclipse也獲得了Languages and Development Environments大獎，Borland卻榜上無名，似乎Borland在IDE市場再也不是從前的Borland了，似乎已經平息的IDE大戰再度爆發，領軍的是Eclipse，同時也出來了無數不同的Java IDE，BEA Weblogic Workshop, Sun Netbeans, Oracle JDeveloper, IntelliJ IDEA后面還有很多很多。BEA宣布了其新版Workshop將基于Eclipse，Borland的新產品也會是基于Eclipse的，將會在明年推出，IDE市場似乎再次被統一，沒有統一的只是各個公司獨有的領域，開發過程，生命周期管理，數據庫系統結合，等等。

不希望Borland倒下去，經歷幾度波折的Borland會再度站起來，站在新的起跑線，給大家一份新的驚喜，讓我們拭目以待吧。

     正式開始做JSF了，這下算是把Web Tier以下的框架搭起來了，用的是JSF + spring + hibernate的三層架構，雖然中間碰到一堆很奇怪的問題，大部分集中在配置文件上，第一個錯誤在hibernate中發生，把主鍵類型配置成“uuid.string”，怎么都跑不過去，最后改成“uuid”解決問題。第二個錯誤發生在spring的配置中，三個bean，第二個引用了第一個，第三個引用了前兩個，結果第三個出錯，最后發現，第三個只要引用第二個就可以了，第二個也會自動的去引用第一個。

JSF提交表單已經完成，這方面比較容易，也是被幾乎所有例程第一個拿出來說的，不過在處理列表的時候出現了點問題，過去struts中是先從一個.do進入讀取數據后轉向頁面，這時候列表就拿到了數據，但JSF中不太清楚，最后有些奇怪的想法算是把解決了，DataTable對應了一個property，有get方法，我在get方法中調用中間層的service去取數據，拿到一個List，由DataTable將其展開。

在新的組里做了半個多月，一直風平浪靜，沒有什么事情，昨天開會時接到新的任務是要開始研究JSF了，公司最新一個巨型項目采用了JSF作為Web Tier，我以后的任務會是輔助開發基于JSF的Framework，以滿足未來的項目開發的需要。現在所在的項目做了快三年了，當時采用的Web Tier是struts，在當時也算是很新的了，三年后，當國內還很難找到有多少JSF成功案例的情況下，我們開始進入JSF時代，雖然說現在的JSF還并不是很成熟，而且可用的資料也比較的少，這時候技術轉型有一定的風險和難度，但畢竟JSF已經成為Java EE 5的標準，作為可以對抗ASP.NET的組件級Web Framework，JSF未來會有很大的發展的，也期待著有更多的JSF Implement能夠出現，畢竟Java本身就是面向開源的。