odooapp外链视频资源小程序动态内容分发应用

odoo实施一个视频类app应用是非常简单的,关于视频媒体的各种播放控制、显示设置、弹幕、投屏、画中画、前贴广告等功能应有尽有。唯一复杂的是运营在全网通小程序环境下,需要根据不同的平台设置相应的视频vid标识号,之后odoo会针对全端小程序的来源平台,动态解析返回能合规外链引用的资源cdn地址。

odoo也能通过大附件来直接上传保存各种影视文件,然后回源分发到自建cdn网络上供用户就近访问。这种模式运营起来就很轻松,每个视频元素全网app都是同个域名链接标准配置。如果是普通小流量短视频类应用这成本还能接受可控,但超高清、大流量、长视频类应用还是建议好好利用每个平台的免费存储和流量资源。

odooapp在很多平台系的载体都是原生小程序,其视频组件读取同系的站点ip资源是绝对不会被服务器禁止该来源访问的。而每个流量派系都至少会有一个视频自媒体服务,比如腾讯系的腾讯视频、微信公众号、视频号;阿里系的优酷;百度系的爱奇艺、好看视频;字节跳动系的抖音、西瓜视频等等。

odooapp运营专员需要提前将原始视频素材分别更新至上述各自媒体后台,然后获取生成的视频id号等识别信息来填入odoo后台资源模块,最后odoo前端关联该资源的内部相对地址即可发布上线。各平台app和小程序解析渲染视频页面时,odoo会根据各分支平台的视频元数据来实时计算有时效访问限制的动态链接,以供应用本次生命周期内的播放使用。

odooapp电子多媒体书籍报纸杂志等出版类应用

odoo多网站架构可以让每个站点都对应一本能实时全网发布动态更新的电子书,其每个菜单每个页面的媒体内容都可以由各种文字、图片、音频、视频、地图、HTML等基本元素所组成,一份内容最多同时可发行的载体有通用H5、安卓苹果APP,各大平台小程序和快应用等十几个展示端。

odooapp电子刊物解决方案相比传统纸质出版内容更丰富、使用更便捷、传播更高效,同时还能与用户进行交流互动和分享裂变。自出版运营成本极低,但发行平台巨广,可算是用仅有的宽带流量来圈养更多的流量用户。所有位置灵活自营各种形式的广告业务,还可以挂载各小程序平台流量主的激励广告进行内容变现。

odoo开源免费版权干净,基于python生态容易二次开发和集成上下游系统。后台支持多域名多类型多应用私有化部署,所对应前端小程序app只要每个平台一次性注册审核通过初始版本,后期即可免更新的快速增加、修改、删除所有出版物内容。odooapp助力每一种书刊都有一个全网通小程序的物联网时代尽快来临。

odoo搭建自媒体平台与公众号头条号等区别

odoo自媒体系统是部署在客户拥有产权的主机或者阿里云、腾讯云的服务器资源上,日期内容无限发布无限编辑。如同宅基地自建房,有天有地装修风格灵活自如,当然不能违法是底线:)其依托odoo全网通技术将相配套的客户端小程序载体植入到各个自媒体平台,后续源源不断的内容自动化同步输入,最终打通了封闭的自媒体世界和外部资讯内容的长连接。

微信公众号、头条抖音号、百度百家号、阿里大鱼号、腾讯企鹅号等自媒体平台号则是一个个独立的SaaS账号,不同的平台都有不同的规则约束,发文数量和内容时效都有不少限制,媒体内容都存储于平台,多个平台需要自己同步。如同商业地产中的租赁户,受各种物业运营管理约束,删帖屏蔽都是小惩罚,底线是不要被封号。

最后总结两者各有绝对优势,前者主站中心化、后者独立分布式。不能互相取代,最好是互补搭配使用,将最优质的创作内容以最小化的成本进行最大化的传播、分享和搜索。

odoo自媒体小程序与自媒体号演变

没有自媒体之前的年代,网站博客是主要的内容营销推广工具,对应大odoo系统的就是website_blog模块,常用于企业新闻、个人动态、品牌故事、知识传播、专题报道等应用场景。每篇博文都是一个网页,有唯一的网址,独立的seo配置,可以被谷歌、百度、360、搜狗、必应等搜索引擎抓取识别并收录。

odoo博客SEO配置

