3.5.7.1 基础概念

模块(module)

概念

在 Oinone 系统的架构中,模块(module)是核心组成元素之一,可以被理解为域(domain)的一个具象化概念。模块的来源有两种:一种是基于后端代码定义,另一种是通过无代码新增。具体的代码定义方式,请参考“[占位符]”,而无代码定义的相关信息则可在“[占位符]”找到。在 Oinone 体系中,模块对应两种实体:模块和应用。

  • 模块: 这是一类特定能力的集合,它可以依赖其他模块,也可以被其他模块依赖。
  • 应用: 它是一种特殊的模块,具备模块的所有特性,并在此基础上可被终端用户访问。

使用

在前端开发中,module通常以应用的形式出现,它们往往对前端用户保持透明。在接下来的讨论中,我们主要围绕应用来探讨module的使用。从应用的角度出发,我们可以在前端开发中识别出以下几种典型使用场景,并通过具体的业务案例来加以说明

  • 应用菜单扩展: 实现自定义母版来定义特定应用的菜单
  • 表格布局扩展: 用于自定义布局的工具,以定义特定应用的表格布局

在这些场景中,我们着重实现了应用层面的隔离,确保每个模块都能在应用的维度上独立运作

查找

在实际业务开发中,有3个方式可以找到应用

  • 浏览器url查找(查找速度快,可能不准)

image.png

图3-5-7-1 浏览器url查找模块(module)

  • 接口返回查找

第一步找到截图类似请求

image.png

图3-5-7-2 接口找到viewActionQuery

第二步根据返回找应用

image.png

图3-5-7-3 接口返回查找模块(module)

  • vue调试器选中对应的组件查找

image.png

图3-5-7-4 vue调试器查找模块(module)

推荐使用浏览器url查找,若与预期不符,可用另外两种方式查找

模型(model)

概念

在 Oinone 系统的架构中,模型(model)是另一个关键核心组成部分。模型在业务层面主要体现之一为数据库的实体表,它是承载业务实现的基础结构。要了解模型的详细介绍,请参考“[占位符]”,前端所用的模型,对应后端代码定义来说,代表的是模型的编码。

关于模型的定义,我们提供了两种方法:

  • 代码定义: 对于需要通过编程实现的模型定义,您可以参考“[占位符]”来了解具体的代码实现方法;
  • 无代码定义:如果您倾向于使用无代码工具来定义模型,具体的操作和流程可以在“[占位符]”中找到

使用

在前端开发中,模型是前端运行的必要条件,以下场景中,模型不直接感知:

  • 视图渲染
  • 页面之间跳转交互
  • 与后端交互

以下场景中,模型会直接决定前端的渲染逻辑

  • 母版扩展:为某模型扩展母版
  • 布局扩展:为某模型扩展布局
  • 页面扩展:为某模型扩展个性化页面
  • 字段扩展: 扩展字段时加上模型的范围
  • 动作扩展: 扩展动作时加上模型的范围

以上场景中,涵盖了前端工作的方方面面,在OInone体系中,模型不止是后端运行得基础,同样也决定了前端如何运行,那这样做有什么好处呢?

  • 前后端几乎不需要联调,联调的协议用模型来承载
  • 前端无需定义路由、权限埋点

查找

在实际业务开发中,有3个方式可以找到模型

  • 浏览器url查找

image.png

图3-5-7-5 浏览器url查找模型(model)

  • 接口返回查找

第一步找到类似截图请求

image.png

图3-5-7-6 接口找到viewActionQuery

第二步根据返回找模型

image.png

图3-5-7-7 接口找到viewActionQuery

  • vue调试器选中对应的组件查找

image.png

图3-5-7-8 vue调试器查找模型(model)

动作(action)

概念

动作(action)定义了终端用户得交互,它描述了前端与前端、前端与后端之间的交互。

动作涵盖了前端以下部分:

  • 页面跳转(router)
  • 调用后端接口
  • 页内交互(打开弹窗、打开抽屉)

