create_function 匿名函數

在 PHP 中的函數只要宣告後就是全域的，而且還不能修改，不小心就會撞名，真是麻煩的事，而且實體宣告在當做變數傳遞時非常麻煩，最近習慣 JavaScript 的函數傳遞方法，為了達到這個作法，PHP 中有一個匿名函數的宣告方法，會直接已變數的形式呈現，可惜的事在宣告上必須用字串編寫，也是很麻煩，但總比沒有好。

<?php
    $newfunc = create_function('$a,$b', 'return $a + $b');
    echo $newfunc(2,5);

參考來源：PHP Manual

利用 JavaScript 讓 IE6 支援 CSS 2.0 hover 的方法

利用 IE6 特有的 expression 屬性質，去執行 JavaScript 程式。
好處是可以簡化開發，讓設計師可以自己去控制想要的樣式。
壞處是執行大量的 expression 會讓 IE6 很吃重。


ie_hover.htc 中的程式碼：

this.onmouseover=function(){
    if(!this.className.match(/(^|\s)hover(\s|$)/)){
        this.className=(this.className+' hover')
            .replace(/\s{2,}/g,' ')
            .replace(/^\s+|\s+$/g, '');
    }
}
this.onmouseout=function(){
    this.className=this.className
        .replace(/(^|\s)hover(\s|$)/,' ')
        .replace(/\s{2,}/g,' ')
        .replace(/^\s+|\s+$/g, '');
}
this.style.behavior=null;

ie_hover.html 中的 CSS：

p{
    padding-left:30px;
    behavior: url(ie_hover.htc);
}
p:hover,
p.hover{
    padding-left:0;
}

展示頁面(Demo Page)

CSS 三欄排版

1. float 排版
   
   這是在 Table 排版之後最常見的排版方式，利用 float 與 clear 的屬性設定去達成的分欄排版。
   
   最近發現除了利用 clear 屬性的空 Tag 以外還有其他的方式可以達到這個效果，在最外層的 div 上加入以下屬性也可以達到相同的效果：
   

   * html #demo_1{
       height: 1%;
   }
   #demo_1:after {
       content: ".";
       display: block;
       height: 0;
       clear: both;
       visibility: hidden;
   }
   #demo_1 {
       zoom: 1;
   }
   

   
   
   
2. table 排版
   
   這是最早期排版方式，雖然有種種的缺點，但還是有很多網站使用，除了利用原有的 Table Tag，也可以使用其他 Tag 設定 display 屬性去達到 Table 排版的效果，雖然在寬度的定義上的彈性，但還是建議保持只有一個欄位的彈性寬度，過多的彈性寬度只會造成意想不到的後果。
   
   
   
3. margin and float 排版
   
   這是利用中欄的 margin 屬性空出側欄位空間，再利用 float 及負邊界方式去達成的三欄排版，因為 float 屬性不會對整體高度做出貢獻，如果需要側欄的高度影響，必須上擁有 clear 屬性的 Tag 或利用第一個範例的方法，由於中欄沒有 float 屬性所以不能在內容使用 clear 屬性。
   
   
   
4. margin and position排版
   
   這是利用中欄的 margin 屬性空出側欄位空間，再利用 position 的定位方式去達成的三欄排版，因為 position 屬性不像 float 屬性，可以利用 clear 屬性做出高度的貢獻，所以側欄的高度不可以大於主欄，要不然會造成顯示重疊。
   
   
   
5. padding and float排版
   
   這是結合 (float 排版) 及 (margin and float 排版) 的排版方式，主要是解決 (margin and float 排版) 的主欄中不可以使用 clear 屬性的問題，CSS 的差別只在於利用外匡的 padding 屬性去做預留空間的設定。

優劣差異：

	float	table	margin float	margin position	padding float
靈活性	高	低	高	高	高
親和力	高	低	高	高	高
HTML 結構	簡單	複雜	簡單	簡單	簡單
寬度彈性	no	yes	yes	yes	yes
允許彈性的欄位數	0	all	1	1	1
overflow 容錯	低	高	低	高	低
瀏覽器的解析差異	小		小	小	小
欄位的高度影響	all	all	all	1	all

展示頁面(Demo Page)

Ajax 模組架構的應用

一樣的就之前所提到的問題(Ajax 開發所產生的問題)，這是另一種以模組架構為基礎的方法，模組開發的好處我就不多作說明了，主要的行為模式是：

1. 在請求 Page 時就先將 Module Include，讓頁面再第一次讀取時就可以完整呈現。
2. 在頁面需要執行局部置換時，再利用 Ajax 向 Module 請求局部內容。
   

這樣做既不會失去模組開發的優點，也不會有 Ajax 造成的過長等待，讓 Ajax 主要應用在局部置換及 UI 處理。

