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低代码应用平台体验

Like (0)
史, 昂's avatar史, 昂数式管理员
Previous 2024年5月23日 am9:14
Next 2024年5月23日 am9:16

相关推荐

  • 5.4 基础支撑之商业关系域

    PamirsPartner作为商业关系与商业行为的主体,那么PamirsPartner间的关系如何描述,本文将介绍两种常见的设计思路,从思维和实现两方面进行对比,给出oinone为啥选择关系设计模式的原因。 一、两种设计模式对比 设计模式思路介绍 角色设计模式思路介绍 从产品角度枚举所有商业角色,每个商业角色对应一个派生的商业主体,并把主体间的关系类型进行整理。 图5-4-1 角色设计模式 关系设计模式思路介绍 从产品角度枚举所有商业角色,每个商业角色对应一个派生的主体间商业关系 图5-4-2 关系设计模式 设计模式对应实现介绍 角色设计模式实现介绍 不单商业主体需要扩展,关系也要额外维护,可以是字段或是关系表。一般M2O和O2M字段维护,M2M关系表维护。 创建合同场景中甲方选择【商业主体A】,乙方必须是【商业主体A】有关联的经销商、分销商、零售商、供应商等,则在角色设计模式下就非常麻烦,因为关系都是独立维护的 图5-4-3 角色设计模式实现介绍 关系设计模式实现介绍 只需维护商业关系扩展 同时在设计上收敛了商业关系,统一管理应对不同场景都比较从容 图5-4-4 关系设计模式实现介绍 二、oinone商业关系的默认实现 首先oinone的商业关系选择关系设计模式 其次模型上采用多表继承模式,父模型上维护核心字段,子模型维护个性化字段。

    2024年5月23日
    1.8K00
  • 7.1 设计器总览

    设计器转为非专业研发设计,在Oinone3.0版本中已经完成元数据完整在线化,真正做到低无一体。对于设计器的定位我们开篇就介绍过,它是LCDP的产品化呈现,是冰山露在外面大家看得到的,核心还是在LCDP本身。我们先目睹下设计器的一些产品页面,如您有想体验,可以在Oinone官网注册 模型设计器 Oinone以模型为驱动,当有模型、数据字典、数据编码等设计功能,我们就可以完整地定义产品数据模型,模型设计器整体呈现区别于普通ER图,以当前模型为核心视角展开,可以点击关联模型切换主视角。这样的好处在于突出当前设计,聚焦设计本身。同时模型上预留了几个核心入口如:分类管理、继承拓扑图、页面设计、逻辑设计等。另外我们在体验上区分了专家模式和经典模式,顾名思义,专家模式的功能会更加丰富,对专业知识的要求也会更高。专家模式下一般会增加一些跟业务无关的配置如:索引设置等调优行为 逻辑设计器 从图灵完备的角度上说,要支持功能越完备,使用越复杂。我们优先从图灵完备的角度出发,所以我们第一版逻辑设计器相对比较复杂,第二版本规划中会类似模型设计器推出专家版和经典版。 界面设计器 界面设计器第一版会先支撑后端页面在线自定义,后边将陆续推出前端页面、多端能力。为了支持多端和2C页面的设计,我们对前后端协议做了比较大的改造。目前设计器已经支持完全基于V3的前后端协议。 数据可视化 数据可视化支持从内部系统模型获取数据内容后,根据业务需求自定义图表,目的是为企业提供更高效的数据分析工具。 与市场同类产品相比,我们的数据可视化产品:不需要前置维护数据源、进行数据转换;可智取业务系统模型,系统自动解析选择的模型、接口、表格中的字段后进行数据分析;降低对数据分析人员研发能力要求的同时,也提升了数据分析的效率。 流程设计器 Oinone流程设计器为业务流程和审批流程提供了可自动执行的流程模型:通过定义流转过程中的各个动作、规则,以此实现流程自动化。在Oinone流程设计器中,流程可以跨应用设计,不同应用的模型之间可以通过同一流程执行。

    2024年5月23日
    1.9K00
  • 2.2 互联网架构作为最佳实践为何失效

    如果把互联网架构比作社会主义,Oinone就是也要做有中国特色的社会主义,才能符合国情。 随着业务和生态的发展,企业对效率、性能、体验和智能化等方面的要求越来越高,但很多企业的系统面临着严重的系统架构落后和系统间割裂等问题,这些问题导致原有系统在业务发展下面临着效率和性能的双重挑战。与此同时,互联网平台的技术水平远远领先于传统企业系统,但是是否可以直接将互联网架构照搬到企业数字化转型中呢?显然,这是不合适的,因为互联网架构在企业数字化转型中面临着许多水土不服的问题。本章节将结合互联网中台架构的发展,分析这些问题的原因。 借鉴互联网中台理念 我们要先看互联网架构的发展,是如何一步步到今天提的中台架构概念的,每一步又解决了什么具体问题,我们以阿里架构变迁史为例来看下(如下图2-2所示): 图2-2 阿里架构变迁史 在2009年,淘宝上线了五彩石项目,这标志着淘宝从单体应用向服务化应用的时代迈出了一步。那么,淘宝为什么要开发五彩石项目呢?因为当时淘宝面临两个非常严峻的问题,一个是性能问题,数据库连接不足,数据库成为了瓶颈;另一个是效率问题,当时淘宝有百余个研发人员,但核心系统只有一套测试、预发、线上环境,导致研发需求排队等待。在开始五彩石项目之前,淘宝还做了千岛湖项目,用来验证服务化架构的可行性,将用户中心独立出来。随后,淘宝开启了五彩石项目,目标是通过增加人力来提升效率,通过增加机器来提升性能。 随着淘宝的业务发展,他们又面临了一个问题:各个服务之间有很多重复的建设,效率低下。为了解决这个问题,淘宝开始从服务化转向平台化,并创立了“共享业务事业部”,将重复建设的公共业务分配给这个事业部,以避免成本浪费。这些公共业务包括商品平台、交易平台和结算平台等。平台化的目标是规避服务化没有规划导致的重复建设问题。 但是随着业务的快速发展,淘宝变成了一个拥有几十个事业部的巨型企业,而这带来了新的问题:效率问题。例如,如果需要在一个业务线上做出改动,需要与十几个平台进行沟通,这是非常低效的。同时,对于一个平台来说,需要面对来自不同事业部的需求,这需要平台研发人员具备理解和抽象所有业务线需求的能力,这让平台研发人员感觉回到了单体应用时代,所有的需求都要排队,即使增加人力也无法提高效率。这个问题主要表现在交易平台上。 为了解决这个问题,淘宝提出了中台的概念,中台是在一套规范下建立的,让具有专业技能的团队自主决策业务系统发展的平台。中台的目标是弱化平台的业务特性,提供通用能力。简而言之,就是将“共享业务”中的“业务”两个字去掉,只提供通用能力的平台 我们将每个阶段的核心目标总结为一句话: 从单体到服务:通过增加人员和机器来提高效率和性能; 从服务化到平台化:解决服务化阶段因缺乏规划而导致的重复建设问题; 平台化到中台化:在一套规范下,让各业务团队自行决定业务系统发展,适用于多个业务线或多个场景应用的独立发展。 类似地,在企业数字化转型过程中,也面临着类似的问题: 随着企业业务在线化,对系统性能和稳定性提出了更高的要求,但由于内部系统之间的割裂,导致很多重复建设。因此,我们需要进行服务化和平台化; 没有一个供应商能够解决企业所有的商业场景问题,所以需要多个供应商共同参与。我们可以将供应商类比为各业务线,在一套规范下让供应商或业务线自行决定业务系统的发展。 然而,阿里的中台架构方案并不能直接照搬到企业中。因为阿里的中台架构采用了平台共建模式,即让业务线基于平台设计的规范共同开发。这本质上还是平台主导模式,对企业来说历史包袱较大。在企业中,让不同背景的研发一起共建交易或商品平台是非常复杂的事情。平台化已经足够复杂,再加上共建会导致企业架构的负载过重,这对企业来说就不再是赋能,而是“内耗”。 互联网中台架构在企业实践中遇到的问题 在1.3《Oinone的生态思考》一文中,《与中台的渊源》部分提到,在阿里云为企业提供数字化项目时,客户经常会对以下三个问题提出质疑,这些问题非常突出: 1我们听说你们具备敏捷响应能力,但为什么改动需求如此缓慢?不仅所需时间更长,而且成本更高? 2我们听说你们有能力中心,但为什么当我们引入新供应商或开发新场景时,前期建立的能力中心无法支持我们? 3我们听说你们的性能很好,但为什么我们需要投入更多的物理资源来支持项目? 在探讨互联网架构的适用性时,我想提出以下两个问题: 1企业应用程序的性能问题是否与互联网平台公司遇到的性能问题相同? 2企业应用程序的开发效率问题是否与互联网平台公司遇到的效率问题相同? 通过比较企业和互联网之间的差异,我们可以了解水土不服的核心原因。 企业 互联网 企业IT组织能力无法与数字化转型的速度匹配,缺乏足够的人才支持。为了提高开发效率,企业需要寻找工具和技术来降低开发难度,同时提高个人开发效率 互联网企业拥有众多优秀的人才,需要解决团队协作和知识共享的问题,即协同开发的效率。 企业无法制定并主导技术规范,这导致了能力复用的不足。为了提高效率和减少开发成本,企业需要建立统一的技术规范和标准,以便能力复用和组织协同。 互联网企业可以自定义技术规范,因此能力复用更易于保障。 企业往往当前业务量相对小,期望数字化建设能打动业务发展,对业务发展的预期比较高,所以企业的诉求是即满足当下成本效应又能兼顾未来对发展预期 互联网企业起步时的系统目标负载就高,通常会忽略资源起步门槛的问题,当然也可以通过自动扩容、云计算等方式来解决初期的负载问题。 表2-1从企业与互联网的对比,看水土不服的核心原因 我们可以看到企业和互联网架构在很多方面存在着不同的需求和问题。因此,在提供数字化服务时,Oinone需要注意与企业的组织能力进行匹配,并根据企业自身的特性来提供在线化的服务能力。这就像在社会主义制度下需要有中国特色一样,Oinone也需要有适合中国企业的特色。

    2024年5月23日
    1.9K00
  • 4.2.7 框架之翻译工具

    一、说明 Oinone目前的默认文案是中文,如果需要使用其他语言,Oinone也提供一系列的翻译能力。 二、定义语言文件 在src/local下新增一个名为zh_cn.ts文件: 图4-2-7-1 语言文件 编辑zh_cn.ts文件,增加以下内容: const zhCN = { demo: { test: '这是测试' } } export default zhCN 图4-2-7-2 语言内容格式示意 在mian.ts注册语言资源: import { LanguageType, registryLanguage} from '@kunlun/dependencies'; import Zh_cn from './local/zh_cn' registryLanguage(LanguageType['zh-CN'], Zh_cn); 图4-2-7-3 注册语言 三、Vue模板使用 <template> <div class="petFormWrapper"> <form :model="formState" @finish="onFinish"> <a-form-item :label="translate('demo.test')" id="name" name="kind" :rules="[{ required: true, message: '请输入品种种类!', trigger: 'focus' }]"> <a-input v-model:value="formState.kind" @input="(e) => onNameChange(e, 'kind')" /> <span style="color: red">{{ getServiceError('kind') }}</span> </a-form-item> <a-form-item label="品种名" id="name" name="name" :rules="[{ required: true, message: '请输入品种名!', trigger: 'focus' }]"> <a-input v-model:value="formState.name" @input="(e) => onNameChange(e, 'name')" /> <span style="color: red">{{ getServiceError('name') }}</span> </a-form-item> </form> </div> </template> <script lang="ts"> import { defineComponent, reactive } from 'vue'; import { Form } from 'ant-design-vue'; export default defineComponent({ // 引入translate props: ['onChange', 'reloadData', 'serviceErrors', 'translate'], components: { Form }, setup(props) { const formState = reactive({ kind: '', name: '', }); const onFinish = () => { console.log(formState); }; const onNameChange = (event, name) => { props.onChange(name, event.target.value); }; const reloadData = async () => { await props.reloadData(); }; const getServiceError = (name: string) => { const error = props.serviceErrors.find(error => error.name === name);…

    2024年5月23日
    1.5K00
  • 4.1.23 框架之信息传递

    在4.1.13【Action之校验】、3.4.1【构建第一个Function】等文章中,都用到PamirsSession.getMessageHub()来设置返回消息,基本上都是在传递后端逻辑判断的异常信息,而且在系统报错时也会通过它来返回错误信息,前端接收到错误信息则会以提示框的方式进行错误提示。其实后端除了可以返回错误信息以外,还可以返回调试、告警、成功、信息等级别的信息给前端。但是默认情况下前端只提示错误信息,可以通过前端的统一配置放开提示级别,有点类似后端的日志级别。 一、不同信息类型的举例 Step1 新建PetTypeAction 借用PetType模型的表格页做为信息传递的测试入口,为PetType模型新增一个ServerAction,在代码中对信息的所有类型进行模拟 package pro.shushi.pamirs.demo.core.action; import org.springframework.stereotype.Component; import pro.shushi.pamirs.demo.api.model.PetCatItem; import pro.shushi.pamirs.demo.api.model.PetType; import pro.shushi.pamirs.meta.annotation.Action; import pro.shushi.pamirs.meta.annotation.Model; import pro.shushi.pamirs.meta.api.dto.common.Message; import pro.shushi.pamirs.meta.api.session.PamirsSession; import pro.shushi.pamirs.meta.enmu.ActionContextTypeEnum; import pro.shushi.pamirs.meta.enmu.InformationLevelEnum; import pro.shushi.pamirs.meta.enmu.ViewTypeEnum; @Model.model(PetType.MODEL_MODEL) @Component public class PetTypeAction { @Action(displayName = "消息",bindingType = ViewTypeEnum.TABLE,contextType = ActionContextTypeEnum.CONTEXT_FREE) public PetType message(PetType data){ PamirsSession.getMessageHub().info("info1"); PamirsSession.getMessageHub().info("info2"); PamirsSession.getMessageHub().error("error1"); PamirsSession.getMessageHub().error("error2"); PamirsSession.getMessageHub().msg(new Message().msg("success1").setLevel(InformationLevelEnum.SUCCESS)); PamirsSession.getMessageHub().msg(new Message().msg("success2").setLevel(InformationLevelEnum.SUCCESS)); PamirsSession.getMessageHub().msg(new Message().msg("debug1").setLevel(InformationLevelEnum.DEBUG)); PamirsSession.getMessageHub().msg(new Message().msg("debug2").setLevel(InformationLevelEnum.DEBUG)); PamirsSession.getMessageHub().msg(new Message().msg("warn1").setLevel(InformationLevelEnum.WARN)); PamirsSession.getMessageHub().msg(new Message().msg("warn2").setLevel(InformationLevelEnum.WARN)); return data; } } 图4-1-23-1 为PetType模型新增一个ServerAction Step2 (前端)修改提示级别 在项目初始化时使用CLI构建初始化前端工程,在src/middleware有拦截器的默认实现,修改信息提示的默认级别为【ILevel.SUCCESS】 图4-1-23-2(前端)修改提示级别 const DEFAULT_MESSAGE_LEVEL = ILevel.SUCCESS; 图4-1-23-3(前端)修改提示级别 Step3 重启系统看效果 从页面效果中看到已经不在是只提示错误信息。从协议端看错误级别的信息是在errors下,其他级别的信息是在extensions下。 图4-1-23-4 示例效果 图4-1-23-5 系统提示的返回结果 二、MessageHub的其他说明 是实现上看MessageHub是基于GQL协议,前后端都有配套实现。同时前端还提供了订阅MessageHub的信息功能,以满足前端更多交互要求,前端MessageHub提供的订阅能力使用教程详见4.2.2前端高级特性之【框架之MessageHub】一文。

    2024年5月23日
    1.6K00

Leave a Reply

Please Login to Comment