2006年8月17日
#
摘要: 這些天一直在為Flex程序中的各個組件之間有效的傳遞參數(shù)，協(xié)調組件間的行為等問題感到困惑。由于Flex程序實際上是一個運行在客戶機上的的客戶端程序，因此在Flex內(nèi)部組件之間無法像B/S程序基于HTTP協(xié)議那樣發(fā)一個請求，由服務器端通過一個標準接口讀出參數(shù)，處理并做出響應。也就是說用表單、URL的方式傳遞參數(shù)和控制流程肯定是行不通的。前一段時間一直嘗試像Javascript中那樣用函數(shù)調用，甚至是全局變量來做，感覺越做越復雜，程序的OO結構也受到很大的破壞，十分的煩惱。
閱讀全文
摘要: 要沒用過E4X，就不知道用這東西處理XML是多簡單好用！過去在Java中一直是用一些用熟了的組件操作XML，這幾天用Actionscript才發(fā)現(xiàn)了這個好東西，真是相見恨晚啊，一定要和大家分享一下。
閱讀全文
摘要: RIA會有將來會成為互聯(lián)網(wǎng)的主流么？這是一個只有一個答案的問題，那就是“會”。不需要去糾纏那些技術細節(jié)，你至少可以相信HTML及其派生出來那些技術不能讓對體驗效果的追求永無止境、又十分挑剔的我們滿意，那么能帶給我們耳目一新的感覺的RIA有什么理由不成為主流？ Microsoft和Adobe已經(jīng)磨刀霍霍，準備在RIA的時代里挑大梁了，我們可別光坐著看熱鬧。
閱讀全文
摘要: 還在遠古刀耕火種的年代，當人類意識到鳥能在天空中飛翔是因為有雙翼，我們的先祖便在石頭上為自己刻上了翅膀；從莊子的《逍遙游》到今天的《黑客帝國》、《哈里波特》，我們?nèi)祟惗蓟孟胫馨熏F(xiàn)實生活放入另一個空間，在那個空間里我們能“水擊三千里，摶扶搖而上者九萬里”。而計算機和互聯(lián)網(wǎng)的出現(xiàn)，給了我們發(fā)揮的想象力的一個理想的平臺，
閱讀全文
Flex 2.0 安裝應要注意的幾個小問題
1. 弄清概念
?? Flex 2.0 實際上是一個產(chǎn)品系列，初學者安裝之前應當弄清楚中各個產(chǎn)品的功能和相互之間的聯(lián)系。 參考Flex官方介紹：http://ww.adobe.com/go/flex，了解Flex 2.0 系列的各個產(chǎn)品特性。
?
2. 記得要Tomcat加入加入JTA支持
?? JTA的包一般都是被應用服務器自帶，可Tomcat默認卻不支持JTA，所以用Flex Enterprise Services 2.0時必須自己手動在Tomcat中安裝JTA以獲得支持。否則的話運行samples.war肯定會在控制臺看到類似下面的錯誤：
?? java.lang.NoClassDefFoundError: javax/transaction/SystemException。 ?
? 如果真是需要使用事務功能，推薦用Java Open Transaction Manager(JOTM) 來提供 UserTransaction。嫌配JOTM麻煩的話可以自己直接拷貝jta**.jar,jdom.jar放到samples/lib下湊合一下，例子的各個功能基本都可以正常運行。
? JOTM的安裝可以參考網(wǎng)上的一些教程，比如
http://jotm.objectweb.org/current/jotm/doc/howto-tomcat-jotm.html。基本就是下載最新的二進制發(fā)行版（http://forge.objectweb.org/projects/jotm/）,解壓縮，從lib目錄拷貝*.jar文件（除了log4j.jar、common-cli.jar和jotm_iiop_stubs.jar之外）到$TOMCAT_HOME/shared/lib目錄下，然后再配置一下server.xml、web.xml即可。
3. 瀏覽器需要安裝支持調試功能的Flash Player插件，否則無法使用 Flex IDE 的調試功能。
? 支持調試功能的Flash Player可以去官方下載：
? ? http://www.adobe.com/support/flashplayer/downloads.html
?? 在那些名字有debugger字樣的里面找需要的吧。
//作者：王瑋琳? 時間：2007-12-30
//聲明：本博客中所有文章均為版主原創(chuàng)，轉載請保留作者信息，并請注明出處。
摘要: 我們都知道對于一個有一定規(guī)模的項目或者有長遠算的產(chǎn)品,僅憑一個和數(shù)個能力突出的人的努力付出很難真正做好的。軟件開發(fā)過程的個人英雄主義往往到最后是限制或者是毀了這個或許本來很有前途的軟件，所有人都知道團隊的整體能力是多么的重要！然而從現(xiàn)實來看，縱然有無數(shù)的管理學和軟件開發(fā)方法的理論，在現(xiàn)實中打造一個有很強執(zhí)行力的團隊卻是那么的困難重重。
閱讀全文
//作者:王瑋琳? 時間：2006-12-12????
???? 不知道是不是巧合，今天一早便看到Blogjava有兩篇關于AJAX感受的文章。而CSDN上這兩天頭版最顯著的位置也發(fā)了一組為MS Expression造勢的文章，口風一致又滿懷激情的預言AJAX將迅速退場，RIA會迅速成為主流。這些個平日專業(yè)寫IT文章的技術專家，也是有備而來，打出"Expression 2006最后的論戰(zhàn)"的口號，一心在CSDN推起再一個AJAX vs RIA論戰(zhàn)的高潮。對這個話題其實我早就憋了一肚子想說的，俺也不喜歡CSDN里那種過于關注趨勢的討論，咱們這主要是能參與一線開發(fā)的技術人員，我想在這里一定能更和各位XDJM進行更實際的討論。小弟先在這淺談幾點陋識，不妥的地方還希望大家指正。
????? 首先是AJAX vs RIA。表面上這是矛盾的焦點，而在我看來是不然。AJAX 技術的核心是XHTML和JavaScript，再加上CSS來做展現(xiàn)，其實是傳統(tǒng)開發(fā)方式的一個發(fā)展，這也是為什么AJAX能這么快的被大家接收和喜歡的原因。從某種意義上來說，AJAX的目的正是要用傳統(tǒng)的Web技術來實現(xiàn)RIA！CSDN的專家們把RIA和AJAX對立起來，是一個概念性的失誤，只有用基于AXML和MXML這種XML布局的思想來實現(xiàn)的富客戶端才是RIA么？ 退一步說，難道基于XHTML布局不是基于XML布局的一種，為什么它不能在RIA中占有一席之地？
????? 回頭看看，從XML開始普及的年代開始，就不斷有人跳出來宣判HTML的死刑，而事實是直到今天HTML依然是互聯(lián)網(wǎng)的主流。看看PHP，也有類似的經(jīng)歷。為什么是這樣？ 我個人執(zhí)著的認為這是因為創(chuàng)造Internet內(nèi)容的不是這些鼓吹新技術的專家，而是廣大的網(wǎng)民，是數(shù)以千萬記的全世界普通的、甚至很多是不入流的半職業(yè)的程序員和普通的網(wǎng)民。一方面對于其中的很多人用最小的代價把內(nèi)容放到網(wǎng)站上，能從網(wǎng)站上得到他們需要的反饋，他們需要傳統(tǒng)而基礎的HTML（或許將來小學生課堂里就會學HTML網(wǎng)頁制作）；另一方面大量的只局限在PHP之類傳統(tǒng)開發(fā)技術的程序員依然大量活躍在互聯(lián)網(wǎng)上，這些人還在，互聯(lián)網(wǎng)的大格局就不會變。只要HTML不會死，AJAX就不會死，至少XHMTL+CSS+JavaScript不會死，不但數(shù)年內(nèi)不會，在很長的時間內(nèi)都不會。
????? 現(xiàn)在我想亮明一下我的態(tài)度：我喜歡AJAX的效果，但不喜歡AJAX的實現(xiàn)方式，我非常贊同CSDN那些人的看法，基于XML布局的RIA將異軍突起，“在WPF、Flash（Apollo）等RIA技術的夾攻之下，越來越多的Web應用將同時部署傳統(tǒng)Web頁面和新的RIA UI。之后此消彼長，幾年之內(nèi)RIA將成為主流。”(摘自孟巖的blog)。
????? 當然，這些用來為MS造勢的文章并沒有真正客觀來介紹RIA技術的現(xiàn)狀，一方面我在前面說的AJAX技術并不是站在RIA的對立面，而是恰恰是達到RIA的一種方式；另一方面RIA的持續(xù)發(fā)展、或是取得突破絕不會是因為Expression的橫空出世。這次WPF出來，CSDN的幾篇文章都不同程度的認為這是跨時代的大事，或許對.net開發(fā)人員是這樣，但對于我們Java開發(fā)者，很幸運，我們早就可以感受到了他們遲到的震撼和快樂了！
????? 了解事情前因后果的人都知道，RIA發(fā)展已久，Expression不過是微軟運用一貫的跟風模仿的手段的另一個成果，基本就是把MM的那一套弄到他的平臺里去，并不是什么有創(chuàng)造性的發(fā)明。在Java領域，我們一直有都是生成SWF的 開源的Laszlo + Javascript 和Adobe的MXML + Actionscript (Flex) 兩套基于XML布局的優(yōu)秀RIA體系，此外還有Sun的基于java的JDNC，加上AJAX來實現(xiàn)RIA，我們有非常豐富的選擇。這幾種技術都經(jīng)過了多年的發(fā)展日趨完善。尤其是Flex，事實上，半年甚至一年前它推出2.0 beta的時候，CSDN這些專家就有足夠的理由像現(xiàn)在這樣歡呼雀躍了。而微軟，好像在明年二季度才會出Expression的正式的第一版，不折不扣的后來者。
????? 微軟來了，作為后來者他毫無疑問會繼續(xù)用一貫的打壓的手段去對付競爭產(chǎn)品，市場洗牌是不可避免的。今年在Laszlo的壓力下，Adobe已經(jīng)在Flex2.0中將原來收費的Flex Data Services改成了有條件的免費使用，現(xiàn)在狼來了，Adobe將來肯定還要有新的拉攏開發(fā)人員動作,對我們來說形勢大好。RIA的趨勢無需辯論，現(xiàn)在的問題是作為一個Java程序員，對于面對眾多可選的實現(xiàn)RIA的路，我們該走那一條？
????? 我對Flex進行過一定的學習，和Java良好的集成以及大量的現(xiàn)有的Flash制作人員，我還是比較看好它的。希望深入用過Flex或是其他RIA技術的朋友能出來交流指點啊！
聲明：本博客中所有文章均為版主原創(chuàng)，轉載請保留作者信息，并注明出處。
??? //作者: 王瑋琳? 2006-12-07 ?? ?
? 近期在一個小項目開發(fā)組里進行推行XP，嘗試了一段時間。結合過去帶項目開發(fā)組的經(jīng)驗，說說我對在實際項目開發(fā)里應用極限編程方法一些體會，和大家交流。完全是個人理解，也不太成熟，不對的大家來拍。
?? 一 如何看待開發(fā)方法
??? 首先說點開發(fā)方法本身的理解。我一向認為沒有哪個開發(fā)方法可以徹底的解決項目開發(fā)的各個環(huán)節(jié)的問題，任何一個開發(fā)方法，其中有些理論的東西放到自己的實踐中可能就是事倍功半，在實際開發(fā)中還是要靈活，要掌握一個應用的度。過去我一直是用RUP的那一套東西，不能說它差，更不能說它好。我覺得RUP也就是給我們組織項目提供了一個參考，我們并沒有嚴格按它的來，比如文檔，我就是按國標的要求來寫，而不是RUP的；甚至文檔的數(shù)量、質量方面，對每個項目我們也是靈活處理，比如這個項目組的人擅長文檔編寫，就要求他們寫的詳細點，要是項目組整體文檔編寫能力都不行，就要求寫的簡略一點，能突出重點就可以了。總之，我覺得實際項目開發(fā)的模式應該是慢慢摸索出來的適合自己的方法和模式，不需要嚴格遵守什么東西，另外就是要根據(jù)各方面的發(fā)展進行不斷的調整。
? 二 推廣XP價值觀???? 極限編程中用來指導開發(fā)的五個主要的價值觀是：
溝通、簡單、反饋、勇氣、尊重。我覺得對PM而言需要重點對Team成員強化的價值觀是：
溝通、簡單和反饋。這三個是實際影響所有工作方式的價值觀，應當在任何時間、任何條件下要求大家來理解、實踐。
?? 溝 通：在實際開發(fā)過程中，通過平時及時的口頭溝通來促進團隊的了解及合作，開發(fā)過程中相關人員盡可能的及時主動報告開發(fā)進度、問題，一方面自己要將所做的工作及時的告訴他人，另一方面不要等著在他人進行階段性的匯報時才了解項目開發(fā)情況，要隨時詢問、關注他人的工作進度，只有大家都了解了項目的真正的進展，才能消除對開發(fā)進度的懷疑、憂慮。
應該強調溝通的作用是多方面的，絕不能把溝通理解成去了解他人的工作進度，而是通過溝通來實現(xiàn)工作的簡單化，實現(xiàn)較小的反饋周期。至于進度問題，從領導角度來說，應當本著尊重、信任的價值觀進行合理的關注。
??
簡 單：開發(fā)過程中各項事務性工作應當化繁為簡，溝通方式、決策盡可能的簡單化；系統(tǒng)實現(xiàn)方案也應當考慮選用簡單的實現(xiàn)方式，盡早盡快的達到效果。
?? 反 饋：反饋是溝通的核心部分，應當成為所有開發(fā)人員的核心價值觀之一。大部分情況下，我們都不可能在開始的時候知道我們最終的系統(tǒng)是什么樣的，需要群策群力參與進來，一方面對系統(tǒng)的功能進行改進、提高，一方面對項目開發(fā)的溝通組織方面進行改進，提高整體的開發(fā)效率。推行反饋的價值觀是非常需要技巧的，因為我感覺大部分開發(fā)人員并不是不想反饋，而是不知道如何反饋、反饋什么，對此我提出的一個說法就是：一切都可反饋，一起都要反饋！
?? 至于
勇氣、尊重則是我認為這兩點和人的天生個性有關，要因人而異，有針對性的對Team的部分成員做出具體要求。我個人認為一些XP的書籍強調這兩個價值觀的前提是不太嚴謹?shù)模e個小例子，要組里一個弟兄本來就是個勇氣過剩，喜歡在項目用高風險的代碼的激進分子，我再老和他強調勇氣，豈不是要搬起石頭砸自己的腳？
? 三 掌握XP原則??? 極限編程方法提供了一整套的開發(fā)原則，在實際開發(fā)過程中，我覺得實踐中需要重點遵循的開發(fā)原則有：
- 人性化
- 質量第一
- 互相受益
- 從經(jīng)濟角度出發(fā)
- 不斷提高 ?
- 慢慢走 (Baby steps，很多書翻成嬰兒步)???????????? ?
??? 挑兩個說說，其中最有感受的是第一條人性化。
??? 人性化是什么？看看國內(nèi)眾多的軟件公司，老板大凡都是覺得自己還算對得起員工；PM總覺得自己比手下人更難更辛苦；干活的人就算受了委屈了，想想哪都差不多，只要薪水還可以能過的去就忍了，等差不多到了時候跳個槽就是了。在這種氛圍下，人性化具體下來是什么東西呢，給點加班費還是多去加幾頓餐？
??? 老外談人性化，說要把工作和生活分開，要讓員工有安全感、成就感、歸屬感，未來能發(fā)展，還能對其他同事感到很親切。對咱們中國的大部分工程師來說，除了遇到個好領導能感到親切一些，安全感、歸屬感、成就感，甚至長遠的發(fā)展就只是少數(shù)幸運的人才能擁有的了。這個問題我也沒有很明確的理解，就我自己的看法，我覺得作為領導能做到公平、寬容、鼓勵優(yōu)先，能盡可能的讓弟兄們少加幾個班，就算是有點人性化原則了。
??? 算了，撇開讓人郁悶的人性化，來說說質量第一和不斷提高。其實在俺們的項目中，尤其對PM而言，質量第一有時候會成了一個自欺欺人的口號。質量和進度有沖突，怎么辦？我的經(jīng)驗是質量第一不等于質量最先，產(chǎn)品有Bug不會扣錢，按期交不出活不但要扣錢，還要損失信譽；那怎么辦，要降低產(chǎn)品質量用不好的解決方案或者弄虛作假么？也不可！現(xiàn)在的程序都是B/S的，方便升級，先交互，再抓緊時間出補丁在客戶反饋之前去升級就是了，你去升級，客戶還高興覺得維護費用沒白交呢。
??? 這里就引出另一個原則了，慢慢走。這個我體會也很深，做項目真的就是應該一步一步做，不能好高騖遠，一下把功能設計的過復雜，把攤子鋪的太大。開發(fā)中把功能一個一個實現(xiàn)了，然后一個一個做穩(wěn)定；交互給用戶后，不斷的能做一些功能的改善、提高；這個慢慢走不僅是一個什么成本、風險的問題，更是一種感覺，一種讓項目開發(fā)人員覺得不斷前進，讓用戶覺得你的產(chǎn)品在不斷的改善提高的Feeling！
? ?
?????? ?
? 四 XP實踐
?? XP編程理論里列舉了大量的實踐方法，我挑感觸比較深的和大家來交流一下：
??? 這一條簡直是中小軟件開發(fā)設計的至理名言！項目做的少的人可能很難理解這句話的重要性，極端的說，那些想一開始就把各個東西都設計好的項目,基本和沒有做設計差不多。過去我們提"原型開發(fā)法",在RUP里我們講短周期迭代，在XP中我們說要周循環(huán)，季循環(huán)，要增量設計，這都是為什么呢？就是因為我們老是發(fā)現(xiàn)設計和后來的變化差別太大，要回去改設計又總存在各方面的問題（懶惰嫌麻煩、怕出問題有顧慮、有風險不愿擔責任，太忙了沒時間等等）。最早原型開發(fā)法就是不要設計了，根據(jù)實際做出的東西來調整，RUP是有致命傷的，不敢面對這個問題，不痛不癢的說把開發(fā)過程多弄幾設幾個里程碑，及時調整好了。而XP提出的一點一點設計，似乎是最靠譜的，把設計過程一點一點分解到開發(fā)的過程中，或許一直一來很多的優(yōu)秀的團隊也正是這樣做的。
??? 這一條對PM來說也是非常有實用價值。從負責人的角度，要盡可能寬松的制定計劃，避免“高承諾、低交付”對團隊帶來的信心、熱情、積極性的負面影響。一個弟兄，活干的快了受了表揚，下次干的可能就更好了；要是活沒干好交不出來，他的信心受了打擊，就不是簡單談談話能調動的起來了。
??? 這個從實際操作來說，XP講究實事求是，成員間信息透明，讓大家了解真實情況，不允許少干不報，也不允許多干少報。但我理解這是局限在團隊內(nèi)部的，屬于人民內(nèi)部矛盾，對于自己人，我們當然不能欺上瞞下，干活時，等或者是拖，都是不對的。但是對外面對那些只要結果的客戶，有時也是需要應用一些必要的策略，盡可能爭取到合理的時間，盡量把客戶的預期引導到正確的范圍內(nèi)。
??? 可能你覺得很多少時候這種事情超出了PM的能力范圍，工作量、交互時間在你接到活時就已經(jīng)定下來了，只能硬著頭皮上。光是咬牙做當然是愚蠢的，這種情況我過去的做法往往是在過的過程中要想辦法逐步降低用戶的預期，即要設法降低承諾，強調強調困難，方法得當大部分情況下客戶還是可以做出一定的讓步的。當然同時一定要提高交付的產(chǎn)品質量，保證客戶的滿意度。
?? 對這個我可能有些保守，我相信結對編程其實是大家一種在用的一種編程方式，并沒有什么特別神奇的。除了XP理論書籍里的提到的那些弊端，我認為結對編程的負面作用其實還有很多。比如對新人，養(yǎng)成編寫程序的獨立思考能力很要緊，不能上來就老結對，靠別人的啟發(fā)來慢慢搞。因此我認為讓大家知道結對編程這種方式是可取的，有必要的時候(比如有些問題自己想不太清楚)找個合適的人結個對，討論討論就可以了。
聲明：本博客中所有文章均為版主原創(chuàng)，轉載請保留作者信息，并請注明出處。
??? 帶著眾多誘人的新特性，Dojo 0.4 發(fā)布了。抽出時間下載了一個體驗了一把，結果用一句話來概況： 驚喜多多！
??? 首先是這一版加入的幾個新的 Widget: Clock, FilteringTable,ProgressBar。這些widget中比較重要的是 FilteringTable， FilteringTable的加入是用來替換以前的SortableTable，相比SortableTable, 它的新的特性包括：
Multiple Column Sorting (number of columns settable, default is 1)
Sorting in place (non-destructive)
Per-column programmatic filtering
Add and remove rows on the fly
Update field values (with typing) on the fly
No restrictions on sorting on markup
??? 從這個地址去體驗一下： http://archive.dojotoolkit.org/nightly/tests/widget/test_FilteringTable.html，功能非常強大，可以直接從傳過來的JSON對象中構造出列表，動態(tài)的過濾數(shù)據(jù)，改變各個字段的值，可惜這個版本中還不支持分頁，列、行的拖拉的功能，只能是期待下一版了。其他幾個Widget也都非常的實用，dojo的官方網(wǎng)站上都有例子，感興趣的可以去找找。
??? 下一個是讓人感到驚喜是新增的 dojo.charting 和 dojo.gfx 包， dojo.charting 提供了一個基于Vector實現(xiàn)了多種圖表類型的charting engine，從demo上來看，非常不錯哦！ 可以從這個地址體驗一下：
?http://archive.dojotoolkit.org/nightly/tests/charting/test_engine.html
?? 另外一個好消息是，從昨天dojo官方網(wǎng)站的新聞上看到 Greenplum 和 SitePen（兩個技術型的企業(yè)） 宣布把他們的一些技術捐贈給Dojo的 new charting engine。dojo.gfx是一個二維矢量圖形的API，能自動的根據(jù)客戶瀏覽器的類型決定使用SVG或是VML，也很實用，比如新增加的Clock Widget就是基于這個包實現(xiàn)的。這兩個包的加入讓我們有理由相信不遠的將來，dojo必然會撐起網(wǎng)頁圖表的一片天!
??? 然后是 dojo.a11y 包，a11y 是accessibility的縮寫，主要是加入對鍵盤按鍵（快捷鍵）的支持。官方網(wǎng)站上說的是在Dojo 0.4中只有一部分widget中已經(jīng)加入了這方面的支持，在0.5中會加入努力更多。
??? 國際化支持方面，這個版本的 dojo.i18n 包做了不少的改動，加入了對 collecting localized resources 的支持，提供了更多的date and time 的格式，此外對很多 widget （DatePicker, TimePicker等等） 也做了國際化的改進，不過DatePicker，TimePicker依然是丑陋無比。可以看到和dojo 0.3.1比，國際化的框架并沒有很大的變動， 這次主要是具體的進行一些完善。
??? 還有很多其他的包，像 dojo.lfx，dojo.namespaces，dojo.html等等，在這一版中也都得到了很大的提高，詳細一點的列表可以查看 http://dojo.jot.com/WikiHome/Release0Point4?。
??? 從0.3.1 到 0.4 幾個月的時間里dojo便得到如此大的提高，根據(jù)Dojo網(wǎng)站上的公告，dojo 0.4.1過幾天也就要發(fā)布了，在幾個月后又要出0.5，按照這效率，想想一年后的dojo，真是讓人抓狂！
摘要: 在Oracle10g開始盛行的今天，9i依然在眾多項目中得到廣泛應用, 這次一個偶然的機會需要在Red Hat ES 4上裝Oracle9i, 想想上次裝Oracle還是三年前的事了, 由于ES4不 在 Oracle 9i 的官方支持的linux版本之內(nèi),這次安裝用了近2天時間才搞定，查資料，找補丁，一遍一遍的重裝，好像回到了當年剛參加工作時的那種狀態(tài)，很有感觸，做技術有些東西總是不會變。裝的過程中發(fā)現(xiàn)網(wǎng)上對ES4上裝Oracle 9i的總結不多，大部分都不是很完整，便整理了這個文檔，希望對大家有用。
閱讀全文
??? 這兩天花了點時間看 Dojo 0.3.1 的新功能， 發(fā)現(xiàn)Dojo果然兌現(xiàn)承諾， 在0.3.1加入了一點國際化支持的功能。最主要的是改動是引進了 dojo.locale 屬性和 dojo.i18n 包， 從而于 javascript 實現(xiàn)了Client端的本地 message bundle 機制，從現(xiàn)在起，我們可以在客戶端根據(jù)locale裝載JS消息文件了! 完整的示例代碼如下：
<script?type="text/javascript">????????????????????????
????????djConfig?=?{
????????????????isDebug:?true
????????};
</script>
<script?type="text/javascript"?src="../../dojo.js"></script>
<script?type="text/javascript"?src="../_bootstrap.js"></script>
<script?type="text/javascript">
????????dojo.locale?=?"fr";
????????dojo.requireLocalization("g11n.messages","salutations","en");
????????dojo.requireLocalization("g11n.messages","salutations","fr");
????????dojo.requireLocalization("g11n.messages","salutations","zh-cn");
????????dojo.require('dojo.i18n.common');????????
</script>
<script?type="text/javascript">
????????function?init()?{
????????????????var?salutations_default?=?dojo.i18n.getLocalization("g11n.messages",?"salutations");
????????????????dojo.debug("default?language:?"+salutations_default.hello);
????????????????
????????????????var?salutations_zh?=?dojo.i18n.getLocalization("g11n.messages",?"salutations",?"zh-cn");
????????????????dojo.debug("Chinese:?"+salutations_zh.hello);????????????????
????????}
????????dojo.addOnLoad(init);
</script>
?? 首先是 dojo.locale 這個屬性，這個屬性是一個全局，作為用戶默認的locale，如果用戶不明確指定，dojo會根據(jù)瀏覽器的locale對這個屬性賦值。和Java不同，目前在dojo中l(wèi)ocale并沒有對應對象，只是一個String對象，典型的格式應該是 "zh","zh-cn"。注意后者用的是 "-" ,而不是Java中的 "_"。
? ?
?? 現(xiàn)在來看最讓人心動的 message bundle 機制, 首先分成三步來把message文件組織好:
??????? 1) 要建立一個集中存放message文件的目錄，我建的是 g11n\messages;
??????? 2) 和在java中一樣，為不同的locale建立存放message文件的文件夾，比如我建的是"en","fr","zh-cn"; 這里要注意文件夾的名稱必須要全部小寫，原因是dojo從文件裝載消息會把傳入的locale屬性進行 toLowerCase() 的處理(暈，不知道作者怎么想的)。
??????? 3) 把翻譯完并用native2ascii轉換好的消息文件放入對應的文件夾內(nèi)。和Java不同的是，dojo用 JSON 格式來組織message文件,所以要把property文件轉換到JSON格式的js文件, 不過這也很容易: 在文件開始的位置加入一個"{", 結尾的地方加入"}", 將所有的 "=" 替換成 ":" , 然后在每一行結尾處加入一個"," ,最后把文件改成js結尾便可以了。一個典型的JSON格式的文件如下(假設文件名叫 salutations.js ) :
{
?hello:?"Hello",
?dojo:?"Dojo",
?hello_dojo:?"%{hello},?%{dojo}!",
?file_not_found:"The?file?you?requested,?%{0},?is?not?found."
}
?
?? 把消息文件放好后，便可以在 dojo 中通過 dojo.requireLocalization() 調用這些文件了,對應的代碼是：
??????
//下載需要的locale的消息文件到客戶端
dojo.requireLocalization("g11n.messages","salutations","en");
dojo.requireLocalization("g11n.messages","salutations","fr");
dojo.requireLocalization("g11n.messages","salutations","zh-cn");
//調用國際化包
dojo.require('dojo.i18n.common');??
?
?? 現(xiàn)在就可以調用指定locale的 message 了！在示例代碼中我舉了兩個簡單的例子：
???
//調用?dojo.locale?指定的locale中對應的消息文件中?hello?那條消息
????var?salutations_default?=?dojo.i18n.getLocalization("g11n.messages",?"salutations");
????dojo.debug("default?language:?"?+?salutations_default.hello);
????//調用"zh-cn"中?hello?那條消息
????var?salutations_zh?=?dojo.i18n.getLocalization("g11n.messages",?"salutations",?"zh-cn");
????dojo.debug("Chinese:?"+salutations_zh.hello);?
?? 怎么樣，非常簡單吧?
??? 除了message bundle, dojo 還聲明要支持其他的一些國際化功能，比如Date,Number,Currency等等，在0.3.1中我只發(fā)現(xiàn)Date有一定的實現(xiàn)，但是基本就是對 Javascript Date 對象的幾個locale相關的方法進行了一下封裝，沒有多少實質性的提高，看來dojo在國際化的支持方面還有很長的路要走。無論如何0.3.1中提供的message bundle已經(jīng)有了一個良好的開端，值得期待。
??? 前幾天遇到一個bug，在一個填email的文本框，當用戶錄入比較長的一段文本后（比如40位以上），頁面就死掉了。檢查后發(fā)現(xiàn)校驗Email的是下面這樣一段javascript代碼：
? function checkEmail(email)
? {
??????? if (email.length == 0 )
??????????? return true;
???????? var validEmail = /^\w+([\.-]?\w+)*@\w+([\.-]?\w+)*(\.\w{2,3})+$/;
???????? if (validEmail.test(email))
???????? {
???????????????? return true
????????? }
?????????? return false
??? }
??? checkEmail("123456789012345678901234567890123456789012345abcdefghijkl");
?? 第一反應是正則表達式寫的有問題，'@'前后的 ([\.-]?\w+)* 都可能會引起效率問題。下面仔細分析一下:
1. 從輸入的值來看， engine會首先匹配 \w+， 這是一個貪婪匹配，可以一直匹配到結尾；
2. 然后按優(yōu)先級開始匹配 ([\.-]?\w+)*中的 [\.-]?\w+，這個時候前面的 \w+ 為了后面的匹配成功，必須要重現(xiàn)匹配，讓出一點匹配的內(nèi)容，假設先讓出的是 'l'，([\.-]?\w+)*匹配成功；
3. ([\.-]?\w+)* 意味著要盡量去匹配多次，再第二次對 [\.-]?\w+ 匹配，這個時候為了第二次匹配的成功，第一次匹配的 [\.-]?\w+ 要讓出能滿足第二次 [\.-]?\w+ 的內(nèi)容，也就是它匹配到的'l'，這個時候，第一次匹配的 [\.-]?\w+ 又不滿足了，\w+ 又得讓出來一個'k'。
4. 這樣未知匹配次數(shù)的 ([\.-]?\w+)* 就形成了一個很大的循環(huán)，而在正則表達式中，每次匹配時被括號里模式匹配的東西都是要被存起來供以后使用的，大量的中間結果被緩存，最終導致IE死掉。
?? 所以這是一條典型的因為循環(huán)嘗試匹配導致效率低下的正則表達式， 表達式中兩個 ([\.-]?\w+)* 都可能導致解釋器的crash，在本例中不需要利用匹配的中間結果，所以解決的辦法很簡單，在括號加入一個冒號，不保存中間結果就是了。即將那個正則表達式改成如下：
? /^\w+(?:[\.-]?\w+)*@\w+(?:[\.-]?\w+)*(\.\w{2,3})+$/
如果性能還是不能滿足需求，可以考慮把這個正則表達式拆成幾個小的表達式，分別進行驗證。