随着移动互联网时代的到来,各大流量巨头纷纷开通了自媒体号,其封闭的搜索和推广只认自家平台号。创作者为了能够全网发布,各种平台的订阅号注册维护成了标准操作。这在PC年代也就是超大型社区论坛的站内基础功能,各种论坛多账号之间的日常发贴回复则是现在各种媒体号信息同步发布的前身。

进入移动互联网后半场存量竞争后,微信小程序的成功让后来者无不一一效仿,甚至华为小米等硬件厂商也组队快应用联盟加入混战,国内的大前端领域总算迎来独有的辉煌。如果说自媒体是平面的结构化信息,那小程序就是立体的信息化互动,自媒体和小程序不是替代而是互补关系,不仅可以流量协作,组合成自媒体小程序矩阵更是强强联合。

未来自媒体小程序的流行取决于全网通系统成熟化和平台私有搜索和推荐引擎大众化。前者解决技术低成本免开发部署odoo开箱即用,后者解决平台超国民待遇,如使用欧度博客后台发布的信息通过各自平台前端小程序转换成原生内容就和公众号、头条号、百家号、大鱼号、企鹅号等内容一样会被搜索爬虫无差别收录并推送到用户面前。

odoo自媒体小程序发布朋友圈

目前字节跳动、百度、微信平台已经实现了自家小程序页面级的收录和搜索排名支持,其中今日头条和手机百度的推荐信息流里更是频繁出现由自媒体小程序提供的素材内容,而微信也开放了自媒体小程序内容页面直接分享朋友圈的私域流量功能。

odoo手机移动客户端app解决方案

原生H5响应式设计自适配是成本最低的,企业版自带主题开箱即用,社区版使用第三方比如OCA组织的web_responsive模块搭配使用效果也很好。各种应用场景广泛兼容,缺点是PC大屏幕菜单不够直观有些人可能不习惯,以及手机浏览器也要加载并执行完整个odoo富客户端框架才能显示过于笨重,体验一般毕竟只是个Web页面。

官方App套壳封装则是进阶之路,UI主题风格虽然不变,但可以在H5的基础上多出一些原生能力替代,比如多套odoo系统用户切换,日期时间下拉框选择控件、消息提醒等功能体验都有所提升。安卓和苹果系统版本都有,缺点就是还没开源无法基于原生能力部分进行扩展开发。

企业微信、钉钉、飞书、WeLink等移动互联网开放平台的集成,odoo整体可以作为其子系统,也可以将各个功能模块平移成各个子应用。其中组织架构和消息通知的互联互通是核心,更多上层应用的一体化整合需要根据需求和成本来定制。优势是有很多开源的通用性模块可参考借鉴和经验交流,取长补短强强联合,最终的用户体验一定是最佳的,毕竟一个国民APP就可完成所有功能。缺点则是odoo就变成没有存在感的纯后台管理和服务支撑了,当然还有一些封闭式的内网环境也不适合。

第三方用RPC协议对接的产品级APP,比如MERP是综合全能型,还有一种是模块应用级对接。这和官方App配置差不多,服务端协议域名端口用户名密码设置正确就可以用了,但是体验完全不同,因为接口只传输必要的数据,界面则是本地化原生控件动态渲染,整体流畅度比HTML页面好太多。缺点就是商业软件没法定制,以及Web前端界面的一些深度二次开发在这里没法体现。

完全定制开发的项目级APP,可以用成本最高性能最好的Android和iOS各端原生开发,也可以先用当下流行轻量级的Vue、React框架重构整个odoo前端UI层,然后用Hybrid混合模式打包成双端应用,更可以用符合中国国情的uniapp、Taro等多端开发框架统一发布微信百度支付宝头条抖音360QQ等战国时代小程序平台的应用需求。

完美理想终身事业型的史诗级APP,吸收上述所有方案经验和精华,不仅支持odoo所有版本,更支持桌面端、平板端、手机端的主流操作系统全部平台的应用程序、APP、小程序、快应用。完全协议原生渲染,包括初始化应用名称、界面主题以及首页、页眉、页脚、菜单等内容都由odoo动态配置实时下发全网通客户端生成。其最大缺点就是如果没有网络将只有一个空白雪花页,优势则颠覆了传统应用的开发方式,只要用odoo最传统的ERP实施理念即可以免开发的拥有自己独一无二的全平台动态同步APP。。。

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可用于中转处理过程中的内存临时存储,避免了要生成和清理文件的麻烦