2012年7月26日

[.Net] Gotcha: Don't use <xhtmlConformance mode="Legacy"/> if you want to cross browser

好吧,我承認,這標題是學 Gotcha: Don't use <xhtmlConformance mode="Legacy"/> with ASP.NET AJAX 的。

不過情況有些不一樣,最近接手一個舊的 ASP.NET 網站,
雖然是 .Net Framework 2.0 的網站,但骨子裡其實是從 .Net Framework 1.1 升級的,
我們的需求不多,只要可以和時下流行的 Browser 相容就好,
也不打算引入 ASP.NET AJAX,
於是著手開始調整相容性相關的程式寫法,
調整得差不多後,開始測試,
沒想到一開始就遇到 Validator 不能正常執行的情況,
追了一下發現一個很特別的現象,

造成 Validator 不正常的問題出在 Asp.Net 的 ValidatorOnLoad 中,
會直接用 DOMObject.Attribute 去取值(如下程式碼片段),
但這在其他 IE 以外的瀏覽器是不允許的(IE9標準模式也不允許)!
function ValidatorOnLoad() {
if (typeof(Page_Validators) == "undefined")
return;
var i, val;
for (i = 0; i < Page_Validators.length; i++) {
val = Page_Validators[i];
if (typeof(val.evaluationfunction) == "string") {
eval("val.evaluationfunction = " + val.evaluationfunction + ";");
} // 略 .....
正確的作法應該要用 getAttribute('name') 才對,
但這不能解釋為什麼相同的程式碼在 .Net Framework 2.0 卻能正常的運作,
我用 evaluationfunction 這個關鍵字找了半天,
完全沒有找到相關的說明,
後來拿一個運作正常的網站所產生的 HTML 來和有問題的比較,
發現:

一般正常的應該要長得像這樣:

但他卻長成這樣:

到這裡,情況已經很明朗了,應該有什麼特別的設定,造成這樣的差異,
於是我改用別的關鍵字搜尋
.Net 1.0 and 2.0 hybrid validator not work
終於勉強找到了
Why might ASP.NET be putting JavaScript in HTML Comment blocks, not CDATA?
裡面提到了關鍵字 <xhtmlConformance mode="Transitional" />
再用 xhtmlConformance 就找到了 Gotcha: Don't use <xhtmlConformance mode="Legacy"/> with ASP.NET AJAX
原來,如果 xhtmlConformance mode="Legacy" 時,
不會處理那些不是標準 XHTML 的屬性,
反之,則會多產生一段 Javascript 把擴充屬性"塞"給 DOM Object ,
確保在不同的瀏覽器下都能夠用 DOMObject.attribute 的方式取到資料。

參考資料:
1. Why might ASP.NET be putting JavaScript in HTML Comment blocks, not CDATA?
2. Gotcha: Don't use <xhtmlConformance mode="Legacy"/> with ASP.NET AJAX
3. xhtmlConformance 項目 (ASP.NET 設定結構描述)
4. KB-由ASP.NET 1.1昇級的網站無法啟用MS AJAX


2012年7月25日

[Software] 分享一個好用的 link file 建立工具

以往傳統 Windows 的使用者,通常只知道所謂的捷徑(而且被捷徑制約很深),
Windows 的捷徑,只是一個文件,描述實際檔案路徑的位置,
透過程式(如Explorer)讀取捷徑文件的內容,再轉譯成實際檔案路徑,
因此,如果程式不是透過 Windows 的機制開啟捷徑所指的檔案,
那開起來的就會是捷徑本身。

Link file 這個概念,有點類似別名,
就好像我們知道 "第三者"、"小三" 指的都是同一件事情,
我們也可以把他想成是捷徑的進階版,而這個進階版,
則是需要作業系統及檔案系統都支持才能達成的,

所謂的檔案系統,就是我們資料儲存在儲存裝置上的方式,
常有人以為,儲存裝置(如硬碟)就像抽屜一樣,把文件通通都疊在裡面,
其實不然,當我們儲存一份文件到硬碟的時候,
作業系統會在一個類似書的目錄頁中,
建立一個索引,指向實際檔案內容的位置,
當我們在列出檔案清單的時候,並不是像在抽屜中一疊一疊的翻找,
而是將建立在目錄頁中的內容列出來,
當我們要開啟某份文件的時候,作業系統才透過該索引取得實際的檔案內容,

符號連結的概念,就是製作一個符號,指向檔案系統建立的目錄頁中的檔案,
而這個符號看起來就像真的指向實際檔案內容一樣,
所以就算一般程式在開啟這個符號連結的時候,
也不用考慮他是不是捷徑,需不需要額外處理,因為他們指的是同一件事情,
概念就介紹到這裡,至於 Symbolic link 、 Hard link 、 Junction 有什麼不同,
有興趣的話可以到以下網站參考
http://en.wikipedia.org/wiki/Hard_link
http://linux.vbird.org/linux_basic/0230filesystem/0230filesystem.php
http://en.wikipedia.org/wiki/NTFS_symbolic_link
http://webcache.googleusercontent.com/search?q=cache:2FHejrp9CZAJ:blog.miniasp.com/post/2011/09/17/How-to-create-NTFS-Reparse-Points-Symbolic-and-Hard-Links.aspx+&cd=2&hl=zh-TW&ct=clnk&lr=lang_zh-TW
http://jdev.tw/blog/729/vista-soft-and-hard-link

現在 Windows 7 之後的版本,提供了 mklink 的指令,
方便我們建立符號連結,但還是不夠直覺,
於是我找到了 Link Shell Extension
他的操作方式很簡單,

首先在 "來源的檔案或目錄" 上按右鍵(如下圖),選擇 Pick Link Source。



接下來在 "目的位置" 按右鍵(如下圖),選擇 Drop As... --> Hardlink(同一磁碟機才會出現) 或 Symbolic Link。

完成後結果如下圖:
選擇 Symbolic link 時,會出現綠色的捷徑符號,佔用的檔案大小為 0 ,
現在這個檔案就代表他的來源檔案,對一般應用程式而言,他們是沒有差別的!

選擇了 Hardlink 的話,來源及目的的檔案都會出現紅色的捷徑符號,
檔案大小也會一樣,但實際只佔一份檔案的硬碟空間,
Hardlink 和捷徑的概念不同,刪掉來源檔案,並不能真正將檔案從磁碟機中刪除,
要把所有 Hardlink 到這份檔案的連結都刪光才會真正的把空間釋放出來。


Link Shell Extension 讓我們就像 Windows 操作檔案的習慣一樣,操作 link file,是一個相當實用的工具,想瞭解更多也可以到 Link Shell Extension 網站上看個明白。