#1 ltotal

之前一段时间基于SP框架弄了个模仿phpcms部分功能的cms，之后用这个cms做网站，但这过程中有一个比较大的疑问，就是cms是不是一般只针对有大体通用性的东西？譬如后台数据的CURD都可以用同一个Controller，同一个Action，只是栏目ID有别而已，前台的封面，列表和内容也是同一个Controller的两个Action而已，一个Action负责封面、栏目页的渲染，只要接受栏目ID就可以了，另一个Action负责内容页的渲染，除了栏目ID外还要接受一个具体内容的ID。而我的疑问是，要是这些过程中的某一些环节“个性化”一些的话，例如一个某种任务的列表，假如访问地址是/index.php?c=main&a=listed&cid=6，现要按任务的完成情况（对应某一数据库字段）进行列表显示，0：任务未开始；1：任务进行中；2：任务结束；表示3种任务状态，这显然要给上面写到的任务列表访问地址加一个参数识别，例如是/index.php?c=main&a=listed&cid=6&status=1，此时这个status参数的接受及处理过程该交给谁负责？如果交由列表页的输出负责动作listed的话，这串获取代码就只能针对这种情况的单一应用，其他栏目的显示都不需要，或者是其他栏目有其他的特殊情况等，这样到最后这个列表动作就会变得较为混乱了；而如果用$smarty.get交由视图接收，当接受参数不是最终目的获取参数时（假如需基于此参数进行一串运算等得出最终参数），作为主要负责输出的View就不好放这堆逻辑处理代码了。这时我只能在前台新建一个专项专用的控制器了，这时就跳出了cms规范的框框了，后台对应的也不需要把任务栏目归到cms内容发布上去了。应该如何规划这些特殊情况？还是这些本来就应该专门针对性开发的呢？太"个性化"的东西，即使有前台的封面列表内容，也不太适合放cms里发布？

2010-03-08 19:16:20

#2 jake

一般来说CMS有两种，一种是通用型的，一种是垂直型的。像PHPCMS那类的就是通用型的，而垂直型的就是针对某个行业或某个领域的，比如说医疗门户CMS、外贸企业类的CMS。

CMS有种叫“内容模型”的东西，它是针对某类型的内容呈现和需求的特殊性来界定它的作用和显示的，比如说dedecms有下载、图片展示、文章列表、甚至是互动的，比如会员中心、问答之类的的。这样cms的初步应用就如下了：

某网站 = 首页 + 图片展示频道 + 文章列表频道 + 文章列表频道 + 文章列表频道 。。。
某网站 = 首页 + 会员中心 + 问答 + 下载 。。。

这里说明一下，通用型CMS和垂直型的CMS不同就在于“内容模型的细分程度”，通用型的一般只分到某“类”功能（会员中心/问答）或是某个页面形式（图片/下载/文章）的，垂直型的会根据所在的行业和领域的需求分得更细，到了某“种”功能或是特殊页面，像医疗CMS，它会细分到医疗机构信息的医生模型、病历模型等等。

2010-03-09 10:15:45

#3 jake

这里还要说明一下SP框架的MVC架构：

model类库，主要还是针对数据的提供和处理，最理想的状况就是能够将一切的数据逻辑都放到model里面，但是model不负责显示任何东西，只能通过接口（函数的参数）来调用，这样的model有很大的好处，因为它们都可以重用（前后台共用，甚至是多系统共用），而且可以针对数据进行集中的优化，可以说model类库是整个应用系统里面最有价值的部分。

view层面（sp中是smarty），主要负责的页面的呈现，最理想的状况就是可以完全把view层的工作交给页面设计人员去做，view的分层主要就是为了把PHP和HTML分开，也是为了数据逻辑和页面呈现分开，这样的好处就是当两者有任何一方变动的时候，另一方都不需要做太大的修改。

controller层，负责交互，也就是用户“点击”、“提交”或者“访问”某个页面时，控制器都负责对它来进行“反映”。一个完整的MVC过程就是：用户点击某个链接 --》 触发某控制器 --》 控制器通过某model的接口存入数据并获取返回的数据 --》 控制器将model处理好的数据传送到view --》 view层把数据显示出来。

2010-03-09 10:15:53

#4 jake

然后结合到CMS来说：

一个“内容模型”，它对应的应该就有MVC的三者在里面了。比如说图片频道模型，那么在V层，它的呈现可以是幻灯片或者是相册，这是最容易理解的。然后是C层，就是考虑在这个图片频道里面，人们会点击那些东西，也就是会进行什么样子的操作，这些都是controller/action。最后是M层，负责数据逻辑的处理，一般而言，我觉得文章/图片/下载这几样模型在数据上都有一些共同点，但是也会有一些不同点，那么M层的逻辑处理，设计上要将这些共同点归纳起来（方便管理和重用、优化），各个“内容模型”自己的不同点就靠各自的M层去处理。

在这些“内容模型”之外，就还有一个大的架子，这个架子就是“如何组织这些内容模型”和“CMS后台管理”，组织页面比较容易，首页就是了。然后后台管理就是比较复杂的地方了，说复杂是要考虑它的用户体验，而不仅仅实现功能。要能够让用户不写一行代码也能做出一个网站来，这个后台还挺费思量的；不过后台的用户体验也是逐步完善的，呵呵。

2010-03-09 10:24:53

#5 ltotal

谢谢jake的详细解答! 我做的就是基于内容模型的, 现在思路清晰一点了, 谢谢:D

2010-03-09 14:22:52

#6 hjp1011

看了jake的回答,对speedPHP也有了新的理解.以前自己也写过一套CMS,现在打算用框架来重构,这段时间总在qeephp和speedphp之间选择,看了jake的贴子,感觉很对用户很热情很负责啊.决定用speed试试!

2010-03-15 14:45:35