3.5.2.2 构建View的Template

相关推荐

• Oinone 7天入门到精通

  页面设计

  1. 功能说明 页面设计时界面设计器中「页面」模块的设计入口，在这个界面，进行页面的设置、搭建、设计、排版。 主要分为顶部操作栏、左侧工具栏、中部设计画布区、右侧属性面板。 2. 操作栏 进入页面设计，顶部显示了页面的标题，以及返回、发布等操作。 2.1 发布 页面设计完成后，点击「发布」运行页面生效。若不点击发布，页面也有自动保存的功能，但在发布前，自动保存也等同于草稿，不会正式生效。 发布时如果有属性不符合校验规则（必填的属性未填、输入的内容校验不通过），会发布失败，相应的字段会特殊标记，需要查看并修改属性。 2.2 显示/隐藏母版 进入页面设计时默认不展示母版，可以手动操作显示母版 3. 工具栏 左侧的工具栏中包括组件库、页面设置等模块。 3.1 组件库 组件库中包含组件和模型，组件是当前设计器支持的所有组件，模型是页面所在模型下的所有字段和动作。 3.1.1 组件 组件中展示了系统支持的所有组件。包含 1）布局类组件，如分组、选项卡等，使用布局组件可以将页面进字段分类、分页； 2）字段类组件，如单行文本、整数、日期等等，使用字段类组件时都会在模型下对应创建一个字段； 3）动作类组件，如跳转动作、提交动作、链接动作等。 3.1.2 模型 组件库顶部，由组件可切换为模型：模型选项下，会展示当前模型的所有字段，以及系统默认动作。可以直接拖拽字段至设计画布中，会应用形成某个组件，可对组件进行多样的属性设置，优化交互。 3.1.2 组件和模型有什么区别 1展示内容维度不同 组件中展示的内容是组件信息，如分组、选项卡、单行文本、文件上传等；模型中展示的是模型下已有的所有字段。 2使用功能不同 组件中的组件使用前需要在模型中创建一个字段，当然，创建好的字段也会存在于模型中；模型中的字段可直接使用，并且使用时会在设计画布中对应生成个默认组件。 3使用场景不同 如果模型中已经存在目标字段，应直接选择从模型中拖拽字段；如果模型中没有需要的字段，可以在页面中增加一个组件，实际上也是在新增一个字段。 3.2 页面设置 页面设置中可以修改当前页面的标题、分组、页面描述，同时也是给页面上传缩略图的唯一入口。 4. 设计画布 将组件或字段拖拽至设计画布区，会生成样式。点击组件，右侧可对其进行设置，大部分属性可实时在画布中展示效果。 5. 属性面板 右侧属性面板抽屉中可以设置属性或查看字段信息，通过不同的属性配置化实现组件的多样化。 5.1 属性 属性中包括基本信息（如标题、占位提示、描述说明等）、校验信息（如是否必填、长度校验等）、交互信息（如排序方式、是否展示计数器等） 5.2 字段 首次从组件中拖拽，会先展示字段信息，并且是需要先创建一个字段，字段创建成功后，再次切换字段选项，只读展示当前组件所对应的字段基本信息。同理，如果是直接从字段中拖拽，字段选项中，只读展示当前字段基本信息。

  史, 昂

  2024年6月20日

  3.3K000
• Oinone 7天入门到精通

  应用审计

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

  史, 昂

  2024年1月20日

  1.2K000
