界面设计器 扩展字段的查询上下文

相关推荐

• 低无一体

  树型表格全量加载数据如何处理

  阅读该文档的前置条件 【界面设计器】树形表格 1.前端自定义表格组件 import { ActiveRecord, BaseElementWidget, Condition, Entity, SPI, TableWidget, ViewType } from '@kunlun/dependencies'; @SPI.ClassFactory( BaseElementWidget.Token({ type: ViewType.Table, widget: ['demo-tree-table'] }) ) export class TreeTableWidget extends TableWidget { // 默认展开所有层级 protected getTreeExpandAll() { return true; } // 关闭懒加载 protected getTreeLazy(): boolean { return false; } public async $$loadTreeNodes(condition?: Condition, currentRow?: ActiveRecord): Promise<Entity[]> { // 树表加载数据的方法，默认首次只查第一层的数据，这里去掉这个查询条件的参数condition，这样就会查所有层级数据 return super.$$loadTreeNodes(undefined, currentRow); } } 2. 注册layout import { registerLayout, ViewType } from '@kunlun/dependencies'; const install = () => { registerLayout( ` <view type="TABLE"> <element widget="actionBar" slot="actionBar" slotSupport="action"> <xslot name="actions" slotSupport="action" /> </element> <element widget="demo-tree-table" slot="table"> <element widget="expandColumn" slot="expandRow" /> <xslot name="fields" slotSupport="field" /> <element widget="rowActions" slot="rowActions" slotSupport="action" /> </element> </view> `, { viewType: ViewType.Table, model: "resource.resourceCity", // 变量，需要替换 actionName: "MenuuiMenu6f6005bdddba468bb2fb814a62fa83c6", // 变量，需要替换 } ); }; install();

  nation

  2024年8月17日

  1.4K000
• 前端

  表单字段API

  FormFieldWidget 表单字段的基类，包含了表单字段通用的属性跟方法 示例 class MyFieldClass extends FormFieldWidget{ } 字段属性 属性名 说明 类型 可选值 默认值 value 当前字段的值 any – null formData 当前表单视图的数据 Object – {} rootData 跟视图的数据，如果当前只有一个视图，那么与formData是一样的 Array – [] metadataRuntimeContext 当前视图运行时的上下文，可以获取当前模型、字段、动作、视图等所有的数据 Object – – urlParameters 当前url参数 Object – – field 当前字段的元数据 Object – – model 当前模型 Object – – view 当前视图 Object – – disabled 是否禁用 Boolean – false invisible 当前字段是否不可见 Boolean – false required 当前字段是否必填，如果当前字段是在详情页，那么是false Boolean – false readonly 当前字段是否只读，如果当前字段是在详情页、搜索，那么是false Boolean – false placeholder 占位符 String – 当前字段的displayName label 字段的标题 String – 当前字段的displayName 方法 方法名 说明 参数 例子 getDsl 获取当前字段所有的配置 – change 修改当前字段的值 any focus 获取焦点触发的方法 – blur 失去焦点触发的方法 – executeValidator 执行当前字段的校验，异步的 – submit 重写当前字段的提交逻辑 – submit() { return ‘value’ } reloadActiveRecords 替换当前视图的数据 Array this.reloadActiveRecords([{code: xxx, name: 111}]) reloadRootData 替换根视图的数据 Array this.reloadRootData([{code: xxx, name: 111}])

  汤乾华

  2023年11月15日

  1.6K002
• 前端

  oinone的rsql与传统sql语法对照表

  rsql sql 描述 field01 == "name" field01 = "name" 等于 field01 != "name" field01 != "name" 不等于 field01 =gt= 1 field01 > 1 大于 field01 =ge= 1 field01 >= 1 大于等于 field01 =lt= 1 field01 < 1 小于 field01 =le= 1 field01 <= 1 小于等于 field01 =isnull=true field01 is null 字段为null field01 =notnull= 1 field01 is not null 字段不为null field01 =in= ("foo") field01 in ("foo") 多条件 field01 =out= ("foo") field01 not in ("foo") 不在多条件中 field01 =cole= field02 field01 = field02 字段作为查询参数 field01 =colnt= field02 field01 != field02 字段作为查询参数 field01 =like="foo" field01 like "%foo%" 全模糊匹配，rsql语法中无需拼接通配符”%“ field01 =starts="foo" field01 like "foo%" 前缀模糊匹配，rsql语法中无需拼接通配符”%“ field01 =ends="foo" field01 like “%foo" 后缀模糊匹配，rsql语法中无需拼接通配符”%“ field01 =notlike="foo" field01 not like "%foo%" 全模糊不匹配，rsql语法中无需拼接通配符”%“ field01 =notstarts="foo" field01 not like "foo%" 前缀模糊不匹配，rsql语法中无需拼接通配符”%“ field01 =notends="foo" field01 not like “%foo" 后缀模糊不匹配，rsql语法中无需拼接通配符”%“ field01 =has=(ENUM_NAME1, ENUM_NAME2) 有多值枚举中的几个值 field01 =hasnt=(ENUM_NAME1,ENUM_NAME2) 没有多值枚举中的几个值 field01 =bit=ENUM_NAME1 有二进制枚举中的单个值 field01 =notbit=ENUM_NAME1 没有二进制枚举中的单个值 前端代码中使用工具类拼接rsql 该工具类在oinone的前端基础框架中提供 import { Condition } from '@kunlun/dependencies'; const rsqlCondition = new Condition('field01').equal('foo') .and(new Condition('field02').in(['bar'])) .and(new Condition('field03').notIn(['foo'])) .or(new Condition('field04').greaterThanOrEuqalTo(12)) .or(new Condition('field05').like('foo')) .or(new Condition('field06').notStarts('bar')) .or(new Condition('field07').isNull()) .or(new Condition('field08').notNull()) .and(new Condition('field09').bitEqual('BIT_ENUM_1')) .and(new Condition('field10').bitNotEqual('BIT_ENUM_2')) .and(new Condition('field11').has('ENUM_NAME_1')) .and(new Condition('field12').hasNot(['ENUM_NAME_2', 'ENUM_NAME_3'])); const rsqlStr = rsqlCondition.toString();…

  oinone

  2023年11月1日

  4.3K002

• 自定义前端拦截器

  某种情况下，我们需要通过自定义请求拦截器来做自己的逻辑处理，平台内置了一些拦截器 登录拦截器LoginRedirectInterceptor 重定向到登录拦截器LoginRedirectInterceptor import { UrlHelper, IResponseErrorResult, LoginRedirectInterceptor } from '@kunlun/dependencies'; export class BizLoginRedirectInterceptor extends LoginRedirectInterceptor { /** * 重定向到登录页 * @param response 错误响应结果 * @return 是否重定向成功 */ public redirectToLogin(response: IResponseErrorResult): boolean { if (window.parent === window) { const redirect_url = location.pathname; // 可自定义跳转路径 location.href = `${UrlHelper.appendBasePath('login')}?redirect_url=${redirect_url}`; } else { // iframe页面的跳转 window.open(`${window.parent.location.origin}/#/login`, '_top'); } return true; } } 请求成功拦截器RequestSuccessInterceptor 请求失败拦截器 RequestErrorInterceptor 网络请求异常拦截器 NetworkErrorInterceptor 当我们需要重写某个拦截器的时候，只需要继承对应的拦截器，然后重写里面的方法即可 // 自定义登录拦截器 export class CustomLoginRedirectInterceptor extends LoginRedirectInterceptor{ public error(response: IResponseErrorResult) { // 自己的逻辑处理 return true // 必写 } } // 自定义请求成功拦截器 export class CustomRequestSuccessInterceptor extends RequestSuccessInterceptor{ public success(response: IResponseErrorResult) { // 自己的逻辑处理 return true // 必写 } } // 自定义请求失败拦截器 export class CustomRequestErrorInterceptor extends RequestErrorInterceptor{ public error(response: IResponseErrorResult) { const { errors } = response; if (errors && errors.length) { const notPermissionCodes = [ SystemErrorCode.NO_PERMISSION_ON_MODULE, SystemErrorCode.NO_PERMISSION_ON_VIEW, SystemErrorCode.NO_PERMISSION_ON_MODULE_ENTRY, SystemErrorCode.NO_PERMISSION_ON_HOMEPAGE ]; /** * 用来处理重复的错误提示 */ const executedMessages: string[] = []; for (const errorItem of errors) { const errorCode = errorItem.extensions?.errorCode; if (!notPermissionCodes.includes(errorCode as any)) { const errorMessage = errorItem.extensions?.messages?.[0]?.message || errorItem.message; if (!executedMessages.includes(errorMessage)) { // 自己的逻辑处理 } executedMessages.push(errorMessage); } } } return true; } } // 自定义网络请求异常拦截器…

  oinone

  前端 2023年11月1日

  1.3K010
• 前端

  组件数据交互基础（v4）

  阅读之前 你应该： 了解DSL相关内容。母版-布局-DSL 渲染基础（v4） 了解SPI机制相关内容。组件SPI机制（v4） 了解组件相关内容。 Class Component(ts)（v4） 组件生命周期（v4） 组件数据交互概述 数据结构设计 数据结构分为三大类，列表（List）、对象（Object）以及弹出层（Popup）。 列表（List）：用于多条数据的展示，主要包括搜索（用户端）、自定义条件（产品端）、排序、分页、数据选中、数据提交、数据校验功能。 对象（Object）：用于单条数据的展示，主要包括数据提交、数据校验功能。 弹出层（Popup）：用于在一块独立的空间展示对应类型的数据。 数据结构与对于的内置视图类型： 列表（List）：表格视图（TABLE）、画廊视图（GALLERY） 对象（Object）：表单视图（FORM）、详情视图（DETAIL） 数据交互设计原则 组件与组件之间的结构关系是独立的，组件与组件之间的数据是关联的。因此，数据交互整体采用“作用域隔离（View），行为互通（CallChaining），数据互通（ActiveRecords）”这样的基本原则进行设计。实现时，围绕不同视图类型定义了一类数据结构所需的基本属性。 在弹出层进行设计时，使用Submetadata的方式，将包括弹出层在内的所有组件包含在内，以形成新的作用域。 通用属性及方法 属性 rootData：根数据源 dataSource：当前数据源 activeRecords：当前激活数据源 为了在实现时包含所有数据结构，我们统一采用ActiveRecord[]类型为所有数据源的类型，这些数据源在不同类型的视图中表示不同的含义： 列表（List）：dataSource为列表当前数据源，activeRecords为列表中被选中的数据。特别的，showDataSource为当前展示的数据源，它是dataSource经过搜索、排序、分页等处理后的数据源，也是我们在组件中真正使用的数据源。 对象（Object）：daraSource和activeRecords总是完全一致的，且长度永远为1。因此我们有时也在组件中定义formData属性，并提供默认实现：this.activeRecords?.[0] || {}。 方法 reloadDataSource：重载当前数据源 reloadActiveRecords：重载当前激活数据源 由于底层实现并不能正确判断当前使用的数据类型，因此我们无法采用统一标准的数据源修改方法，这时候需要开发者们自行判断。 重载列表数据源 cosnt dataSource: ActiveRecord[] = 新的数据源 // 重载数据源 this.reloadDataSource(dataSource); // 重置选中行 this.reloadActiveRecords([]); 重载表单数据源 cosnt dataSource: ActiveRecord[] = 新的数据源（数组中有且仅有一项） // 重载数据源 this.reloadDataSource(dataSource); // 此处必须保持相同引用 this.reloadActiveRecords(dataSource); 内置CallChaining（链式调用） 在自动化渲染过程中，我们通常无法明确知道当前组件与子组件交互的具体情况，甚至我们在定义当前组件时，并不需要关心（某些情况下可能无法关心）子组件的具体情况。这也决定了我们无法在任何一个组件中完整定义所需的一切功能。 为了保证组件行为的一致性，我们需要某些行为在各个组件的实现需要做到组件自治。以表格视图为例：当view标签在挂载时，我们无法确定应该怎样正确的加载数据，因此，我们需要交给一个具体的element标签来完成这一功能。当element标签对应的组件发生变化时，只需按照既定的重载方式将数据源提交给view标签即可。 除了保证组件行为的一致性外，我们不能完全的信任第三方框架对组件生命周期的处理顺序。因此，我们还需要对组件行为进行进一步的有序处理。以表格视图为例：我们希望搜索视图（SEARCH）的处理总是在加载数据前就处理完成的，这样将可以保证我们加载数据可以正确处理搜索条件，而这一特性并不随着模板结构的变化而发生变化。 平台内置的CallChaining mountedCallChaining：挂载时钩子； refreshCallChaining：刷新时钩子； submitCallChaining：提交时钩子； validatorCallChaining：验证时钩子； 优先级常量 VIEW_WIDGET_PRIORITY（0）：视图组件优先级 FETCH_DATA_WIDGET_PRIORITY（100）：数据提供者组件优先级 SUBVIEW_WIDGET_PRIORITY（200）：子视图组件优先级 未设置优先级的hook将最后执行，在通常情况下，你无需关心优先级的问题。 注意事项 CallChaining通常不需要手动初始化，仅需通过inject方式获取即可。 CallChaining的hook/unhook方法需要在组件生命周期的mounted/unmounted分别执行，如无特殊情况，一般通过this.path作为挂载钩子的唯一键。 在字段组件中使用mountedCallChaing @Widget.Reactive() @Widget.Inject() protected mountedCallChaining: CallChaining | undefined; protected mountedProcess() { // 挂载时处理 } protected mounted() { super.mounted(); this.mountedCallChaining?.hook(this.path, () => { this.mountedProcess(); }); } protected unmounted() { super.unmounted(); this.mountedCallChaining?.unhook(this.path); } 字段组件的mountedCallChaing并不是必须的，因此我们未进行内置处理。 一般的，当视图数据被加载完成时，字段组件的formData和value等属性，将通过响应式自动获取对应的值，因此在大多数情况下是不需要使用这一特性的。 当我们需要对字段获取的值做进一步初始化处理时，我们将需要使用这一特性。例如TreeSelect组件，必须在初始化时填充树下拉所需的结构化数据，这样才能正确展示对应的值。 当字段组件的mounted方法被执行时，我们还未执行视图数据加载，因此，在我们无法在mounted方法中操作formData和value等属性，只有在mountedCallChaining被view标签执行时，按照执行顺序，此时字段的mountedChaining将在视图数据被加载完成后执行。 数据源持有者和数据源提供者 在设计上，我们通常将view标签设计为数据源持有者，将element标签设计为数据源提供者。 原则上，在一个视图中有且仅有一个数据源提供者。 即：当一个element标签的实现组件通过reloadDataSource方法向view标签设置数据源，我们就称该实现组件为当前view标签的数据源提供者，view标签为数据源持有者。 provider/inject 阅读该章节需要理解vue的依赖注入原理 在实现上，我们通过provider/inject机制将上述通用属性/方法进行交替处理，就可以实现根据模板定义的结构进行隔离和共享功能。 例如dataSource属性的实现： /** * 上级数据源 * @protected */ @Widget.Reactive() @Widget.Inject('dataSource') protected parentDataSource: ActiveRecord[] | undefined; /** * 当前数据源 * @protected */ @Widget.Reactive() private currentDataSource: ActiveRecord[] | null | undefined; /** * 提供给下级的数据源 * @protected */ @Widget.Reactive() @Widget.Provide() public get dataSource(): ActiveRecord[] | undefined { return this.currentDataSource || this.parentDataSource; } 不足的是，由于provider/inject机制特性决定，通过provider提供的属性和方法，在某些情况下可能会进行穿透，导致组件通过inject获取的属性和方法并非是我们所期望的那样，因此，我们仍然需要进行一些特殊的处理，才能正确的处理子视图的数据交互，这一点在对象（Object）类型的视图中会详细介绍。 运行时上下文（metadataHandle/rootHandle） 在之前的文章中，我们知道前端的字段/动作组件渲染和后端元数据之间是密不可分的。 在数据交互方面，后端元数据对于字段类型的定义，将决定从API接口中获取的字段、数据类型和格式，以及通过API接口提交数据到后端时的字段、数据类型和格式。 数据类型和格式可以通过field标签的data属性，获取到经过后端编译的相关字段元数据。 那么，我们该如何决定，当数据提供者向后端发起请求时，应该获取哪些字段呢？ 因此，我们设计了RuntimeContext机制，并通过metadataHandle/rootHandle机制，在任何一个组件都可以通过view标签正确获取已经实现隔离的运行时上下文机制。 以表单视图为例，我们来看这样一个经过合并后的完整视图模板： （以下模板所展示的并非实际的运行时的结果，而是为了方便描述所提供的完整视图模板） <view type="FORM"> <element widget="actions"> <action…

  oinone

  2023年11月1日

  1.7K000