odooapp应用的前世今生

TinyERP远古时期,是没有Web版的,也就是用Client客户端的,就如同现在手机App一样是需要每台电脑都安装的,俗称C/S架构模式,一般每次升级版本服务端和客户端都需要同步更新。现在看起来很不方便,但是当年这种采用GTK+XMLRPC的解决方案已经是很优秀了,不仅能跨平台支持,还有完整的协议来动态呈现菜单、执行动作、渲染视图及反馈交互。

OpenERP上个世纪,与时俱进的引入了B/S架构Web版,但还保留Client到最后7.0版本才无奈抛弃,毕竟鱼与熊掌很难兼得:Web端的快速革新始终受限于Client端的兼容性,因为动态协议虽美丽,但协议自身还需要不断迭代加强,这是日新月异Web世界与保守稳定Client王朝之间的结构性矛盾。现在renjie.me看来这次革命很及时,又一次走在历史的正确道路上,否则现在估计会有基于WebKit内核的客户端版本。

Odoo改革开放,在HTML5浏览器统一天下的趋势和潮流下,姓open姓erp已不重要了,综合卓越的、基础扎实的、业务饱满的,版权干净的,且历史包袱和技术债务都不重的,完全可以冲击企业级操作系统的宝座,其轻快的日日发新版本腾飞,生态又由与日俱增的appstore应用市场和开源社区保驾护航,使得各种层次的企业级应用开发者都可以在odoo上找到自己的归属与定位。截止目前其在企业应用操作系统的地位犹如Android+iOS合体遥遥领先:所谓的社区版就如安卓开放的架构并自带原生的应用,任何组织都可以基于这个成熟的开源基础设施来打造自己的企业级甚至行业级业务系统,而官方企业版不就是那个封闭的苹果巨人及其相关付费app吗:)

odoo vs uniapp

写在odoo14发布之前
时间过的真快,两年前曾自信以为12版本架构可以稳定几年,没想到odoo自我革命基因这么强,凡是跟不上时代节奏的环节,迟早都会被升级替代掉,问题是时代一直在进步呀:)

于是从odoo13开始,我就在思索与寻觅一个能和其完美互补的搭档,直到我发现并体验了uniapp,又经过将近一年的磨合实践,总算可以将两者融为一体了

如果说odoo是倚天剑,那uniapp就是屠龙刀,刀剑合力,其利断金。后台工业互联网和前端移动互联网技术强强全栈组合,就没有什么需求是不能完成的,这种能伴随一身的感觉很好

从此不管odoo年复一年的迭代发布,都对renjie.me这种互补的、对冲的、跨界的全平台组合栈技术影响甚微了

odoo list view sequence number backend solution

ODOO列表视图序号后端解决方案
市场上很多是基于前端二次开发的,比如在列表头增加首列做为序号列,由于需要对列表的页面结构进行一些覆盖式的修改,导致不同版本之间的兼容性很差,且同类型模块之间也很容易冲突

上述代码将虚拟序号的功能封装为标准抽象模型,适用于模块按需继承给视图直接使用即可

odoo one2many2many mix field model

ODOO一对多对多混合字段模型
原生的One2many和Many2many已经可以解决大部分模型之间的关系映射,但在一些特殊场景下还是需要混合两者优点形成一个新的关系模型

odoo one2many2many mix field model

如生产制造相关的部件与工序:一个部件是由多个工序所组成,而其工序之间还有调整顺序等要求;一个工序可以在多个部件里的不同位置所引用,也可以在同一个部件里不同顺序多次引用

标准的一对多模型桥接做映射可以自定义明细行顺序、独立参数。缺点是只能一个个添加,无法直接打开被桥接的模型进行操作
标准的多对多模型直接做映射可以批量选择、直接编辑。缺点是不可重复且没有顺序及独立参数,后续基本没有可扩展的灵活性
混合的一对多对多模型则是结合上述两者各自优势进行互补以达到可用性层面的最佳用户体验

odoo integrated excel xls and xlsx file read write library

