作為CMS，最需要做到地是把程序和數據展示分離出來，讓用戶不需要了解太多程序的程序即可很方便的使用來搭建合種個性化站點，而標簽的靈活性，很大程度上決定了CMS的好用與不好用，而標簽的好用不好用，除了處決于標簽本身在細節上做的細致程度(如詳細的幫助文檔、簡單的標簽生成方式等)決定外，整個標簽體系的設計思路更起到決定作用。

本文中落葉對PHPCMS、DEDECMS及帝國CMS的標簽的設計思路與解析方式作一些簡要的對比分析。

現在主流的PHP程序實現數據處理與數據展示的分離，都會使用第三方的或者自己開發的模板引擎，一般的模板引擎中除了支持特定格式的數據變量標簽展示外，還支持數組循環、邏輯判斷、函數處理、文件包含、PHP原生語法等。

一般的模板引擎的處理思路時各種以HTML文本的方式存儲(有的是.html的擴展名，有的是.tpl的擴展名)，然后模板引擎會對模板中的標簽或代碼進行編譯預處理成PHP文件緩存到特定目錄，處理成的PHP文件里面不再是標簽格式，而是標簽被處理后可直接執行的對應的PHP語句塊。然后在PHP 控制文件中處理好數據后，使用模板調用函數調用編譯好的PHP文件形式的緩存模板(當然，過程中會有判斷，如果緩存不存在，則直接從原模板文件編譯一次生成緩存后調用)，直接整合到PHP控制文件中一起執行。

如果是生成靜態，則是先處理好數據后，引用編譯好的模板文件，執行，輸入后緩存區，后面再寫入生成HTML文件。

早期的ASP類風格的CMS設計沒有系統化的模板引擎，而是采用單一替換的模式，即先讀入模板文件，然后替換模板文件中標簽，每一個標簽都是單獨處理替換。

PHPCMS和DEDECMS中模板的處理方式為通用的模板引擎處理方式，而帝國CMS的模板處理方式為早期的ASP類風格CMS的處理方式。

1. PHPCMS標簽的解析方式：

PHPCMS標簽形式主要有TAG標簽和GET標簽，靜態HTML模板在編譯過程中會經過模板引擎統一進行正則替換并轉化為對應的PHP函數塊。

如：{tag_標簽內容列表}，經模板引擎編譯處理后：

<?php echo tag('phpcms', 'tag_content', "SELECT a.contentid,a.catid,a.typeid,a.areaid,a.title,a.style,a.thumb,a.keywords,a.description,a.userid,a.updatetime,a.inputtime,a.url FROM `phpcms_content` a, `phpcms_content_position` p WHERE a.contentid=p.contentid AND p.posid=1 AND a.status=99 ORDER BY a.contentid DESC", 0, 5, array ( 'class' => 'url', 'target' => '_blank', 'titlelen' => '35',));?>

在控制PHP文件中使用模板引用函數引用模板時，該標簽即自動調用global.func.php文件中的tag函數執行得到文章列表結果后輸出。

又如GET標簽：調用最新10條文章標題的GET標簽

{get sql=" SELECT `title` FROM `phpcms_content` ORDER BY contentid DESC " rows="10"}

<li>{str_cut($r[title],20,’’)}</li>

{/get}

經PHPCMS模板引擎編譯解析后的PHP代碼塊：

<?php $DATA = get("SELECT `title` FROM `phpcms_content` ORDER BY contentid DESC", 10, 0, "", "");foreach($DATA AS $n => $r) { $n++;?>

<li>

<?php echo str_cut($r['title'],20,'');?>

</li>

<?php } unset($DATA); ?>

2. DEDECMS標簽的解析方式：

DEDECMS標簽的解析方式和PHPCMS類，經過DEDE模板引擎類的dedetag.class.php的編譯處理，標簽被處理成PHP代碼塊后緩存到data目錄的tplcache目錄。

如：分頁頁碼列表標簽{dede:pagelist listsize=‘5’ listitem=‘’/}經DEDE模板引擎編譯解析后和模板HTML一起緩存到緩存目錄的對應的PHP代碼塊為：

<?php

$atts = array();

$atts['tagname'] = 'pagelist';

$atts['listsize'] = '6';

echo $this->refObj->GetPageList($atts,$this->refObj,$fields);

?>

因為DEDE CMS模板引擎也是目前通用的模板引擎編譯解析方式，所以整個流程和PHPCMS類似。

3. 帝國CMS標簽處理方式：

據落葉的觀察，帝國CMS是沒有模板引擎這個概念的，每一個標簽的處理都是單獨用函數來替換。前一段時間，一位朋友希望在內容頁有多分頁的文章前面加上分頁小標題導航。當時，為了實現這個小小的功能，落葉仔細研究了下落葉的模板標簽解析功能，實際發現，帝國CMS在生成靜態時，是先將需要展示的數據處理好，甚至整合HTML文件然后單個替換模板中的標簽，每個標簽都單獨寫一個或幾個函數來處理，然后替換后生成靜態?；旧系蹏鳦MS中的標簽替換基本是白名單替換。結果是，即使自己想在內容頁增加一個簡單的自定義標簽，實現一些小的功能，都需要修改帝國的functions.php和 t_functions.php中的核心函數文件。

舉個帝國CMS處理標簽的簡單例子：

獲取面包屑導航的標簽的處理代碼如下：

$string=str_replace('[!--newsnav--]',$url,$string);

處理標題標簽的代碼如下：

$string=str_replace('[!--pagetitle--]',$title,$string);

一般如果按照模板引擎編譯解析的方式，會選將所有變量性質的標簽直接通過定界符判斷出是標簽，然后統一使用正則進行解析，而帝國的處理方式是一個個單獨處理，所以就出現像上面的那樣，$string為讀取出來的模板內容，然后一步一步逐一替換處理，典型的早期的動易、新云等ASP類CMS的標簽的處理方式。

不管帝國CMS這樣處理的執行效率高不高，至少二次開發的效率是很低的，每個頁面的標簽或者變量都要單獨去處理。如果是想在模板中增加一個自定義變量類的標簽，在PHPCMS中只需要在模板中{$自定義變量名}這樣即可，而帝國CMS中除了在模板中添加[!—自定義變量名--](如[!--pagedes--])外，不得不在生成靜態的處理函數中增加類似上面的標簽替換步驟，如：$string=str_replace('[!--pagedes--]',$pagedes,$string);

也許對于普通用戶而言，不論標簽的解析方式如何，只要把標簽做得細致，簡單好用，靈活， 就夠了，所以帝國CMS還是有比較多的忠實用戶的，很多人覺得很省心，不要考慮啥邏輯，按照說明，標簽放上去，就基本沒問題。而對于深度用戶，尤其是有編程基礎的用戶，喜歡DIY或者個性需求較多的，更習慣目前主流的模板引擎的編譯解析方式，不太喜歡封裝得很好的標簽，希望得到干凈的數據，可以直接在模板中進行邏輯處理，而標簽除了一部分是變量外，調用數據類標簽，實際是特定格式調用的系統函數。

至少落葉，偏向于喜歡PHPCMS和DEDECMS的標簽解析方式，而對帝國CMS的標簽處理方式比較糾結。

系列文章：

織夢、帝國及PHPCMS對比(1)：自定義模型功能分析

織夢、帝國及PHPCMS對比(2)：支持SQL調用的標簽

織夢、帝國及PHPCMS對比(3)：自定義URL規則

織夢、帝國及PHPCMS對比(4)：碎片功能分析

更多信息請查看IT技術專欄