它有两部分的来源:

  • 模型内定义动作
  • 窗口动作(页面跳转、打开弹窗、打开抽屉)
  • 服务器动作(调接口)
  • 前端定义客户端动作,可自定义其它逻辑,例如: 把选中行的某一列数据复制一下

使用

动作的使用绝大部分的情况是由平台自动执行的,在平台执行不符合预期时可以使用自定义动作自行扩展

查找

  • vue调试器选中对应的组件查找
  • 选中服务器动作(ServerAction)

image.png

图3-5-7-9 vue调试器查找服务器动作(ServerAction)

  • 选中窗口动作(ViewAction)

image.png

图3-5-7-10 vue调试器查找窗口动作(ViewAction)

字段(field)

概念

在我们的后端模型中,字段(Field)是核心的定义元素,它们在数据库中表现为数据表的列。更重要的是,这些字段在前端应用中发挥着数据传输的关键作用。例如,当前端需要调用后端接口时,它会发送如下结构的数据:

图3-5-7-11 name字段数据举例

这里的 "name" 是一个字段实例,它连接了前后端的交互。在后端,该字段不仅用于数据存储,也参与逻辑运算。

字段在 Oinone 系统中的加强应用

在 Oinone 系统中,字段的功能得到了扩展。除了基本的前后端数据交互,字段的定义还直接影响前端的用户界面(UI)交互。例如:

  1. 前端交互组件的选择:前端交互组件的类型取决于字段的数据类型。对于 String 类型的 "name" 字段,前端会使用输入框来收集用户输入的 "张三"。

  2. 数据存储和类型定义:在后端,"name" 字段被明确定义为 String 类型,这决定了它如何存储和处理数据。

字段与前端组件定义的解耦

一个关键的设计原则是,前端组件的定义与具体的字段值或字段名(如 "name" 或 "张三")不直接相关,而是基于字段的数据类型(此例中为 String)。这种设计实现了:

  • 前端组件的一致性:确保所有组件的输入输出遵循同一数据类型(如 String)。
  • 高度的组件复用性:在满足 UI 要求的前提下,任何 String 类型的字段都可以使用这种通用的组件设计。

使用

Oinone 系统中的视图与字段交互的灵活性

Oinone 系统为每种视图和字段类型(Ttype)提供了默认的交互模式。这不仅保证了前端工程启动时所有界面的即时展示,也为开发者带来了高度的灵活性和扩展能力。以下是这一设计理念的关键点:

1. 视图与字段交互的默认实现

每种视图都有对应字段类型(Ttype)的默认交互实现,确保用户界面一致且直观。这使得在前端工程启动时,所有界面能够无需额外配置即可正常展示。

2. 灵活性与扩展能力

尽管系统提供了默认的交互方式,开发者仍然拥有自定义这些交互方式的能力。这意味着开发者可以根据应用需求,设计更加贴合业务逻辑和用户体验的交互模式。

3. 覆盖和替换默认组件

最为重要的是,开发者不仅可以添加新的交互方式,还可以完全覆盖和替换系统的默认组件。这提供了极大的自由度,使开发者能够根据具体场景重新设计和实现界面组件,从而达到完全定制化的用户体验。

查找

  • vue调试器选中对应的组件查找

image.png

图3-5-7-12 vue调试器查找字段(field)

视图类型(viewType)

概念

在 Oinone 系统中,视图是模型在前端的具体表现形式。视图的核心组成和功能如下:

1. 组成要素

  • 字段:视图中的字段代表了模型的数据结构,它们是界面上数据显示和交互的基础。
  • 动作:视图包含的动作定义了用户可以进行的操作,如添加、编辑、删除等。
  • 前端UI:视图的界面设计,包括布局、元素样式等,决定了用户的交互体验。

