3.5.4 Ux注解详解

史, 昂 • 2024年5月23日 am9:23 • Oinone 7天入门到精通 • 阅读 636

我们默认视图已经基本可以用了，但实际业务中还是会有一些不大不小的自定义需求，写自定义视图又太麻烦，今天我们来学习一种更加轻量的模式即：后端研发可以通过注解来配置视觉交互。该系列注解以Ux开头，例如@UxHomepage、@UxMenu、@UxAction、@UxView、@UxWidget等等。

视图XML的配置优先级大于在代码上的注解，也就是代码上的注解影响的是默认展示逻辑。

一、Ux家族图谱

我们先简单通过家族图谱做个简单了解，脑海里有一个影响当有需要的时候知道能不能做，深入了解还需要大家多多动手去尝试

图3-5-4-1 Ux家族图谱

二、默认视图后端配置举例

在下面的代码片段中UxTable、UxForm、UxDetail、UxTableSearch都有涉及，几个特殊点做些解释其他的留大家自行测试

Group分组的配置逻辑：为了不让一个分组内的字段不断的写Group，所以采取了第一个字段写了Group，到下一个出现的group之间的字段都自动归为一个Group
搜素整体不展示可以用“@UxTable(enableSearch = false)”配置在模型的类上。
字段搜索用“UxTableSearch”配置在模型的字段上，其特殊逻辑是只要你配了一个字段，系统就不自动补充了，例子中表格页的搜索栏只会留下店铺名称和店铺编码

……其他代码
//@UxTable(enableSearch = false)，整体不支持搜索
public class PetShop extends AbstractDemoIdModel {
    public static final String MODEL_MODEL="demo.PetShop";

    @Field(displayName = "店铺编码")
    @UxForm.FieldWidget(@UxWidget(group = "Form基础数据"))//Form分组
    @UxTableSearch.FieldWidget(@UxWidget())//支持搜索
    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;

    @UxTableSearch.FieldWidget(@UxWidget())//支持搜索
    @UxTable.FieldWidget(@UxWidget(invisible = "true"))//表格中不展示支持搜索
    @Field(displayName = "店铺名称",required = true,immutable=true)
    private String shopName;

    @Field(displayName = "一年内新店")
    @UxForm.FieldWidget(@UxWidget(widget = "Switch",group = "Form基础数据"))//Switch,Checkbox可以切换着看，字段可选widget参考【字段的配置】一文
    private Boolean oneYear;

    @Field(displayName = "开店时间",required = true)
    @UxDetail.FieldWidget(@UxWidget(invisible = "true"))//详情不展示
    private Time openTime;

    @Field(displayName = "闭店时间",required = true)
    @UxDetail.FieldWidget(@UxWidget(invisible = "true"))//详情不展示
    private Time closeTime;
    …… 其他代码
}

图3-5-4-2 默认视图后端配置举例

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

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

Oinone 7天从入门到精通

史, 昂数式管理员

0 0

3.5.5 设计器的结合（改）

上一篇 2024年5月23日 am9:22

3.5.3 Action的类型

下一篇 2024年5月23日 am9:24

Oinone 7天入门到精通

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日
784000
Oinone 7天入门到精通

4.1.1 模块之yml文件结构详解

