Odoo Field Widget 入坑指南（三）

        前两节指南中，我们对odoo的Widget机制进行了详细解释，它实则是一套前端模板生成系统，其核心是自动生成HTML模板代码。编程人员仅需调用odoo架构中的QWeb模板，即可让odoo系统自动生成相应的HTML或CSS文件。

        此机制在简化程序编写的同时，还有另外一个重要意义，就是允许页面内容在线更新。具体来讲，此机制可以理解为，页面中视图元素在无后端服务器参与的情况下，可动态更新。也就是说，客户端的样式调整、函数计算和内容修改等，全部都可由前端代码来实现。这一机制的优势是，整个交互过程完全不涉及网络数据传输，所以系统响应延迟得到了极大地降低。同时，得益于客户端计算资源的引入，远端服务器计算压力也得到明显减小。

接下来，让我们看一下此动态更新页面机制的核心，也被称为前端 event 系统。

       从代码层面看，一个Widget组件一般包含5个参数，它们分别是：tagName，id，className，attributes 和 events。根据HTML规范可知，这里的tagName、className和attributes分别对应的是HTML中的标签名称、类名称和属性名称。它们的作用是定位Widget在HTML中的位置。

  当用户触发浏览器动作时，odoo就将根据动作名称，找到锚点位置，并执行相应的渲染函数。

这里有一个值得注意的地方，odoo中 events 有两类，一类叫 events，另一类叫 custom_events。此分类不仅仅把动作函数进行了归类，它还将影响函数的具体执行情况。

      从在代码层面看，这两类 events 存在本质区别是，一类为 JQuery事件触发的，而另外一类则为添加在odoo前端注册表中触发的。

      那么，就实践而言，第一种由 JQuery 绑定events 而言，可被任何JavaScript 函数调用。此类events 可以看作一种全局变量，其调用不受代码所在位置限制。

      而对另外一种 custom_events，在没有特殊说明的情况下，是不能从 Widget 所在层级外进行调用的。也就是说，它的作用域仅仅是 Widget 自身。

举个例子，若我们希望调用一个 custom_event 的父级，在代码中必须通过 trigger_up() 函数来递归寻找，却不能简单使用点号来粗暴执行。

这一做法的意义在于，因为每一个 event 名称都是一个 Widget 所独有的，它可有效避免新 Widget 构建时出现的 event 命名冲突问题。

        在认识了 Widget 中的 event 机制后，我们就需要了解这些 event 触发是在哪里被监控的。odoo系统中，为了抓取用户页面操作，前端动态函数都被封装在了一个名为 action_manager 的 div 中。

       当用户点击页面中的按钮或字段时，用户操作的都是此 action_manager 中的元素。也就是说，通过监听此 action_manager 区域中的用户动作，即可监听所有的函数触发。

      另一方面，为了统一页面渲染机制，让odoo系统中页面全部由Widget 来渲染，odoo 创建了一个名叫 Client Action的 Widget。其作用，是将页面初始化也纳入至前端渲染过程中。

     如此一来，整个odoo的渲染（即HTML、CSS等生成）全部由 Widget 组件来完成。新引入的JavaScript代码，仅仅需要监听此 action_manager 区域内的用户动作，即可实现全局活动监听与动态触发。

        详细来讲，在上方代码中，通过配置XML可生成一名为 report.report_page 的模板。将此模板加入至前端注册表 action_registry 后，标记为 client action，即可渲染出相应页面。

       综上，本节对 odoo 前端 widget 中的 event 进行了说明。特别是其监控区域的定位，也就是action_manager 这一 div 进行了详细描述。希望可以为新入odoo的同学，提供一定帮助。