Odoo丨Odoo框架源碼研讀三：異常處理與定制化開發(fā)

Odoo源碼研讀的第三期內(nèi)容：異常處理與定制化開發(fā)。

*異常處理*

Odoo中的Exception是對Python內(nèi)置異常做了繼承和封裝，設定了自己核心的幾個Exception。

而對異常的處理和Python內(nèi)置異常的處理方式并無不同。

異常處理：

raise：通過raise來主動拋出異常。

try-except-finally：捕獲異常進行處理。

*流程引擎與業(yè)務流程*

流程引擎：

作為ERP產(chǎn)品，必然要處理很多流程，對于流程的控制，Odoo是通過狀態(tài)值的變化來進行控制的，也就是簡單的狀態(tài)機。

以銷售模塊為例：

一個銷售訂單從報價（Draft）到銷售訂單（Sale），實際上就是訂單狀態(tài)的改變。

業(yè)務流程：

模塊之間的跳轉(zhuǎn)一般都是基于視圖跳轉(zhuǎn)，而視圖的跳轉(zhuǎn)都是通過Action來進行跳轉(zhuǎn)。

一般都是通過添加按鈕來調(diào)用Action動作進行視圖跳轉(zhuǎn)，完成流程的跳轉(zhuǎn)。

*定制化開發(fā)*

手動編碼

Odoo的定制化開發(fā)主要都是通過新建module繼承原module對原module進行拓展。

而拓展的內(nèi)容分四個方面：

# Model的拓展

通過對原Model的繼承（三種繼承方式，詳見官方文檔），增加Field和重寫Method等。

# XML視圖的拓展

通過對視圖繼承，可以在原有視圖上增添元素，比如按鈕、字段等。

還有就是qweb自定義視圖，這個通過qweb語法去創(chuàng)建自定義的視圖。

# 前端組件的拓展

通過include/extend來重寫或者繼承原有前端js組件，創(chuàng)建自定義組件，然后通過xml將創(chuàng)建的js引入即可。

# controller的拓展

原有的公共Controllers已經(jīng)不能滿足特定需求，可以模仿系統(tǒng)自帶的Controller創(chuàng)建自己Controller和Api方法。

配置化開發(fā)：

Odoo Studio模塊開發(fā)者模式下，對視圖XML的修改會因為模塊升級而丟失。

究其原因，主要還是開發(fā)者模式下，是直接修改數(shù)據(jù)庫存儲的視圖XML內(nèi)容，模塊下次升級時，會把XML內(nèi)容覆蓋，導致修改丟失。

而Studio通過新建module的方式去做module繼承、視圖繼承、model繼承來對原有的模塊做拓展，這樣的話，原模塊的升級并不會影響新建模塊，所以不會丟失修改。

商業(yè)版Odoo中存在Studio模塊，支持通過拖拽方式進行配置新模塊或?qū)υK進行拓展。

通過解讀Studio模塊的代碼可以看出，Studio提供了創(chuàng)建App、編輯View視圖、設置背景圖片等接口，這也就解釋了Studio拖拽配置頁面的背后，實際是調(diào)用了這些封裝的接口。

再深入到接口內(nèi)，可以看出實際上是操作了視圖相關的model（ir.ui.menu,ir.ui.action,…）。

比如創(chuàng)建App這個操作，我們來看其中邏輯 ?

• 1）ir.model給新module創(chuàng)建新的model(ir.model)；
• 2）通過創(chuàng)建好的model，來創(chuàng)建model的默認的action(ir.actions.window)；
• 3）創(chuàng)建module對應的菜單樹(ir.ui.menu)，以及關聯(lián)的action。

這個流程看起來和Odoo提供的官方文檔上創(chuàng)建模塊的流程是不是非常一致？

與之不同的是，這里是直接在數(shù)據(jù)庫創(chuàng)建對象，省去了模塊安裝的過程。

同樣，對其他試圖、model等的拓展實際和官方文檔的流程并無區(qū)別。

*總結(jié)*

本文通篇著眼于Odoo后端對于請求的處理流程，從請求流轉(zhuǎn)的過程來看Odoo的后端架構。

但對很多地方都是一帶而過，其中包括threadLocal、cache緩存、orm對接數(shù)據(jù)庫的具體細節(jié)、以及包括前端的框架的介紹等，這些都是后面努力的方向。

分享就到這了，文中如果有不當之處，歡迎大家指出，不吝賜教！