本节是对demo的boot工程的application-*.yml文件关于oinone相关配置的扩充讲解，大家可以先通读留个影响，以备不时之需在基础入门的模块一章中大家构建，并通过启动前后应用，直观地感受到我们自己建的demo模块。在上述过程中想必大家都了解到我们oinone的boot工程是专门用来做应用启动管理，它完全没有任何业务逻辑，它只决定启动哪些模块、启动方式、以及相关配置。它跟Spring Boot的一个普通工程没有什么差异。所有我们只要看application-*.yml文件，oinone提供了哪些特殊配置就能窥探一二。这里主要介绍pamirs路径下的核心以及常用的配置项一、pamirs.boot pamirs.boot.init 描述：启动加载程序，是否启动元数据、业务数据和基础设施的加载与更新程序，在应用启动时同时对模块进行生命周期管理 true ##标准版，只支持true pamirs.boot.sync 描述：同步执行加载程序，启动时对模块进行生命周期管理采用同步方式 true ##标准版，只支持true pamirs.boot.modules a. 描述：启动模块列表。这里只有base模块是必须的。为了匹配我们的前端模版，在demo的例子中加入了其他几个通用业务模块。当然这些通用业务模块也是可以大大降低大家的开发难度以及提升业务系统的设计质量 b. – base #oinone的基础模块 c. – common #oinone的一些基础辅助功能 d. – sequence #序列的能力 e. – resource #基础资源如 f. – user #基础用户 g. – auth #权限 h. – message #消息 i. – international #国际化 j. – business #商业关系 k. – file #文件，demo里没有默认加入，如果要开发导入导出相关功能，可以对应引入改模块 l. – …… 还有很多通用业务模块以及这些模块的详细介绍，我们在介绍第六章【oinone的通用能力】的章节去展开 pamirs.boot.mode ⅰ. dev：不走缓存，可以直接修改元数据。特别是我们在说页面设计的时候，可以修改base_view表直接生效不需要重启系统配置举例 pamirs: boot: init: true sync: true modules: – base – common – sequence – resource – user – auth – message – international – business – demo_core 图4-1-1-1 pamirs.boot.mode配置举例二、pamirs.boot.profile与pamirs.boot.options pamirs.boot.option, 在pamirs.boot.options中可以自定义可选项，也可以根据pamirs.boot.profile属性来指定这些可选项，pamirs.boot.profile属性的默认值为CUSTOMIZE。只有pamirs.boot.profile=CUSTOMIZE时，才能在pamirs.boot.options中自定义可选项。可选项说明默认值 AUTO READONLY PACKAGE DDL reloadModule 是否加载存储在数据库中的模块信息 false true true true true checkModule 校验依赖模块是否安装 false true true true true loadMeta 是否扫描包读取模块元数据 true true false true true reloadMeta 是否加载存储在数据库中元数据 false true true true true computeMeta 是否重算元数据 true true false true true editMeta 编辑元数据，是否支持编程式编辑元数据 true true false true true diffMeta 差量减计算元数据 false true false true false refreshSessionMeta 刷新元数据缓存 true true true true true rebuildHttpApi 刷新重建前后端协议 true true true false false diffTable 差量追踪表结构变更 false true false true false rebuildTable 更新重建表结构 true true false true false…

史, 昂
2024年5月23日
926000
Oinone 7天入门到精通

翻译

翻译应用是管理翻译规则的应用，以模型为基础、维护字段的翻译值，支持导入、导出 1. 操作步骤 Step1：导出所有翻译项； Step2：线下翻译； Step3：导入翻译项； Step4：刷新远程资源； Step5：页面右上角可切换语言，查看翻译效果。 2. 新增翻译翻译是具体到模型字段，其中需要区分出是否字典；源语言、目标语言，是在资源中维护的语言，可在资源中维护需要翻译的语言；翻译项则是模型字段，默认翻译项为激活状态，关闭后维护的翻译项无效。 3. 导出、导入不勾选导出：导出所有需要翻译的翻译项，包括模块、字段，源术语、翻译值等，其中如果已经翻译过的内容，会体现在翻译值中；勾选导出：导出勾选模型的翻译项。导入：导入翻译项，平台会根据模型拆分为多条数据。 4. 刷新远程资源导入翻译项后，点击“刷新远程资源”按钮。 5. 查看翻译内容页面右上角切换语言，查看翻译效果。

史, 昂
2024年6月20日
717000
Oinone 7天入门到精通

4.1.11 函数之异步执行

