如何解决小网站内容管理问题

2019-03-27  本文已影响0人  王昌彬

文章篇幅较长，慎入

随着网络应用的丰富和发展，网站往往不能迅速跟进大量信息衍生及业务模式变革的脚步，常常需要花费许多时间、人力和物力来处理信息更新和维护工作。 ——引自「百科」

小公司、小网站因人员、技术问题，在内容管理处理上处于「食之无味弃之可惜」的一种情况：内容维护会经常打乱开发人员节奏，但是又没有精力去思考投入统一去解决类似问题。

有哪些运营内容需要维护

开始之前，我们先看下小网站一般会存在哪些内容需要维护配置：

现状

遇到这些内容维护，好的小公司可能会一开始就同步建立一个配置发布管理功能，其他的可能因为工期赶就代码写死，通过发布解决，发布频繁了才去做配置发布管理功能。

作为一个有追求的攻城狮，这样的重复性工作应该主动拒绝，通过工具或者流程去改善生活

CMS是什么

在很早以前，内容管理就成为一个重要的应用领域，并且伴随着时间、技术的推移，CMS的功能也变得越来越强大。

CMS简单来说就是内容管理系统（Content Management System），主要解决用户网站建设与信息发布中常见的问题和需求，运营同学可以通过它进行网站内容新增、修改、审核发布，提高信息发布效率和准确性；其技术核心思想是分离内容的管理和设计。

业界CMS系统

篇幅原因，这里并不想去对比和介绍业界相关的系统，只是想大概介绍下相关类型

从小公司的诉求和运营的专业水平来看，类似云凤蝶这样的基于组件化搭建页面的CMS平台，其操作成本高，另外组件开发、维护成本也很高，小公司也很难有业务发展需求，可以沉淀出自己的组件模块。所以除非一开始就不打算投入网站服务建设，只是简单得搭个网站门面，才会使用类似可视化建站服务。

下面的篇幅我们还是以实现「传统CMS系统」为目标，去考虑如何做得更好

诉求

那么小网站对内容管理又有哪些诉求呢？

  • 上篇文章提到的jsonschema-form-vue - 自动生成表单库，就能快速生成体验一致的表单；
  • 通过抽象将内容表设计成一套统一结构，一方面避免每种配置都建表，另一方面也容易提供统一API；
  • 关于正确性保障，可以通过 预览 -> 审核发布流程 提前保障；

不过虽然保证了内容配置管理，但是文章一开始提到的「新闻公共」、「帮助」、「关于我们」这些内容相似、字段一致的页面，难道每次都要创建类似的配置管理，然后在web应用创建相关页面，再发布应用吗？

  • 需要提供一套页面模板机制，通过复制页面模板，快速复制同类型页面以及跟它关联的内容配置；通过这种关联关系，应用只要通过路由pageId去查询页面相关的内容，即可避免发布

目标

基于诉求，先明确解决小网站内容管理需要完成的目标

分层关系和表设计

通过内容，对数据模型进行抽象，主要分成以下三层：


cms-guanxi.png

组件

最底层组件，它包含了基于 jsonschema-form-vue的表单相关配置，可以使用版本管理，让配置升级更安全。

{
    id: Schema.Types.ObjectId,
    name: String, // 配置名称
    version: String, // 版本号
    jsonSchema: String, // JSONSchema
    definition: String, // Form Definition
    histories: Array, // 历史记录
    author: String, // 用户
    createdAt: Date, // 创建时间
    modifiedAt: Date // 修改时间
}

模块

模块是运营内容编辑单元，基于组件表单配置去生成表单，可以保存草稿和发布数据，用于预览和线上内容

{
    id: Schema.Types.ObjectId,
    name: String, // 模块名称
    title: String, // 模块标题
    siteId: Schema.Types.ObjectId, // 所属站点ID
    pageId: Schema.Types.ObjectId, // 页面ID
    componentId: Schema.Types.ObjectId, // 组件ID
    componentVersion: String, // 组件版本号
    model: {}, // 配置数据
    draft: {}, // 配置草稿
    status: Number, // 状态 0: 配置更新, 1: 内容更新, 2: 发布审核
    online: Boolean,
    histories: Array, // 历史记录
    author: String, // 用户
    createdAt: Date, // 创建时间
    modifiedAt: Date // 修改时间
}

为什么不把表单配置直接放模块，而是增加组件这一层？ 这主要是因为模块和组件是「多对一」的关系，一个表单配置可能会被用到多个模块；另外上面提到的相似页面，会复制出相似模块，如果将表单配置放在模块表中，会存在重复数据，后续也很难同步配置升级

页面

页面就是浏览器中看到页面，主要用来保存模块的关联关系，一个页面可能存在多个独立模块

{
    id: Schema.Types.ObjectId,
    name: String, // 页面名称
    url: String, // 页面url
    realUrl: String, // 页面实际url
    useRoute: Boolean, // 是否启用路由规则
    router: String, // 路由规则
    siteId: Schema.Types.ObjectId, // 所属站点ID
    modules: String, // 模块
    owner: String, // 用户
    createdAt: Date, // 创建时间
    modifiedAt: Date // 修改时间
}

为什么有url又有实际url？这主要考虑后面的「可视化编辑」功能，需要去请求真实页面，所以在页面复制发布时，需要基于「页面路由」生成实际url

因为数据模型的核心是配置和内容，所以选用了文档型数据库MongoDB

整体设计

抽象了数据模型，先通过设计看下CMS需要提供哪些功能

cms-jiagou.png

设计上，CMS遵循以下几点原则：

所以：

Web应用接入只要改动以下几点：

流程

通过流程可以更清楚了解CMS的功能

cms-process.png
  1. 创建组件配置
    前端在本地开发完静态页面后，先mock内容，完成数据模板分离；然后可以借助JSON2JSONSchema工具快速生成JSONSchema结构，根据 jsonschema-form-vue文档，生成组件配置
cms-step1.png

  1. 创建内容模块，引用相应的组件配置（内容模块才是运营内容维护单元）；如果有初始数据，可以帮运营填入；复制moduleId到web应用中调用相应方法获取CMS数据；然后，发布web应用后，开发的工作就完成了，以后的内容维护都交由运营同学。

  2. 运营同学维护模块内容，有两种方式：
    3.1 通过模块名查找模块进行编辑
    3.2 通过页面编辑进行可视化编辑，见下面

  3. 内容编辑确认无误后，进行保存预览

  4. 预览确认没有问题后，审核发布，内容上线

到这里，CMS最基本的功能已经完成了；再也不用因为文案内容改动，需要进行应用发布重启了

MORE

接下来的篇幅最后介绍「页面复制」和「可视化编辑」功能

关于页面复制

上文提到的新闻公告、关于我们，或者一些风格类似的活动页面，需要提供快捷复制创建新页面，然后修改页面内容即可。

主要思考如下：

可视化编辑

最后必须来点看起来科技感满满的功能来个收尾，以提供该CMS系统的档次，直接跟前沿接轨。

在具备了模块编辑功能后，可视化编辑就是如何获取编辑的数据并实时渲染页面预览，同时预览页面可识别可编辑模块，并表现出自己能被编辑，引起运营点击修改的欲望：

就这样，马上提供一个档次

到这里，文章就结束了，在工作过程中，多去发现工作流程中，重复性的、自己不喜欢去处理但又不得不去处理的活儿，去思考如何通过工具、流程化去处理它们；让事情变得简单、可复制；这个思考和实现的过程，不仅能提升你的设计和技术能力，同时也能增加公司对你的依赖性，走向升职加薪的路上。

上一篇 下一篇

猜你喜欢

热点阅读