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

相关推荐

  • 数据字典

    1. 什么是数据字典 数据字典是一些固定字典项的集合,可作为多选或单选的选项,例如人员性别、员工属相、杭州市下属的行政区等都是数据字典。 选择一个应用/模块下的一个小模块,可以查看其中包含的自定义字典(自建的数据字典)和系统字典。可以通过导入或添加创建自定义字典。 2. 数据字典基本操作 删除:系统字典不支持删除,无法批量删除自定义数据字典,若数据字典已经被字段、页面等引用时,也无法删除这个数据字典。 隐藏/可见:自定义字典、系统字典都可以操作隐藏和可见,隐藏和可见不影响数据字典在字段、页面等处的使用。 查看引用关系:点击查看引用关系,展开弹窗,展示该数据字典和字段、视图的引用关系。 修改:若数据字典已经被引用,无法删除其中的字典项。若无引用关系则可以任意修改。 3. 数据字典导入 点击“导入数据字典”按钮,弹出窗口,可根据图中引导进行数据字典的导入。 在经典模式下,导入数据字典会新建数据字典。 在专家模式下,数据字典导入的模板中包含字段“字典编码”,若导入的字典编码不存在则会新建数据字典,若导入的字典编码已存在则会修改字典编码的设置,新建和修改的动作会校验是否符合规范。 4. 数据字典创建 4.1 专家模式(低代码模式) 字典项类型有“二进制、文本、整数”三种可选,选择二进制时,字典项值需要选择存储在数据库二进制中的第几位。系统根据字典项值去查找字典项名称,因此字典项值不可重复。 数据字典的api名称、代码名称、描述可不填,部分系统会赋默认值。 字典项中字典项名称和字典项值必填,api名称和字典项描述不填系统会赋默认值。 4.2 经典模式(无代码模式) 经典模式下只需要填写字典名称,添加字典项即可。系统会自动将字典项类型设置为“二进制”,并将字典项按照创建的先后顺序设置字典项值的位数。字典项类型、字典项值释义可参照专家模式的解释。

    2024年6月20日
    2.8K00
  • 梅丛银

    认识陈鹏程及数式核心团队同学已经有一段时间了,在我们多次的交流讨论中时常会谈及:未来中国哪家软件企业能在互联网云原生时代走出来超越传统软件企业?史昂说这是他的梦想,也是他们团队这么多年坚持技术和产品研发与应用优先思考之路。史昂及数式核心团队面向企业应用市场历经三年的潜心研发和实战交付,推出Oinone产品及配套的低代码平台工具:对比国内外应用软件平台在开放生态和云原生均有它的继承性和独特性,特别是将技术平台赋予企业各种业务领域属性,便于企业客户和开发伙伴的二次开发并能快速搭建各类企业核心应用场景是Oinone的最大亮点。Oinone的内在特点之一是参考了全球最大开源ERP Odoo的元数据模型设计,同时基于业务中台架构和云原生技术,形成了自己一套国际化的快速开发平台、建模规范和应用产品,通过自己进场落地很多品牌企业的应用中台化不断迭代升级,走出了一条具有显著特色的新应用软件之路。史昂及团队特点谦卑、善于思考,善于吸收他山之精华,这是创业团队难能可贵之点,由此能善于与生态伙伴合作也是能够走的更远更长的基础基因。最后希望和祝愿Oinone能为中国企业在云时代数字化实践做出更多的贡献,为软件产业构建强大的应用生态和开发社区,真正树立起Oinone自己的软件品牌形象。 资深IT咨询专家&浩鲸云智能专家学院院长:梅丛银

    Oinone 7天入门到精通 2024年5月23日
    1.6K00
  • 应用审计

    1. 整体介绍 应用审计是基于模型字段记录用户操作留痕记录,通过定义审计规则,平台基于审计规则订阅的字段记录形成日志。平台名词概念: 应用日志:针对已订阅的审计规则记录用户操作信息,是用户在各应用中操作行为留痕记录。 审计规则:业务审计中,数据变化订阅记录的规则。 操作入口:应用中心——业务审计应用。 2. 审计规则 审计规则是指定义审计过程订阅数据变化的信息,根据模型、订阅到具体字段内容变化形成应用日志。如订阅销售订单的备注,销售订单S20231001888,订单备注【尽快发货】,备注修改为【需易碎品包装】,审计规则为:销售订单模型,订阅【备注】。 操作包括:新增、编辑、删除。 2.1. 新增 新增时,定义审计规则名称,选择需要审计的模型,指定需要订阅的字段信息,同时可以指定关联关系的字段。 需要注意:每个模型仅限定义单条审计规则。 2.2. 编辑 编辑同新增操作,不做赘述。 2.3. 删除 删除规则后,平台将不再监听对应数据的变更日志,请慎重删除。 3. 应用日志 应用日志是针对已订阅的审计规则记录用户操作信息。记录操作用户、IP、登录设备、位置、订阅的字段变化内容。 应用日志详情 4. 业务表达 4.1. 展示效果 表格-行操作—日志记录 详情—日志记录 4.2. 操作步骤 Step1:在应用中心,需要维护业务应用依赖业务审计应用; 操作入口:应用中心,找到业务应用——编辑,依赖模块选择业务审计。 Step2:配置审计规则; 操作入口:业务审计应用——审计规则——新增规则。 Step2:界面设计器配置日志记录; 操作入口:界面设计器,找到需要配置的页面——模型组件,将动作区的日志记录拖动到页面中。

    2024年1月20日
    1.6K00
  • 节点动作

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

    Oinone 7天入门到精通 2024年6月20日
    2.2K00
  • 3.3.9 字段类型之关系与引用

    有关系与引用类型才让oinone具备完整的描述模型与模型间关系的能力 在PetShop以及其代理模型中已经上用到了O2M、M2O字段,分别如petItems(PetItem)和create(PamrisUser)字段,但是没有过多的讲解。本文重点举例RELATED、M2M、O2M,至于M2O留给大家自行尝试。 一、引用类型(举例) 业务类型 Java类型 数据库类型 规则说明 RELATED 基本类型或关系类型 不存储或varchar、text 引用字段【数据库规则】:点表达式最后一级对应的字段类型;数据库字段值默认为Java字段的序列化值,默认使用JSON序列化【前端交互规则】:点表达式最后一级对应的字段控件类型 表3-3-9-1 字段引用类型 Step1 修改PetShopProxy类 为PetShopProxy类新增一个引用字段relatedShopName,并加上@Field.Related("shopName")注解 为PetShopProxy类新增一个引用字段createrId,并加上@Field.Related({"creater","id"})注解 package pro.shushi.pamirs.demo.api.proxy; import pro.shushi.pamirs.demo.api.model.PetShop; import pro.shushi.pamirs.meta.annotation.Field; import pro.shushi.pamirs.meta.annotation.Model; import pro.shushi.pamirs.meta.enmu.ModelTypeEnum; import pro.shushi.pamirs.user.api.model.PamirsUser; @Model.model(PetShopProxy.MODEL_MODEL) @Model.Advanced(type = ModelTypeEnum.PROXY) @Model(displayName = "宠物店铺代理模型",summary="宠物店铺代理模型") public class PetShopProxy extends PetShop { public static final String MODEL_MODEL="demo.PetShopProxy"; @Field.many2one @Field(displayName = "创建者",required = true) @Field.Relation(relationFields = {"createUid"},referenceFields = {"id"}) private PamirsUser creater; @Field.Related("shopName") @Field(displayName = "引用字段shopName") private String relatedShopName; @Field.Related({"creater","id"}) @Field(displayName = "引用创建者Id") private String createrId; } 图3-3-9-1 修改PetShopProxy类 Step2 重启系统查看效果 我们发现商店管理-列表页面多出了两个有值字段:引用字段shopName和引用创建者Id 图3-3-9-2 商店管理-列表页面新增两个有值字段 二、关系类型 业务类型 Java类型 数据库类型 规则说明 O2O 模型/DataMap 不存储或varchar、text 一对一关系 M2O 模型/DataMap 不存储或varchar、text 多对一关系 O2M List<模型/DataMap> 不存储或varchar、text 一对多关系 M2M List<模型/DataMap> 不存储或varchar、text 多对多关系 表3-3-9-2 字段关系类型 多值字段或者关系字段需要存储,默认使用JSON格式序列化。多值字段数据库字段类型默认为varchar(1024);关系字段数据库字段类型默认为text。 关系字段 关联关系用于描述模型间的关联方式: 多对一关系,主要用于明确从属关系 一对多关系,主要用于明确从属关系 多对多关系,主要用于弱依赖关系的处理,提供中间模型进行关联关系的操作 一对一关系,主要用于多表继承和行内合并数据 图3-3-9-3 字段关联关系 名词解释 关联关系比较重要的名词解释如下: 关联关系:使用relation表示,模型间的关联方式的一种描述,包括关联关系类型、关联关系双边的模型和关联关系的读写 关联关系字段:业务类型ttype为O2O、O2M、M2O或M2M的字段 关联模型:使用references表示,自身模型关联的模型 关联字段:使用referenceFields表示,关联模型的字段,表示关联模型的哪些字段与自身模型的哪些字段建立关系 关系模型:自身模型 关系字段:使用relationFields表示,自身模型的字段,表示自身模型的哪些字段与关联模型的哪些字段建立关系 中间模型,使用through表示,只有多对多存在中间模型,模型的relationship=true 举例M2M关系类型 多对多关系,主要用于弱依赖关系的处理,提供中间模型进行关联关系的操作。这也是在业务开发中很常见用于描述单据间关系,该例子会举例两种方式描述多对多关系中间表,一是中间表没有在系统显示定义模型,二种是中间表显示定义模型。第一种往往仅是维护多对多关系,第二种往往用于多对多关系中间表自身也需要管理有业务含义,中间表模型还经常额外增加其他字段。 一是中间表没有在系统显示定义模型:如果出现跨模块的场景,在分布式环境下两个模块独立启动,有可能会导致系统关系表被删除的情况发生,因为没有显示定义中间表模型,中间表的模型所属模块会根据两边模型的名称计算,如果刚好被计算到非关系字段所属模型的模块。那么单独启动非关系字段所属模型的模块,则会导致删除关系表。 为什么不直接把中间表的模型所属模块设置为关系字段所属模型的模块?因为如果这样做,当模型两边都定义了多对多关系字段则会导致M2M关系表的所属模块出现混乱。 所以这里建议大家都选用:第二种中间表显示定义模型,不论扩展性还是适应性都会好很多。请用:through=XXXRelationModel.MODEL_MODEL 或者 throughClass=XXXRelationModel.class Step1 新建宠物达人模型,并分别为宠物商品和宠物商店增加 到宠物达人模型的字段 新建宠物达人模型PetTalent package pro.shushi.pamirs.demo.api.model; import pro.shushi.pamirs.meta.annotation.Field; import pro.shushi.pamirs.meta.annotation.Model; @Model.model(PetTalent.MODEL_MODEL) @Model(displayName = "宠物达人",summary="宠物达人",labelFields ={"name"}) public class PetTalent extends AbstractDemoIdModel{ public static final String MODEL_MODEL="demo.PetTalent"; @Field(displayName = "达人") private String name; } 图3-3-9-4 新建宠物达人模型PetTalent 修改宠物商品模型,新增many2many字段petTalents,类型为List ,并加上注解@Field.many2many(relationFields = {"petItemId"},referenceFields = {"petTalentId"},through = PetItemRelPetTalent.MODEL_MODEL),through为指定关联中间表。 package pro.shushi.pamirs.demo.api.model; import pro.shushi.pamirs.demo.api.tmodel.PetItemDetail; import pro.shushi.pamirs.meta.annotation.Field; import…

    2024年5月23日
    1.9K00

Leave a Reply

Please Login to Comment