#
??? 這兩天花了點時間看 Dojo 0.3.1 的新功能， 發現Dojo果然兌現承諾， 在0.3.1加入了一點國際化支持的功能。最主要的是改動是引進了 dojo.locale 屬性和 dojo.i18n 包， 從而于 javascript 實現了Client端的本地 message bundle 機制，從現在起，我們可以在客戶端根據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會根據瀏覽器的locale對這個屬性賦值。和Java不同，目前在dojo中locale并沒有對應對象，只是一個String對象，典型的格式應該是 "zh","zh-cn"。注意后者用的是 "-" ,而不是Java中的 "_"。
? ?
?? 現在來看最讓人心動的 message bundle 機制, 首先分成三步來把message文件組織好:
??????? 1) 要建立一個集中存放message文件的目錄，我建的是 g11n\messages;
??????? 2) 和在java中一樣，為不同的locale建立存放message文件的文件夾，比如我建的是"en","fr","zh-cn"; 這里要注意文件夾的名稱必須要全部小寫，原因是dojo從文件裝載消息會把傳入的locale屬性進行 toLowerCase() 的處理(暈，不知道作者怎么想的)。
??????? 3) 把翻譯完并用native2ascii轉換好的消息文件放入對應的文件夾內。和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');??
?
?? 現在就可以調用指定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中我只發現Date有一定的實現，但是基本就是對 Javascript Date 對象的幾個locale相關的方法進行了一下封裝，沒有多少實質性的提高，看來dojo在國際化的支持方面還有很長的路要走。無論如何0.3.1中提供的message bundle已經有了一個良好的開端，值得期待。
??? 前幾天遇到一個bug，在一個填email的文本框，當用戶錄入比較長的一段文本后（比如40位以上），頁面就死掉了。檢查后發現校驗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. 然后按優先級開始匹配 ([\.-]?\w+)*中的 [\.-]?\w+，這個時候前面的 \w+ 為了后面的匹配成功，必須要重現匹配，讓出一點匹配的內容，假設先讓出的是 'l'，([\.-]?\w+)*匹配成功；
3. ([\.-]?\w+)* 意味著要盡量去匹配多次，再第二次對 [\.-]?\w+ 匹配，這個時候為了第二次匹配的成功，第一次匹配的 [\.-]?\w+ 要讓出能滿足第二次 [\.-]?\w+ 的內容，也就是它匹配到的'l'，這個時候，第一次匹配的 [\.-]?\w+ 又不滿足了，\w+ 又得讓出來一個'k'。
4. 這樣未知匹配次數的 ([\.-]?\w+)* 就形成了一個很大的循環，而在正則表達式中，每次匹配時被括號里模式匹配的東西都是要被存起來供以后使用的，大量的中間結果被緩存，最終導致IE死掉。
?? 所以這是一條典型的因為循環嘗試匹配導致效率低下的正則表達式， 表達式中兩個 ([\.-]?\w+)* 都可能導致解釋器的crash，在本例中不需要利用匹配的中間結果，所以解決的辦法很簡單，在括號加入一個冒號，不保存中間結果就是了。即將那個正則表達式改成如下：
? /^\w+(?:[\.-]?\w+)*@\w+(?:[\.-]?\w+)*(\.\w{2,3})+$/
如果性能還是不能滿足需求，可以考慮把這個正則表達式拆成幾個小的表達式，分別進行驗證。
1） SVN配置文件中各個屬性行前不能有空格
?在Windows平臺下安裝Subversion之后，使用時提示svnserve.conf中一些行有問題。打開svnserve.conf一看 "password-db = passwd" 這一行最前面被我無意中加了個空格，刪掉后SVN便工作正常了。
2） Tomcat 5.5 連接池的古怪錯誤
??? 在tomcat 5.5下配置連接池，使用時總是出錯： Cannot create JDBC driver of class '' for connect URL 'null'。
??? 一樣的配置以前在5.0下都是可以正常工作的。查了Tomcat的聯機文檔也沒有什么發現，多次嘗試最后找到解決辦法：在 $CATALINA_HOME/conf/Catalina/Host Name/ 下建一個和應用同名的xml文件，將原來放在server.xml文件中的該應用對應的Context定義放在這個xml文件中，便不會有這個錯了。
3） Velocity配置文件中${webapp.root}變量不起作用
??? 在spring中使用velocity作為顯示層，以前一直是用絕對路徑來指定velocity模板文件的根目錄，這次想直接和應用的root路徑掛起來。
??? 在velocity.properties中file.resource.loader.path的注釋中看到有一個${webapp.root}的描述，便在velocity.properties中設置 file.resource.loader.path=${webapp.root}\\velocity\\，不起作用。看來velocity自己并不會設置類似于${webapp.root}這樣一個變量，查velocity的Developer's Guide，也沒有找到有類似${webapp.root}的變量，Guide中倒是推薦將模板文件打成jar，然后用ClasspathResourceLoader來找模板文件，開發階段可不想弄的如此晦澀，還是直接改回用絕對路徑好了。
??? 幾個小問題雖然都解決了，但卻不知道為什么，因為時間的原因我也沒有深究。現在貼出來，有人知道原因的，還請不吝賜教。
? 用了四五年的Table排版，沒覺得有什么不好，這一段時間迷上了Dojo,才發現如今已經到了不用DIV不行的年代。還是趕緊跟上潮流，把Table換成DIV吧! 改了幾個頁面，發現比想象的簡單，更是嘗到了用div的甜頭。share自己一點淺淺的經驗：
1. 先上網搜一下找點前人經驗。推薦兩篇好文：
? http://www.glish.com/css/???????????????????????? "CSS Layout Techniques: for Fun and Profit"
? http://www.alistapart.com/articles/practicalcss?? "Practical CSS Layout Tips, Tricks, & Techniques"?? ?
2. 隨便找幾個用DIV+CSS實現，結構又比較簡單的網站，研究一下它的頁面結構和CSS。比如我就是主要看了下面幾個網站：
????? CSS禪花園????????? http://csszengarden.com/????? ?
????? Eclipse.org??????? http://www.eclipse.org/
????? mozilla.com??????? http://www.mozilla.com/
作為世界上CSS高手比武的擂臺，CSS禪花園的模板實在多的恐怖，以前都只站在欣賞的角度不覺得，自己研究起來，也就只能是挑了一兩個看看，再感慨了一番作者真是好創意好美工。有趣的是Eclipse.org的首頁居然基本用的都是mozilla.com的CSS，對比著這兩個網站看更能看出端倪。
3.? 自己上手干吧，讓你的頁面內容和顯示樣式徹底分離，其實并不難。
GB18030 的正式名稱為“中文國家標準 GB 18030-2000：信息技術 － 信息交換用漢字編碼字符集－ 基本集的擴充”。它是針對在中國出售的所有產品制定的政府強制標準要求，該標準于 2001 年 9 月 1 日生效。這也意味著從理論說，每個在出售的產品都要支持GB18030字編碼字符集，否則就不讓賣[嘿嘿，您的產品達標了么？]。
有人曾經在他的一篇blog[ http://blog.cathayan.org/archive/1/2005-7-4 ]里非常形象的介紹過 GB18030 的歷史,轉貼精彩部分如下：
1，GB2312是很老的東西了，早就發現不夠用了。
2，94年（還是之前）國家推出了建議性標準gb18000（還是13000我忘了），這個標準其實就是utf-8標準（除了名字，完全一樣），同時也建議微軟公司采納。－－（據說是1993年，GB13000，應該是ISO10646）
3，微軟借口說gb18000還不成熟，為了取得中國市場的壟斷地位，自己搞了一套漢字標準，于是它就隨著win95和office之類的流行起來了，國家看生米已經煮成了熟飯，只好把這套標準定為國標GBK標準。－－（其實只是指導性標準，并非強制性，GB18030是強制性標準）
4，微軟到了99年（前后吧），又說GBK已經落伍了，現在流行utf-8標準，準備全盤轉換成utf-8，這些把有關部門惹怒了。NND，當年我們推utf-8你說不成熟，自己搞了一套，現在賺得盆滿缽滿了又自己說要推utf-8了，你丫微軟分明就沒把政府放在眼里。
5，于是政府怒了，強制推行gb18030標準（這個標準前面兼容GBK，其他碼位兼容utf-8），算是過渡標準吧。要求微軟強制執行，否則產品不得在大陸買。于是基本搞死了微軟的WindowsMe，差點搞死了Office2000（據說發行前幾個月，微軟除了改字符編碼就沒干其他什么事情）－－（確實，WinMe是我認為的最差的Windows版本，而office2k也是前不著村，后不著店，前后兼容性都差）
6，由于以上歷史原因，現在就是GB2312，GBK，GB18030，UTF-8并存了。
7，如果不是萬惡的微軟，我們早就用上UTF-8了。
?? 或許正是因為微軟和中國之間為GB18030發生了這么多的恩恩怨怨和當年微軟的倉促上陣，直到現在微軟的很多產品對GB18030支持的依然不是很好。訪問下面的頁面，了解MS對GB18030支持情況及下載Windows下的GB18030安裝包：
http://www.microsoft.com/globaldev/DrIntl/columns/015/default.mspx
雖然MS聲明在Windows XP 和 Windows 2000 中通過"add-on"來支持GB18030，但是IE 6.0直接顯示 List Box、Drop Down Menu、Text Area、Text Field中的GB18030字符依然還是有問題，下面的這篇文章有相關的介紹：
http://www-306.ibm.com/software/globalization/gb18030support/retrieve.jsp
在IBM的這篇名為"Globalize your On Demand Business"的文章里，給出的solution是在要顯示GB18030的元素上加上類似 "STYLE="font-family:'SimSun-18030'"的CSS聲明。在當今WEB2.0如火如荼的年代，我們當然要把內容和顯示分離，在CSS中進行配置！當然實際問題要比這個文檔說的略微復雜一點，有下面幾個比較明顯的問題：
1) 一般來說，大部分html標簽(包括Input)都不要，但<Select> 要必須要在CSS中強制指定"font-family"為"SimSun-18030"。
2) 當要為一個元素指定多個字體的時候，要將"SimSun-18030"作為首選，即放在最前面。
3) 對于大部分標簽,當font-family設為 SimSun-18030 時，而font-size 為：8pt,9pt,11px 時，有一部分字符比如 "㊣"和一些標點 會顯示成其他的字符，對 "㊣" 這樣的字符，IE 會出現亂碼。原因可能是因為這些個font-size針對WEB做了優化。
小結：GB18030是個形式大于內容的東西，但是如果想要讓你的產品理直氣壯的再中國銷售，略微花點時間設置一下還是有必要的。
?
昨天抽出空來裝了一個Ruby，體會體會這個最近很多人提起的東西。從下載到安裝，包括裝Cygwin一共也就用了一個小時。看了看它自帶的文檔，寫了兩個小腳本試了一下，覺得和perl很點類似，語法很簡單，上手非常快，用起來也沒感到什么特別神奇之處。接著下了久仰大名的Ruby on rails 裝了一下試試，發現用它建站的確很快，就像當年用傻瓜相機的感覺。
簡單來說，Ruby 給我的感覺一般，沒有讓我有一見鐘情的感覺。我不是很喜歡Ruby這種很隨意的語法，對于Ruby on rails這個輕量級的構架未來內能達到的高度也有所懷疑。Ruby就是Ruby，還是不能和Java來比較，離取代Java更是差十萬八千里，Ruby本身是一個普通的腳本語言，和Java差別太大，Ruby無非是在各有千秋的眾多編程語言里又加了一種。Ruby on Rails 的思路是比較前衛的，不過主要就是個思路，別人很容易就借鑒了，沒準用不了多久java on rails,dotnet on rails就會出來。不知道Ruby on rails在事務、安全方面是怎么處理的,運行起來效率會怎樣,反正覺得Ruby on Rails好像是用來做中小型網站的。網上好像Ruby的fans很多，其實回頭看看，每種流行一點的腳本語言的Fans都很多。
我認為Ruby的語法、Ruby on Rails的特點注定了它只能給一些想快速建網站的人使用，是很難得到大公司青睞從而在商業領域獲得更大空間的。對于目前新流行起來的幾個腳本語言，我覺得groovy的定位還是很不錯的，傍著Java這個巨人，將來沒準能吃香的喝辣的。雖然不是特別看好Ruby,以后有時間還是準備系統的看一下ruby的語法和試一試ruby on rails的應用開發，應該能從里面找到很多可以借鑒的東西。
剛才無意中發現自己很久以前寫給同事看的東西，干脆貼出來。
- 安裝環境
Wiki的功能比較簡單，因此互聯網上Wiki的實現非常非常的多，有各種各樣的實現，基于asp、java、php、Python、perl等等，大家可以根據情況自己挑一個。從這方面看，Wiki映證了一個道理，簡單的就是最美的，好像有一大筐做工精致的藝術品擺在你面前讓你挑，真是人生快事。至于俺么，當然是選擇基于Java的了！有人做好了給你用，爽哦。
我的安裝環境：Linux + Tomcat-5.0.19 + JSPWiki 2.0.52 + jdk1.4 。
- 開始安裝的準備工作
下載 JDK, Tomcat 并安裝,這里就不說了,呵呵。
從 http://www.jspwiki.org/ 下載JSPWiki, 當前的穩定版本是2.0.52。當然這個網站本身也是用Wiki做的，去下載時你就已經認識到Wiki是什么東東了。下載下來的是一個壓縮文件 jspwiki-2.0.52-bin.zip ，解壓后進入解壓的文件夾，可以看到JSPWiki.war、JSPWiki-samplepages.zip兩個文件，前者就是JSPWiki的程序了,JSPWiki-samplepages.zip里是其官方給出的一些例子頁面，很有價值哦。
- 安裝
將JSPWiki.war解壓到一個文件夾，假設叫wiki，后放到 Tomcat 的Webapps文件夾下，進入 wiki/WEB-INF/ , 編輯 jspwiki.properties ,進行相關的設置,幾個重要的參數:
a) jspwiki.applicationName = your app name -------- 你這個Wiki網站的名稱
b) jspwiki.pageProvider = VersioningFileProvider -------- Wiki對頁面的管理方式，有三種： RCSFileProvider， FileSystemProvider， VersioningFileProvider(推薦使用).
c) jspwiki.fileSystemProvider.pageDir = /home/wiki -------- 網站內容存放地點
d) jspwiki.basicAttachmentProvider.storageDir = /home/wiki/attach -------- 網站用戶上傳的附件的存放地點
e) jspwiki.encoding = UTF-8 -------- 設置頁面的編碼格式
f) jspwiki.rss.channelLanguage = zh-cn -------- 設置rss語言格式,如果你不需要rss功能的話可以不設置
g) jspwiki.baseURL= ——wiki的基本URL，如果你不需要rss功能的話可以不設置
h)jspwiki.translatorReader.allowHTML = false -------- 是否允許wiki里面支持html，網站對外開放時最好不要設，因為wiki是協同編輯的，如果有人惡意使用js的話，就慘了，呵呵。
- 設置字符集
安裝后要使有中文問題,注意看上一項4中的 e ,f 兩項是不是都設置對了.
- 運行Wiki,添加頁面
jspWiki內置了一些用于布局的版面page，包括Home、Index、LeftFooter、LeftMenu、LegalAndPrivacyNotice、MenuBar、RightFooter、RightMenuBar、Website、Contacts、ErrorMessage等等，只要稍加編輯就可以攢一個挺專業的網站。激活它們的方法是瀏覽器中輸入： http://localhost:8080/wiki/Wiki.jsp?page=pageName.
- 后期處理
設置tomcat為自啟動： 在startup.sh 中設置 JAVA_HOME , CLASSPATH , PATH 等環境變量，在 /etc/rc.d/rc.local 中添加啟動腳本。
熟悉wiki之后可以進一步學習FitNesse之類的 Wiki 的較高級的應用。
上周末按一個朋友的要求，寫一個整合Tomcat-5.5.4與apache-2.0.49的文檔。很久沒用Apache了，在家用了一兩個小時才在自己的XP下配成功，簡單整理了一個文檔貼出來，與需要的人共享。我開始是在 apache 的conf 文件夾里建了一個mod_jk2.conf個文件，用JkSet config.file ***語句指到TOMCAT_HOME\conf\workers2.properties, 無論如何都不成功，最后就直接把workers2.properties拷到apache 的 conf 文件夾里就OK了。具體步驟如下：
1、假設Apache2安裝在 C:\Program Files\Apache Group\Apache2, 上Apache網站下載jakarta-tomcat-connectors-jk2.0.4-win32-apache2.0.49.zip , 解壓后將modules\mod_jk2.so拷貝到C:\Program Files\Apache Group\Apache2\modules里面。
2、 在C:\Program Files\Apache Group\Apache2\httpd.conf中設置Dynamic Shared Object (DSO) Support的那塊區域里增加一行：
LoadModule jk2_module modules/mod_jk2.so
3、修改 Tomcat-5.5.4 HOME\conf\ 下的配置文件, 編輯jk2.properties，修改handler.list的值，要注意端口channelSocket.port設置的值，默認是8019，改成8009, 這樣改各個配置文件的改動量最小。
# Set the desired handler list
# handler.list=apr,request,channelJni
handler.list=channelSocket,request
#,
# Override the default port for the socketChannel
channelSocket.port=8009
4、將 Tomcat-5.5.4 HOME \conf\ 下的workers2.properties 拷貝到 C:\Program Files\Apache Group\Apache2\conf 中，然后修改workers2.properties 內容：
[logger.apache2]
level=INFO
[shm]
file=C:\\apache\\Apache2\\logs\\shm.file
size=1048576
[channel.socket:localhost:8009]
port=8009
host=localhost
[ajp13:localhost:8009]
channel=channel.socket:localhost:8009
[uri:/*]
worker=ajp13:localhost:8009
要進一步設置的，修改[uri:/*]，比如改為[uri:/*.jsp]。當然這樣記住要先將Apache的默認目錄指到tomcat下的對應的應用. 此外[uri:/*] 這部分可以設置多個。
5、重新啟動apache、tomcat, 訪問apache的地址http://localhost/和tomcat的地址http://localhost:****/ ,如果看到一樣的東西,應該就可以了。
6、配Apache的默認目錄或虛擬主機，指到要用Apache來顯示的目錄里面去；網上很多，Apache本身的文檔說的也比較清楚，就不詳細說了。
7、如果是 Linux 平臺的話，Apache 必須要在編譯的時候加上選項，使其能動態的加載DSO模塊，大概的步驟就是下載Apache源文件 ，然后依次執行：
#cd /usr/local/src/ ( /usr/local/src/ 就是保存安裝源文件的文件夾 )
#tar -xzvf httpd-2.0.49.tar.gz
#cd httpd-2.0.49
#./configure --prefix=/usr/local/apache2 --enable-so (-enable-so 這個選項最重要，一定要加上 )
#make
#make install
后來的步驟和windows下應該是一樣的（那個so文件應該也可以在linux用），linux下面我這次沒有試，不過思路和步驟應該差不多就是這樣,俺以前配過。
?? 從年初到現在，AJAX之風預演愈烈，尤其是在國內，大多是一片叫好的聲音。目前好像很多人都在搞基于AJAX的框架，國外也有一些都已經發布。對于這種一直都存在技術，Google、微軟一造勢，大家的熱度好像有點過了頭。看來現在咱們這些程序員真的都是些追星族啊！
?? 難到AJAX真的就那么優秀，值得提升到框架的高度，讓系統UI端圍著它轉？單純從AJAX本身來說，其最主要不過就是解決在網頁上一個無刷新獲取數據的問題，再加上減少了數據的傳輸量，將數據解析的工作推到了客戶端，的確能解決很多傳統的問題，很方便的實現一些動態效果。然而，要圍繞AJAX建立一個框架，通過AJAX完成UI端絕大部分內容的展現，我個人認為卻是欠妥。現在很多人在網站上說，AJAX多多成熟，能達到多好多好的效果，但是問題是，AJAX技術本身成熟，但AJAX框架卻是十分的不成熟。
?? 筆者前一段一直在參與一個國外知名大公司的一個產品的開發，這套系統好幾年前就開始做了，系統的UI很多是基于AJAX的，對AJAX的應用可謂登峰造極（當然，那個時候肯定還沒有AJAX這個名詞），其界面的可操作行幾乎可與桌面系統媲美。這系統有一個強大的AJAX框架，光是相關基礎JS文件就是數十個，整個UI基于Javascript事件驅動，數據由XMLHttp獲取。整個方案看上去的確很棒，或許正是現在很多人想要實現的。但實際情況是如何呢？效果是實現了，程序開發和測試、維護的效率則是大大的下降了。開發就不說了，前期投入巨大，系統復雜性劇增，程序也只能用IE訪問。測試的時候這邊 AJAX的javascript的bug滿天飛，那邊調試這種錯誤極不方便，沒有好的JS的調試器，更看不到實際輸出的html代碼。維護那就糟糕，加個新功能，JSP文件、標簽、JS、后臺類全要過一遍。或許正是這些不易克服的問題，我看到在最近開發的配套軟件里，就基本沒有用什么AJAX了。
?? 大公司的嘗試和經驗，或許能給大家一些啟示。說到底，所有的技術都是有利有弊的，AJAX也是一樣。我個人認為AJAX 最適合的就是Google Map這種網上地圖系統，展現方案相對比較單一，又非常的需要無刷新的獲取數據。對于那些業務比較多，展現風格非常多樣的業務系統，萬萬不可腦子一熱，真的要用什么AJAX框架，到頭了只回為了一點無謂的效果砸了自己的腳。
?? 最后強調一下，AJAX是個好東西，在項目里用它來實現一些輔助效果（最傳統的比如用戶輸入數據時實時的驗證，給出相關提示）即快捷又神奇，但過度使用很容易讓自己系統陷入麻煩之中，一定要慎重！此外目前公布出來的所謂的那些AJAX框架大多都是實現一個Form或者一部分頁面的無刷新取數，根本談不上什么Web框架，目前沒必要抱太大的希望。最近down了幾個開源的ajax的東西看了看，覺得對一般開發人員來說，ajaxtags (http://sourceforge.net/projects/ajaxtags/) 是個不錯的東東，簡單易懂，可以仿照它的標簽做一些自己的實現，值得看一看。
聲明：本博客中所有文章均為版主原創，轉載請保留作者信息，并請注明出處。
昨天無意中發現教育網內也能上google了，高興之余也頗有感慨。回想過去數年我和朋友在教育網里搜資料，每每破費周折的設代理、找國際網關，還常常不如愿，不得不用蹩腳的baidu, 現在終于是方便了。
細想起來，這事情還得感謝我一向不太看的起的百度了! 數年前百度不過是個有些小聰明的模仿者，用一個類似Google的界面，搜出一堆雜亂的糟粕，前一段時間卻因為上市一下譽滿神州了。在我看來百度的紅火，除了百度自己說的和門戶網站合作掙錢之外，兩個因素發揮了很大的作用，一個百度提供的mp3搜索下載，另一個是教育網內數量巨大的網民無法使用google，迫不得已就用百度了。
前者當然不用說，為了自己的利益，百度用一份所謂“著作權保護聲明”做掩護便大張旗鼓的為侵犯知識產權的行為推波助瀾，就連這份用來做作的聲明，估計也還是被人告了一通之后才炮制出臺的。寫到這里，突然想去以前百度被告時申述的理由：要告應該去告那些侵權的網站，我百度只是提供搜索服務的，這跟我沒關系。呵呵，百度邏輯的荒謬，由此可見一斑！分門別類的把那些侵權的東東排列好讓人去down，還說和他沒關系。倘若按這種邏輯，那些銷贓的人就可以說，我知道這東西是偷來的，但這不是我偷的，我只是賣的，要抓抓那些小偷去！當然，銷贓的人不只是百度一家，然百度卻必是其中之一。
再看第二個因素，教育網內網民無法用google是歷史問題，google最早是國外網站訪問要算國際流量。于是缺乏就產生了，在經濟學家眼里，缺乏、競爭、物產是同義詞，有了缺乏就會有競爭，于是百度來了，承擔起和google來compitition的責任，結果大家都看到了，百度受益不小。現在Google當然不會容忍在地球上人口最多,經濟最有活力的國家有這樣一個競爭對手，也開始反思其漠視中國最具前衛性的網民群體的行為，于是我在家能上google了。紅塵俗世、莫不競爭，我這個老百姓又一次深深的感受到競爭的好處。
教育網內能有google了，百度會淪為一個mp3搜索站么？百度錢圈了一大筆，但是搜索的質量沒有任何提高，倒是網站的亂七八糟的東西多了不少。我絕不并是刻意的要說百度的不是，我是中國人，當然希望我們自己國家的搜索引擎能強過美國人。最盼望的是百度能認真的把搜索做好，銷贓的事情少做一點，compitition的責任多承擔一點。等過些年倘若大家不用因教育網能上google欣喜，我們這些網民也算是有幸了。