界面设计器教程：如何设置字段联动变更

相关推荐

• 前端

  字段组件submit方法详解

  场景介绍 在日常开发调试表单页的过程中，细心的小伙伴应该注意到，视图内的数据(通过vue调试工具看到的formData就是视图的数据)和最终通过服务端动作提交的数据不总是一致的，本文将带领大家解开疑惑。 为什么会出现这种现象？ 出现这种情况都是当前模型上有关联关系字段的场景，以多对一(M2O)场景为例，由于当前模型的关联关系字段是通过字段配置中的referenceFields属性和当前模型的relationFields属性进行关联的，所以提交数据的时候只需要拿到relationFields配置的字段就可以了，没有必要再去多拿关联关系字段本身的数据。 结合业务场景说明 这里以商品模型和类目模型举例，商品模型内有个类目的m2o字段category和对应的relationFields字段categoryId，数据提交到后端的时候前端默认会根据字段配置只获取categoryId，而category的整个对象都不会被提交。 package pro.shushi.pamirs.demo.api.model; import pro.shushi.pamirs.demo.api.model.DemoItemCategory; import pro.shushi.pamirs.meta.annotation.Field; import pro.shushi.pamirs.meta.annotation.Model; import pro.shushi.pamirs.meta.base.common.CodeModel; @Model.model(DemoItem.MODEL_MODEL) @Model(displayName = "测试商品") public class DemoItem extends CodeModel { private static final long serialVersionUID = -5104390780952631397L; public static final String MODEL_MODEL = "demo.DemoItem"; @Field.String @Field(displayName = "商品名称") private String name; @Field.Integer @Field(displayName = "类目ID") private Long categoryId; @Field.many2one @Field.Relation(relationFields = {"categoryId"}, referenceFields = {"id"}) @Field(displayName = "商品类目") private DemoItemCategory category; } 前端是如何处理数据的 前端的字段组件提供了submit()方法来让我们可以有就会在提交数据的时候改变数据。 // 字段组件基类 export class BaseFormItemWidget< Value = unknown, Props extends BaseFormItemWidgetProps = BaseFormItemWidgetProps > extends BaseDataWidget<Props> { /** * 数据提交的方法，例如：m2o字段user(假设其关系字段为userId)的值{id: 1, name: 'xxx'},但是实际后端数据只需要其中的id，所以用m2o对应的关系字段userId提交数据就可以了 * @param submitValue */ public submit(submitValue: SubmitValue): ReturnPromise<Record<string, unknown> | SubmitRelationValue | undefined> { return undefined; } } 这里先以FormStringFieldSingleWidget组件处理密码类型的字段讲解。密码一般在输入的时候是明文，为了提高提交到后端的安全性，可以将这个密码加密后再传到后端，后端再做进一步处理，这个场景中，视图中的密码和提交给后端的密码就出现了不一致的情况， @SPI.ClassFactory( BaseFieldWidget.Token({ viewType: [ViewType.Form, ViewType.Search], ttype: ModelFieldType.String }) ) export class FormStringFieldSingleWidget extends FormStringFieldWidget { public submit(submitValue: SubmitValue) { let finalValue = this.value; /** * 数据提交的时候，如果判断当前字段是否需要加密，需要加密的情况用encrypt函数做加密处理 */ if (this.crypto && finalValue) { finalValue = encrypt(finalValue); } return SubmitHandler.DEFAULT(this.field, this.itemName, submitValue, finalValue); } 注意：关系字段配置的透出字段只影响该字段的查询数据方法的返回值，不会因为此配置就在提交数据里加上这部分配置的字段 字段需要提交关联关系字段内的所有数据如何处理？ 我们可以在自定义组件里覆写submit()方法，直接将this.value内的数据返回这里以覆写多对多m2m字段为例 import { BaseFieldWidget, FormM2MFieldSelectWidget, ModelFieldType, SPI, SubmitValue, ViewType } from '@kunlun/dependencies'; @SPI.ClassFactory( BaseFieldWidget.Token({ viewType: ViewType.Form, ttype: ModelFieldType.ManyToMany, widget: 'Select', model: 'xxx.yyyyy', name: 'fileName01',…

  nation

  2024年9月10日

  885000
• 产品常用功能讲解

  界面设计器教程：如何配置左树右表布局

  相关文章参考 【界面设计器】左树右表：https://doc.oinone.top/designer/uidesigner/63.html 左树右表,支撑不同场景的树表结构：https://doc.oinone.top/dai-ma-shi-jian/5576.html 前端自定义左树右表中的树：https://doc.oinone.top/frontend/18420.html

  shao

  2024年9月30日

  278000
