3.4.3.3 SPI机制-扩展点

相关推荐

• Oinone 7天入门到精通

  3.5.7.6 自定义字段

  字段是什么 字段的基本概念 定义：字段通常指的是数据的一个单独项，它可以是一个文本框、下拉菜单、复选框等，用于在用户界面上收集或展示数据。 用途：在表单中，字段用于收集用户输入；在表格或列表中，字段用于显示数据。 类型：字段可以有不同的类型，如文本、数字、日期等，这些类型通常由数据模型定义。 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 自定义字段效果示例

  史, 昂

  2024年5月23日

  2.2K000
• Oinone 7天入门到精通

  自定义组件

  1. 定义组件介绍 平台提供了大多数的通用组件，面对企业个性话需求、复杂的业务场景，我们也提供了自定义组件的能力，帮助企业更快实施业务需求。 自定义组件包含“组件画廊”“组件排序”“元件画廊”“元件属性设计”四个页面。 1.1 组件与元件 在介绍如何自定义组件前，需要先了解以下概念： 组件：页面设计的组件库中看到的是组件。每个组件都有自己的属性面板，通过属性、字段决定组件逻辑，而自定义组件就是需要构建出组件自身的属性信息，再结合业务配置组件的属性、使用组件。 一个组件在不同的业务类型、视图类型、单值/多值，其属性面板是不同的，不同业务类型、视图类型、单值/多值的组合我们成为元件，多种组合即为多个元件，所以一个组件包括多个元件。 元件：一个组件可以对应多个元件。在创建时明确元件所适用的字段业务类型、单/多值、视图类型，在画布中切换元件时，会结合当前组件的字段业务类型、单/多值、所在视图类型确定可以使用哪一个元件。 此处切换的也是元件。 示例：创建一个“下拉选”的组件，其中可以包含“下拉单选”“下拉多选”两个元件。“下拉选”组件从组件库中拖入时，设置单值时使用“下拉单选”元件，设置多值时使用“下拉多选”元件。 2. 组件管理 2.1 组件创建 在组件画廊页面，点击添加组件，在弹窗中完善信息创建组件。 2.2 组件操作 自定义组件支持“搜索、删除、作废、查看引用关系、管理元件、编辑、低无一体、排序”的操作。 搜索：默认搜索可见组件，可切换“全部、可用、废弃”搜索组件，也可使用组件名称搜索。 删除：若组件未被引用，则可以直接删除。 作废：组件作废后，不可在画布中展示，不可在组件切换时使用，但已使用的数据不影响。 查看引用关系：可以查看存在引用关系的页面，支持点击跳转到对应页面的设计页面。仅当组件无引用关系时才支持删除。 管理元件：点击进入元件的管理页面。 编辑：可修改组件名称、组件图表、组件描述。 低无一体：比较复杂，在第5章中单独讲解。 排序：进入排序页，可拖动排序自定义组件。自定义组件会插在系统组件之后。可以点击“查看排序结果”选项页查看最终排序结果。排序同样会更新画布中的组件库顺序。 3. 元件管理 3.1 元件创建 在元件画廊页面，点击添加元件，在弹窗中完善信息创建一个元件。 3.2 元件操作 元件支持“删除、作废、查看引用关系、编辑、设计元件属性”的操作。 删除：若元件未被引用，则可以直接删除。 作废：元件作废后，不影响原来已使用的元件，无法新添加、使用该元件。 查看引用关系：可以查看存在引用关系的页面，支持点击跳转到对应页面的设计页面。仅当元件无引用关系时才支持删除。此处的引用关系数量会小于等于组件引用关系的数量。 编辑：可修改元件名称、支持视图类型、元件描述。 设计元件属性：比较复杂，将在第4章中单独讲解。 4. 设计元件属性 元件属性设计页面主要操作集中在这三部分，分别是①视图切换②属性面板设计区③复制功能 视图切换：元件创建时选择的支持视图类型，在①区域平铺可切换对应视图的属性面板进行设计。 属性面板设计区：可将组件拖入属性面板设计区进行设计，设计的是自定义组件的属性面板，左侧组件库和页面设计的组件库相同，仍然支持创建字段或使用模型字段，右侧进行元数据面板、属性面板设置。 复制功能：可将已设置好的属性面板复制到其他视图，提高设计效率。 5. 低无一体 低无一体简单讲就是组件代码上传，通过载入代码使组件在设计页面和实现页面可见和交互。 系统内置的属性不满足需求时，要用低无一体写代码，定制属性，比如从模型中拖拽设计就是内置的属性，从组件库中设置，就要配合低无一体，否则无效。 首次进入组件设计或组件中的元件变更时需要生成SDK。 生成结束后展示SDK生成时间，并且“下载模版工程”按钮可用。 点击下载模版工程，会自动下载模板工程。 在模版工程中编写前端代码。 根据实际需求上传JS、CSS文件后提交即可。

  史, 昂

  2024年6月20日

  2.1K000

