标签：website

odooapp纯前端方向子产品，不需要安装任何后台应用模块，也就自然规避了odoo年复一年的大版本更新迭代所带来的变化问题。同一个app可以同时对接多个版本的odoo，也可以多个小程序连接到同一个实例的odoo，各版本之间的兼容性全部在前台分支解决，这样架构上就可以支持所有odoo版本。

这种odoo万能客户端模式几乎所有竞品都在采用，包括官方的闭源app也是这套路，接口起点都是从调用rpc的common服务version方法开始，只不过官方仅仅根据所返回的odoo详细版本号信息就限制了开源社区版的使用，并没有严格检测所谓的企业版商业授权。

标准odoo原生api直连就可以编译app的方式，如果应用在website领域是非常创新有竞争力的，能让很多从odoo8年代开始就建设好的各种存量网站、博客、商城、问卷、活动、课程、自由表单等互联网在线应用，不作任何改动和配置，就可以直接发布出绑定其odoo域名ip的多系统app和多平台小程序，一步跨入移动互联全网通时代。

当然website系列模块很多信息都是以页面html为格式的整体输出结果，并没有规范的json数据接口，这就有必要将常用于服务端的爬虫技术移植到客户端应用，通过对odoo渲染生成的模板页面进行实时结构化数据分析，剥离出各种标准的菜单、页眉、页脚、区块等样式结构和文本、图片、视频、地图、链接等元素内容，就可以输入给各种移动框架的渲染引擎，来动态生成原生的手机app交互界面。

odoo通用移动端的研发适配是一项长期的系统工程，多少年来国际国内不少个人和组织都尝试开发过，但往往都是起个头打个水漂后就停留在欧度历史长廊里了。这些结果，renjie.me也假设性地分析过，可能是基础设施的日常迭代太过枯燥或者技术债务的不断积累达到瓶颈，也可能是相关的项目结束以及没有持续稳定的现金流烧不起这看不到头的吞金巨兽：）

之前还有一个共性就是大家都只是围绕着OpenERP的业务层次进行定位，app仅仅是原有内部管理系统在移动互联网上的延伸和扩展，没有也能将就用web。从技术角度，只是用平台原生的新语言和UI重写替换了标准web模块里的js逻辑、css样式和qweb界面，有些甚至还是用的h5混合开发技术来冗余重构。

针对上述种种问题，odooapp的产品开发决定走一条从外部全网推广包围核心erp业务的不寻常路。即优先实现website系列模块的public功能对接创新，最后才会对内部业务模块的user应用进行兼容支持。这个策略从非主流的浅水区开始，业务场景相对单纯有趣更独特，且odoo所改即所见的热更新优势更容易在互联网流量营销这个新领域发挥到炉火纯青高境界。