• Oinone 7天入门到精通

  3.3.10 字段类型之关系描述的特殊场景

  在3.3.9【字段类型之关系与引用】一文中已经描述了各种关系字段的常规写法，还有一些特殊场景如：关系映射中存在常量，或者M2M中间表是大于两个字段构成。 举例说明关系字段-高级用法 场景描述 PetTalent模型增加talentType字段，PetItem与PetTalent的多对多关系增加talentType（达人类型），PetItemRelPetTalent 中间表维护petItemId、petTalentId以及talentType，PetDogItem和PetCatItem分别重写petTalents 字段，关系中增加常量描述。示意图如下 实际操作步骤： Step1 新增 TalentTypeEnum package pro.shushi.pamirs.demo.api.enumeration; import pro.shushi.pamirs.meta.annotation.Dict; import pro.shushi.pamirs.meta.common.enmu.BaseEnum; @Dict(dictionary = TalentTypeEnum.DICTIONARY,displayName = "达人类型") public class TalentTypeEnum extends BaseEnum<TalentTypeEnum,Integer> { public static final String DICTIONARY ="demo.TalentTypeEnum"; public final static TalentTypeEnum DOG =create("DOG",1,"狗达人","狗达人"); public final static TalentTypeEnum CAT =create("CAT",2,"猫达人","猫达人"); } Step2 PetTalent模型增加talentType字段 package pro.shushi.pamirs.demo.api.model; import pro.shushi.pamirs.demo.api.enumeration.TalentTypeEnum; 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; @Field(displayName = "达人类型") private TalentTypeEnum talentType; } Step3 修改PetItem的petTalents字段，在关系描述中增加talentType（达人类型） @Field.many2many(relationFields = {"petItemId"},referenceFields = {"petTalentId","talentType"},through = "PetItemRelPetTalent") @Field.Relation(relationFields = {"id"}, referenceFields = {"id","talentType"}) @Field(displayName = "推荐达人",summary = "推荐该商品的达人们") private List<PetTalent> petTalents; Step4 PetDogItem增加petTalents字段，重写父类PetItem的关系描述 talentType配置为常量，填入枚举的值 增加domain描述用户页面选择的时候自动过滤出特定类型的达人，RSQL用枚举的name @Field.many2many(relationFields = {"petItemId"},referenceFields = {"petTalentId","talentType"},through = "PetItemRelPetTalent") @Field.Relation(relationFields = {"id"}, referenceFields = {"id","talentType"}) @Field(displayName = "推荐达人",summary = "推荐该商品的达人们") private List<PetTalent> petTalents; Step5 PetCatItem增加petTalents字段，重写父类PetItem的关系描述 talentType配置为常量，填入枚举的值 增加domain描述用户页面选择的时候自动过滤出特定类型的达人，RSQL用枚举的name @Field(displayName = "推荐达人") @Field.many2many( through = "PetItemRelPetTalent", relationFields = {"petItemId"}, referenceFields = {"petTalentId","talentType"} ) @Field.Relation(relationFields = {"id"}, referenceFields = {"id", "#2#"}, domain = " talentType == CAT") private List<PetTalent> petTalents; Step6 清除中间表demo_core_pet_item_rel_pet_talent的数据记录 清除PetItem与PetTalent的多对多中间表demo_core_pet_item_rel_pet_talent的数据记录 Step7 重启看效果 修改达人记录，选择不同达人类型 PetItem、PetCatItem、PetDogItem不同的交互页面

  史, 昂

  2024年5月23日

  1.5K000
