Odoo 14 CMS 网站开发

Odoo的前端架构主要设计针对三种用户场景：

• web client

私有 Web 应用, 用来查看与编辑 业务数据, 也就是通俗说的 中后台. 其属于 SPA 前端渲染 web 框架

• website

Odoo 的 公有 Web 应用, 它可以运行 非注册用户 浏览, 购物 等等, 可以理解成 CMS. 也即是 传统的 网站. 它同时支持 后端和前端渲染， 前端渲染并非是 SPA.

• point of sale

针对特定的 商业场景暂不讨论.

那么如果我们想基于 Odoo 的自定义业务模块来定制一个 CMS 网站,前后端 UI 框架就需要建立在webclient与website之上.

• CMS 网站

  Odoo website 有着Odoo独有的前端网站开发体系.

• Website Designer (Builder)

  Odoo 希望用户能通过 无代码/低代码 的方式建设一个网站, 它提供了设计器和丰富的静态区块模版, 例如走马灯, Cover, 广告, 图片, 文字, 视频, 图表等等.搭建一个静态网站只需要拖拉拽就能搞定.

• Snippets

  上面提到的 设计器 操作的目标就是 区块, 或者换句话说 被拖拽到页面上的内容, 就叫区块. 区块是组成页面的基本单元. 基于 Odoo 前端架构 我们能很轻松的创建一个自定义区块, 然后这些区块就和默认的区块一样可以被拖放到任何一个页面.

  你很容易想到这就意味着每一个区块都是自治的.

• CMS 业务模型管理中后台

• webclient

  除了网站之外中后台开发也涉及到前端开发. 一般而言, Odoo 后台的前端架构 主要是 基于三类定制化开发.

• Views

  视图可以说是 Odoo 前端架构里面最为复杂的部分, 默认的视图已经完全能满足大部分 业务模型的 渲染与交互需求. 但是 定制化一个自定义视图依然是可行的.

• Field Widget

  模型由字段组成, 如果说一个模型 所渲染的 UI 对应 一个 视图, 那么 一个模型字段 所渲染的 UI 则对应一个 Field Widget.

  自定义 Widget 远远比 自定义视图 更常见.

• Client Actions

  客户动作定制化并不常见, 我们暂不讨论.

因为我们采用website 架构来进行研发, 这有别于传统网站开发, 其静态还原的工作, 不适合在Odoo网站中开发, 所以我们将其放在独立静态网站工程中进行研发. (因为最小研发单位不再是 网页 而是区块, 我们需要先开发好区块的静态部分 然后再 迁移到 Odoo 工程中调试 动态的部分)

• parcel

  我们选择parcel作为静态网站还原研发的构建工具. 它相对于webpack更为轻量级

  proxy

  代理服务器引入方便做Mock数据

• bootstrap, jquery 与 keen2 或者 基于 bootstrap 的 定制主题

  odoo 前端架构的两个核心依赖是bootstrap 4.x与jquery 3.x. 为了避免造轮子, 我们可以选择bootstrap主题 例如keen2的来研发前端网站. 但是这里需要仔细考虑架构上的设计冲突. odoo 与 keen2 自身都对bootstrap 4.x做了定制化,所以我们选择用keen2的定制化bootstrap覆盖odoo定制化bootstrap. 建议先考虑样式覆盖, 相对而言这样的冲突更好解决. 至于主题自定义组件及其依赖JS建议选择性引入 逐步消除冲突.

• html/css 架构

  区块是模块化的, 所以即便是静态还原, 我们也需要引入模块化设计思想, 避免重复的编码. 我们选择了主流的SMACSS+OOCSS +BEM的混合方案来作为静态还原的架构基础. 限于篇幅我们不做展开, 会在单独的主题中分享.

• sass

  静态还原的核心是 HTML 与 CSS, 传统的 CSS 并不是模块化的, 而我们目标区块是模块化的, 所以引入 CSS 架构以及对应的模块化工具显得尤为必要. 我们选择 主流的SASS来编写模块化的CSS.

• live style guide

  在线样式指南并非必须, 通过实践反馈, 严格避免在 Odoo 工程内修改样式, 对于代码的后期方便维护起决定性的作用.

这种最佳实践方式让还原开发与功能开发分别在 2 个工程中独立进行. 做到了静态还原和功能开发分离. 这个设计思想源自单一职责原则, 很容易想象如果直接在 Odoo 工程中编写 CSS 无论是开发效率还是开发质量都会降低.