Bookmark and Share

Lee's 程序人生

HTML CSS Javascript XML AJAX ATLAS C# C++ 数据结构 软件工程 设计模式 asp.net Java 数字图象处理 Sql 数据库
  博客园  :: 首页  :: 新随笔  :: 联系 :: 管理

CMS模块化开发

Posted on 2008-02-07 01:33  analyzer  阅读(2541)  评论(2编辑  收藏  举报

CMS模块化开发 一

什么是CMSCMSContent Management System的缩写,意为“内容管理系统”。

CMS具有许多基于模板的优秀设计,可以加快网站开发的速度和减少开发的成本。

CMS的功能并不只限于文本处理,它也可以处理图片、Flash动画、声像流、图像甚至电子邮件档案。 CMS其实是一个很广泛的称呼,从一般的博客程序,新闻发布程序,到综合性的网站管理程序都可以被称为内容管理系统。

根据不同的需求,CMS有几种不同的分类方法。比如,根据应用层面的不同,可以被划分为:

重视后台管理的CMS
重视风格设计的CMS
重视前台发布的CMS

等等。就目前已经存在的各种CMS来说,最终界面上都是大同小异,但是在编程风格与管理方式上来讲却是相差万别。

CMS本身被设计出来的出发点来说,应该是方便一些对于各种网络编程语言并不是很熟悉的用户用一种比较简单的方式来管理自己的网站。这虽然是本身的出发点,但由于各个CMS系统的原创者们自己本身的背景与对“简单”这两个字的理解程度的不同,就造成了现在没有统一的标准群雄纷争的局面。

我们所熟悉的CMS系统应有的基本模块

在进行WEB系统开发中,最常用到的功能模块有以下几种:

下载管理(download)系统
文章管理(article)系统
图片管理(picture)系统

当然,另外仍然有许多业务模块在应用中得到广泛应用,比如 会员管理系统、权限管理系统等等,它们与基本模块相互协作,共同构成强大的CMS系统,这与本文所描述的系统开发思想并不冲突。而在模块的通用性及可扩展性上来讲,我们只择选一些具有广泛代表意义的来进行描述。

为什么使用模块化进行CMS系统的开发?

模块化开发的好处在于:

1.子系统无关性。
    我们这里所描述的子系统无关性指:在一个CMS系统中相应的子系统(相应模块)不进行相互制约与影响,这体现在当一个子系统(相应模块)崩溃时,不至于影响到其它模块的正常运行。

2.高效协同开发。
    团队开发过程中,由于子系统的无关性,每个团队小组或者团队成员负责自己的子系统开发,而无须关心其它子系统。达到高效分工协同开发的目的。

3.可扩展性。
    由核心系统统一管理,很轻松在原系统的基础上开发扩展模块及相应的插件,如 评论、留言板及添加子系统(功能模块)。

使用模块化开发的前提是,你必须有一个很好的前期规划,做好基本资源仓库的资料收集及搭建统一核心管理平台。

单一入口应用程序概述

为什么这里会讲到单一入口?这与我们的核心管理平台有很大的关系。我们需要一个统一、标准的核心管理平台来支撑整个系统平台的运作,这是模块化开发的基础。

什么是单一入口应用程序?

在解释什么是单一入口应用程序之前,我们先来看看传统的 web 应用程序。
list.php列表程序
view.php内容显示程序
这两个页面不但分别实现了两个功能,还成为了应用程序的两个入口。

所以单一入口的应用程序实际上就是说用一个文件处理所有的 HTTP 请求。例如不管是列表功能还是内容显示程序功能,都是从浏览器访问特定的文件。这个特定的文件就是这个应用程序的单一入口。

单一入口的处理方式:

当服务器收到一个http请求时,会解析此请求,并决定访问那个文件。如 www.demo.com/list.php 是请求服务器中的list.php程序来执行相应操作,并把结果返回给游览器。

现在我们看看通过单一入口程序的处理方式。 www.demo.com/?mod=article&file=list。不难发现,实际上默认执行文件(一般为index或者default)执行了二次整理解析,我们可能实现的程序如下:




其中 class.base.php文件可能有如下程序:
<?php

Class base
{

Var $mod;


Var $file;



Function get_module()


{


//get module

}

Functon get_file()
{

//get file

}

Function run()
{

Require_once($this->mod.$this->file);

}
}
?>

那么我们很可能将执行结果定位于 module/article/list.php,由list.php程序来进行相关操作。当然,对于一个安全、健壮的系统来说,上面的处理方式明显过于简单,我们只是以实例说明。
那么OK,同学们会说,单一入口,对我们有什么好处吗?

那么我们说一下其优势:
因为所有的执行操作都由一个文件去进行维护,进行管理,那么我们很轻易的对全局系统进行安全检测,核心类库的布署及相应的过滤。当我们添加一个模块时,我们仅仅需要在我们规划的相应目录下添加相应程序就OK

当然,它也是有一定缺点的,任何事物都是两面性的。你在使用单一入口时,你必须对整体框架有一个长期的规划,这点是需要技术和经验的积累才能完成的。你在后续的程序写作中添加一些东西到index.php文件中也未尝不可,但我并不建议在已存在的执行文件中添加或者删除(删除绝对不允许的)一些功能,这有可能会影响到或者改变我们系统设计之初的一些思想,甚至背离了我们的初衷。

模块化CMS结构应用


前者我们提到了在CMS开发过程中的一些基本模块,本文就以这些为例。

早在2005年四月份,笔者发布了 phpsohov1.0 ,这个系统原来的设想是设计一个强大的平台,通过单一入口,进行多个系统的聚合,但最后由于种种原因被遗弃了。这个系统应用了模块化及单一入口,大家可以到网上搜索一下源码。

OK,话转回来,我们开始详细讲述模块化CMS的设计应用。

在此文中,我们以应用视角分布讲解,着重讲以后台为主的CMS设计,因为前台的灵活多样性,我们可以有很多种方案去处理。

我们布署文件目录:




首先从后台的单一入口讲起。

在管理系统中,我们使用了单一入口的模式进行项目模块的管理,admin.php文件即是为此功能而产生的。

我们在admin.php文件中,对http请求执行了二次解析,在getAdminModuleJobFile 函数中,我们进行了模块定位工作。通过这个函数,我们可以很轻松的把类似于 http://www.demo.com/admin.php?mod=article&file=add定位于 /module/article/admin/add.php中,从而执行相应的操作。

当然,在此文件中,我们还执行了另一情况检查: admin.php?act=login 。这是一个例外,只有我们在执行loginlogout操作时,act才会存在。

Admin.php可能文件如下所示:



通过admin.php的描述,应该很轻松的了解我们这次设计的基本理念了。

/admin目录对于我们来说,仅仅是提供一个初始的平台界面,当然。Top页面对我们的整个管理系统来说是很重要的。目录结构如下:



我们通过index.php分别载入topleftright框体页面,index.php文件可能如下:



那么我们知道,此次系统的关键在于module目录中,此目录存放了我们所根据系统平台开发的相应模块。如下图:

我们以article模块进行实例操作。在article的模块目录下,我们做以下目录布署:



顾名思义,admin目录是此模块(article)模块的管理程序,此目录中文件的相应功能大家通过文件名就可以看得出来,不再一一进行解说。
Include目录主要为模块前台所需要的公共文集。

相对于比较陌生的是cp文件夹,那么这个文夹是干什么的呢?OK,让我们打开此文件夹,里面的文件可能如下:


里面只有四个文件,且这四个文件一一对应了模块根目录下的文件。

想明白这个文件目录的用处,还须从我们设计中心思想讲起。

比如说我们在一个CMS系统中需要这样一些频道:财经新闻、体育新闻、娱乐新闻等等。
不难发现,这些频道有一个共性:他们都属于文章系统的范畴,而不同的仅仅是他们的表现形式(前台模板)的差异。

那么我们有必要反复的进行书写相似或者说相同的代码吗?
有没有一种方案使我们能够很好的利用已有的资源进行循环利用呢?
答案是肯定的。于是,频道设计理念被我们引入到当前实例中来。

我们假设 channel-1 ~ 3同为文章模块(module/article)中的分支频道,那么,我们可以使用它的执行流程如下图所示:



cp/index.php文件中,我们执行以下程序:



我们引入了前台的全局文件 global.php,并且根据相应的一些参数得到了 $channeldir(频道所属目录),将系统执行解析程序定位在此module/article/index.php,其它类似,改变的只是定位的执行程序而已。


那么有一点我们可以确定,我们必须有一个channeldir 这个变量存在,而这个变量是通过URL剖析后得到的。
设计思想清晰了,我们制定这么一个流程出来,以应付我们的需求:










当然,我们这些模块是已经录入到数据库中的,比如我们可能存在着这么几个数据表:
注:表结构已经精简,只为描述思想而定,如果实际使用,请按相应系统设计需要改变。





我们已经了解了模块与频道之间的对应关系,接下来,一切都变得容易多了。

回过头来,看我们的后台文件操作流程:
我们的后台管理页面为框架结构,分为 topleftright三个框体。在top程序处理中,我们可以通过数据得到我们已经设定的频道(这里不是模块,而是频道)。模块并不能直接用来操作,而必须依赖于频道的基础上进行相应的操作。



上图中的的两个频道,分别隶属于 新闻模块、下载模块。如下图:





那么当我们点击 top中的Articles链接时,可能会给出这样的地址:
http://www.demo.com/admin.php?mod=article&file=left&channelid=int
现在很清晰了,系统二次解析后,执行的是 module/article/left.php,其中channelid参数为正整数。



现在回头看看我们的article/admin中的操作,left.php文件很忠实的没有做任何处理,只是列出了一些菜单列表,但它们有一个共同点,就是将 $channelid=int传递给了相应的操作程序。

点击添添加文章之后,链接指向了admin.php?channelid=int&mod=article&file=add,我们可以很清晰的看出来,由module/article/admin/add.php来执行指令的处理操作了。

add.php文件中,我们执行了如下操作:



由于图片大小所限,我略去了操作过程。

这里引入了global.php,此文件作用在于:

1.判断相应频道所属模块
2.得到相应频道目录
3.权限判断

如下图所示:



其它文件操作思路同上。

到此为止,后台的操作思路已经完成。其它模块类似,不一一说明。

待续...

关于作者:无喱头。七零后人,03年进入php大家庭。曾参与过北京法院网案件执行系统核心流程设计、河南八方电器有限公司B/S系统核心流程及上海骄阳网公会系统、上海理想动画有限公司B/S核心系统开发,现在理想动画有限公司任技术主管。
网站:www.phpsoho.com
MSNphpsoho@tom.com
转载请注明作者及出处(www.phpsoho.com)
我要啦免费统计