Oinone社区 作者：史, 昂原创文章，如若转载，请注明出处：https://doc.oinone.top/oio4/9332.html
访问Oinone官网:https://www.oinone.top获取数式Oinone低代码应用平台体验
相关推荐
-
模型
1. 模型介绍 Oinone低代码设计器是采用模型驱动的方式来设计应用，数据、数据都在模型，在模型设计器的模型管理模块，通过可视化配置的方式为用户提供快速设计模型的功能。 模型是对应用中所需要描述的实体进行必要的简化，并用适当的变现形式或规则把它的主要特征描述出来所得到的系统模仿品。模型由元信息、字段、数据管理器和自定义函数构成。 2. 操作模式 为了满足有无研发背景知识的不同用户使用需求，在模型设计器中，支持切换操作模式，包含专家模式和经典模式。经典模式功能基础且完善，操作交互简单易理解，适用于非研发用户；专家模式下模型的设计能力更高，有经典模式下的所有功能，相比于经典模式，功能更多，适用于一般有研发知识基础的用户。 比如在添加模型时，经典模式下可以创建的模型类型有：存储模型、传输模型，专家模式下，在此基础上还可以创建抽象模型和代理模型。 3. 分组管理 当模型过多时，可以自定义添加15个分组，将模型进行归类管理。点击「全部」展开所有分组，展开后，分组右侧可以管理分组。 3.1 管理分组 展开分组后，点击「管理分组」，出现弹窗，在弹窗中可以修改分组名称、添加分组、删除分组。 3.2 添加分组 操作「+模型分组」，可以直接输入分组名称后回车以添加一个新分组，或快捷选择其他应用使用的分组。最多添加15个分组。 3.3 修改分组 双击分组标签，即可对已有分组进行名称的修改。若分组在其他应用也使用，则在其他应用内，该分组名称也同步变化。 3.4 删除分组 点击分组标签右侧的“X”按钮，即为删除分组，但分组下如果有模型或者分组有被其他应用使用，则分组无法删除。 4. 模型管理 4.1 管理模式 在模型管理中，有两种管理模式，分别是图管理模式和列表管理模式。（下文简称图模式、表模式） 可以根据不同的使用场景，切换管理模式： 图管理模式下，模型操作区展示当前模型和与当前模型有直接关联关系的模型关系图，可以在关注模型关联关系时使用； 列表管理模式下，展示更多更详细的模型信息、字段信息，且左侧可快速切换不同模型，可以在关注模型基础信息时使用； 4.2 筛选 4.2.1 图模式筛选 在图模式下，顶部进行应用/模块、模型类型、分组的筛选，依此向下可以搜索或展开当前筛选条件下的模型列表，切换模型后在模型操作区将展示另一模型的信息。为了更大程度保留图模式下的模型展示区域，模型列表默认不会展示，点击搜索行的任意筛选项，即可展开模型列表。 4.2.2 表模式筛选 在表模式下，顶部和图模式一致，都是应用/模块、模型类型、分组的筛选，模型操作区左侧会直接展示模型列表。 4.2.3 重置筛选 图模式和表模式下，右侧都有重置筛选的选项。如果点击“重置筛选”按钮，则将筛选栏恢复到进入页面时的选项。 4.3 模型分组 模型新增成功后，默认无所属分组，每个模型可以设置所属分组，设置后通过分组进行筛选时，模型即展示在所属分组下。 4.3.1 图模式设置分组 图模式下为模型设置分组，点击模型信息顶部第一个「模型分组」操作图标，点击后设置或修改分组。 4.3.2 表模式设置分组 表模式下为模型设置分组，点击模型信息右上角第一个操作「模型分组」，点击后设置或修改分组。 4.4 继承关系 查看模型的继承关系，点击展示跟当前模型有父子关系的模型关系图。 页面初始状态只展示一层父模型与一层子模型，父模型顶部和子模型底部有“展示更多”按钮，点击展示更多再向上或向下加载一层。连线的顶部展示“收起”按钮，点击“收起”按钮收起子模型。 点击非当前模型，会打开新窗口，链接跳转到点击模型的模型设计器页面，新页面满足点击模型的筛选条件； 支持设置显示比例，缩放模型关系图； 支持最大化全屏展示。 4.4.1 图模式继承关系 4.4.2 表模式继承关系 4.5 查看引用关系 当删除模型时，如果模型有被其他设计器引用使用，则无法被删除。删除失败时会弹出“该模型仍在使用中，无法删除模型”的提示，并且可以点击「查看模型引用」，进而展示引用的详细信息。 引用包括五种：模型引用、页面引用、逻辑引用、流程引用、图表引用。 每种关系通过列表展示，列表项为链接（链接到对应的设计页面），内容为对应名称。例如，存在引用关系的流程的列表项显示的是流程的名称。列表项链接到对应流程的设计页面。 4.6 导入模型 导入模型的添加模型的一种方式，下载导入模板后在Excel中按照规则填写模型信息，成功导入后即添加模型成功。 点击「导入模型」后，可在弹窗中下载导入模板、上传导入文件、查看导入说明。 4.6.1 下载导入模板 下载导入模板时，会根据当前的操作模式不同，下载到的模板也不同。 在经典模型下，下载的导入模板中需要填写的模型信息基础、数量少、易懂。 在专家模型下，下载的导入模板中需要填写的模型信息丰富、数量多、专业。 4.6.2 查看导入说明 导入说明中描述了导入模板中各项内容的含义、填写规则等，有助于用户正确填写导入文件。在经典模式或专家模式下点击「导入说明」后，分别弹出两种操作模式下的导入说明。 4.6.3 导入上传 导入文件正确填写后，在弹窗中选择Excel文件，或将Excel直接拖入弹窗中的文件上传区域。Excel文件仅支持三种格式：.xlsx .xls .xlsm。 4.7 添加模型 点击「添加模型」，出现模型信息填写的弹窗，弹窗中包括：模型名称、模型类型、父模型。填写并保存成功后，模型即创建成功。 4.7.1 模型类型 专家模式下支持创建4种类型的模型：存储模型、传输模型、抽象模型、代理模型；经典模式下支持创建2种类型的模型：存储模型、传输模型。 存储模型：用于存储数据的模型，生成前后端交互协议、数据表、数据构造器和数据管理器。 抽象模型：用于配置多个子模型的公用字段和函数的模型，不会生成前后端交互协议、数据表、数据构造器和数据管理器。 传输模型：用于数据传输的模型，生成前后端交互协议和数据构造器，不生成数据表和数据管理器。 代理模型：用于以代理的方式扩展存储模型的模型，可以在存储模型的基础上增加传输字段和函数，与被代理的存储模型共用相同的数据管理器。 4.7.2 选择父模型 添加模型时，需要选择父模型，其中，经典模式下，无需且不展示父模型；专家模式下，必须选择父模型。 存储模型的父模型，默认是“基础存储模型”，可选项为可见的抽象模型和存储模型。 传输模型的父模型，默认是“基础存储模型”，可选项为可见的传输模型。 抽象模型的父模型，默认是“基础存储模型”，可选项为可见的抽象模型。 代理模型的父模型，无默认值，可选项为可见的存储模型和代理模型。 4.8 编辑模型 创建成功的模型，可以对其进行编辑，但只有部分信息支持编辑。 4.8.1 图模式编辑模型 图模式下，点击模型标题右侧的「编辑模型」按钮，即可在右侧弹出的抽屉中编辑模型信息。 4.8.2 表模式编辑模型 表模式下，点击模型信息标题右侧的「编辑模型」按钮，下方模型信息中可以被编辑修改的字段即由只读变为可编辑。 4.9 隐藏/可见模型 对于暂时不使用的模型，可以进行隐藏（隐藏后可再设置可见）的操作。 在其他设计器需要选择模型使用时，隐藏的模型将不被展示。对隐藏的模型再次操作可见后，即可选择到。 4.9.1 图模式隐藏/可见模型 图模式下，展开模型列表，模型列表中每个模型所在行的右侧，可点击隐藏/可见图标，以隐藏/可见该模型。 可见的模型常规展示，无特殊标识；隐藏后的模型在列表中将置灰展示。 4.9.1 表模式隐藏/可见模型 表模式下，模型信息左侧的模型列表中每个模型所在行的右侧，可点击隐藏/可见图标，以隐藏/可见该模型。 可见的模型常规展示，无特殊标识；隐藏后的模型在列表中将置灰展示。 4.10 删除模型 不再使用模型可以进行删除，删除时需要确保模型没有被其他设计器引用。删除成功后的模型将不在列表展示，且不可恢复，请谨慎操作。 4.10.1 图模式删除模型 图模式下，展开模型列表，模型列表中每个模型所在行的右侧，可点击删除图标，以删除该模型。 4.10.2 表模式删除模型 表模式下，模型信息左侧的模型列表中每个模型所在行的右侧，可点击删除图标，以删除该模型。 4.10.3 存在引用关系 如果删除的模型存在引用关系，则无法删除，并提示模型仍在使用。点击提示中的「查看模型引用」，可以查看这个模型引用情况。 5. 字段管理 在模型中，可以对字段进行增删改查等基础管理操作。 5.1 添加字段 每个模型中可以添加多个字段，手动添加的字段都为自定义字段。点击「添加字段」，右侧出现字段信息填写的抽屉，抽屉中包括：字段名称、字段业务类型、存储类型、长度（部分业务类型的字段无长度设置）。填写并保存成功后，字段即创建成功。 5.1.1 图模式添加字段 5.1.2 表模式添加字段 5.1.3 字段业务类型 添加字段时，支持设置16种基础类型的字段、支持设置4种关系类型字段。 基础类型：用户ID、整数、浮点数、金额、布尔型、文本、多行文本、富文本、日期时间、年份、日期、时间、数据字典、键值对、手机、邮箱； 字段为数据字典时需要选择一个数据字典。 关系类型：一对一、多对一、一对多、多对多 字段为关系类型字段时需要选择关联的模型。 5.1.4 多值字段 多值字段表示该字段可以存储或传输多个该业务类型的数据，非多值字段只能存储或传输单个该业务类型的数据。 5.1.5 存储类型 设置字段的存储类型：存储字段、传输字段 存储字段：用于查询和存储字段 传输字段：仅用于数据的组装与存储 5.2 编辑字段 创建成功的字段，可以对其进行编辑，但只有部分信息支持编辑。 字段长度和精度只能由小往大改，不能由大往小改。 关联关系的关联模型、关联字段、关系字段、中间模型，中间关系字段、中间关联字段、支持关联查询不可修改。 5.2.1 图模式编辑字段 图模式下，点击字段列表所在行右侧的「编辑字段」按钮，即可在右侧弹出的抽屉中编辑字段信息。 5.2.2 表模式编辑字段 表模式下，点击模型信息标题右侧的「编辑模型」按钮，下方模型中的字段都可以被展开编辑。 5.3 隐藏/可见字段 对于暂时不使用的字段，可以进行隐藏（隐藏后可再设置可见）的操作。 在其他设计器需要选择字段使用时，隐藏的字段将不被展示。对隐藏的字段再次操作可见后，即可选择到。 5.3.1 表模式隐藏/可见字段 表模式下，编辑模型时，字段所在行右侧可以操作隐藏/可见。 可见的字段常规展示，无特殊标识；隐藏的字段在列表中将置灰展示。 5.4 删除字段…
-
数据字典
1. 什么是数据字典 数据字典是一些固定字典项的集合，可作为多选或单选的选项，例如人员性别、员工属相、杭州市下属的行政区等都是数据字典。 选择一个应用/模块下的一个小模块，可以查看其中包含的自定义字典（自建的数据字典）和系统字典。可以通过导入或添加创建自定义字典。 2. 数据字典基本操作 删除：系统字典不支持删除，无法批量删除自定义数据字典，若数据字典已经被字段、页面等引用时，也无法删除这个数据字典。 隐藏/可见：自定义字典、系统字典都可以操作隐藏和可见，隐藏和可见不影响数据字典在字段、页面等处的使用。 查看引用关系：点击查看引用关系，展开弹窗，展示该数据字典和字段、视图的引用关系。 修改：若数据字典已经被引用，无法删除其中的字典项。若无引用关系则可以任意修改。 3. 数据字典导入 点击“导入数据字典”按钮，弹出窗口，可根据图中引导进行数据字典的导入。 在经典模式下，导入数据字典会新建数据字典。 在专家模式下，数据字典导入的模板中包含字段“字典编码”，若导入的字典编码不存在则会新建数据字典，若导入的字典编码已存在则会修改字典编码的设置，新建和修改的动作会校验是否符合规范。 4. 数据字典创建 4.1 专家模式（低代码模式） 字典项类型有“二进制、文本、整数”三种可选，选择二进制时，字典项值需要选择存储在数据库二进制中的第几位。系统根据字典项值去查找字典项名称，因此字典项值不可重复。 数据字典的api名称、代码名称、描述可不填，部分系统会赋默认值。 字典项中字典项名称和字典项值必填，api名称和字典项描述不填系统会赋默认值。 4.2 经典模式（无代码模式） 经典模式下只需要填写字典名称，添加字典项即可。系统会自动将字典项类型设置为“二进制”，并将字典项按照创建的先后顺序设置字典项值的位数。字典项类型、字典项值释义可参照专家模式的解释。
-
2.2 互联网架构作为最佳实践为何失效
如果把互联网架构比作社会主义，Oinone就是也要做有中国特色的社会主义，才能符合国情。 随着业务和生态的发展，企业对效率、性能、体验和智能化等方面的要求越来越高，但很多企业的系统面临着严重的系统架构落后和系统间割裂等问题，这些问题导致原有系统在业务发展下面临着效率和性能的双重挑战。与此同时，互联网平台的技术水平远远领先于传统企业系统，但是是否可以直接将互联网架构照搬到企业数字化转型中呢？显然，这是不合适的，因为互联网架构在企业数字化转型中面临着许多水土不服的问题。本章节将结合互联网中台架构的发展，分析这些问题的原因。 借鉴互联网中台理念 我们要先看互联网架构的发展，是如何一步步到今天提的中台架构概念的，每一步又解决了什么具体问题，我们以阿里架构变迁史为例来看下（如下图2-2所示）： 图2-2 阿里架构变迁史 在2009年，淘宝上线了五彩石项目，这标志着淘宝从单体应用向服务化应用的时代迈出了一步。那么，淘宝为什么要开发五彩石项目呢？因为当时淘宝面临两个非常严峻的问题，一个是性能问题，数据库连接不足，数据库成为了瓶颈；另一个是效率问题，当时淘宝有百余个研发人员，但核心系统只有一套测试、预发、线上环境，导致研发需求排队等待。在开始五彩石项目之前，淘宝还做了千岛湖项目，用来验证服务化架构的可行性，将用户中心独立出来。随后，淘宝开启了五彩石项目，目标是通过增加人力来提升效率，通过增加机器来提升性能。 随着淘宝的业务发展，他们又面临了一个问题：各个服务之间有很多重复的建设，效率低下。为了解决这个问题，淘宝开始从服务化转向平台化，并创立了“共享业务事业部”，将重复建设的公共业务分配给这个事业部，以避免成本浪费。这些公共业务包括商品平台、交易平台和结算平台等。平台化的目标是规避服务化没有规划导致的重复建设问题。 但是随着业务的快速发展，淘宝变成了一个拥有几十个事业部的巨型企业，而这带来了新的问题：效率问题。例如，如果需要在一个业务线上做出改动，需要与十几个平台进行沟通，这是非常低效的。同时，对于一个平台来说，需要面对来自不同事业部的需求，这需要平台研发人员具备理解和抽象所有业务线需求的能力，这让平台研发人员感觉回到了单体应用时代，所有的需求都要排队，即使增加人力也无法提高效率。这个问题主要表现在交易平台上。 为了解决这个问题，淘宝提出了中台的概念，中台是在一套规范下建立的，让具有专业技能的团队自主决策业务系统发展的平台。中台的目标是弱化平台的业务特性，提供通用能力。简而言之，就是将“共享业务”中的“业务”两个字去掉，只提供通用能力的平台 我们将每个阶段的核心目标总结为一句话： 从单体到服务：通过增加人员和机器来提高效率和性能； 从服务化到平台化：解决服务化阶段因缺乏规划而导致的重复建设问题； 平台化到中台化：在一套规范下，让各业务团队自行决定业务系统发展，适用于多个业务线或多个场景应用的独立发展。 类似地，在企业数字化转型过程中，也面临着类似的问题： 随着企业业务在线化，对系统性能和稳定性提出了更高的要求，但由于内部系统之间的割裂，导致很多重复建设。因此，我们需要进行服务化和平台化； 没有一个供应商能够解决企业所有的商业场景问题，所以需要多个供应商共同参与。我们可以将供应商类比为各业务线，在一套规范下让供应商或业务线自行决定业务系统的发展。 然而，阿里的中台架构方案并不能直接照搬到企业中。因为阿里的中台架构采用了平台共建模式，即让业务线基于平台设计的规范共同开发。这本质上还是平台主导模式，对企业来说历史包袱较大。在企业中，让不同背景的研发一起共建交易或商品平台是非常复杂的事情。平台化已经足够复杂，再加上共建会导致企业架构的负载过重，这对企业来说就不再是赋能，而是“内耗”。 互联网中台架构在企业实践中遇到的问题 在1.3《Oinone的生态思考》一文中，《与中台的渊源》部分提到，在阿里云为企业提供数字化项目时，客户经常会对以下三个问题提出质疑，这些问题非常突出： 1我们听说你们具备敏捷响应能力，但为什么改动需求如此缓慢？不仅所需时间更长，而且成本更高？ 2我们听说你们有能力中心，但为什么当我们引入新供应商或开发新场景时，前期建立的能力中心无法支持我们？ 3我们听说你们的性能很好，但为什么我们需要投入更多的物理资源来支持项目？ 在探讨互联网架构的适用性时，我想提出以下两个问题： 1企业应用程序的性能问题是否与互联网平台公司遇到的性能问题相同？ 2企业应用程序的开发效率问题是否与互联网平台公司遇到的效率问题相同？ 通过比较企业和互联网之间的差异，我们可以了解水土不服的核心原因。 企业 互联网 企业IT组织能力无法与数字化转型的速度匹配，缺乏足够的人才支持。为了提高开发效率，企业需要寻找工具和技术来降低开发难度，同时提高个人开发效率 互联网企业拥有众多优秀的人才，需要解决团队协作和知识共享的问题，即协同开发的效率。 企业无法制定并主导技术规范，这导致了能力复用的不足。为了提高效率和减少开发成本，企业需要建立统一的技术规范和标准，以便能力复用和组织协同。 互联网企业可以自定义技术规范，因此能力复用更易于保障。 企业往往当前业务量相对小，期望数字化建设能打动业务发展，对业务发展的预期比较高，所以企业的诉求是即满足当下成本效应又能兼顾未来对发展预期 互联网企业起步时的系统目标负载就高，通常会忽略资源起步门槛的问题，当然也可以通过自动扩容、云计算等方式来解决初期的负载问题。 表2-1从企业与互联网的对比，看水土不服的核心原因 我们可以看到企业和互联网架构在很多方面存在着不同的需求和问题。因此，在提供数字化服务时，Oinone需要注意与企业的组织能力进行匹配，并根据企业自身的特性来提供在线化的服务能力。这就像在社会主义制度下需要有中国特色一样，Oinone也需要有适合中国企业的特色。
-
流程类
1.流程类 1.1 审批 审批节点配置步骤： 添加审批节点 选择审批的模型和视图 设置审批人和通过方式 设置审批人在审批时的操作权限和数据权限 1.1.1 审批节点 审批节点只能放置在有数据可审批的流程链路上，审批分支只能放置在审批节点后。 1.1.2 审批模型和视图 可选的审批模型包含添加的审批节点之前的所有能获取到数据的模型。可选视图为该选择的数据模型关联的界面设计器中视图类型为表单的页面。 1.1.3 审批人和通过方式 审批人可在个人、部门、角色和模型中的字段里复选。当某人在不同类型人员选择中被重复选中，只会收到一次审批的代办。若为多人审批，审批是同步进行的。 单人审批： 通过方式：唯一通过方式，同意通过，拒绝否决 多人审批： 通过方式：或签/会签（默认或签） a. 或签（一名审批人同意或拒绝即可） 任意一位审批人操作通过或否决后流程就结束，其他审批人无法进入审批操作，但是会弹出消息提示审批结果。 场景：紧急且影响不大的审批可以由任意一位领导层或签。 b. 会签（需所有审批人同意才为同意，一名审批人拒绝即为拒绝） 场景：影响比较重大的审批，一票否决的形式决定是否通过。 c. 会签（一名审批人同意即为同意，需所有审批人拒绝才为拒绝） 场景：需要评估项目可操作性时，若有领导觉得有意义就通过，进入下一步评估，全员否决就否决项目。 1.1.4 操作&数据权限 操作权限 可设置是否必填拒绝原因、是否允许转交、是否允许加签、是否允许退回。 选择允许转交或允许加签之后，可选择添加人员的候选名单，不填默认所有人都可选。 选择允许退回后，可以选择退回到该审批节点之前的任意审批节点。ps：需所有审批人拒绝才为拒绝的会签不允许退回。 数据权限 选择视图后自动显示该视图下的数据字段，可选择的权限为查看、编辑、隐藏数据字段，默认可查看全部字段。 1.1.5 参与人重复 勾选参与人重复的场景时，满足场景的审批流程会由系统自动审批通过。 1.2 填写 当流程需要某些人提交数据才能继续时，可以使用填写这个动作。区别于数据类中的操作，填写这个动作只能修改当前触发模型中关联的视图表单，而数据类中的更新数据可以修改其他模型中的数据。 和审批动作相似，填写动作需要选择填写的模型和视图表单，需要选择填写人，可以选择添加转交权限。另外，填写动作必须包含一个及以上的可编辑的数据权限供操作人填写。
-
3.5.7.1 基础概念
模块(module) 概念 在 Oinone 系统的架构中，模块（module）是核心组成元素之一，可以被理解为域（domain）的一个具象化概念。模块的来源有两种：一种是基于后端代码定义，另一种是通过无代码新增。具体的代码定义方式，请参考“[占位符]”，而无代码定义的相关信息则可在“[占位符]”找到。在 Oinone 体系中，模块对应两种实体：模块和应用。 模块： 这是一类特定能力的集合，它可以依赖其他模块，也可以被其他模块依赖。 应用： 它是一种特殊的模块，具备模块的所有特性，并在此基础上可被终端用户访问。 使用 在前端开发中，module通常以应用的形式出现，它们往往对前端用户保持透明。在接下来的讨论中，我们主要围绕应用来探讨module的使用。从应用的角度出发，我们可以在前端开发中识别出以下几种典型使用场景，并通过具体的业务案例来加以说明 应用菜单扩展： 实现自定义母版来定义特定应用的菜单 表格布局扩展： 用于自定义布局的工具，以定义特定应用的表格布局 在这些场景中，我们着重实现了应用层面的隔离，确保每个模块都能在应用的维度上独立运作 查找 在实际业务开发中，有3个方式可以找到应用 浏览器url查找(查找速度快，可能不准) 图3-5-7-1 浏览器url查找模块(module) 接口返回查找 第一步找到截图类似请求 图3-5-7-2 接口找到viewActionQuery 第二步根据返回找应用 图3-5-7-3 接口返回查找模块(module) vue调试器选中对应的组件查找 图3-5-7-4 vue调试器查找模块(module) 推荐使用浏览器url查找，若与预期不符，可用另外两种方式查找 模型(model) 概念 在 Oinone 系统的架构中，模型（model）是另一个关键核心组成部分。模型在业务层面主要体现之一为数据库的实体表，它是承载业务实现的基础结构。要了解模型的详细介绍，请参考“[占位符]”，前端所用的模型，对应后端代码定义来说，代表的是模型的编码。 关于模型的定义，我们提供了两种方法： 代码定义： 对于需要通过编程实现的模型定义，您可以参考“[占位符]”来了解具体的代码实现方法； 无代码定义：如果您倾向于使用无代码工具来定义模型，具体的操作和流程可以在“[占位符]”中找到 使用 在前端开发中，模型是前端运行的必要条件，以下场景中，模型不直接感知: 视图渲染 页面之间跳转交互 与后端交互 以下场景中，模型会直接决定前端的渲染逻辑 母版扩展：为某模型扩展母版 布局扩展：为某模型扩展布局 页面扩展：为某模型扩展个性化页面 字段扩展: 扩展字段时加上模型的范围 动作扩展: 扩展动作时加上模型的范围 以上场景中，涵盖了前端工作的方方面面，在OInone体系中，模型不止是后端运行得基础，同样也决定了前端如何运行，那这样做有什么好处呢？ 前后端几乎不需要联调，联调的协议用模型来承载 前端无需定义路由、权限埋点 查找 在实际业务开发中，有3个方式可以找到模型 浏览器url查找 图3-5-7-5 浏览器url查找模型(model) 接口返回查找 第一步找到类似截图请求 图3-5-7-6 接口找到viewActionQuery 第二步根据返回找模型 图3-5-7-7 接口找到viewActionQuery vue调试器选中对应的组件查找 图3-5-7-8 vue调试器查找模型(model) 动作(action) 概念 动作(action)定义了终端用户得交互，它描述了前端与前端、前端与后端之间的交互。 动作涵盖了前端以下部分: 页面跳转(router) 调用后端接口 页内交互(打开弹窗、打开抽屉) 它有两部分的来源: 模型内定义动作 窗口动作(页面跳转、打开弹窗、打开抽屉) 服务器动作(调接口) 前端定义客户端动作，可自定义其它逻辑，例如: 把选中行的某一列数据复制一下 使用 动作的使用绝大部分的情况是由平台自动执行的，在平台执行不符合预期时可以使用自定义动作自行扩展 查找 vue调试器选中对应的组件查找 选中服务器动作(ServerAction) 图3-5-7-9 vue调试器查找服务器动作(ServerAction) 选中窗口动作(ViewAction) 图3-5-7-10 vue调试器查找窗口动作(ViewAction) 字段(field) 概念 在我们的后端模型中，字段（Field）是核心的定义元素，它们在数据库中表现为数据表的列。更重要的是，这些字段在前端应用中发挥着数据传输的关键作用。例如，当前端需要调用后端接口时，它会发送如下结构的数据： 图3-5-7-11 name字段数据举例 这里的 "name" 是一个字段实例，它连接了前后端的交互。在后端，该字段不仅用于数据存储，也参与逻辑运算。 字段在 Oinone 系统中的加强应用 在 Oinone 系统中，字段的功能得到了扩展。除了基本的前后端数据交互，字段的定义还直接影响前端的用户界面（UI）交互。例如： 前端交互组件的选择：前端交互组件的类型取决于字段的数据类型。对于 String 类型的 "name" 字段，前端会使用输入框来收集用户输入的 "张三"。 数据存储和类型定义：在后端，"name" 字段被明确定义为 String 类型，这决定了它如何存储和处理数据。 字段与前端组件定义的解耦 一个关键的设计原则是，前端组件的定义与具体的字段值或字段名（如 "name" 或 "张三"）不直接相关，而是基于字段的数据类型（此例中为 String）。这种设计实现了： 前端组件的一致性：确保所有组件的输入输出遵循同一数据类型（如 String）。 高度的组件复用性：在满足 UI 要求的前提下，任何 String 类型的字段都可以使用这种通用的组件设计。 使用 Oinone 系统中的视图与字段交互的灵活性 Oinone 系统为每种视图和字段类型（Ttype）提供了默认的交互模式。这不仅保证了前端工程启动时所有界面的即时展示，也为开发者带来了高度的灵活性和扩展能力。以下是这一设计理念的关键点： 1. 视图与字段交互的默认实现 每种视图都有对应字段类型（Ttype）的默认交互实现，确保用户界面一致且直观。这使得在前端工程启动时，所有界面能够无需额外配置即可正常展示。 2. 灵活性与扩展能力 尽管系统提供了默认的交互方式，开发者仍然拥有自定义这些交互方式的能力。这意味着开发者可以根据应用需求，设计更加贴合业务逻辑和用户体验的交互模式。 3. 覆盖和替换默认组件 最为重要的是，开发者不仅可以添加新的交互方式，还可以完全覆盖和替换系统的默认组件。这提供了极大的自由度，使开发者能够根据具体场景重新设计和实现界面组件，从而达到完全定制化的用户体验。 查找 vue调试器选中对应的组件查找 图3-5-7-12 vue调试器查找字段(field) 视图类型(viewType) 概念 在 Oinone 系统中，视图是模型在前端的具体表现形式。视图的核心组成和功能如下： 1. 组成要素 字段：视图中的字段代表了模型的数据结构，它们是界面上数据显示和交互的基础。 动作：视图包含的动作定义了用户可以进行的操作，如添加、编辑、删除等。 前端UI：视图的界面设计，包括布局、元素样式等，决定了用户的交互体验。 2. 数据源与交互 数据源：视图的数据直接来源于后端模型。这意味着前端视图展示的内容是根据后端模型中定义的数据结构动态生成的。 交互：视图不仅展示数据，还提供与数据交互的能力。这些交互也是基于后端模型定义的，包括数据的增删改查等操作。 3. 灵活性 视图可以灵活选择是否采用模型的交互。这意味着开发者可以根据需求决定视图仅展示模型的数据，或者同时提供与数据的交互功能。 使用 在 Oinone 系统中，用户可以通过无代码界面设计器轻松配置视图。系统内置了以下主要视图类型： 表格（Table） 表单（Form） 详情（Detail） 搜索（Search） 画廊（Gallery） 树（Tree） 界面设计器配置…