异步任务是非常常见的一种开发模式，它在分布式的开发模式中有很多应用场景如：高并发场景中，我们一般采用把长流程切短，用异步方式去掉可以异步的非关键功能，缩小主流程响应时间，提升用户体验异构系统的集成调用，通过异步任务完成解耦与自动重试分布式系统最终一致性的可选方案今天我们了解oinone是如何结合Spring+TbSchedule来完成异步任务一、TbSchedule介绍它是一个支持分布式的调度框架，让批量任务或者不断变化的任务能够被动态的分配到多个主机的JVM中,在不同的线程组中并行执行,所有的任务能够被不重复,不遗漏的快速处理。基于ZooKeeper的纯Java实现，由Alibaba开源。在互联网和电商领域TBSchedule的使用非常广泛,目前被应用于阿里巴巴、淘宝、支付宝、京东、聚美、汽车之家、国美等很多互联网企业的流程调度系统。也是笔者早期在阿里参与设计的一款产品。 oinone的异步任务执行原理（如下图4-1-11-1所示），先做一个大致了解：图4-1-11-1 Oinone的异步任务执行原理图基础管理工具下载tbSchedule的控制台jar包去除文件后缀.txt（详见本书籍【附件一】）pamirs-middleware-schedule-console-3.0.1.jar.txt(31.2 MB) 启动控制台 java -jar pamirs-middleware-schedule-console-3.0.1.jar 图4-1-11-2 控制台启动方式访问地址 http://127.0.0.1:10014/schedule/index.jsp?manager=true 图4-1-11-3 访问地址配置zk连接参数图4-1-11-4 配置zk连接参数 oinone默认实现任务类型图4-1-11-5 Oinone默认实现任务类型 baseScheduleNoTransactionTask baseScheduleTask remoteScheduleTask — 适用于pamirs-middleware-schedule独立部署场景 serialBaseScheduleNoTransactionTask serialBaseScheduleTask serialRemoteScheduleTask — 适用于pamirs-middleware-schedule独立部署场景 cycleScheduleNoTransactionTask delayMsgTransferScheduleTask deleteTransferScheduleTask 注： a. 默认情况下：所有任务的任务项都只配置了一个任务项0，只有一台机器能分配任务。 1. 如果要修改配置可以在启动项目中放置schedule.json，来修改配置 2. 人工进入控制修改任务对应任务项的配置 b. 如果想为某一个核心任务配置的独立调度器，不受其他任务执行影响。那么见独立调度的异步任务任务表相关说明图4-1-11-6 任务表相关说明二、构建第一个异步任务（举例） Step1 新建PetShopService和PetShopServiceImpl 1 新建PetShopService定义updatePetShops方法 package pro.shushi.pamirs.demo.api.service; import pro.shushi.pamirs.demo.api.model.PetShop; import pro.shushi.pamirs.meta.annotation.Fun; import pro.shushi.pamirs.meta.annotation.Function; import java.util.List; @Fun(PetShopService.FUN_NAMESPACE) public interface PetShopService { String FUN_NAMESPACE = "demo.PetShop.PetShopService"; @Function void updatePetShops(List<PetShop> petShops); } 图4-1-11-7 新建PetShopService定义updatePetShops方法 PetShopServiceImpl实现PetShopService接口并在updatePetShops增加@XAsync注解 displayName = "异步批量更新宠物商店"，定义异步任务展示名称 limitRetryNumber = 3，定义任务失败重试次数，，默认：-1不断重试 nextRetryTimeValue = 60，定义任务失败重试的时间数，默认：3 nextRetryTimeUnit，定义任务失败重试的时间单位，默认：TimeUnitEnum.SECOND delayTime，定义任务延迟执行的时间数，默认：0 delayTimeUnit，定义任务延迟执行的时间单位，默认：TimeUnitEnum.SECOND package pro.shushi.pamirs.demo.core.service; import org.springframework.stereotype.Component; import pro.shushi.pamirs.demo.api.model.PetShop; import pro.shushi.pamirs.demo.api.service.PetShopService; import pro.shushi.pamirs.meta.annotation.Fun; import pro.shushi.pamirs.meta.annotation.Function; import pro.shushi.pamirs.trigger.annotation.XAsync; import java.util.List; @Fun(PetShopService.FUN_NAMESPACE) @Component public class PetShopServiceImpl implements PetShopService { @Override @Function @XAsync(displayName = "异步批量更新宠物商店",limitRetryNumber = 3,nextRetryTimeValue = 60) public void updatePetShops(List<PetShop> petShops) { new PetShop().updateBatch(petShops); } } 图4-1-11-8 实现PetShopService接口并在updatePetShops增加@XAsync注解 Step2 修改PetShopBatchUpdateAction的conform方法引入PetShopService 修改conform方法利用ArgUtils进行参数转化，ArgUtils会经常用到。调用petShopService.updatePetShops方法 package pro.shushi.pamirs.demo.core.action; …… 引依赖类 @Model.model(PetShopBatchUpdate.MODEL_MODEL) @Component public class PetShopBatchUpdateAction { @Autowired private PetShopService petShopService; ……其他代码 @Action(displayName = "确定",bindingType = ViewTypeEnum.FORM,contextType = ActionContextTypeEnum.SINGLE) public PetShopBatchUpdate conform(PetShopBatchUpdate data){ if(data.getPetShopList() == null || data.getPetShopList().size()==0){ throw…

史, 昂
2024年5月23日
588000
Oinone 7天入门到精通

5.1 CDM的背景介绍

