form视图中的action，点击后打开table的弹窗的，xml中配置的filter，但是table查询的时候没有带上查询条件：
<action name="action_name" label="打开tabel弹窗视图" filter="id==${activeRecord.id}" />
将xml中的activeRecord修改成openerRecord即可。
<action name="action_name" label="打开tabel弹窗视图" filter="id==${openerRecord.id}" />
Oinone社区 作者：oinone原创文章，如若转载，请注明出处：https://doc.oinone.top/frontend/12.html
访问Oinone官网:https://www.oinone.top获取数式Oinone低代码应用平台体验
1.通过vue devtool查看vue组件和oinone组件的信息 平台字段、动作、视图组件都是以Widget结尾的，可以通过关键字快速找到组件 安装vue devtool插件 chrome安装最新版的vue devtool插件 谷歌应用商店插件地址，隐藏窗口需要在扩展程序的详情页额外设置才能使用该插件 安装好插件后，可以通过插件选中html页面中的元素查看相关信息 相关特性了解 组件自动创建的vue组件以组件的class类名命名，据此特性可以得出自定义组件的时候，可继承该命名的父类 一般oinone的组件以Widget后缀命名，也推荐大家也以此为后缀，方便在vue调试面板快速看出哪些是oinone组件 选中oinone组件后可以在右侧面板看到相关的组件信息，部分属性介绍 template属性为dsl的配置 activeRecords、formData、rootData、parentData、dataSource等属性为常用数据属性 action为动作的元数据 field为字段的元数据 2.直接在浏览器开发者工具的源码处调试源码 打开浏览器开发者工具，进入标签页源代码/来源(英文版为Source)，win系统用快捷键ctrl+O，mac系统用快捷键cmd+O, 可以打开文件搜索面板，通过关键字搜索文件名找到代码文件，可直接在里面debug调试或者查看执行逻辑
阅读之前 你应该： 了解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…
屏幕边缘滑出的浮层面板。 何时使用 抽屉从父窗体边缘滑入，覆盖住部分父窗体内容。用户在抽屉内操作时不必离开当前任务，操作完成后，可以平滑地回到原任务。 当需要一个附加的面板来控制父窗体内容，这个面板在需要时呼出。比如，控制界面展示样式，往界面中添加内容。 当需要在当前任务流中插入临时任务，创建或预览附加内容。比如展示协议条款，创建子对象。 API 参数 说明 类型 默认值 版本 class 对话框外层容器的类名 string – closable 是否显示左上角的关闭按钮 boolean true closeIcon 自定义关闭图标 VNode | slot destroyOnClose 关闭时销毁 Drawer 里的子元素 boolean false footer 抽屉的页脚 VNode | slot – getTriggerContainer 指定 Drawer 挂载的 HTML 节点 HTMLElement | () => HTMLElement | Selectors ‘body’ height 高度, 在 placement 为 top 或 bottom 时使用 string | number keyboard 是否支持键盘 esc 关闭 boolean true mask 是否展示遮罩 Boolean true maskClosable 点击蒙层是否允许关闭 boolean true placement 抽屉的方向 ‘top’ | ‘right’ | ‘bottom’ | ‘left’ ‘right’ style 可用于设置 Drawer 最外层容器的样式，和 drawerStyle 的区别是作用节点包括 mask CSSProperties – title 标题 string | slot – visible(v-model:visible) Drawer 是否可见 boolean – width 宽度 string | number 378 zIndex 设置 Drawer 的 z-index Number 1000 cancelCallback 点击遮罩层或右上角叉或取消按钮的回调, return true则关闭弹窗 function(e) enterCallback 点击确定回调 function(e)
阅读之前 什么是GraphQL? Oinone官方解读GraphQL入门 可视化请求工具 insomnia下载 概述 (以下内容简称GQL) 众所周知，平台的所有功能都是通过一系列元数据定义来驱动的，而GQL作为服务端和客户端交互协议，其重要性不言而喻。下面会从以下几个方面介绍GQL在平台中是如何运作的： 服务端定义元数据生成GQL对应的schema 通过HttpClient发起一个GQL请求 通过window.open使用GET方式发起一个GQL请求 客户端泛化调用任意API服务 客户端通过运行时上下文RuntimeContext发起GQL请求 准备工作 在开始介绍GQL之前，我们需要定义一个可以被GQL请求的服务端函数，以此来介绍我们的相关内容。（对服务端不感兴趣的同学可以跳过代码部分） DemoModel.java @Model.model(DemoModel.MODEL_MODEL) @Model(displayName = "演示模型", labelFields = {"name"}) public class DemoModel extends IdModel { private static final long serialVersionUID = -7211802945795866154L; public static final String MODEL_MODEL = "demo.DemoModel"; @Field(displayName = "名称") private String name; @Field(displayName = "是否启用") private Boolean isEnabled; } DemoModelAction.java @Model.model(DemoModel.MODEL_MODEL) public class DemoModelAction { @Action(displayName = "启用") public DemoModel enable(DemoModel data) { data.setIsEnabled(true); data.updateById(); return data; } @Action(displayName = "禁用") public DemoModel disable(DemoModel data) { data.setIsEnabled(false); data.updateById(); return data; } } 上面的java代码定义了演示模型的字段和动作： 字段 field id：ID 整数 Integer name：名称 字符串 String isEnabled：是否启用 布尔 Boolean 动作 action enable：启用 提交动作 ServerAction disable：禁用 提交动作 ServerAction 服务端定义元数据生成GQL对应的schema 模型和字段 type DemoModel { id: Long name: String isEnabled: Boolean } 动作 type DemoModelInput { id: Long name: String isEnabled: Boolean } type DemoModelQuery { queryOne(query: DemoModelInput): DemoModel …… } type DemoModelMutation { enable(data: DemoModelInput): DemoModel disable(data: DemoModelInput): DemoModel …… } PS：平台内置了多种Query和Mutation定义，通过模型继承关系将自动生成，无需手动定义。比如Query定义包括queryOne、queryPage等；Mutation定义包括create、update等。特殊情况下，默认逻辑无法满足时，服务端通常采用函数重载的方式进行替换，客户端则无需关心。 生成规则 type DemoModel：通过模型编码demo.DemoModel取.分隔后的最后一位，并转换为大驼峰格式。字段与声明类型一致。 type DemoModelInput：动作入参定义，未做特殊声明的情况下与模型定义一致。 type DemoModelQuery和type DemoModelMutation：Query和Mutation为固定后缀，分别生成动作相关类型。当函数类型为QUERY时，使用Query后缀，其他情况使用Mutation后缀。 （此处仅做简单解释，详细生成规则过于复杂，客户端无需关心） Query类型的GQL示例 query { demoModelQuery { queryOne(query: { id: ${id} }) { id name isEnabled } } } Mutation类型的GQL示例 mutation…
「前端」获取系统配置 简介 系统配置对于前端开发至关重要，它包含了许多关键信息，通过调用「systemMajorConfig」API，可以轻松地获取这些关键配置信息。除了主要的系统配置外，底层还提供了一些快捷的API，比如获取当前主题、当前主题大小、登录页面主题、版权状态和默认浏览器信息。 使用步骤 调用「systemMajorConfig」API获取系统配置数据。 使用返回的数据对象来访问特定的系统配置参数，如企业名称、企业官网等。 使用底层提供的快捷API来获取与系统配置相关的特定信息。 系统配置参数 logo (string): 应用logo（未折叠状态） appSideLogo (string): 应用logo（折叠状态） smallLogo (string): 小型logo slogan (string): 企业slogan favicon (string): 浏览器logo browserTitle (string): 浏览器标题 loginPageLogo (string): 登录页logo loginBackground (string): 登录页背景 loginLayoutType (any): 登录页布局主题 mode (any): 主题模式 size (string): 主题大小 快捷API列表 getCurrentTheme: 获取当前主题信息。 getCurrentThemeSize: 获取当前主题大小。 getLoginTheme: 获取登录页面主题信息。 getCopyrightStatus: 获取版权状态信息。 getDefaultBrowser: 获取默认浏览器信息。 示例代码 import { systemConfig, getCurrentTheme } from ‘@kunlun/dependencies’ // 访问特定系统配置参数 console.log(systemConfig.logo); // 输出企业名称 // 使用快捷API获取特定信息 console.log(getCurrentTheme());
