專案開發告一段落，喘口氣，總結一下。
1 ajax還是ajah
* ajax的很多經典應用其實都是利用xmlhttp空間訪問後台程式，後台程式返回指令碼用eval**或者返回簡單資料的方式來開發。這樣的開發模式的好處是設計簡單輕巧，對熟悉dhtml的開發者來說上手會比較塊，跨瀏覽器問題也容易解決，做簡單的應用也夠用。gmail，google suggest都是用這種方式。但是在我看來gmail已經吧ajah應用到極限了，更複雜的資料結構用簡單資料和**方式來組織就開始有點力不從心了。
* 前ajax的一種傳統做法是後台返回完整的xml檔案後用指令碼（利用控制項）解析xml後操作頁面的dom節點來動態生成頁面的一部分。這樣作的優點是可以充分利用xml的強大表達能力傳輸各種資料結構，缺點是頁面的dom操作效率不高，而且ie在dom操作的api上bug多多。之所以叫「前ajax」，因為我們在ajax這個名詞出現前已經這樣做了很多年了。
* ajax另一種傳統做法是後台返回完整的xml檔案後用指令碼（利用控制項）解析xml後生成html**再灌回頁面的層中。這樣的做法迴避了頁面dom操作的一些問題，在生成的內容比較多的時候利用一些字串計算的優化技巧（主要是陣列和正則的應用）可以相當高效的生成頁面。在我看來這是未來的發展趨勢。
我現在的專案主要採用的是第三種方式，結合第二種。我使用的是自己的乙個小巧的框架，模擬jsp的語法來生成html**，但是依賴於瀏覽器的xml解析api，因此難以跨瀏覽器。google的開源專案ajaxslt提供了乙個純js的xslt解決方式，功能更強大，可以在頁面中區域性的應用xslt解析xml生成html或者其他形式的資料，但是帶來了xslt這個技術門檻。sf上的zk似乎也不錯，但是帶來的是xul這個技術門檻，同時後台被繫結在了j2ee伺服器上面。
2 cache
如果使用xmlhttp控制項，在發起http請求的時候ie會包辦cache策略，很多時候更新了資料卻無法獲得更新後的資料。一開始試圖用傳統方式在url後面加隨機數來強制更新，但是ie仍然距不發出新的請求。
乙個解決方法是在後台寫expires: 0或者其他的禁止前台cache的頭，但是這樣在資料沒有更新的時候又會帶來不必要的伺服器壓力、響應延遲和頻寬浪費。
乙個稍微好一點的解決方法是，前台在提交資料以後，需要強制更新資料的時候：
3 系統錯誤: -1072896748。
用xmlhttp接收到資料的時候經常是用xmldom.loadxml(xmlhttp.respon***ml.xml）來判斷返回的資料的正確性，但是如果後台送過來不正確的xml的時候有時回觸發-1072896748系統錯誤。這是因為xmlhttp.respon***ml已經沒有解析到東西了，我們還試圖訪問它的xml屬性而觸發的。
解決的方法是在使用respon***ml.xml 或者 responsetext的時候要做try/catch：
trycatch(ex)
有些人喜歡catch的時候判斷 exception.description=="系統錯誤: -1072896748。" , 如果客戶端不是簡體中文版的系統的時候就判斷不到了。其實這個地方只要有異常，都必須走異常處理流程了，不用區分的那麼仔細。
實習兩個月的總結
工作總結和工作計畫 我將從三方面進行我的工作總結，第一 我做的工作 第二 我的學習 第三 我的體會。然後是今年我的工作計畫。我做的工作 1.mvc4.0的校園一 2.jquery方式的增加刪除 3.儲存過程的分頁 4.linq簡單例子練習 5.記錄訪客的ip，瀏覽器，ip歸屬地，作業系統並將資料計入...
乙份工作入職兩個月總結
在公司入職兩個月以後，領導對我的開發提出了意見與建議，現在總結如下，這既是對個人以往開發的反思與分析，也是對以後開發的指導。做個簡單記錄。首先，我以前主要是在小公司和個人獨自開發，並沒有完全進入團隊開發的經歷。所以在新公司仍然按照了單打獨鬥的方式自己開發。但是，這不同，畢竟公司的專案也開發有一段時間...
新的歷程 近兩個月的工作總結
工作兩個月回來，會發現自己欠缺的還是非常多。我也不停的在問自己，這兩個月的工作經歷究竟帶給我了如何的收穫？技術 經驗 交流 眼界 信任 膽量 自信，這些詞語出如今我的腦海中，我不得不一項項處理掉這些，變成自己切實的財富。技術上接觸的新的內容並不算多，算是.net方向上的一些深入，給自己最大的感觸是 ...