2. 数据源与交互

  • 数据源:视图的数据直接来源于后端模型。这意味着前端视图展示的内容是根据后端模型中定义的数据结构动态生成的。
  • 交互:视图不仅展示数据,还提供与数据交互的能力。这些交互也是基于后端模型定义的,包括数据的增删改查等操作。

3. 灵活性

  • 视图可以灵活选择是否采用模型的交互。这意味着开发者可以根据需求决定视图仅展示模型的数据,或者同时提供与数据的交互功能。

使用

在 Oinone 系统中,用户可以通过无代码界面设计器轻松配置视图。系统内置了以下主要视图类型:

  1. 表格(Table)

  2. 表单(Form)

  3. 详情(Detail)

  4. 搜索(Search)

  5. 画廊(Gallery)

  6. 树(Tree)

界面设计器配置

  • 简便配置:系统提供无代码界面设计器,使用户能够轻松配置内置视图。
  • 系统支持视图:表格、表单、详情等内置视图类型可以直接通过设计器进行配置,包括字段的展示和交互。

自定义页面

  • 个性化需求:如果用户需求超出系统内置视图的范围,可以选择创建自定义页面。
  • 高级专家认证:高级专家认证的用户,理解透前端元数据,可以将自定义页面转化为内置视图之一。
  • 与无代码结合:高级专家认证用户可以结合无代码界面设计器,将个性化的页面与系统内置视图深度融合。

通过这种深度的整合和自定义的能力,系统提供了更灵活、更个性化的前端界面配置和设计体验。

查找

  • 浏览器url查找

image.png

图3-5-7-13 浏览器url查找视图类型(viewType)

-vue调试器查找

image.png

图3-5-7-14 vue调试器查找视图类型(viewType)

-代码查找

-找到如下代码,点击后看所有类型的定义

image.png

图3-5-7-15 SPI中找到注册的视图类型(viewType)

image.png

图3-5-7-16 点击查看所有视图类型(viewType)定义

字段类型(ttype)

概念

在 Oinone 系统中,每个字段的数据类型都与后端的 ttype(类型)一一对应。这意味着每个前端字段类型都有其对应的后端数据类型。开发者可以根据这些 ttype 定义某类类型的组件,以便在前端实现对应类型的数据展示和交互

使用

在 Oinone 系统中,字段类型的前后端协议已经枚举了所有存在的业务类型,满足了多样化的业务场景需求。这些字段类型在前端是只读的,前端开发者只能查看,而不能定义和变更。

内置字段类型包括:

  1. 字符串(String)

  2. 文本(Text)

  3. HTML

  4. 电话号码(Phone)

  5. 电子邮件(Email)

  6. 整数(Integer)

  7. 长整数(Long)

  8. 浮点数(Float)

  9. 货币(Currency)

  10. 日期时间(DateTime)

  11. 日期(Date)

  12. 时间(Time)

  13. 年份(Year)

  14. 布尔(Boolean)

  15. 枚举(Enum)

  16. 映射(Map)

  17. 关联(Related)

  18. 一对一(OneToOne)

  19. 一对多(OneToMany)

  20. 多对一(ManyToOne)

  21. 多对多(ManyToMany)

  22. 对象(Object)

这些内置字段类型涵盖了多种业务场景,同时在前端上的只读特性确保了数据类型的一致性和稳定性。

查找

  • 每一个字段必然有ttype,选中字段查看对应的ttype

image.png

图3-5-7-17 vue调试器查找字段ttype

部件(widget)

概念

在 Oinone 系统中,widget 是字段组件的另一个筛选条件,可以被理解为组件的别名。当字段没有指定别名时,该组件将覆盖所有符合 ttype 和 viewType 条件的组件。widget 适用于在特定页面中定义组件的出现,提供了更灵活的定制能力。

使用

使用场景:

  1. 组件别名:widget 可以被视为字段组件的别名,用于在配置中标识和引用特定的组件。

  2. 条件筛选:通过 widget,可以在部分页面中定义组件的出现,而不影响其他页面的配置。