利用屏壁來延長頁面的呈現時間

就之前提到的問題(Ajax 開發所產生的問題)，這很可能連帶出現以下問題：

1. 瀏覽者再頁面尚未完整呈現時誤觸連結，造成錯誤操作。
2. 功能的初始未完成，瀏覽者再使用上出現無法動作的錯愕情形。

這些問題可以用一個有效的方法去延長瀏覽者的等待時間，在一開始的頁面裡預設疊上一個遮蓋整個頁面的等待圖示，在 JavaScript 處理完後再移出屏壁，一個很好的範例就是 Gmail，再一個主要的頁面呈現前，置入一個等待圖示去避免一些可能的不當操作。

順帶一提，Gmail 利用 ifreme 去做出局部置換的效果，這樣做的好處是，瀏覽器會自動去紀錄上下頁，在 Ajax 的應用上瀏覽紀錄這件事是必須額外處理的。

利用 Ajax 減少 Server 運算量

在 Ajax 還沒有出現時 JavaScript 本身就可以執行許多計算方面的程式了，像之前的文章『HTML 比較(diff)』、『數獨（sudoku）解題』、『線性代數-計算機』等都是利用 JavaScript 去達成的計算程式，象 Yahoo 也有在 Login 時利用 JavaScript 做 md5 的計算，其實瀏覽器還是可以做一些有規模的運算。



主要是將運算資料取回，計算結果明細後，再跟 Server 取得剩餘的詳細資料，這個架構可以讓 Server 原本的運算量轉由瀏覽器執行，是一個以空間換時間的作法，當然有一好沒兩好，沒錯這樣的方法明顯會發生之前所說的問題(Ajax 開發所產生的問題)，是否要用這個方法就看各位的考量了。

其中特別要注意的一些事項：

1. 再資訊必須是即時性，且運算量大於一定時間以上時，考慮這種架構才會有意義，要不然只會浪費頻寬。
2. 資料安全性問題，必須定義哪些瀏覽者可以取得計算資料，要不然會造成嚴重的漏洞。
3. 資料量的大小，太大的資料可能會造成瀏覽器整個當掉，再規劃時要特別注意最大上限，至於詳細的範圍要依瀏覽者的設備而定。

利用 Plugin 的架構做模組應用

這是我很久之前在開發所有的類別架構，主要是以 MoreModile 類別為主作延伸應用，這個繼承方式並不是一個很好架構，因為 Base 的 MoreModile 常常會有異動的可能，而且子類別也不是完全以父類別為基礎，有時候只需要部份的成員函數，這樣的架構在之前的開發上變得綁手綁腳，怕改錯一個東西造成其他的類別也受到牽連。


後來想到這樣的開發架構，由一個主要的 DataLoad 類別負責整體的處理，再選擇需要 Plugin 那些 Module，這個方法讓架構變得更有彈性，且整體的牽連性也不至於像之前那麼嚴重，而且還有預留一個 Plugin 的虛擬類別，提供額外的修改空間，再實行的過程中也明顯的加快日後的開發速度。


這是目前的類別架構圖，每一個新類別都可以選擇所需的 Module，或者實作一個特定需求的虛擬類別，讓基礎類別有更多的應用，且實作上也具有很高的彈性。
這樣的架構並不是一個標準的類別繼承架構，正常來說應該利用成員物件的方式去執行 Plugin 這樣的架構，但可惡的是 JavaScript 有一個麻煩的事件問題，物件再做事件整合上其實並不是那麼快樂，常常會因為參數的傳遞及 this 的處理造成不少困境，所以使用標準架構只會讓開發更複雜。

CSS 與 HTML 規劃心得檢討

由於所開發的系統愈來愈大，免不了開始出現一些排版上的問題，對於目前的狀況做了一些整理：

每加入一個新功能就建立一個新樣式，造成過多獨立應用的樣式。

再新功能規劃時，可多考慮使用舊有的樣式。

HTML 在的設計上過於精簡缺乏彈性及流通性。

在結構上的規劃時多考慮多變應用以增加日後應用上的彈性。

類似的樣式過多沒有統一的規劃。

再設計多預想未來的應用，增加樣式重複利用的可能性。

過度使用已 Tag 為主的選擇器，造成過度的樣式覆寫。

在較複雜的樣式區塊中，先做分割規劃出許多小區塊，簡化樣式選擇器的深度。

ID 與 Class 命名沒有規範清楚，造成樣式與功能上的混淆。

排版與樣式沒有分離，造成管理不易。

對於排版的寬度定義不明確，造成異常 overflow 跑版。

主要的問題還是出在一致性的樣式共用與命名規則的問題上，在開發的過程中沒有謹慎規劃，對於未來可能的應用也許要考慮進去，避免重複定義相似的樣式。