在App Finder 中点击应用中心可以进入oinone的应用中心，可以看到oinone平台所有应用列表、应用大屏、以及技术可视化。
标准版本不支持在线安装，只能通过boot工程的yml文件来配置安装模块。在 www.oinone.top 官方SaaS平台客户可以在线管理应用生命周期如：安装、升级、卸载。同时针对已安装应用可以进行无代码设计（前提安装了设计器），针对应用类的模块则可进行收藏，收藏后会在App Finder中的我收藏的应用中出现。在应用列表中可以看到我们已经安装的应用以及模块，我们oinoneDemo工程也在其中。
但我们的测试应用没有设置应用类目，则无法在应用大屏中呈现。
在技术可视化页面，出展示已经安装模块的元数据，并进行分类呈现
Oinone社区 作者：史, 昂原创文章，如若转载，请注明出处：https://doc.oinone.top/oio4/9230.html
访问Oinone官网:https://www.oinone.top获取数式Oinone低代码应用平台体验
字段是什么 字段的基本概念 定义：字段通常指的是数据的一个单独项，它可以是一个文本框、下拉菜单、复选框等，用于在用户界面上收集或展示数据。 用途：在表单中，字段用于收集用户输入；在表格或列表中，字段用于显示数据。 类型：字段可以有不同的类型，如文本、数字、日期等，这些类型通常由数据模型定义。 Oinone框架中的字段 在Oinone框架中，字段的设计和实现遵循以下原则： 后端模型驱动：前端的字段直接由后端的数据模型决定。这意味着后端定义了哪些数据应该展示，以及如何展示。 减少前后端联调：由于字段的定义和行为是由后端控制的，前后端的联调需求大大减少。前端开发者主要关注于如何呈现这些字段，而后端则负责数据的逻辑和结构。 灵活性与规范性：虽然Oinone推荐所有场景都遵循后端模型驱动字段的原则，以保持前后端的一致性和减少沟通成本，但它也为高度定制化的前端页面提供了灵活性。 元数据使用：Oinone可能还使用元数据来进一步定义字段的行为，例如它们是否可见、如何验证用户输入等。 结合前后端 在使用Oinone时，理解前后端如何合作来定义和展示字段是很重要的。这种方法不仅提高了开发效率，而且有助于确保数据的一致性和应用程序的可维护性。同时，对于那些需要特定定制或特殊处理的场景，开发团队能够灵活地适应这些需求，在遵守总体架构原则的同时进行一些特定的调整和优化。 作用场景 在Oinone框架中，字段扮演着连接后端数据模型和前端用户界面的重要角色。其作用场景包括但不限于以下几点： 业务组件的核心： Oinone集成了AntdDesignVue的全部UI组件，将它们转化为业务组件。这些业务组件以字段的形式存在，使得前端开发变得简单高效。开发人员可以直接使用这些现成的业务组件来构建用户界面，大大减少了开发工作量。 无代码开发支持： 字段的设计使得Oinone支持无代码开发。开发者可以通过拖拉拽的方式在前端快速构建界面，而后端模型的定义直接决定了这些界面的生成。这种模式简化了传统的前端开发流程，提升了开发效率。 个性化定制： 虽然标准的UI组件可以满足大部分需求，但复杂多变的业务场景往往需要更多个性化的处理。在Oinone中，开发者可以根据具体业务需求和公司的UI指南，定义专门针对特定行业或客户的定制化字段和组件。 与无代码平台的结合： Oinone允许将个性化的字段和组件与无代码平台相结合。这意味着即使在进行个性化定制时，也能保持使用无代码工具的便利性，实现更灵活、更高效的前端开发。 适应多维度业务需求： 由于字段在Oinone中的灵活性和可定制性，它们能够适应多维度的业务需求，无论是从UI设计、用户体验还是业务逻辑的角度，字段都能提供合适的解决方案 自定义字段 示例工程目录 以下是需关注的工程目录示例，main.ts更新导入./field： 图3-5-7-24 自定义字段工程目录示例 示例代码 创建自定义字段组件： 使用Vue框架创建一个新的组件（例如 CustomStringFieldVue），并定义其模板、脚本和样式。 在模板中定义字段的HTML结构。 在脚本中使用 defineComponent 来定义Vue组件。 字段类的定义： 导入必要的模块，如 FormFieldWidget, ModelFieldType, SPI, ViewType 等。 使用 @SPI.ClassFactory 装饰器来注册自定义字段。 在类内部初始化并设置组件。 SPI注册参数解释： viewType: 指定视图类型，如表单视图或搜索视图。 widget: 可以指定组件名称。 ttype: 字段的业务类型，例如字符串、数字等。 multi: 指明字段是否支持多值。 model: 定义字段所属的模型。 viewName: 指定视图名称。 name: 定义所属字段的名称。 import {FormFieldWidget, ModelFieldType, SPI, ViewType} from '@kunlun/dependencies'; import CustomStringFieldVue from './CustomStringField.vue'; @SPI.ClassFactory( FormFieldWidget.Token({ viewType: [ViewType.Form, ViewType.Search], ttype: ModelFieldType.String }) ) export class CustomStringField extends FormFieldWidget { public initialize(props) { super.initialize(props); this.setComponent(CustomStringFieldVue); return this; } } 图3-5-7-24 自定义字段组件(TS)示例 <template> <div class="custom-string-filed-wrapper"> 字段组件 </div> </template> <script lang="ts"> import { defineComponent } from 'vue' export default defineComponent({ inheritAttrs: false, name: 'CustomStringFieldVue' }) </script> <style lang="scss"> .custom-string-filed-wrapper { } </style> 图3-5-7-24 自定义字段组件(Vue)示例 效果 图3-5-7-24 自定义字段效果示例
SPI(Service Provider Interface)服务提供接口，是一套用来被第三方实现或者扩展的API，它可以用来启用框架扩展和替换组件，简单来说就是用来解耦，实现组件的自由插拔，这样我们就能在平台提供的基础组件外扩展新组件或覆盖平台组件。 目前定义SPI组件 ViewWidget 视图组件 FieldWidget 字段组件 ActionWidget 动作组件 表4-2-3-1 目前定义SPI组件 前提知识点 使用 TypeScript 装饰器(注解)装饰你的代码 1. 通过注解定义一种SPI接口(Interface) @SPI.Base<IViewFilterOptions, IView>('View', ['id', 'name', 'type', 'model', 'widget']) export abstract class ViewWidget<ViewData = any> extends DslNodeWidget { } 图4-2-3-1 代码示意 2. 通过注解注册提供View类型接口的一个或多个实现 @SPI.Base<IViewFilterOptions, IView>('View', ['id', 'name', 'type', 'model', 'widget']) export abstract class ViewWidget<ViewData = any> extends DslNodeWidget { } 图4-2-3-2 代码示意 3. 视图的xml内通过配置来调用已定义的一种SPI组件 <view widget="form" model="demo.shop"> <field name="id" /> </view> 图4-2-3-3 代码示意 图4-2-3-4 组件继承示意图 当有多个服务提供方时，按以下规则匹配出最符合条件的服务提供方 SPI匹配规则 SPI组件没有严格的按匹配选项属性限定，而是一个匹配规则 按widget最优先匹配，配置了widget等于是指定了需要调用哪个widget，此时其他属性直接忽略 按最大匹配原则（匹配到的属性越多优先级越高） 按后注册优先原则
布局是什么 在系统中，布局决定了母版内的页面元素，一个页面可以由多个组件进行组装，布局可以根据视图类型来替换。 默认布局范围: 图3-5-7-36 默认布局范围 作用场景 系统内置了多个布局组件，这些组件适用于全局、某个应用或某个页面，提供了灵活的布局定制选项。这些组件根据不同类型的视图进行了默认的组装，这也是选择了视图类型后，页面能够呈现的原因。当然，这些默认的组装是可以被覆盖、新增和添加新组件的。 使用registerLayout进行自定义布局 开发者在使用这些布局组件时，应该遵循公司的规范进行统一的调整。自定义布局组件的使用可通过 registerLayout 实现。registerLayout 的第一个参数是代表布局的 XML，第二个参数是不同的选项维度，默认包含以下维度： viewType: 视图类型 module: 视图模型所在模块 moduleName: 视图模型所在模块名称 model: 视图模型编码 modelName: 视图模型名称 viewName: 视图名称 actionName: 动作名称 inline: 是否内嵌视图(子视图特有) ttype: 模型字段类型(子视图特有) relatedTtype: 关联模型字段类型(子视图特有) field: 字段(子视图特有) 需要注意的是，动作可以是A模块下的a模型，这个动作可以打开B模块下的b模型的视图，module、moduleName、model、modelName应该填b模型对应的值，只不过大部分场景我们都是本模型的动作打开本模型的视图，所以这些场景拿动作所在模型填这些值也可以这些纬度也可以通过查看TS的定义查看 全局 在系统中，我们可以通过指定视图类型来决定某一类视图的全局布局。以表格为例，当第二个入参为 { viewType: ViewType.Table } 时，代表了替换了系统内所有表格的布局样式。 示例工程目录 以下是需关注的工程目录示例，main.ts更新导入./layout，layout/index.ts更新导出./tableLayout： 图3-5-7-37 全局纬度注册布局工程目录示例 示例代码 import {registerLayout, ViewType} from '@kunlun/dependencies' /** * 把系统内所有表格类型视图的全局动作放入搜索区域 * * 移动actionBar布局至外层 * <element widget="actionBar" slot="actionBar" slotSupport="action"> * <xslot name="actions" slotSupport="action" /> * </element> * */ const registerGlobalTableLayout = () => { return registerLayout(`<view type="TABLE"> <element widget="actionBar" slot="actionBar" slotSupport="action"> <xslot name="actions" slotSupport="action" /> </element> <pack widget="group"> <view type="SEARCH"> <element widget="search" slot="search" slotSupport="field" /> </view> </pack> <pack widget="group" slot="tableGroup"> <element widget="table" slot="table" slotSupport="field"> <element widget="expandColumn" slot="expandRow" /> <xslot name="fields" slotSupport="field" /> <element widget="rowActions" slot="rowActions" slotSupport="action" /> </element> </pack> </view>`, { viewType: ViewType.Table }) } registerGlobalTableLayout() 图3-5-7-38 全局纬度注册布局代码示例 效果 图3-5-7-39 全局纬度注册布局效果示例 应用 在系统中，我们可以通过指定视图类型和模块名称来替换某一类视图在特定模块下的全局布局。以表格为例，当第二个入参为 { viewType: ViewType.Table, moduleName: ‘resource’ } 时，代表了替换了资源应用下所有表格的布局样式，而其他应用仍使用默认布局 import {registerLayout, ViewType} from '@kunlun/dependencies' const registerModuleTableLayout = () => { return registerLayout(`<view type="TABLE"> <element widget="actionBar" slot="actionBar" slotSupport="action"> <xslot name="actions" slotSupport="action" /> </element> <pack widget="group"> <view type="SEARCH"> <element widget="search" slot="search" slotSupport="field" /> </view> </pack> <pack…
前言 当我们碰到一个全新的场景，除了写代码以外也可以通过设计器来完成，大致步骤如下： 分析业务场景，规划对应的模型并通过模型设计器进行配置 通过界面设计器，设计出必要管理页面 通过流程设计器，设计对应业务流程 通过数据可视化，设计相应的数据看板 场景说明 本节通过例子完成一个积分成本分摊的业务场景 积分支出：谁受益谁支出原则+导购手动确认原则，通过门店应用的积分规则，来实现自动化+手动积分形式实现 案例背景 某家具企业经营多种家具类型，不同系列不同品类分事业部经营。 注： 独立门店：只能售卖本事业部下的商品； 融合门店：可以售卖多事业部下的商品； 需求：需要建立一套积分规则，遵循谁受益谁支出原则+导购手动确认原则；通过门店应用的积分规则，来实现自动化+手动积分。 场景一 导购a邀请老客户c通过裂变分享新客户x在独立门店1下单。系统根据独立门店1的积分规则，自动发放积分给老客户c和新客户x，积分由国一事业部承担。 场景二 融合门店1导购b邀请老客户d裂变分享新客户y在融合门店下单。该订单可能涉及多个事业部，由导购b手动选择最大量值的积分规则进行发放 场景三 独立门店1的导购a邀请老客户c裂变分享新客户z在独立门店2下单。系统根据独立门店2的积分规则，来计算积分值，自动发放老客户c和新客户z的积分，积分由国二事业部 实战训练 Step1 分析业务场景规划对应模型 本场景下涉及基础对象模型包括：事业部、门店、导购、会员等 事业部：它是积分成本的载体 门店：类型分为独立门店和融合门店，独立门店必须隶属于一个事业部，同时配置默认积分发放规则，融合门店可能属于多个事业部当发生积分发放时，需要店员手工选择成本事业部和积分发放规则 导购员：导购员必须隶属于一个门店等 会员：消费者需要记录它隶属导购员，以及是由哪个会员推荐过来的等 涉及业务对象模型包括：积分发放规则，积分发放记录，邀请下单记录 积分发放规则：会员积分发放规则，对应邀请老客的积分发放规则等 积分发放记录：本次发放积分、本次发放积分规则、发放对象(会员)、成本事业部、关联门店、关联导购、关联老客（可空）、关联下单记录编码等 邀请下单记录：导购、下单会员、下单门店、商品信息、下单金额等 对应模型如下： 模型 设计器呈现 自定义字段列表 关系字段说明 说明 事业部 事业部负责人(文本) 门店列表(o2m) 与门店建立o2m绑定关系,绑定时选择双向绑定，双向绑定意思是在事业部这边建立o2m到门店的关系字段，在门店那边建立m2o的关系字段 关系字段需要在有对方模型的情况下再建，比如事业部中的门店列表则是再后面追加新增的 门店 导购列表(o2m) 事业部(m2o) 默认积分发规则(m2o) 门店类型(枚举) 分别与事业部、导购、积分发放规则建立m2o、o2m、m2o关系 门店类型：需要先建对应的数据字典 导购 绑定用户(m2o) 门店(m2o) 是否离职(布尔型) 与门店建立m2o关系 1. 绑定用户，用于后续业务流程设计中的填写规则 2. 打马赛克的忽略，其他场景测试用 会员 会员累计积分(浮点数) 推荐客户(m2o) 所属于导购员(m2o) 是否为新客(布尔型) 与导购、会员建立m2o关系 1. 会员m2o的字段是自关联用于存储推荐会员 2. 打马赛克的忽略，其他场景测试用 积分发放规则 推荐客户发放比例(浮点数) 发放倍数(整数) 积分发放记录 最终发放积分(浮点数) 关联积分规则(m2o) 事件编码(文本) 推荐导购员(m2o) 推荐会员(m2o) 关系门店(m2o) 成本事业部(m2o) 会员(m2o) 成本事业部名称（文本） 会员名称（文本） 与积分发放规则、导购员、会员、门店、事业部建立m2o关系 1. 会员有两个m2o，分别用户记录发放会员和发放会员的推荐会员也就是老客 2. 事件编码用户维护触发本次积分发放记录产生的源头单据编码如：邀请下单记录的编码 邀请下单记录 成本事业部(m2o) 选择积分发放规则(m2o) 下单门店(m2o) 购买商品(文本) 下单金额(整数) 会员(m2o) 导购(m2o) 与成本事业部、积分发放规则、下单门店、会员、导购等建立m2o的关系 1. 会员、下单门店、导购属于必要信息 2. 成本事业部、积分发放规则是业务流程中自动计算回填的数据 Step3 利用界面设计器，设计出必要的管理页面 以事业部为例，构建管理页面。其他模型依次按例子建立管理页面 进入界面设计器，应用选择全员营销，模型选择事业部，点击添加页面下的直接创建 设置页面标题、模型（自动带上可切换）、业务类型（运营管理后续会扩展其他类型）、视图类型（表单）后点击确认按钮进入事业部表单设计页面 进入页面设计器，对事业部表单页面进行设计（更多细节介绍，请参考界面设计产品使用手册） a. 左侧为物料区：分为组件、模型。 ⅰ. 【组件】选项卡下为通用物料区，我们可以为页面增加对应布局、字段（如同在模型设计器增加字段）、动作、数据、多媒体等等 ⅱ. 【模型】选项卡下为页面对应模型的自定义字段、系统字段、以及模型已有动作 b. 中间是设计区域 c. 右侧为属性面板，在设计区域选择中组件会显示对应组件的可配置参数 在左侧【组件】选项卡下，拖入布局组件【分组】，并设置组件【标题属性】为基础信息 在左侧【组件】选项卡下，再次拖入布局组件【分组】，并设置组件【标题属性】为门店列表 在左侧【模型】选项卡下，分别把自定义字段中的【事业部负责人】和系统字段中的【名称】拖入【基础信息】分组，把自定义字段中的【门店列表】字段拖入门店列表分组 在设计区域切换【门店列表】展示组件为【表格】 此时【门店列表】展示形式变成了表格形式，选中【门店列表】组件，会发现左侧【模型】选项卡下的当前模型切换成了【门店】，同时我们在右属性面板区置空其【标题属性】 设计区选中【门店列表】的表格组件，分别把自定义字段中的【默认积分发规则】、【门店类型】、【导购列表】和系统字段中的【名称】拖入【门店列表】表格组件的表格字段设计区 设计区选中【门店列表】的表格组件的【创建】按钮，点击【打开弹窗】设计关系字段【门店】的新增页面 11.分别把自定义字段中的【默认积分发规则】、【门店类型】和系统字段中的【名称】拖入门店的新增页面设计区 选中弹出框中【取消】取消按钮，设置其【按钮样式】属性为【次要按钮】 关闭弹出框，回到主设计区 设计区选中【门店列表】的表格组件的【删除】按钮，设置其【按钮样式】属性为【次要按钮】，【二次确认】属性打开 设计区选中【门店列表】的表格组件中操作列的【编辑】按钮，点击【打开弹窗】设计关系字段【门店】的编辑页面， a. 分别把自定义字段中的【默认积分发规则】、【门店类型】和系统字段中的【名称】拖入门店的新增页面设计区。 b. 选中弹出框中【取消】取消按钮，设置其【按钮样式】属性为【次要按钮】 c. 把门店类型展示组件切换为【单选框】 d. 关闭弹出框 设计区选择非【门店列表】组件如基础信息，模型切换为主模型【事业部】，在左侧【模型】选项卡下，把动作分类下的提交类型【创建】动作拖入中间设计区的动作区 选择中展示名为【确定】的创建动作按钮，在右侧属性面板中设置：是否隐藏属性为【条件隐藏】，隐藏条件为【id非空】 在左侧【模型】选项卡下，把动作分类下的提交类型【更新】动作拖入中间设计区的动作区 选择中展示名为【确定】的更新动作按钮，在右侧属性面板中设置：是否隐藏属性为【条件隐藏】，隐藏条件为【id为空】。之所以同时拖入【创建】和【更新】动作并都命名为确认，是期望这个页面同时可以做为新增页面也可以做为编辑页面，只不过要通过条件隐藏来设置按钮的出现规则 在左侧【组件】选项卡下，把动作分类下的【客户端动作】拖入中间设计区的动作区 选择设计区【客户端动作】，在右侧属性面板中设置：动作名称为【返回】，客户端行为为【返回上一个页面】并点击保存 选择设计区【返回】动作，在右侧属性面板中设置：按钮样式为【返回】，【二次确认】属性打开并设置提示文字为【返回页面操作将不被保存】，可以点击预览二次确认看效果 点击【发布】按钮，页面成功发布，每发布一次会有一个例子版本，可以通过历史版本进行恢复 点击右上角历史版本图标，进入历史版本查看页面 在历史版本页面可以选择对应历史版本记录，并通过【恢复此版本】来完成页面的历史版本切换 接下来我们为事业部模型创建表格管理页面，入口同编辑页面。设置页面标题、模型（自动带上可切换）、业务类型（运营管理后续会扩展其他类型）、视图类型（表格）后点击确认按钮进入事业部表格设计页面 进入页面设计器，对事业部表格页面进行设计（更多细节介绍，请参考界面设计产品使用手册） 在左侧【模型】选项卡下，分别把自定义字段中的【事业部负责人】和系统字段中的【名称】拖入表格组件的表格字段设计区 在左侧【组件】选项卡下，把动作分类下的【跳转动作】拖入中间设计区的动作区，并在右侧属性面板中设置动作名称为【新增】，数据控制类型为【不进行数据处理】，打开方式为【当前窗口打开】，动作跳转页面为【事业部编辑】页面，并点击保存 在左侧【组件】选项卡下，把动作分类下的【跳转动作】拖入中间设计区的行内动作区，并在右侧属性面板中设置动作名称为【编辑】，数据控制类型为【处理单条数据】，打开方式为【当前窗口打开】，动作跳转页面为【事业部编辑】页面，并点击保存 在左侧【模型】选项卡下，把动作分类下的【删除】拖入中间设计区的动作区，并在右侧属性面板中设置动作名称为【删除】，按钮样式为【次要按钮】，【二次确认】属性打开 点击右上角【显示母版】进入页面最终展示形式，点击添加菜单项，并在输入框中输入【事业部管理】 点击菜单右侧设置图标，选择【绑定已有页面】，进行菜单与页面的绑定操作 在绑定页面中，模型选择【事业部】，视图选择【事业部管理】，点击确认按钮提交 拖动【事业部管理】菜单到【积分管理】父菜单下 最后别忘了点击右上角【发布】按钮对【事业部管理】表格页面进行发布，回到界面设计器首页查看刚刚建好的两个页面 以事业部为例分别对门店、导购、会员、积分发放规则、积分发放记录、邀请下单记录等模型进行页面设计，这里不再累赘，请按照自身学习需要，尝试进行界面设计 Step4 通过流程设计器，设计对应业务流程 我们先来整理下核心流程即：邀请下单流程 Step4.1 创建导购邀请下单记录触发流程 进入流程设计器，点击【创建】按钮 注意：流程中需要获取关系类型的字段（如：O2O、O2M、M2O或M2M），这种类型都是复杂的对象字段，除关联字段(一般为ID)以外的字段，需要通过【数据获取】节点单独获取【关系字段】的对象数据。所以在流程设计中经常会用到【数据获取】节点 左上角编辑流程名称为【导购邀请下单触发流程】，点击第一个【触发】节点，触发方式选择模型触发，模型选择【导购邀请下单】，触发场景选择【新增数据时】，点击该节点的【保存】按钮 点击流程图节点间的【+】图标选择增加【获取数据】节点，或者拖动左侧物料区【获取数据】到特定的【+】图标 点击【获取数据】，在右侧属性面板中设置【获取数据条数】为单条，选择模型为【导购】，点击【筛选条件】的【{X}】图标，进行数据获取的条件设置 选择条件字段为【ID】条件操作符为【等于】，条件为变量的导购字段的ID。当上下文只有一个变量时默认不需要选择，这里默认的是【触发[导购邀请下单记录]】，设置好以后点击确认，回到属性面板设置【未获取到数据时执行方式】为【终止流程】，并点击节点【保持】按钮 再增加一个【获取数据】节点，在右侧属性面板中设置 a. 【获取数据条数】为单条，选择模型为【会员】 b. 点击【筛选条件】的【{X}】图标，进行数据获取的条件设置，选择条件字段为【ID】条件操作符为【等于】，条件为变量【导购邀请下单记录】的会员关系字段的ID字段。因为上下文中存在多个变量时需要选择对应变量，跟获取导购数据有点区别，在获取导购数据时，上下文中只有此次【导购邀请下单记录】所以不需要选择对应变量，设置好以后点击【确认】按钮 c. 回到属性面板设置【未获取到数据时执行方式】为【终止流程】 d. 最后点击节点【保持】按钮。…
