网站内容管理系统后台 设计(内容管理系统被分离成以下几个优先考虑的需求)

　　网站内容管理系统后台 设计(内容管理系统被分离成以下几个优先考虑的需求)

　　内容管理系统是一个很宽泛的概念：从商业门户网站的新闻系统到个人Weblog都可以称为发布系统。

　　框架类型：它本身不收录任何应用实现，只提供底层框架。具体应用需要一定的二次开发，如Cocoon、Vignette；

　　应用类型：是一种特定类型的应用实现，已经收录了一些子系统，如新闻/评论管理、投票、论坛、WIKI等。例如：postNuke xoops 等；

　　但无论如何，在发布系统选型之前，最重要的是先了解自己的实际需求：在现有系统的基础上复制自己的需求是非常不可取的。访问、权限控制和各种功能需求。各个模块和功能稍微清晰一点后，去网上找类似的实现：你会发现各个环节都有比较成熟的实现，而且还在完善和发展中。如果不是：你的需求过于具体，或者你可以尝试将其分解为更小的系统组合实现。

　　内容管理系统分为以下几层：每一层优先考虑不同的需求

　　1、后台业务子系统管理（管理优先级：内容管理）：新闻录入系统、BBS论坛子系统、全文检索子系统等，方便管理者的不同系统的内容录入：所见即所得编辑管理界面，等，清晰的业务逻辑：各个子系统的权限控制机制等；

　　2、门户系统（性能优先：模板管理）：大部分最终输出页面：网站首页、子频道/专题页、新闻详情页一般是各种后台子系统模块的各种组合，这个发布组合逻辑非常丰富，Portal系统负责上述后台子系统的组合性能管理；

　　3、前端发布（效率优先：发布管理）：终端用户缓存发布、搜索引擎蜘蛛的URL设计等……

　　内容管理与呈现分离：很多成套的cms系统并没有将各种后台子系统从Portal中分离出来，使得Portal层的模板呈现管理和新闻子系统的内容管理逻辑混在一起。甚至BBS等子系统的管理也是高度耦合的，整个系统会显得非常复杂。而且这种系统的各个子系统都比较死板，因此后台的模块很难更换。但是，如果把后台各个子系统的内容管理逻辑和前台的性能/发布分开，Portal和后台各个子系统的关系就只是数据传递关系：

　　内容管理和数据分发分离：在设计Portal系统时，注意缓存友好设计：cms后台管理和发布机制，不要过多考虑“效率”本身，只要最终页面输出设计是可缓存的，效率问题可以通过更前端的专用缓存服务器来解决。

　　此外，除了终端浏览器用户外，我们还应该注意对搜索引擎友好的 URL 的设计：通过 URL REWRITE 重定向或基于 PATH_INFO 的参数解析，动态网页更像是静态形式的链接（URI ) 便于搜索引擎收录 搜索网站内容的目录结构。