如果说低代码开发框架输出技术标准，CDM则是结合oinone技术特性和软件工程设计，让输出数据标准变成可能。一、背景介绍无法照搬的最佳实践要了解引入CDM的初衷，得从互联网架构的演进开始，了解其过程，就知道为什么说Oinone的CDM是中台架构的最佳技术实践的核心！我们在2.2【互联架构做为最佳实践为何失效】一文中介绍过互联网技术发展的四个阶段，特别平台化到中台化的阶段，目的是在一套规范下让听的见炮火声音的团队自行决定业务系统发展，适用多业务线（或多场景应用）独立发展。互联网架构在演进过程中碰到的问题跟企业数字化转型过程中碰到的问题是非常类似：随着企业业务在线化后对系统性能、稳定都提出了更高的要求，而且大部分企业的内部很多系统相互割裂导致，导致很多重复建设，所以我们需要服务化、平台化。同时没有一个供应商能解决企业所有商业场景问题，又需要多个供应商共同参与，所以把供应商类类比成各个业务线，在一套规范下让供应商自行决定业务系统发展既然跟阿里当初在架构演进过程中碰到的问题非常类似，那么是不是照搬阿里中台架构方案到企业就好了？当然不是，因为历史原因阿里的中台架构是采用的平台共建模式：“让业务线研发以平台设计好的规范进来共同开发”，其本质还是平台主导模式，它是有非常大的历史包袱。我们想象各个供应商的共建一个交易平台或商品平台，那是多么荒唐的事情，平台化已经足够的复杂了，还让不同背景、不同企业的研发一起共建，最后往往导致企业架构负载过重，这时对企业来说便不再是赋能而是“内耗”。那么如果没有历史包袱，我们重新设计，站在上帝视角去看有没有更好的方式呢？当然有借鉴微软的CDM 这里我们借鉴微软的CDM理念，CDM这个概念最早是2016年微软宣布“以Dynamics 365的形式改造其CRM和ERP”战略时提出的。微软给它的定义是“用于存储和管理业务实体的业务数据库，而且是开箱即用的”。CDM不仅仅提供标准实体，它还允许用户建立个性化的实体，用户可以扩展标准实体也可以增加和标准实体相关的新实体。 CDM可能并不性感，但绝对是非常必要的。它成为了微软的很多产品的基础，是构建了无数业务领域的原型。同时微软也期望它能成为快速实现数据交换和迁移的标准，这个有点像菜鸟网络推出的奇门，让所有TMS、OMS、WMS都基于一套数据接口API进行互通，一套标准是为了解决一个行业问题，而不是具体某一个企业一个集团的问题。我们发现CDM的理念跟我们想要的“企业级的数据标准”是非常吻合的。但是我们也不能照搬照抄，虽然微软的CDM很好的解决了数据割裂问题，但就模型来说就够大家喝一壶了，模型库非常庞大而且复杂，学习成本巨高。数字化时代软件会产生新的技术流派我们知道传统软件的设计理念：侧重在模型对业务支撑全面性上。优点体现为配置丰富，缺点模型设计过于复杂，刚开始有前瞻性，但在理解、维护都非常困难，随着业务发展系统原先的设计逐渐腐化，异常笨重。而Oinone的CDM设计理念：侧重在简单、灵活、统一上，体现为在上层应用开发时，每一业务领域保持独立，模型简单易懂，并结合Oinone的低代码开发机制进行快速开发，灵活应对业务变化。所以我更想说Oinone的CDM是微软CDM的在原有基础上，与互联网架构结合，利用Oinone低代码开发平台特性形成新的工程化建议。Oinone-CDM不以把模型抽象到极致，支撑“所有业务可能性”为目标，而是抽象80%通用的设计，保持模型简单可复用，来解决数据割裂问题，并保持业务线独立自主性，快速创新的能力。图5-1-1 Oinone-CDM要解决的问题二、Oinone的CDM本质是创新的工程化建议引入CDM以后系统工程结构会有什么变化，跟大家认知的互联网架构有什么区别。原本上层的业务线系统，需要调用各个业务平台提供的功能，增加CDM以后也就是我们右的图，每个业务线就像一个独立右边。看上去复杂了，其实对业务线来说更加简单了。互联网整体平台化带来的问题：业务线每次业务调整都需要给各个平台提需求业务平台研发需要了解所有业务线的知识再做设计，对研发要求非常高各个业务域的不同需求相互影响包括系统稳定性、研发对需求响应的及时性结合oinone特性提出的新工程建议：一些通用性模块继续以平台化的方式存在，能力完全复用。业务线自建业务平台，保持业务线的独立性和敏捷性业务线以CDM为原型，保证核心数据不割裂，形成一致的数据规范图5-1-2 引入CDM概念后的工程结构对比三、CDM思路示意图该示例中OinoneCDM的商品域不仅仅提供标准实体，保证各个业务系统的对商品的通用需求、简单易懂，在我们星空系列业务产品中如全渠道运营、B2B交易等系统以此为基础建立属于自身个性化的实体，可以扩展标准实体也可以增加和标准实体相关的新实体。带来的好处：通过多种继承方式，继承后的模型可扩展模型本身、模型行为等，从而解决业务独立性问题。通过CDM层统一数据模型，从而解决多应用数据割裂问题图5-1-3 Oinone-CDM思路示意图

史, 昂
2024年5月23日
610000