• Oinone 7天入门到精通

  3.3.8 字段类型之基础与复合

  模型字段是描述实体的特征属性，本文介绍重点介绍字段的基础类型与复合类型 使用@Field注解来描述模型的字段。如果未配置字段类型，系统会根据Java代码的字段声明类型来自动获取业务类型。建议配置displayName属性来描述字段在前端的显示名称。可以使用defaultValue配置字段的默认值。 一、安装与更新 使用@Field.field来配置字段的不可变更编码。字段一旦安装，无法在对该字段编码值进行修改，之后的字段配置更新会依据该编码进行查找并更新；如果仍然修改该注解的配置值，则系统会将该字段识别为新字段，存储模型会创建新的数据库表字段，而原字段将会rename为废弃字段。 二、字段类型 类型系统由基本类型、复合（组件）类型、引用类型和关系类型四种类型系统构成。通过类型系统描述应用程序、数据库和前端视觉视图如何进行交互，数据及数据间关系如何处理的协议。其中引用类型和关系类型介绍详见3.3.9【字段类型之关系与引用】一文,字段命名规范参见3.3.1【构建第一个Model】一文，这里不再赘述。 基本类型 业务类型 Java类型 数据库类型 规则说明 BINARY ByteByte[] TINYINTBLOB 二进制类型，不推荐使用 INTEGER ShortIntegerLongBigInteger smallintintbigintdecimal(size,0) 整数, 包括整数（10-11位有效数字）、长整数（19-20位有效数字）和大整数（超过19位）。【数据库规则】：默认使用int；如果size小于6则使用smallint；如果size超过6则使用int；如果size超过10位数字，即大于11（包含符号位），则使用长整数bigint；如果size超过19位数字，即大于20（包含符号位），则使用大数decimal。若未配置size，则按Java类型推测。【前端交互规则】：整数使用Number类型，长整数和大整数前后端协议使用字符串类型。 FLOAT FloatDoubleBigDecimal float(M,D)double(M,D)decimal(M,D) 浮点数,?包括单精度浮点数（7-8位有效数字）、双精度浮点数（15-16位有效数字）和大数（超过15位）。【数据库规则】：默认使用单精度浮点数float；如果size超过7位数字，即大于等于8，则使用双精度浮点数double；如果size超过15位数字，即大于等于16，则使用大数decimal。若未配置size，则按Java类型推测。【前端交互规则】：单精度浮点数float和双精度浮点数double使用Number类型（因为都使用IEEE754协议64位进行存储），大数前后端协议使用字符串类型。 BOOLEAN Boolean tinyint(1) 布尔类型，值为1,true(真)或0,false(假) ENUM Enum 与数据字典指定基本类型一致 【前端交互规则】：可选项从ModelField的options字段获取，options字段值为字段指定数据字典子集的JSON序列化字符串。前后端传递的是可选项的name，数据库存储使用可选项的value。multi属性为true，则使用多选控件；multi属性为false，则使用单元控件 STRING String varchar(size) 字符串，size为长度限制默认值参考，前端可以view中覆盖该配置 TEXT String text 多行文本，编辑态组件为多行文本框，长度限制为配置项size值 HTML String text 富文本编辑器 DATETIME java.util.Datejava.sql.Timestamp datetime(fraction)timestamp(fraction) 日期时间类型【数据库规则】：日期和时间的组合，时间格式为?YYYY-MM-DD HH:MM:SS[.fraction]，默认精确到秒，在默认的秒精确度上，可以带小数，最多带6位小数，即可以精确到?microseconds (6 digits) precision。可以通过设置fraction来设置精确小数位数，最终存储在字段的decimal属性上。【前端交互规则】：前端默认使用日期时间控件，根据日期时间类型格式化格式format格式化日期时间 YEAR java.util.Date year 年份类型日期类型【数据库规则】：默认“YYYY”格式表示的日期值【前端交互规则】：前端默认使用年份控件，根据日期类型格式化格式format格式化日期 DATE java.util.Datejava.sql.Date datedate 日期类型【数据库规则】：默认“YYYY-MM-DD”格式表示的日期值【前端交互规则】：前端默认使用日期控件，根据日期类型格式化格式format格式化日期 TIME java.util.Datejava.sql.Time time(fraction)time(fraction) 时间类型【数据库规则】：默认“HH:MM:SS”格式表示的时间值【前端交互规则】：前端默认使用时间控件，根据日期类型格式化格式format格式化日期 表3-3-8-1 字段基本类型 复合类型 业务类型 Java类型 数据库类型 规则说明 MONEY BigDecimal decimal(M,D) 金额，前端使用金额控件，可以使用currency设置币种字段 表3-3-8-2 字段复合类型 不可变更字段 使用immutable属性来描述该字段前后端都无法进行更新操作，系统会忽略不可变更字段的更新操作。 自动生成编码的字段 详见3.3.5【模型编码生成器】一文。 字段的序列化与反序列化 使用@Field注解的serialize属性来配置非字符串类型属性的序列化与反序列化方式，最终会以序列化后的字符串持久化到存储中。 详见3.3.7【字段之序列化方式】一文 前端默认配置 可以使用@Field注解中的以下属性来配置前端的默认视觉与交互规则，也可以在前端设置覆盖以下配置。 @Field(required)，是否必填 @Field(invisible)，是否不可见 @Field(priority)，字段优先级，列表的列使用该属性进行排序 更多前端默认视图配置详见：3.5.4【Ux注解详解】一文，如：readonly是否只读等。 举例 回顾我们前面学习例子 现有PetShop代码如下 package pro.shushi.pamirs.demo.api.model; import pro.shushi.pamirs.core.common.enmu.DataStatusEnum; import pro.shushi.pamirs.demo.api.enumeration.PetShopOptionEnum; import pro.shushi.pamirs.meta.annotation.Field; import pro.shushi.pamirs.meta.annotation.Model; import java.sql.Time; import java.util.List; @Model.model(PetShop.MODEL_MODEL) @Model(displayName = 宠物店铺,summary=宠物店铺,labelFields ={shopName} ) @Model.Code(sequence = DATE_ORDERLY_SEQ,prefix = P,size=6,step=1,initial = 10000,format = yyyyMMdd) public class PetShop extends AbstractDemoIdModel { public static final String MODEL_MODEL=demo.PetShop; @Field(displayName = 店铺编码) private String code; @Field(displayName = 店铺编码2) @Field.Sequence(sequence = DATE_ORDERLY_SEQ,prefix = C,size=6,step=1,initial = 10000,format = yyyyMMdd) private String codeTwo; @Field(displayName = 店铺名称,required = true) private String shopName; @Field(displayName = 开店时间,required = true) private Time openTime; @Field(displayName = 闭店时间,required = true) private Time closeTime; @Field(displayName =…

  史, 昂

  2024年5月23日

  1.4K000
• Oinone 7天入门到精通

  2.4.2 Oinone独特性之每一个需求都可以是一个模块

  我们的Oinone平台采用模型驱动的方式，并符合面向对象设计原则，每个需求都可以是一个独立模块，可以独立安装、升级和卸载。这让系统真正像乐高积木一样搭建，具有高度的灵活性和可维护性。 与大部分低代码或无代码平台不同的是，它们的应用市场上的应用往往是模板式的，也就是说，这是一个拷贝，个性化只能在应用上直接修改，而且一旦修改就不能升级。这对于软件公司和客户来说都非常痛苦。客户无法享受到软件公司产品的升级功能，而软件公司在服务大量客户时，也会面临不同版本的维护问题，成本也非常高。而我们的Oinone平台完全避免了这些问题，让客户和软件公司都可以从中受益（如下图2-9、2-10所示）。 图2-9软件公司与客户项目的关系-让标准与个性化共存 图2-10 软件公司与客户项目的关系-让升级无忧 实现原理 在满足客户个性化定制需求时，传统的方法通常是直接修改标准产品源码，但这样做会带来一个问题：标准产品无法持续升级。相反，无论是在OP模式还是SaaS模式下，Oinone都采用全新的模块为客户进行个性化开发，保持标准产品和个性化模块的独立维护和升级。这是因为在元数据设计时，Oinone采用了面向对象的设计原则，实现了元数据设计与面向对象设计思想的完美融合。 面向对象设计的核心特征包括封装、继承、多态，而Oinone的元数据设计完全融入了这些思想。下面是几个例子，说明Oinone的元数据设计如何体现面向对象设计的核心特征，并带来了什么好处： 继承：在继承原有模型的字段、逻辑、展示的情况下，增加一段代码来扩展模型的字段、逻辑、展示。 多态：在继承原有模型的字段、逻辑、展示的情况下，增加一段代码来覆盖模型的原有字段、逻辑、展示。 封装：外部无需关心模型内部如何实现，只需按照不同场景调用模型对应开放级别的字段、逻辑、展示。 这些特征和优势使得Oinone在满足客户个性化需求时更加灵活和可持续，同时使得标准产品的维护和升级变得更加容易和高效。 在Java语言设计中，万物皆对象，一切都以对象为基础。而Oinone的元数据设计则是以模型为出发点，作为数据和行为的承载体。如下图2-11清晰地描述了Java面向对象编程中封装、继承、多态在Oinone元数据中的对应关系。Oinone元数据描述了B对象继承A对象并拥有其所有属性和方法，并覆盖了A对象的属性1和方法1，同时新增了属性3和方法3。 此外，Oinone的面向对象特性是用元数据来描述的。一方面，我们基于Java编码规范收集相关元数据，以保持不改变Java编程习惯。另一方面，方法和对象的挂载是松耦合的，只要按照元数据规范进行挂载，就能轻松地将其附加到模型上。在不改变原有A对象的情况下，我们可以直接增加方法和属性（如下图2-12所示）。 图2-11 java面向对象在Oinone元数据中对应 图2-12 java对象的修改 VS Oinone元数据模型的修改 Oinone函数不仅支持面向对象的继承和多态特性，还提供了面向切面的拦截器和SPI机制的扩展点，以应对方法逻辑的覆盖和扩展，以及系统层面的逻辑扩展（如下图2-13所示）。这些扩展功能可以独立地在模块中维护。 其中，拦截器可以在不侵入函数逻辑的情况下，根据优先级为满足条件的函数添加执行前和执行后的逻辑。 扩展点是一种类似于SPI机制的逻辑扩展机制，用于扩展函数的逻辑。通过这一机制，可以对函数逻辑进行灵活的扩展，以满足不同的业务需求。 图2-13 Oinone函数拦截与扩展机制 不管是对象、属性还是方法，都可以以独立的模块方式来扩展，这就使得每一个需求都可以成为一个独立的模块，方便我们在研发标准产品时进行模块化的划分，同时也让我们在以低代码模式为客户进行二次开发时，能够更好地支持“标准产品迭代与个性化保持独立”的需求。在2.4.3【oinone独特性之低无一体】一文中，我们也提到了这个特性，但那是在低无一体的情况下，通过元数据融合来实现的。让我们看看基于低代码开发模式下，典型的Oinone二次开发工程结构（如下图2-14所示），就可以更好地理解这个特性啦！ 图2-14 Oinone典型的二开工程结构

  史, 昂

  2024年5月23日

  1.3K000