odoo框架源码研读三：异常与定制化开发

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

黄华信，神州数码云基地软件开发工程师，擅长odoo定制化开发。

上一篇文章讨论了odoo源码的ORM和日志。感兴趣的同学可以戳下面的链接~

odoo框架源码研读二：ORM与日志

odoo框架源码研读一：前后端交互

本文接着研读odoo的源码，主要讲述odoo的异常处理与定制化开发。

1 异常

odoo中的Exception是对python内置异常做了继承和封装，设定了自己核心的几个exception。
而对异常的处理和python内置异常的处理方式并无不同。

1.1 异常处理

raise
通过raise来主动抛出异常。
try-except-finally:
捕获异常进行处理。

2 流程引擎与业务流程

2.1 流程引擎

作为erp产品，必然要处理很多流程，对于流程的控制，odoo是通过状态值的变化来进行控制的，也就是简单的状态机。
以销售模块为例

一个销售订单从报价(draft)到销售订单(sale)，实际上就是订单状态的改变。
2.2 业务流程

模块之间的跳转一般都是基于视图跳转，而视图的跳转都是通过action来进行跳转。一般都是通过添加按钮来调用action动作进行视图跳转完成流程的跳转。

3 定制化开发

3.1 手动编码

odoo的定制化开发主要都是通过新建module继承原module对原module进行拓展。而拓展的内容分四个方面

1. model的拓展

通过对原model的继承（三种继承方式，详见官方文档），增加field和重写method等。

1.  xml视图的拓展

通过对视图继承，可以在原有视图上曾添元素，比如按钮、字段等。还有就是qweb自定义视图，这个通过qweb语法去创建自定义的视图。

1. 前端组件的拓展

通过include/extend来重写或者继承原有前端js组件，创建自定义组件，然后通过xml将创建的js引入即可。

1. controller的拓展

原有的公共controllers已经不能满足特定需求，可以模仿系统自带的controller创建自己controller和api方法。

3.2 配置化开发

odoo studio模块
开发者模式下对视图xml的修改会因为模块升级而丢失，究其原因，主要还是开发者模式下是直接修改数据库存储的视图xml内容，模块下次升级的时候会把xml内容覆盖导致修改丢失。而studio通过新建module的方式去做module继承、视图继承、model继承来对原有的模块做拓展，这样的话，原模块的升级并不会影响新建模块，所以不会丢失修改。
商业版odoo中存在studio模块，支持通过拖拽方式进行配置新模块或对原模块进行拓展。

通过解读studio模块的代码可以看出，studio提供了创建app、编辑view视图、设置背景图片等接口，这也就解释了studio拖拽配置页面的背后实际是调用了这些封装的接口。
再深入到接口内，可以看出实际上是操作了视图相关的model（ir.ui.menu,ir.ui.action,...）,
比如创建app这个操作，我们来看其中逻辑

1. ir.model给新module创建新的model(ir.model)
2. 通过创建好的model来创建model的默认的action(ir.actions.window)
3. 然后创建module对应的菜单树(ir.ui.menu)，以及关联的action

这个流程看起来是不是和odoo提供的官方文档上创建模块的流程是不是非常一致？与之不同的是，这里是直接在数据库创建对象，省去了模块安装的过程。同样，对其他试图、model等的拓展实际和官方文档的流程并无区别。

4 总结

本文通篇着眼于odoo后端对于请求的处理流程，从请求流转的过程来看odoo的后端架构，从而对很多地方都是一带而过，其中包括threadLocal、cache缓存、orm对接数据库的具体细节、以及包括前端的框架的介绍等，这些都是后面努力的方向。由于笔者时间和水平的有限，文中如果有不当之处，还请看官指出，不吝赐教，感谢!

传送门

TiKV源码略读-Server Start

小“菜鸟”成长记

RPA实战之网络表格数据处理