注意事项:

  • 默认覆盖:当字段未指定 widget 时,该组件将覆盖所有符合 ttype 和 viewType 条件的组件。

  • 页面定制:使用 widget,开发者可以更精细地定制组件在不同页面中的呈现方式。

通过合理使用 widget,系统提供了更加灵活和个性化的组件配置方式,使得不同页面可以呈现不同的组件。

查找

在 Oinone 系统中,用户可以选择查看当前字段对应的 widget。这个操作并非必选项,若未选择,系统将使用默认的字段渲染方式。然而,若用户选择了 widget,它必须与当前字段相同,以确保正确覆盖当前字段的渲染方式。

操作步骤:

  1. 选中字段:在字段配置界面,用户可以选择特定字段进行配置。

  2. 查看 Widget:用户可以查看当前字段对应的 widget,以了解当前字段的渲染方式。

  3. 非必选项:查看当前字段的 widget 是一个非必选项,用户可以选择使用默认的字段渲染方式。

  4. Widget 一致性:如果用户选择了 widget,确保它与当前字段相同,以便正确覆盖当前字段的渲染方式。

通过这种设计,系统提供了灵活的字段配置选项,同时保证了渲染方式的一致性和准确性。

image.png

图3-5-7-18 vue调试器查找部件(widget)

多值(multi)

概念

在 Oinone 系统中,multi 是字段的一个扩充选项,主要解决普通数据类型字段存储多个值的情况。举例来说,如果某个字段定义为 String 类型,后端存储的是单个图片的地址,而需要上传多张图片时,后端需要将该字段定义为 List<String> 类型。在前端,multi 允许将普通数据类型的 String 转换为 Array<String> 进行传输。

使用

在 Oinone 系统中,前端使用时需要在字段注册上标记 multi。这个标记的取值(true 或 false)并非由前端决定,而是由后端在定义字段时确定的。前端只具有查看权限,无法变更这个标记。

操作步骤:

  1. multi 标记:multi 标记表示该字段是否支持存储多个值,由后端在字段定义时决定,缺省时默认为false。

  2. 前端权限:前端只有查看权限,不能在字段注册时变更 multi标记的取值。

查找

  • 每一个字段必然有multi,选中字段查看对应的multi,若没有声明,默认为false

image.png

图3-5-7-19 vue调试器查找多值(multi)

Oinone社区 作者:史, 昂原创文章,如若转载,请注明出处:https://doc.oinone.top/oio4/9264.html

访问Oinone官网:https://www.oinone.top获取数式Oinone低代码应用平台体验

(0)
史, 昂的头像史, 昂数式管理员
上一篇 2024年5月23日 am9:14
下一篇 2024年5月23日 am9:16