• 3.4.3 函数的相关特性

  本小章会从oinone的函数拥有三方面特性，展开介绍 面向对象，继承与多态 面向切面编程，拦截器 SPI机制，扩展点

  史, 昂

  Oinone 7天入门到精通 2024年5月23日

  1.3K000
• Oinone 7天入门到精通

  应用审计

  1. 整体介绍 应用审计是基于模型字段记录用户操作留痕记录，通过定义审计规则，平台基于审计规则订阅的字段记录形成日志。平台名词概念： 应用日志：针对已订阅的审计规则记录用户操作信息，是用户在各应用中操作行为留痕记录。 审计规则：业务审计中，数据变化订阅记录的规则。 操作入口：应用中心——业务审计应用。 2. 审计规则 审计规则是指定义审计过程订阅数据变化的信息，根据模型、订阅到具体字段内容变化形成应用日志。如订阅销售订单的备注，销售订单S20231001888，订单备注【尽快发货】，备注修改为【需易碎品包装】，审计规则为：销售订单模型，订阅【备注】。 操作包括：新增、编辑、删除。 2.1. 新增 新增时，定义审计规则名称，选择需要审计的模型，指定需要订阅的字段信息，同时可以指定关联关系的字段。 需要注意：每个模型仅限定义单条审计规则。 2.2. 编辑 编辑同新增操作，不做赘述。 2.3. 删除 删除规则后，平台将不再监听对应数据的变更日志，请慎重删除。 3. 应用日志 应用日志是针对已订阅的审计规则记录用户操作信息。记录操作用户、IP、登录设备、位置、订阅的字段变化内容。 应用日志详情 4. 业务表达 4.1. 展示效果 表格-行操作—日志记录 详情—日志记录 4.2. 操作步骤 Step1：在应用中心，需要维护业务应用依赖业务审计应用； 操作入口：应用中心，找到业务应用——编辑，依赖模块选择业务审计。 Step2：配置审计规则； 操作入口：业务审计应用——审计规则——新增规则。 Step2：界面设计器配置日志记录； 操作入口：界面设计器，找到需要配置的页面——模型组件，将动作区的日志记录拖动到页面中。

  史, 昂

  2024年1月20日

  1.5K000
• Oinone 7天入门到精通

  5.8 商业支撑之执行域

  一、基础介绍 执行域包括两个核心一是订单的产生，二是订单的履约。往往品牌商既有自营渠道（包括2c、2b）、又有第三方渠道。那么有两种设计思路： 把第三方渠道的订单当作自有渠道的订单产生一种特殊方式，开放订单创建接口，并统一履约。 好处：简单，在3方渠道不多、且自有渠道单一，并且逻辑相识时系统结构会简单 坏处： 当3方渠道的履约方式、库存分配方式、逆向逻辑等有差异时，会让自有渠道参杂很多不相干的逻辑引入不必要的复杂度 自有渠道不够独立和纯粹，自有渠道多样化时难以支撑 把商家自营渠道假设为特殊的第三方渠道，再建立统一的订单管理系统来对接渠道订单，并完成履约 好处：交易与履约逻辑分离，对未来发展有扩展性 坏处：引入一定复杂度 我们采用的是第二套方案，整体结构简易图如下 图5-8-1 方案整体结构简易图 二、模型介绍 图5-8-2 模型介绍 核心设计逻辑 首先我们看到上图交易域和履约域有很多相同父模型的子模型，交易域和履约域的父模型在CDM的在himalaya-trade里。履约域看oms（libra）对himalaya-trade扩展，交易域看b2c（leo）和b2b（aries）对对himalaya-trade扩展。libra、leo、aries是我们对上层业务产品的命名，取自黄道十二星座 交易域是多商家平台视角设计，有自身渠道必要的履约相关信息，完成自闭环。 履约域是从单一商家对接多渠道视角设计，有渠道交易订单同步后完成履约发货相关设计，完成自闭环。 履约域的合单拆单发货设计，渠道订单只能合单为履约单不可拆，履约单可以拆单发货不可合。用m2o和o2m的组合设计来降低难度，而非采用两个m2m的设计。

  史, 昂

  2024年5月23日

  1.3K000