阿舍的精彩生活

問題：open方法的第一個參數不論寫"GET"或是"POST"，在Process裡都是調用的doPost方法？為什麼不調用doGet方法？
答案：按照哪種方式提交不是由open()方法的第一個參數完全決定的，還與send()方法有關。

一、當open()方法裡指定的是GET，並且
1、send()方法的參數是""或者null，跟踪代碼可以知道調用了Servlet中的doGet方法
2、send()方法的參數是地址重寫的方式，或者就是一個字符串，都調用doPost方法，例如：
xmlHttp.open("GET", "ProcessServlet?choose="+document.getElementById("choosejsfile").value, true);//open裡調用GET方法。
xmlHttp.send("aaa=dd"); //a
xmlHttp.send("paramTest"); //b
xmlHttp.send(" "); //c
xmlHttp.send(null); //d
xmlHttp.send(""); //e
對於a、b、c、d、e五中send()函數，只有d和e會調用doGet方法，a、b、c三種方式均調用doPost方法。

二、當open()方法裡指定的是POST，則對於以上5種send()函數，服務器均會調用doPost方法。
所以使用哪種方式提交是由open方法和send方法共同決定的。

xmlhttp:open方法創建一個新的http請求，並指定此請求的方法、URL以及驗證信息語法
oXMLHttpRequest.open(bstrMethod, bstrUrl, varAsync, bstrUser, bstrPassword); oXMLHttpRequest.open(bstrMethod,bstrUrl,varAsync,bstrUser,bstrPassword);
參數
bstrMethod
http方法，例如：POST、GET、PUT及PROPFIND。 http方法，例如：POST、GET、PUT及PROPFIND。大小寫不敏感。
/*****
POST：用"POST"方式發送數據,可以大到4MB
GET：用"GET"方式發送數據,只能256KB
如果請求帶有參數的化實用POST方式，POST方式將參數放置在頁面的隱藏控件內沒有參數使用GET方式對於請求的頁面在中途可能發生更改的，也最好用POST方式用GET方式可能會拿不到最新的信息
*****/
bstrUrl
請求的URL地址，可以為絕對地址也可以為相對地址。
varAsync[可選]
布爾型，指定此請求是否為異步方式，默認為true。如果為真，當狀態改變時會調用onreadystatechange屬性指定的回調函數。
bstrUser[可選]
如果服務器需要驗證，此處指定用戶名，如果未指定，當服務器需要驗證時，會彈出驗證窗口。
bstrPassword[可選]
驗證信息中的密碼部分，如果用戶名為空，則此值將被忽略。

阿舍

何謂TraceMonkey
TraceMonkey的名稱來自於Mozilla的JavaScript解析引擎－SpiderMonkey與加州大學教授Andreas Gal等人所提供的技術－tracing。Gal目前為TraceMonkey的專案領導人。

簡單來說，TraceMonkey是一套「即時編譯器」，可將程式語言即時編譯成機器語言丟給電腦執行。多數的桌面端程式均是屬於事先編譯好的二元機器碼(binary code)，但JavaScript是一種程序語言，通常是逐條執行，因此效能低落。

而即時編譯器(just-in-time compiler)則是當使用者瀏覽新網頁時，將網站傳送來的JavaScript碼編譯成二元機器碼，但TraceMonkey並非編譯所有送來的JavaScript碼，而在追蹤與記錄JavaScript程式執行後，TraceMonkey將會找出容易耗費大量執行時間的程式迴圈，然後再將這些迴圈編譯成可執行碼。

傳統的編譯器(compiler)設計用來編譯整支程式，將所有的程式動作全部編譯成可執行碼，因此編譯工作相當耗時耗力。而Tracing技術將會根據實際的程式執行動作，只編譯實際耗用電腦運算資源的程式碼。

透過濃縮(Concentration)特點，TraceMonkey不需要大量記憶體或是載入速度慢的外掛程式，因此也適合行動裝置使用，這也是未來Moziila的重要開發項目之一。

當然，改善Web應用程式還有許多空間，Mozilla下一步要改善DOM，這是瀏覽器用來描繪與處理網頁用的文件物件模組元件。

阿舍

Flash起於圖像概念而發展，Silverlight則起於程式概念而發展。
對程式設計師來說，Silverlight會比Flash來的容易上手，未來一旦Silverlight填補了圖像工具及增加中文輸入、網路能力，那麼其將成為新一代的RIA Web Application開發標準。

Silverlight 2.0不需要.NET Framework 3.0，她內建的SLR約4.6MB，完全提供了.NET Language所需要的功能，其雖繼承了WPF複雜度偏高的缺點，但可於瀏覽器上直接執行的優點，可以完全Cover掉這個缺陷。

Silverlight 2.0能做什麼是Flash做不到，或是AIR做不到的呢？
用Silverlight 2.0可以做出一套於IE上執行的進銷存、會計、人事薪資，而且UI介面的方便性可與Windows Forms比擬，而且對.NET程式設計師而言，操控Silverlight比起操控AIR來得輕鬆。而且最近的Silverlight Toolkit推出，證明了Silverlight在元件/控件上的架構，足以讓許多3rd Party廠商生產出很多簡單易用的控件。

阿舍

如果用 OpenID ，當你瀏覽的網站有支援 OpenID 的話，那你就不必再產生一組帳號密碼，直接用你的 OpenID 進行驗證登入。

OpenID 有幾個主要的角色：分別為 Provider, Consumer, 及 Server。

OpenID 的運作模式如下：

假設今天網站A是一個支援 OpenID 驗證的網站，那麼網站A算是一個「OpenID consumer」；而 Yahoo! 的帳號可以生成一個 OpenID，使用者可以拿著這個生成的 OpenID 到 OpenID consumer 去作驗證登入的動作，這樣 Yahoo! 就算是一個「OpenID provider」；但對 consumer 來說，使用者輸入的 OpenID 不一定長成什麼樣子（往往是 URL 形式），更沒辦法單靠這個字串判斷要把使用者導向何處（理論上是 provider 的登入畫面）作帳號密碼的驗證動作，所以 consumer 必須透過某個協定向「Server 」來問這樣的 OpenID 是否合法，以及要導向的網址。

像一個知名的圖片分享網站 — Zooomr 就是一個支援 OpenID 的網站（當然就是 consumer），當你試圖要登入 Zooomr 時，可以選擇以 OpenID 的方式登入，這時 Zooomr 會把你導向你的 OpenID provider 去作驗證（帳號密碼的輸入動作），如果驗證成功，那 Zooomr 就會信任這個驗證，開始讓你使用 Zooomr 的服務。

當然，即便 OpenID provider 愈來愈多，它們的會員帳號都成為 OpenID，但並不代表這些 OpenID 是相同的，簡而言之，由不同 provider 提供的 OpenID 就會被視為不同的 id，只不過它們有遵循 OpenID 的規格而已。但是對 consumer 而言，只要是遵守 OpenID 規格的 id 都可以進行驗證。