Wagtail 的设计理念(The Zen of Wagtail)

Wagtail 基于多年构建 Web 站点的经验，吸取工作中成功与失败经验，在简单、结构化以及灵活等特性中不断平衡。当前 Wagtail 已经能创建了 许多优秀站点，开发者在使用之前有必要了解 Wagtail 的设计理念。就像 “Python 之禅” 一样, Wagtail 的设计理念也是一套指导原则，无论是使用 Wagtail 构建 Web 站点，还是开发 Wagtail 自身。

Wagtail 不是一个开箱即用的 Web 站点系统

只使用 Wagtail 及网络上的相关插件并不能搭建起一个可商用的站点，Wagtail 是为网站开发者准备的平台，其基本理念是帮助开发者通过代码快速构建灵活、可交互、界面丰富多样的内容管理系统。

为不同的角色开发

虽然 Wagtail 可以用来构造一个个人的博客系统，但 Wagtail 设计网站时充分考虑了网站设计、编辑、管理及使用人员的不同角色。站在不同角度和操作步骤，Wagtail 都提供了相关的功能， 例如：内容作者或管理者需要通过管理界面对内容进行批量处理，开发或设计人员更聚焦在 Python, HTML 或 CSS 代码方面。 Wagtail 在界面提供了一些方便编辑的工具，比如可以通过拖动改变 显示顺序，但本质上 Wagtail 不是一个 UI 设计工具，它在方便开发人员和灵活编辑输入内容之间做了取舍，通过编辑、管理人员与开发人员的协作，让网站实现运营的总体成本代价最优。

在构建内容管理平台时，通常最容易犯的错误是把界面的布局、样式等让内容编辑人员和管理人员来做，这会让内容编辑人员不能专注内容的编辑，也给代码的开发者带来极高的设计复杂度。 好的内容管理系统并不一定为 CMS 用户提供功能强大复杂的工具，而是着重让系统各个角色分工明确，大家做自已擅长的事情。遵循这样的理念，内容编辑人员不用过于担心版本和样式的问题， 管理者可以把过于复杂的操作流程让开发人员用简单代码进行实现。

内容管理系统 CMS 应为内容编辑者将其思想保存到数据库中提供简单高效的工具

一个网站可能是提供关于汽车、宠物、食物等方面内容，这些领域的作者在网站内容管理上应该专注于将其思想及内容输出并保存到数据库中，而不是聚焦在网站的展示方面。他们贡献的内容在展示上会经常变化的， 会随网站风格而变化，或者在 PC 或手机上采用不同的展示效果。所在在网站设计过程中应该尽可能以原始的形态保存文字或图片内容，而展示的效果或方式由网站开发或设计者进行设计。 例如，一个文章的图片可以独立于文章文字进行定义和保存，在列表上显示缩略图，在文章中根据位置不同采用不同的效果; 同样图片在 PC、手机上不同的版式会使用不同的分辨率进行显示。 在系统改变样式时，应没有理由再要求内容编辑人员参与调整内容或样式工作。

当内容作者有一个 “我们想这句文字使用粉色的雅黑字体进行显示”，那么做为开发者需要问 “为什么需要这样，有什么特殊的意义嘛”？ 如果答案只是 “我感觉这样比较好”，则开发者应 说服作者放弃这样的想法，可以想像在整体版面采用蓝色的基调进行展示时，只有特定一小块使用粉色进行显示，会使页面变得非常的突兀。 但如果是 “我们需要创建一个幼儿专区”，则开发者应该协同作者开辟 一个专区，让总体显示的颜色更加丰富多彩，并有别于新闻等严肃的版面。

对于程序员来讲实现最好的用户交互界面是程序语言

众多内容管理系统会提供追求通用的模型定义及界面定义，来表明系统可以提供强大的自定义能力。例如:

这种想法听起来非常高大上，但在实际使用中有时确十分的鸡肋。多数的数据模型并不是简单的输入和展示，而是需要有针对性的业务逻辑，在这样的情况下，业务模型由最终用户定义， 而业务逻辑实现由设计人员完成，会设计人员失去开发根基。试想开发设人员将代码编写、测试完成进行部署时，用户将数据模型进行了变更，能出现的错误完全超出了开发人员的预期。

Wagtail 认识到了这样问题，理解哪些是编程容易实现的，哪些是可以让编辑人员进行调整和配置的。例如 Wagtail 提供了表单构造工具让内容作者输入内容或采集用户信息，表单 可以直接使用，也可以做为复杂的系统如CRM或支付系统的一部分使用。但做为数据录入表单，录入字段及字段可选项的种类是受开发人员设计限定的，这样就最大限度保证数据输入的规范性和一致性。 Wagtail 系统为了方便开发人员的开发，基于 Django 的表单架构让开发人员无需编写过多的代码就能生成表单的录入和校验系统，最简单的情况下，只需在模型中定义字段更新数据库， 并将字段加入 panels 列表中，就能实现在后台管理界面录入数据的需求，而在编程实现方面只需要编写 3、4 行代码，执行两条命令。