Odoo 14 CMS 网站开发

版权声明:本文由神州数码云基地团队整理撰写，若转载请注明出处。

Odoo 前端架构概述

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

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

前端网站 HTML/CSS 架构

因为我们采用 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 无论是开发效率还是开发质量都会降低.

前端网站 JS 架构

前端网站的架构 完全基于 Odoo JS 框架进行研发. 涉及到 Odoo 的资源管理, 模块系统, 类系统, Widgets, QWeb 模版, 事件系统, 注册系统, 服务调用, 通知系统, 网站会话 等等. 在 这些 Odoo JS 框架的基础之上 我们设计了一个小型的 JS 框架来实现前端网站的主要功能.

• 区块

区块的职责是获取业务模型数据以及渲染, 每个区块的开发人员只需要关注这两件事件的实现.

区块是 网站 核心单位, 每个区块都是 自治 的. 这样的设计建立在 Odoo 网站开发的 Snippet 基础之上, 但是区块的拆分 依然和 该 网站 灵活的权限控制 密不可分, 换句话来说 权限控制的需求 决定了 以 区块 作为一个个 研发单位. 而不是页面.

• 区块的基类

区块的权限控制 对于每个区块来说都是一致的, 除此之外, 数据获取, 数据标准化, XHR 请求的逻辑我们都放在 每个区块的 父类来处理, 避免代码的重复.

• 权限模块

• 权限模块负责根据当前登录用户获取权限配置信息

• 控制 区块 的可见性以及是否能够发送请求获取数据

• 数据处理

• 依据权限过滤数据 通过 过滤的字段 来控制 字段 级别的权限

• 针对 UI 的要求对数据进行格式化预处理

• 数据获取模块

• 包装 请求与数据处理的业务流程逻辑

• XHR 请求

• 封装 底层 RESTFUL 或者 RPC 风格的 API 请求

• 静态模版渲染

• 当模版是后端渲染, 统一来处理该类型区块的渲染

• 前端组件库

第三方组件库与自定义组件的使用不可避免, 以下列举两个典型案例

• 三方 报表与可视化组件

• 基于 常见的 数据可视化组件库 例如 ali g2 或者 g6 组件进行二次开发

• 自定义 表格
  基于 JQ Plugin 标准模版开发 JQ 组件

• 基于 bootgrid 二次封装的 自定义 Jquery 组件

管理端 JS 架构

参考上文中的 Odoo 前端架构.

• Views
• Field Widgets
  这里我们展现一个典型自定义字段 Widget 的场景, 可以看到字段类型列在编辑状态下渲染了一个较为复杂的组件

• Client Actions

总结

本文从 High Level 的角度概述了基于 Odoo 进行 CMS 网站开发涉及到的前端技术框架, 和我们采用的自定义架构方案.得益于 Odoo 本身 website 与 webclient 架构的完整性, 我们能够快速打造一个高度自定义的网站.

参考文档

• Odoo Javascript Reference

• Odoo Website Theme

• Building a Website with Odoo

• Building a Backend Module with Odoo