相关推荐

  • 节点动作

    节点动作为触发和结束结点中间的动作,点击节点名称可以进行修改。

    Oinone 7天入门到精通 2024年6月20日
    1.1K00
  • 4.2.8 自定义组件与设计器结合(新)

    界面设计器组件管理页面添加组件 进入组件的元件管理页面 点击“添加元件” 设计元件的属性 这里以是否“显示清除按钮”作为自定义属性从左侧拖入到中间设计区域,然后发布 点击“返回组件” 鼠标悬浮到卡片的更多按钮的图标,弹出下拉弹出“低无一体”的按钮 在弹窗内点击“生成SDK”的按钮 生成完成后,点击“下载模板工程” 解压模板工程kunlun-sdk.zip 解压后先查看README.MD,了解一下工程运行要点,可以先运行 npm i 安装依赖 再看kunlun-plugin目录下已经有生成好的组件对应的ts和vue文件 下面在vue文件内增加自定义代码,可以运行 npm run dev 在开发模式下调试看效果 <template> <div class="my-form-string-input"> <oio-input :value="realValue" @update:value="change" > <template #prepend>MyPrepend</template> </oio-input> </div> </template> <script lang="ts"> import { defineComponent, ref } from 'vue'; import { OioInput } from '@kunlun/vue-ui-antd'; export default defineComponent({ name: 'customField1', components: { OioInput }, props: { value: { type: String }, change: { type: Function }, }, setup(props) { const realValue = ref<string | null | undefined>(props.value); return { realValue }; } }); </script> <style lang="scss"> .my-form-string-input { border: 1px solid red; } </style> 确定改好代码后运行 npm run build,生成上传所需的js和css文件 可以看到 kunlun-plugin目录下多出了dist目录,我们需要的是 kunlun-plugin.umd.js 和 kunlun-plugin.css 这2个文件 再次回到组件的“低无一体”管理弹窗页面,上传上面生成的js和css文件,并点击“确定”保存,到这里我们的组件就新增完成了。 下面我们再到页面设计器的页面中使用上面设计的组件(这里的表单页面是提前准备好的,这里就不介绍如何新建表单页面了) 将左侧组件库拉直最底部,可以看到刚刚新建的组件,将其拖至中间设计区域,我们可以看到自定义组件的展示结果跟刚刚的代码是对应上的(ps: 如果样式未生效,请刷新页面查看,因为刚刚上传的js和css文件在页面初始加载的时候才会导入进来,刚刚上传的动作未导入新上传的代码文件),再次点击设计区域中的自定义组件,可以看到右侧属性设置面板也出现了元件设计时拖入的属性。 最后再去运行时的页面查看效果,与代码逻辑一致!

    2024年5月23日
    1.2K00
  • 业务域

    1. 业务域介绍 业务域是根据业务域对集成应用、开放接口进行归类管理。在创建集成应用、开发接口时,可选择归属的业务域。 操作入口:集成设计器——业务域。 2. 业务域管理 业务域管理提供新增、删除、搜索操作。 2.1 业务域列表 支持按照编码、名称、描述搜索业务域。 2.2 新增业务域 新增业务域:输入业务域名称、描述新增。 2.3 删除业务域 当前业务域未被其他数据记录引用时,可删除成功,反之如果被引用了,不允许删除。

    2024年6月20日
    1.4K00
  • 1.3 Oinone的生态思考

    以“企业级软件生态”的方式去帮助企业建立“一站式的商业智能软件”。 通过观察信息化到数字化的软件行业发展历程(如下图1-3所示),我们可以发现,企业真正需要的是一站式的软件产品。然而,一站式的软件产品往往都是从单个领域的需求满足开始,这在信息化时代和数字化时代都是如此。在信息化时代,以ERP为终点的一站式趋势逐渐形成;而在数字化时代,中台概念的提出则标志着一站式的趋势重新开始。本文将从企业数字化转型所面临的困境出发,探讨Oinone的生态思考。 图1-3 从信息化到数字化软件行业发展历程 1.3.1 与中台的渊源 中台概念的提出标志着企业数字化改造进入了一个新的时代。随着数字化转型不断深入,企业面临着严重的数据割裂、系统隔离等问题。在这样的背景下,“敏捷响应,低成本地快速创新”成为了推动一站式商业智能软件的内在诉求。需要澄清的是,互联网中台架构只是一种企业解决数据割裂、系统隔离,建立一站式商业智能软件的技术概念之一,并不是技术标准。而且这种方式只适用于企业自建模式。在多供应商环境下,则会适得其反,导致建立更复杂的烟囱系统。 阿里于15年提出中台架构概念,抓住了企业数字化转型的核心诉求,即“敏捷响应,低成本快速创新”。然而,阿里作为一家生态公司,在16年时基本上是带着合作伙伴来给企业交付,但由于伙伴对互联网技术的理解和能力的限制,基本上都做得不好,甚至失败。在2017年,阿里成立了原生交付团队,希望能够树立一些标杆案例。我和公司的核心成员也都来自于这个团队。在做完几个客户后,我发现阿里也做不好,但这次做不好的原因不是技术不行或项目上不了线,而是上线以后预期的效果没有达到,其本质是企业的IT组织能力无法驾驭复杂的互联网中台架构。当无法驾驭的时候,所谓的目标“敏捷响应,快速创新”就无从说起了。结果客户会反馈以下三类问题: 不是说敏捷响应吗?为什么改个需求这么慢,不但时间更长,付出的成本也更高了?是因为中台架构需要一定的技术能力和经验才能有效地应用,就像一个只会骑自行车的人给他一辆汽车或者飞机,他也不能驾驭它们,更不用说是手动挡的。 不是说能力中心吗?当引入新供应商或有新场景开发的时候,为什么前期做的能力中心不能支撑了?是因为能力中心是一种面向业务的能力组织方式,它将不同的业务能力抽象出来,以服务的形式对内提供。然而,由于业务场景的差异,不同的业务需要的能力也会不同,因此能力中心需要不断迭代和升级。对于新引入的供应商或新场景开发,需要根据实际情况对能力中心进行定制化和扩展化,但谁来负责呢?新项目的供应商还是客户自己? 不是说性能好吗?为什么我投入的物理资源更多了?是因为中台架构采用微服务来解决单点瓶颈问题,提高系统性能和可用性,但是在初始阶段,投入的资源可能会更多。每个模块至少需要两个实例来保障高可用性,因此物理资源的投入量可能会比以前更多。 1.3.2 找解决方案 在考虑解决方案之前,我们需要思考企业数字化软件的最终状态将是什么样子。目前有两种主要的方案(如下图1-4所示): 第一种是以自建研发团队为核心。中国的大型企业已经开始尝试这种模式,看起来似乎是一个时下比较流行的可行性方案。然而,绝大多数企业由于成本、人才团队等原因而难以坚持下去,只能与供应商合作开发。 第二种是以供应商为核心。由于大多数企业无法选择第一种路径,他们必须接受目前分散的情况,并通过系统集成尽可能拉通各个系统。尽管如此,在数字化时代中,真正意义上的一站式商业智能软件供应商还未出现。 图1-4 企业数字化桎梏和囹圄 对企业来说,这两种方案都非常艰难,但在大规模数字化历程中又不得不做出选择。此外,我们还能清晰看到以下几点: "敏捷响应,低成本地快速创新"成为企业推动一站式商业智能软件的内在诉求 目前没有一家软件供应商能满足企业所有外围商业场景,也不可能有这样的供应商 绝大部分企业需要软件供应商,而不是自建 如何突破这种局面也成为中国软件行业发展的一个机遇。因此,我的思考是: 我们的目标不是依托于提升研发人员的能力,而是降低互联网架构的门槛,让更多企业真正拥有“敏捷响应,低成本快速创新”的能力。 我们的目标不是输出中台方法论,而是提供中台建设的技术平台。 我们的目标不是只服务大企业,而是真正赋能不同IT组织能力的企业,让它们都具备持续创新的能力。 今天,许多中台软件公司告诉企业:“中台是持续演进和快速迭代的过程,因此企业需要组建中台架构团队来实现,而他们则通过中台项目落地将中台建设方法论传授给企业。”这句话的前半部分是正确的,因为我们之前提到企业需要具备敏捷响应业务的能力,即应变能力,因为应变是不断变化的。然而,后半部分是不正确的,因为今天的企业已经有能力组建团队,那么这些中台软件公司到底有什么用呢?企业真的缺少方法论吗?在19年,我就提出了自己的看法:没有低代码能力的中台公司都在收取智商税,都在欺诈,因为很多企业根本找不到足够懂互联网架构的人才。明白流氓在哪里了吗?这些流氓公司赚了很多钱,最后责怪企业无法招到人才,这是企业的责任。因此,仍然认为“最好的赋能是降低门槛,而不是让客户提高技术水平”。 最终,我们得出了一个服务模式的想法:构建企业级的软件生态。企业级软件生态的确切定义是:通过开放的方式,让企业本身以及不同的软件供应商共同参与,遵循相同的技术和数据规范,打造一体化、无需集成的各类企业级软件。如果要打造企业级软件生态,我们列出了六个要点(如下图1-5所示)。 图1-5 打造企业级软件生态需要具备的六大能力 我很幸运地有机会通过“企业级软件生态”的方式,为企业建立“一站式的商业支持平台”提供帮助。我们的Oinone平台结合了低代码开发、通用数据模型和业务产品的优势(如下图1-6所示)。 图1-6 Oinone = 低代码开发平台 + 通用数据模型 + 业务产品 我们对Oinone一站式低代码商业支撑平台展开介绍,它大致分为4部分: 以低代码开发平台为基础,输出具备互联网架构下的软件快速开发标准。这可以帮助企业快速构建符合互联网架构标准的应用程序,从而实现快速响应和低成本创新。 以通用数据模型为基础,满足不同软件基于同一套数据标准的扩展能力。这可以确保不同软件系统之间的数据兼容性和互操作性,避免数据孤岛和信息隔离。 在业务产品层面上,企业和伙伴基于相同的技术标准和数据标准共同提供解决方案。这可以帮助企业和伙伴共同开发出符合标准的商业支撑平台,以提高业务效率和创新能力。 最后是无代码设计器,用于满足项目开展中,超出业务标品范围之外的需求,或者针对标品的临时需求。这可以帮助业务人员在不需要专业软件支持的情况下,自主解决业务需求,并支持部门间的协同工作。 1.3.3 生态建设 Oinone致力于打造全球最大的无需集成的商业应用程序及其生态系统,通过开源内核、汇集数千名开发人员和业务专家,为企业提供成本效益、一体化、模块化的解决方案,解决所有商业需求,让不同技术之间的合作变得简单易行,摆脱烦恼的集成问题。 在客户和场景领域,我们严格限定了自身的专注领域。针对超大型头部企业,我们专注于树立标杆,而对于大、中、小型企业,则交由我们的伙伴来支持。小微企业可以通过我们的开源社区版获得覆盖。在企业数字化转型的核心领域中,我们的解决方案涵盖了数字化交易场景、全渠道订单履约场景、数字化采购场景、数字化营销等产品。在其他领域,我们完全交由伙伴来建设。由于我们自身在企业协同商务领域拥有深厚的背景,因此在该领域提供的产品拥有特别的优势。 企业数字化转型核心领域 图1-7 企业数字化转型核心领域

    2024年5月23日
    1.7K00
  • 3.5.7.5 自定义动作

    动作是什么 动作(action)描述了终端用户的各种操作。这些操作可以涉及多个层面,包括但不限于: 页面间的跳转:用户可以通过动作从一个页面跳转到另一个页面。 业务交互:动作可以触发与后端服务的交互,例如提交表单、请求数据等。 界面操作:动作可以用于打开模态对话框、抽屉(侧边栏)等界面元素。 作用场景 Oinone 平台内置了一系列的基础动作,默认实现了常见的功能,如页面跳转、业务交互和界面操作等。这些内置动作旨在满足大多数标准应用场景的需求,简化开发过程,提高开发效率。以下是一些常见的内置动作示例: 页面跳转:允许用户在不同页面间导航。 业务交互:支持与后端服务的数据交互,如提交表单。 界面操作:提供动态返回上一页、校验表单、关闭弹窗等。 自定义动作的需求场景 尽管内置动作覆盖了许多常规需求,但在某些复杂或特定的业务场景中,可能需要更加个性化的处理。这些场景可能包括: 特殊的业务逻辑:需要执行不同于标准流程的特定业务操作。 个性化的用户界面:标准的 UI 组件无法满足特定的设计要求。 高级交互功能:需要实现复杂的用户交互和数据处理。 扩展和定制动作 为了满足这些特定需求,Oinone 平台支持通过继承和扩展来自定义动作。开发者可以通过以下步骤实现自定义动作: 继承基类:从平台提供的动作基类继承,这为自定义动作提供了基础框架和必要的接口。 实现业务逻辑:在继承的基础上,添加特定的业务逻辑实现。 自定义界面:根据需要调整或完全重写界面组件,以符合特定的UI设计。 集成测试:确保自定义动作在各种情况下的稳定性和性能。 最佳实践 明确需求:在进行扩展之前,清楚地定义业务需求和目标。 重用现有功能:尽可能利用平台的内置功能和组件。 保持一致性:确保自定义动作与平台的整体风格和标准保持一致。 充分测试:进行全面的测试,确保新动作的稳定性和可靠性。 案例分析 假设有一个场景,需要一个特殊的数据提交流程,该流程不仅包括标准的表单提交,还涉及复杂的数据验证和后续处理。在这种情况下,可以创建一个自定义动作,继承基础动作类并实现特定的业务逻辑和用户界面。 自定义动作 自定义跳转动作 示例工程目录 以下是需关注的工程目录示例,main.ts更新导入./action,action/index.ts更新导出./custom-viewactioin: 图3-5-7-24 自定义跳转动作工程目录示例 步骤 1: 创建自定义动作类 首先,您创建了一个名为 CustomViewAction 的类,这个类继承自 RouterViewActionWidget。这意味着自定义动作是基于路由视图动作的,这通常涉及页面跳转或导航。 import {ActionWidget, RouterViewActionWidget, SPI} from '@kunlun/dependencies'; import CustomViewActionVue from './CustomViewAction.vue'; @SPI.ClassFactory( ActionWidget.Token({ model: 'resource.ResourceCity', name: 'redirectCreatePage' }) ) export class CustomViewAction extends RouterViewActionWidget { public initialize(props) { super.initialize(props); this.setComponent(CustomViewActionVue); return this; } } 图3-5-7-24 自定义跳转动作组件(TS)代码示例 @SPI.ClassFactory: 这是一个装饰器,用于向平台注册这个新的动作。 ActionWidget.Token: 通过这个Token,指定了这个动作与特定模型 (resource.ResourceCity) 关联,并给这个动作命名 (redirectCreatePage). 步骤 2: 初始化和设置组件 在 initialize 方法中,调用了父类的初始化方法,并设置了自定义的 Vue 组件。 public initialize(props) { super.initialize(props); this.setComponent(CustomViewActionVue); return this; } 图3-5-7-24 初始化和设置组件 步骤 3: 定义 Vue 组件 在 CustomViewAction.vue 文件中,定义了自定义动作的视觉表示。 <template> <div class="view-action-wrapper"> 自定义挑战跳转动作 </div> </template> <script lang="ts"> import { defineComponent } from 'vue' export default defineComponent({ inheritAttrs: false, name: 'ViewActionComponent' }) </script> <style lang="scss"> .view-action-wrapper { } </style> 图3-5-7-24 自定义跳转动作组件(Vue)代码示例 步骤 4: 效果如下 图3-5-7-24 自定义跳转动作效果示例 自定义服务器动作 示例工程目录 以下是需关注的工程目录示例,action/index.ts更新导出./custom-serveraction: 图3-5-7-24 自定义服务器动作工程目录示例 步骤 1: 创建自定义动作类 首先, 创建了一个名为 CustomServerAction 的类,这个类继承自 ServerActionWidget。这表明您的自定义动作主要关注服务器端的逻辑。 import {ActionWidget, ServerActionWidget, SPI, Widget} from '@kunlun/dependencies'; import CustomServerActionVue from './CustomServerAction.vue'; @SPI.ClassFactory( ActionWidget.Token({ model: 'resource.ResourceCity', name: 'delete' })…

    2024年5月23日
    1.1K00

Leave a Reply

登录后才能评论