致Oinone读者

相关推荐

• 4.2.1 组件之生命周期

  组件生命周期的意义所在：比如动态创建了「视图、字段」，等它们初始化完成或者发生了修改后要执行业务逻辑，这个时候只能去自定义当前字段或者视图，体验极差，平台应该提供一些列的生命周期，允许其他人调用生命周期的api去执行对应的逻辑。 一、实现原理 图4-2-1-1 实现原理 当用户通过内部API去监听某个生命周期的时候，内部会动态的去创建该生命周期，每个生命周期都有「唯一标识」，内部会根据「唯一标识」去创建对应的「Effect」，Effect会根据生命周期的「唯一标识」实例化一个「lifeCycle」，「lifeCycle」创建完成后，会被存放到「Heart」中，「Heart」是整个生命周期的心脏，当心脏每次跳动的时候（生命周期被监听触发）都会触发对应的生命周期 二、生命周期API API 描述 返回值 View LifeCycle onViewBeforeCreated 视图创建前 ViewWidget onViewCreated 视图创建后 ViewWidget onViewBeforeMount 视图挂载前 ViewWidget onViewMounted 视图挂载后 ViewWidget onViewBeforeUpdate 视图数据发生修改前 ViewWidget onViewUpdated 视图数据修改后 ViewWidget onViewBeforeUnmount 视图销毁前 ViewWidget onViewUnmounted 视图销毁 ViewWidget onViewSubmit 提交数据 ViewWidget onViewSubmitStart 数据开始提交 ViewWidget onViewSubmitSuccess 数据提交成功 ViewWidget onViewSubmitFailed 数据提交失败 ViewWidget onViewSubmitEnd 数据提交结束 ViewWidget onViewValidateStart 视图字段校验 ViewWidget onViewValidateSuccess 校验成功 ViewWidget onViewValidateFailed 校验失败 ViewWidget onViewValidateEnd 校验结束 ViewWidget Field LifeCycle onFieldBeforeCreated 字段创建前 FieldWidget onFieldCreated 字段创建后 FieldWidget onFieldBeforeMount 字段挂载前 FieldWidget onFieldMounted 字段挂载后 FieldWidget onFieldBeforeUpdate 字段数据发生修改前 FieldWidget onFieldUpdated 字段数据修改后 FieldWidget onFieldBeforeUnmount 字段销毁前 FieldWidget onFieldUnmounted 字段销毁 FieldWidget onFieldFocus 字段聚焦 FieldWidget onFieldChange 字段的值发生了变化 FieldWidget onFieldBlur 字段失焦 FieldWidget onFieldValidateStart 字段开始校验 FieldWidget onFieldValidateSuccess 校验成功 FieldWidget onFieldValidateFailed 校验失败 FieldWidget onFieldValidateEnd 校验结束 FieldWidget 表4-2-1-1 生命周期API 上面列出的分别是「视图、字段」的生命周期，目前Action的生命周期还没有，后续再补充。 三、第一个View组件生命周期的监听（举例） Step1 新建registryLifeCycle.ts 新建registryLifeCycle.ts，监听宠物达人的列表页。’宠物达人table_demo_core’为视图名，您需要找后端配合 import { onViewCreated } from '@kunlun/dependencies' function registryLifeCycle(){ onViewCreated('宠物达人table_demo_core', (viewWidget) => { console.log('宠物达人table_demo_core'); console.log(viewWidget); }); } export {registryLifeCycle} 图4-2-1-2 新建registryLifeCycle.ts Step2 修改main.ts 全局注册lifeCycle import { registryLifeCycle } from './registryLifeCycle'; registryLifeCycle(); 图4-2-1-3 修改main.ts Step3 看效果 图4-2-1-4 示例效果 四、第一个Filed组件生命周期的监听（举例） Step1 修改registryLifeCycle.ts 通过onFieldValueChange增加宠物达人搜索视图的name（达人）字段的值变化进行监听。 宠物达人search:name 代表 视图名:字段名 import { onViewCreated , onFieldValueChange} from '@kunlun/dependencies' function registryLifeCycle(){ onViewCreated('宠物达人table_demo_core', (viewWidget) => { console.log('宠物达人table_demo_core'); console.log(viewWidget); }); onFieldValueChange('宠物达人search:name', (filedWidget) => { console.log('宠物达人search:name');…

  史, 昂

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

  1.1K000
• 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.3K000
• Oinone 7天入门到精通

  2.4.1 Oinone独特性之单体与分布式的灵活切换

  企业数字化转型需要处理分布式带来的复杂性和成本问题。尽管这些问题令人望而却步，但分布式架构对于大部分企业仍然是必须的选择。如果一个低代码平台缺乏分布式能力，那么它的性能就无法满足客户的要求。相比之下，Oinone平台通过对部署的创新（如图2-6所示），成功实现了分布式架构的支持，而且能够按照客户的业务发展需求，灵活选择不同的部署模式，同时节约企业成本，提升创新效率。这一创新是Oinone平台与其他低代码平台的重要区别，能够满足客户预期发展并兼顾成本效益。 图2-6 传统部署方式VS Oinone部署方式 实现原理 要实现灵活部署的特性，必须满足两个基本要求： 开发过程中不需要过多关注分布式技术，就像开发单体应用一样简单。代码在运行时应该能够根据模块是否在运行容器中，来决定路由走本地还是远程。这样可以大大减少研发人员的工作量和技术复杂度。 研发与部署要分离，即"开发单体应用一样开发分布式应用，而部署形式由后期决定"。为此，我们的工程结构支持多种启动模式，并逐一介绍了针对不同场景的工程结构类型（如下图2-7所示）。这样可以让客户在后期根据业务发展情况和需求，选择最适合的部署模式，从而达到灵活部署的目的。 图2-7 Oinone工程结构梳理 在整个工程结构上，我们秉承了Spring Boot的规范，不会改变大家的工程习惯。而Oinone的部署能力则可以让我们更灵活地应对各种情况。现在，我们来逐一介绍几种常规的工程结构以及它们适用的场景： 单模块工程结构（常规操作） a. 这是非常标准的Spring Boot工程，适用于简单的应用场景开发以及入门学习。 多模块工程结构（常规操作） a. 这是非常标准的多Spring Boot工程，可以实现分布式独立启动，适用于常规的分布式应用场景开发。 多模块工程结构-独立boot工程模式 a. 这种工程结构在多模块工程的基础上，通过独立的boot工程来支撑多部署方式。适用于中大型分布式应用场景开发。 b. 然而，随着工程越来越多，我们也会面临一些问题： ⅰ研发：环境准备非常困难，每个模块都要单独启动，研发调试跟踪困难。 ⅱ部署：分布式的高可靠性保证需要每个模块至少有两个部署节点，但在模块较多的情况下，起步成本非常高。同时，企业初期业务不稳定且规模较小，使用多模块工程的第二种模式会增加问题排查难度和成本。 c. 此时，Oinone的多模块工程下的独立boot工程模式部署就可以发挥其灵活性，让研发和业务起步阶段可以选择all-in-one模式，等到业务发展到一定规模的时候，只需要把线上部署模式切换成模块独立部署，而研发还可以保留all-in-one模式的优势。 d. 值得注意的是，分分合合的部署模式在传统互联网架构和低代码或无代码平台上都是有代价的，但是Oinone却可以灵活适配，只需要在boot工程的yml文件中写入需要加载的模块就可以解决。此处我们仅介绍多模块加载配置，选择性忽略其他无关配置，具体配置（如下图2-8所示）。 pamirs: boot: init: true sync: true modules: – base – resource – sequence – user – auth – web tenants: – pamirs 图2-8 Oinone yml配置图大型多场景工程结构-独立boot工程模式： a. 在多模块工程结构基础上的加强版，增加CDM层设计，让不同场景即保持数据统一，又保持逻辑独立。这种工程结构特别适用于大型企业软件开发，其中涉及到多个场景的情况，例如B端和C端的应用，或者跨不同业务线的应用，能够保证数据的一致性，同时也能够保持逻辑独立，避免不同场景间的代码冲突。 b. 这种工程结构是我们Oinone支撑“企业级软件生态”的核心，我们可以把场景A当作我们官方应用，场景B当作其他第三方伙伴应用。在这个工程结构下，我们的客户可以定制化开发自己的应用，同时我们也可以通过这种模式来支持我们的伙伴们进行开发，实现多方共赢。 c. 基于独立boot工程模式，我们同样对应多种部署模式应对不同情况，并统一管理所有伙伴应用。这种工程结构的优点是扩展性好，可以支持不同规模的应用，并且可以根据需要进行快速扩展或缩小规模，具有很高的灵活性。 基于标准产品的二开工程结构，是指基于标准产品进行二次开发，满足客户特定需求的工程结构。这种模式下，Oinone提供标准产品，客户可以根据自己的需求进行二次开发，实现定制化需求，同时可以利用我们的模块化开发特性，将每一个需求作为一个模块进行开发和管理。这种工程结构的优点是能够快速满足客户特定需求，同时也具有很好的可维护性和可扩展性，因为每个需求都是一个独立的模块，可以方便地进行维护和扩展。在下一篇“Oinone独特性之每一个需求都是一个模块”文章中有详细介绍。

  史, 昂

  2024年5月23日

  1.8K000

• 界面设计器

  史, 昂

  Oinone 7天入门到精通 2024年6月20日

  1.3K000
• Oinone 7天入门到精通

  3.5.7.4 自定义页面

  页面是什么 在Oinone前端体系中，页面是一个核心概念，它代表着终端用户所看到的当前视图。这个视图可以有多种形式，主要取决于页面是如何定义和构建的。在深入理解页面之前，我们需要了解两个关键的功能：自定义布局 和 自定义母版。 作用场景 自定义布局 提供了布局调整的强大功能，但在某些情况下，它可能无法完全满足特定的需求。这时，自定义页面就显得尤为重要。自定义页面是对 自定义布局 的补充，允许开发者从更深层次自由地控制和设计用户界面。 当标准布局无法实现所需的视觉效果或功能时，自定义页面提供了更高的灵活性。开发者可以通过自定义页面来实现独特的布局设计，添加特定的交互元素，或者整合复杂的业务逻辑，以创造独特且丰富的用户体验。 自定义页面 自定义视图组件允许开发者定义和使用特定于业务需求的视图布局。下面是一个具体的示例，展示了如何定义、注册和使用通过 setComponent 结合 TypeScript 和 Vue 的自定义视图组件。 示例工程目录 以下是需关注的工程目录示例，main.ts更新导入./view： 图3-5-7-48 自定义页面工程目录示例 1. 定义 TypeScript 组件 首先，我们定义了一个名为 CustomViewWidget 的 TypeScript 组件，并在该组件中通过 setComponent 结合 Vue 单文件组件。 import { BaseElementWidget, BaseElementViewWidget, SPI, ViewWidget } from '@kunlun/dependencies'; import CustomViewVue from './CustomView.vue'; @SPI.ClassFactory(BaseElementWidget.Token({ widget: 'CustomViewWidget' })) export class CustomViewWidget extends BaseElementViewWidget { public initialize(props) { super.initialize(props); this.setComponent(CustomViewVue); return this; } } 图3-5-7-49 定义TypeScript组件代码示例 2. Vue 单文件组件 其次，我们创建了对应的 Vue 单文件组件 CustomView.vue，用于展示自定义视图的具体内容。 <template> <div class="custom-view-wrapper"> <h1>自定义视图</h1> </div> </template> <script lang="ts"> import { defineComponent } from 'vue'; export default defineComponent({ inheritAttrs: false, name: 'ViewComponentVue' }); </script> <style lang="scss"> .custom-view-wrapper {} </style> 图3-5-7-50 定义Vue组件代码示例 3. 注册自定义视图布局 接下来，我们使用 registerLayout 函数注册了一个表格视图布局，并在其中引入了通过 setComponent 结合的自定义视图组件。 import { registerLayout, ViewType } from "@kunlun/dependencies"; export const registerCustomView = () => { registerLayout( ` <view type="TABLE"> <element widget="CustomViewWidget" /> </view> `, { viewType: ViewType.Table, moduleName: 'resource', model: 'resource.ResourceCountryGroup' } ); }; registerCustomView(); 图3-5-7-51 注册自定义视图布局代码示例 效果 图3-5-7-52 自定义页面效果示例 4. 自定义视图在表格中的应用 当我们注册了自定义视图后，它就可以在表格视图中被使用。在表格视图的布局中，我们通过 标签将自定义视图嵌套在表格中，从而覆盖了表格的默认布局 5. 入参一致性 值得强调的是，registerLayout 函数和自定义布局的规则是一致的，这意味着开发者可以在自定义布局中使用与 registerLayout 相同的入参规则，从而实现更加灵活和统一的视图布局设计 与内置组件结合 1. 注册视图元素布局 首先，我们使用 registerLayout 函数注册了一个表格视图的布局。这个布局包含了搜索框、操作栏、以及一个自定义视图组件。 import { registerLayout, ViewType } from "@kunlun/dependencies"; import { CustomViewWidget } from…

  史, 昂

  2024年5月23日

  1.6K000