整站
整站
整站,即CMS(Content Management System ),內容管理系統。內容管理系統是一個很泛的概念:從商業門戶網站的新聞系統到個人的Weblog都可以稱作發布系統。
整站,即內容管理系統是一個很泛的概念:從商業門戶網站的新聞系統到個人的Weblog都可以稱作發布系統。
內容管理系統一般分為兩類,框架型和應用型。
框架型:本身不包含任何應用實現,只是提供了底層框架,具體應用需要一定的二次開發,比如Cocoon,Vignette;
應用型:本身是一個面向具體類型的應用實現,已經包含了新聞/評論管理,投票,論壇,WIKI等一些子系統。比如:postNuke xoops等;
但無論如何,在發布系統選型之前,首先了解自己的實際需求是最重要的:想根據現成系統將自己的需求硬往上照搬是非常不可取的。訪問量,許可權控制和各種功能需求。每個模塊和功能自己都比較清晰一點以後,再去網上找找類似的實現:你會發現其實每個環節到目前上都有比較成熟的實現了,而且還在不斷完善和發展中,如果沒有:你的需求太特殊,或者可以嘗試分解成更小的系統組合實現。
內容管理系統被分離成以下幾個層面,各個層面優先考慮的需求不同。
後台業務子系統管理(管理優先:內容管理):
新聞錄入系統,BBS論罈子系統,全文檢索子系統等,針對不同系統的方便管理者的內容錄入:所見即所得的編輯管理界面等,清晰的業務邏輯:各種子系統的許可權控制機制等。
Portal系統(表現優先:模板管理):
大部分最終的輸出頁面:網站首頁,子頻道/專題頁,新聞詳情頁一般就是各種後檯子系統模塊的各種組合,這種發布組合邏輯是非常豐富的,Portal系統就是負責以上這些後檯子系統的組合表現管理。
前台發布(效率優先:發布管理):
面向最終用戶的緩存發布,和搜索引擎spider的URL設計等……
內容管理和表現的分離:
很多成套的CMS系統沒有把後台各種子系統和Portal分離開設計,以至於在Portal層的模板表現管理和新聞子系統的內容管理邏輯混合在一起,甚至和BBS等子系統的管理都耦合的非常高,整個系統會顯得非常龐雜。而且這樣的系統各個子系統捆綁的比較死,如果後台的模塊很難改變。但是如果把後台各種子系統內容管理邏輯和前台的表現/發布分離后,Portal和後台各個子系統之間只是數據傳遞的關係:Portal只決定後台各個子系統數據的取捨和表現,而後台的各個子系統也都非常容易插拔。
內容管理和數據分發的分離:
需要要Portal系統設計的時候注意可緩存性(Cache Friendly)性設計:CMS後台管理和發布機制,本身不要過多考慮“效率”問題,只要最終頁面輸出設計的比較Cacheable,效率問題可通過更前端專門的緩存伺服器解決。
此外,就是除了面向最終瀏覽器用戶外,還要注意麵向搜索引擎友好(Search engine Friendly)的URL設計:通過URL REWRITE轉向或基於PATH_INFO的參數解析使得動態網頁在鏈接(URI)形式上更像靜態的目錄結構,方便網站內容被搜索引擎收錄。