• 数式Oinone培训学习路径

  数式Oinone培训学习路径

  一、培训学习路径 下载培训清单(world) 数式Oinone 培训学习路径清单.docx 类别 步骤详解 核心事件 参与人员 是否完成 快速上手 阅读查看快速上手文档 阅读并理解文档中的每个步骤和视频 前端/后端 ✅ 启动完成 对应参与人员完成前/后端工程启动 前端/后端 ✅ 实现deno 生成demo 效果 前端/后端 ✅ 准备工作 技术工具检查 请确在本地已安装并配置好必要的开发工具和环境（如 IDE、Node.js、数据库等） 前端/后端 ✅ 问题反馈 快速上手过程中问题清单提交 前端/后端 ✅ 版本情况 版本是否是最新的版本，且建议研发人员版本一致，且类型是 min 前端/后端 ✅ 培训知识点 前后端标准研发流程 了解数式Oinone 前后端协作 前端/后端 ✅ 前端工程讲解 了解数式Oinone 前端工程最佳实践 前端 ✅ 后端工程讲解 了解数式Oinone 后端工程最佳实践 后端 ✅ 前端文章大纲 阅读数式Oinone 前端文章大纲,知道相应文章如何查找 前端 ✅ 前端初阶知识点讲解 了解数式Oinone 如何自定义母版/视图/动作/字段 前端 ✅ 前端进阶知识点讲解 了解如何自定义GraphQL 请求/前端组件覆盖/ 前端ts写法 前端 ✅ 前端调试工具使用 了解数式Oinone debug 调试工具如何使用 前端 ✅ 后端文章大纲 阅读数式Oinone 后端文章大纲,知道相应文章如何查找 后端 ✅ 后端初阶知识点讲解 了解数式Oinone 模块类型/定义/数据管理器/继承/枚举与数据字典/字段序列化与类型、函数（Function）概述Oinone执行逻辑单元与模型方法的绑定 后端 ✅ 后端进阶知识点讲解 了解数式Oinone 界面导入导出、文件导入导出、工作流、协同开发等功能如何使用 后端 ✅ 二、培训注意要点事项 快速入门，简单快捷 数式Oinone培训前注意事项 三、培训学习知识点 优秀创见者经验分享，让学习事半功倍 数式Oinone 标准研发流程（点击此处观看） 视频简介：前后端同学将了解如何高效协作，解决常见开发难题，并掌握如何使用Oinone平台提高工作效率。课程分为五个模块：1) 前后端开发流程最佳实践，2) 前端与后端各自的责任，3) 协同开发模式，4) 自查自纠方法，5) 传统开发模式的问题 观看对象：建议都看 数式Oinone前端工程合理讲解（点击此处查看） 视频简介：前端工程结构建议参考，以及注意事项 观看对象：前端，对Vue有基础的了解，且已经完成了前端工程启动 点击查看文章：前端工程结构示例，包括标品和定制层 数式Oinone后端工程合理讲解(点击此处查看） 视频简介：后端工程结构建议参考，以及注意事项 观看对象：后端，对Java有基础的了解，且已经完成了后端工程启动 点击查看文章：后端工程示例 前端必看知识点清单 前端文章大纲 （建议前端伙伴一定要收藏哦） 文章内容：使用数式Oinone ,前端项目中场景使用场景文章合集 观看对象：前端，且已经完成前端工程启动，对Vue有基础的了解 前端初阶知识点讲解 数式Oinone— 如何自定义母版（点击此处观看） 视频简介：母版是什么，以及在业务中如何应用，如何自定义 观看对象: 前端，且已经完成前端工程启动，对Vue有基础的了解 点击查看文章：3.5.7.2 自定义母版 数式Oinone —如何自定义视图（点击此处观看） 视频简介：视图是什么，以及在业务中如何应用，如何自定义 观看对象: 前端，且已经完成前端工程启动，对Vue有基础的了解 点击查看文章:3.5.7.4 自定义页面 数式Oinone —如何自定义动作（点击此处观看） 视频简介：动作各种类型操作及示例，以及在业务中如何应用，如何自定义 观看对象: 前端，且已经完成前端工程启动，对Vue有基础的了解 点击查看文章 ：3.5.7.5 自定义动作 数式Oinone—如何自定义字段（点击此处观看） 视频简介：动作各种类型操作及示例，以及在业务中如何应用，如何自定义 观看对象: 前端，且已经完成前端工程启动，对Vue有基础的了解 点击查看文章：3.5.7.6 自定义字段 前端进阶知识点讲解 如何自定义 GraphQL 请求 （点击此处观看） 视频简介：GraphhQL在业务中如何应用，如何自定义 观看对象: 前端，且已经完成前端工程启动，对Vue和GraphhQL有基础的了解 点击查看文章：如何自定义 GraphQL 请求 数式Oinone—前端组件覆盖 （点击此次观看） 视频简介：了解如何自定义组件，以及如何组件覆盖 观看对象: 前端，且已经完成前端工程启动，对Vue有基础的了解 数式Oinone—前端ts写法（点击此处观看） 视频简介：了解如何前端ts写法，以及如何应用 观看对象: 前端，且已经完成前端工程启动，对Vue有基础的了解点击查看文章：前端 SPI 注册 + 渲染 数式–Oinone前端调试工具如何使用提升开发效率（点击此处观看） 视频简介：了解数式Oinone debug，学会使用平台默认的调试工具，通过控制台查看当前视图元数据信息，学会浏览器调试，以及如何使用vue 调试工具提升研发效率 观看对象: 前端，且已经完成前端工程启动，对Vue有基础的了解 点击查看文章：调试工具在业务场景的使用-前端 点击查看文章：如何提高自定义组件的开发效率…

  shao

  2024年12月24日

  2.1K013
• 产品常用功能讲解

  3分钟了解如何配置权限

  相关知识文档 权限手册（5.1以上）：https://doc.oinone.top/chan-pin-shi-yong-shou-ce/17797.html常见权限问题：https://doc.oinone.top/oinone-faq/18529.html

  shao

  2024年9月30日

  238000
• 后端

  后端代码规范

  前言 虽然oinone框架减少了很多的代码，但是低代码部分的代码质量也需要高度关注，不管是写的代码bug多，或者说被吐槽代码不行，还是说写的代码经常被重构，核心点还是没有代码规范的意识和技巧，下面摘录了一些常见的规范要求，去提高后端的代码质量，代码质量提高后，自然效率也会提升。 常见代码规范 **1、规范命名** 命名是写代码中最频繁的操作，比如类、属性、方法、参数等。好的名字应当能遵循以下几点： **见名知意** 比如需要定义一个变量需要来计数 int i = 0; 名称 i 没有任何的实际意义，没有体现出数量的意思，所以我们应当指明数量的名称 int count = 0; **能够读的出来** 如下代码： private String sfzh; private String dhhm; 这些变量的名称，根本读不出来，更别说实际意义了。 所以我们可以使用正确的可以读出来的英文来命名 private String idCardNo; private String phone; **2、规范代码格式** 好的代码格式能够让人感觉看起来代码更加舒适。 好的代码格式应当遵守以下几点： 合适的空格 代码对齐，比如大括号要对齐 及时换行，一行不要写太多代码 好在现在开发工具支持一键格式化，可以帮助美化代码格式，大家统一使用idea的规范即可。 **3、写好代码注释** 在《代码整洁之道》这本书中作者提到了一个观点，注释的恰当用法是用来弥补我们在用代码表达意图时的失败。换句话说，当无法通过读代码来了解代码所表达的意思的时候，就需要用注释来说明。 书的作者之所以这么说，是因为作者觉得随着时间的推移，代码可能会变动，如果不及时更新注释，那么注释就容易产生误导，偏离代码的实际意义。而不及时更新注释的原因是，程序员不喜欢写注释。😒 但是这不意味着可以不写注释，当通过代码如果无法表达意思的时候，就需要注释，比如如下代码： for (Integer id : ids) { if (id == 0) { continue; } //做其他事 } 为什么 id == 0 需要跳过，代码是无法看出来了，就需要注释了。 好的注释应当满足一下几点： 解释代码的意图，说明为什么这么写，用来做什么 对参数和返回值注释，入参代表什么，出参代表什么 有警示作用，比如说入参不能为空，或者代码是不是有坑 当代码还未完成时可以使用 todo 注释来标记 代码review发现漏洞时 可以使用 fixme 注释来标记 **4、try catch 内部代码抽成一个方法** try catch代码有时会干扰我们阅读核心的代码逻辑，这时就可以把try catch内部主逻辑抽离成一个单独的方法 如下图是Eureka服务端源码中服务下线的实现中的一段代码 整个方法非常长，try中代码是真正的服务下线的代码实现，finally可以保证读锁最终一定可以释放。 所以这段代码其实就可以对核心的逻辑进行抽取。 protected boolean internalCancel(String appName, String id, boolean isReplication) { try { read.lock(); doInternalCancel(appName, id, isReplication); } finally { read.unlock(); } // 剩余代码 } private boolean doInternalCancel(String appName, String id, boolean isReplication) { //真正处理下线的逻辑 } **5、方法别太长** 方法别太长就是字面的意思。一旦代码太长，给人的第一眼感觉就很复杂，让人不想读下去； 同时方法太长的代码可能读起来容易让人摸不着头脑，不知道哪一些代码是同一个业务的功能。 比如代码中有那种2000+行大类，各种if else判断，光理清代码思路就需要用很久时间。🤷🏻‍♀️ 所以一旦方法过长，可以尝试将相同业务功能的代码单独抽取一个方法，最后在主方法中调用即可。 **6、抽取重复代码** 当一份代码重复出现在程序的多处地方，就会造成程序又臭又长，当这份代码的结构要修改时，每一处出现这份代码的地方都得修改，导致程序的扩展性很差。 所以一般遇到这种情况，可以抽取成一个工具类，还可以抽成一个公共的父类。 **7、多用return** 在有时我们平时写代码的情况可能会出现if条件套if的情况，当if条件过多的时候可能会出现如下情况： if (条件1) { if (条件2) { if (条件3) { if (条件4) { if (条件5) { System.out.println("11111"); } } } } } 面对这种情况，可以换种思路，使用return来优化 if (!条件1) { return; } if (!条件2) { return; } if (!条件3) { return; } if (!条件4) { return; } if (!条件5) { return; } System.out.println("11111"); 这样优化就感觉看起来更加直观 **8、if条件表达式不要太复杂**…

  冯, 天宇

  2024年12月11日

  1.6K002