ODOO集成Excel xls和xlsx文件读写库
开源物以类聚角度LibreOffice Calc的ods格式是整合电子表格的最佳选择,但由于Excel尾大不掉还有着2003及之前xls格式和2007及之后xlsx格式的历史问题

存储:原生Binary字段是最合适的,但不管最终是文件存储还是数据库存储,程序上都是以base64库的encodestring编码和decodestring解码进行出入

前端:SheetJS库可以用来做附件和报表的预览应用及所见即所得数据的快速结构化导出

后端:xlrd+xlwt、XlsxWriter、OpenPyXL三大Python库各有所长又相互制衡反垄断,根据场景自由组合起来可以做各种类型复杂应用。StringIO和BytesIO可用于中转处理过程中的内存临时存储,避免了要生成和清理文件的麻烦

odoo list view table tr hover background color

ODOO列表视图表格行悬停背景色
原生列表的鼠标悬停和点击选择一样,都是没有特别的视觉效果,有些列和数据都非常多的场景,满屏都是数据逐行浏览下来很疲劳

一段简洁的less代码轻松搞定,odoo就像纯净的简装房,其框架结构非常优秀,但不同的应用需要对其各种细节进行个性化精装修才能获得最佳体验:)

odoo search view touch device disable auto focus

ODOO搜索视图触屏设备禁用自动聚焦
标准搜索视图都是配合其他数据视图组合呈现的,其有个特性就是会自动获取焦点到搜索输入框方便用户快速进行数据筛选

如今大部分的移动设备如手机、平板等都是使用软键盘进行触控输入,当系统检测到焦点被可输入元素获取到时会自动弹出占用将近一半屏幕大小的虚拟键盘。如此搜索视图那原本人性化的设计在移动设备下日常使用动不动就被弹出键盘的行为反而变的更不友好

经过源码分析若不覆盖原设计方法冗余重构的情况下还有自动失焦的对冲方案,同时这个效果也是Web浏览器经典的UI线程和JS线程互斥表现演示:

odoo integrated raphaël visualization marketing control view

ODOO集成Raphaël可视化销控视图
Raphaël 是一个用于在网页中绘制矢量图形的 Javascript 库。它使用 SVG W3C 推荐标准和 VML 作为创建图形的基础,你可以通过 JavaScript 操作 DOM 来轻松创建出各种复杂的柱状图、饼图、曲线图等各种图表,还可以绘制任意形状的图形,可以进行图表或图像的裁剪和旋转等复杂操作

虽然 D3.js 已经非常优秀,但多一个选择也不是坏事,何况理论上各种优秀的前端图形库都可以按照 ODOO 视图规范兼容共处一起飞:)

地产销控图

odoo modal dialog window draggable

ODOO模态对话框窗口拖动
年年一个大版本推进,但其前端基础库还是很古老的Bootstrap + jQuery + Underscore组合,11版本虽然对View层进行了激进的重构,也还是基于这个基架之上。同理jQuery UI交互界面库也一脉相承的延续至今,这就可以直接调用其Draggable Widget部件以最小的代价扩展原生模态对话框的拖拽功能:

 

odoo community version toggle left nav menu

ODOO社区版切换左侧导航菜单
社区版的菜单体系是一二三级同时分别展示于顶部和左侧,非常的直观,习惯这点后用企业版的菜单系统是非常难受的。个人认为最好的体验因该是大屏幕设备用社区版菜单,小屏幕终端用企业版菜单,关于这个课题以后在深入探讨,先回归本次主题:

以上通过继承菜单对应的模版在导航区植入一个切换开关按扭的入口

以上LESS代码定义其样式外观与一级菜单和谐保持一致并定位到合适的位置,没错,导航最左也就是第一个菜单前面的空位也就是它了

最后绑定上前端行为代码就可以开关自如的控制左侧导航区,同时还有一个小小的切换动画效果。至此,社区版也可以像企业版那样间接实现整个内容区都可以用来展示视图数据,特别适合那些数据多到需要用水平滚动条来左右拖动配合使用的场景