Oinone社区 作者：史, 昂原创文章，如若转载，请注明出处：https://doc.oinone.top/oio4/9431.html
访问Oinone官网:https://www.oinone.top获取数式Oinone低代码应用平台体验
接口日志
Previous
2023年5月23日 pm5:20
4.2.x版本更新说明-20230615
Next
2023年6月15日 pm4:12
相关推荐
-
4.1.4 模块之元数据详解
介绍Module相关元数据，以及对应代码注解方式。大家还是可以通读下，以备不时之需 如您还不了解Module的定义，可以先看下2.3【oinone独特之源，元数据与设计原则】一文对Module的描述，本节主要带大家了解Module元数据构成，能让小伙伴非常清楚oinone从哪些维度来描述Module， 一、元数据说明 ModuleDefinition 元素数据构成 含义 对应注解 备注 displayName 显示名称 @Module( displayName=””, name=””, version=””, category=””, summary=””, dependencies={“”,””}, exclusions={“”,””}, priority=1L ) name 技术名称 latestVersion 安装版本 category 分类编码 summary 描述摘要 moduleDependencies 依赖模块编码列表 moduleExclusions 互斥模块编码列表 priority 排序 module 模块编码 @Module.module(“”) dsKey 逻辑数据源名 @Module.Ds(“”) excludeHooks 排除拦截器列表 @Module.Hook(excludes={“”,””}) website 站点 @Module.Advanced( website=”http://www.oinone.top”, author=”oinone”, description=”oinone”, application=false, demo=false, web=false, toBuy=false, selfBuilt=true, license=SoftwareLicenseEnum.PEEL1, maintainer=”oinone”, contributors=”oinone”, url=”http://git.com” ) author module的作者 description 描述 application 是否应用 demo 是否演示应用 web 是否web应用 toBuy 是否需要跳转到website去购买 selfBuilt 自建应用 license 许可证 默认PEEL1 可选范围： GPL2 GPL2ORLATER GPL3 GPL3ORLATER AGPL3 LGPL3 ORTHEROSI PEEL1 PPL1 ORTHERPROPRIETARY maintainer 维护者 contributors 贡献者列表 url 代码库的地址 boot 是否自动安装的引导启动项 @Boot 加上该注解代表： 启动时会自动安装，不管yml文件的modules是否配置 moduleClazz 模块定义所在类 只有用代码编写的模块才有 packagePrefix 包路径，用于扫描该模块下的其他元数据 dependentPackagePrefix 依赖模块列对应的扫描路径 state 状态 系统自动计算，无需配置 metaSource 元数据来源 publishCount 发布总次数 platformVersion 最新平台版本 本地与中心平台的版本对应。做远程更新时会用到 publishedVersion 最新发布版本 表4-1-4-1 ModuleDefinition UeModule 是对ModuleDefinition的继承，并扩展了跟前端交互相关的元数据 元素数据构成 含义 对应注解 备注 homePage Model 跳转模型编码 @UxHomepage(@UxRoute() 对应一个ViewAction，如果UxRoute只配置了模型，则默认到该模型的列表页 homePage Name 视图动作或者链接动作名称 logo 图标 @UxAppLogo(logo=””) 表4-1-4-2 UeModule 二、元数据，代码注解方式 Module Module ├── displayName 显示名称 ├── name 技术名称 ├── version 安装版本 ├── category 分类编码 ├── summary 描述摘要 ├── dependencies 依赖模块编码列表 ├── exclusions 互斥模块编码列表 ├── priority 排序 ├── module 模块编码 │ └── value ├── Ds 逻辑数据源名 │ └── value ├── Hook 排除拦截器列表…
-
页面设计
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 字段 首次从组件中拖拽，会先展示字段信息，并且是需要先创建一个字段，字段创建成功后，再次切换字段选项，只读展示当前组件所对应的字段基本信息。同理，如果是直接从字段中拖拽，字段选项中，只读展示当前字段基本信息。
-
工作台
有工作台权限的用户，默认登录页为工作台，也可以通过APP Finder进入工作台。 1. 快捷处理 右上角消息中会气泡展示未处理或未读的操作，点击展开后可以点过去进行快捷处理。 2. 查看、处理流程 2.1 流程查看 流程管理页面共同点： 1包含选项分类筛选 2包含标签筛选 3包含应用下拉选筛选 4包含根据流程名称搜素 流程管理页面名词解释： 待办：当前登录用户未处理的流程节点 我发起的：当前登录用户人为触发的流程（模型触发） 抄送：抄送给当前登录用户的节点（审批/填写） 我已办结：由当前登录用户完成人工/自动同意、人工拒绝或人工填写的节点 无需办理：当前登录用户转交的任务/被退回、被撤销、被或签、被其他分支任务拒绝的还未办理的任务 站内信：当前登录用户收到的站内信 2.2 流程处理 每条流程数据下方有动作，点击进入流程处理页面，大致分为详情页和操作页。 待办中点击“审批/填写”会进入流程操作页。审批操作页可能包含“同意、拒绝、退回、加签、转交、返回”，填写操作页可能包含“提交、暂存”，审批操作页包含哪些动作由流程设计决定。 我发起的、抄送、我已办结、无需处理点击“查看”会进入流程详情页。 3. 应用快捷入口 应用中心中星标的收藏应用会展示在此处，点击可快捷进入应用。 应用中心中已安装的应用点击星标即可收藏。
-
5.7 商业支撑之库存域
库存的差异会反馈到企业的整个价值链上，所以对库存的设计是至关重要的 一、基础介绍 我们先抛开仓库中对库存的实操管理和整个流通领域的库存，只围绕企业自身一级的采销链路上我们可以从管理和销售两个角度去看。 从管理角度上我们会关心：实物库存、在途库存、在产库存、库存批次等等，也就是企业有多少库存分布在哪里在什么环节。 从销售角度上我们会关心：可售库存、安全库存等等，也就是企业在特定渠道销售中库存分配规则。 在商业场景中库存管理一头对接仓库、生成、采购，另一头对接多个销售渠道。它的挑战在于不同行业不同特征商品都有比较大的差异。比如家具行业卖的是生产能力，家电区域化销售，生鲜拼车销售，服饰一仓销全国。热销的要分配提升体验防止超卖，滞销的要活动拉流量，普通的要渠道共享最大化可售。库存管理的差异会反馈到企业的整个价值链上，所以对库存的设计是至关重要的。 库存设计挑战在于： 技术上：库存类似账户账本的设计，需要能追溯库存变化的过程，且库存操作都能可追溯业务单据。热点数据的并发控制 业务上：在管理角度上游能跟仓库、采购、生产等进行对接、对账、并为其设置可售规则，下游能为各个销售渠道设置库存分配与同步规则 二、模型介绍 图5-7-1 模型介绍 核心设计逻辑： 单据链路：业务单据（外部业务单据+库存业务单据）产生库存指令（库存调整入\出库单），再由库存指令操作库存并记录库存流水。 管理链路：基础数据维护仓库、供应商、服务范围与费用。这些数据是订单履约路由和可售库存同步的基础 库存数据：对外跟商品域，通过库存指令进行操作。不同库存各自维护自身库存与流水记录，确保可追溯。 如果跟销售渠道对接，还需要扩展可售库存逻辑规则以及同步规则。比如oms类似的应用
-
4.1.24 框架之分库分表
随着数据库技术的发展如分区设计、分布式数据库等，业务层的分库分表的技术终将成老一辈程序员的回忆，谈笑间扯扯蛋既羡慕又自吹地说到“现在的研发真简单，连分库分表都不需要考虑了”。竟然这样为什么要写这篇文章呢？因为现今的数据库虽能解决大部分场景的数据量问题，但涉及核心业务数据真到过亿数据后性能加速降低，能给的方案都还有一定的局限性，或者说性价比不高。相对性价比比较高的分库分表，也会是现阶段一种不错的补充。言归正传oinone的分库分表方案是基于Sharding-JDBC的整合方案，所以大家得先具备一点Sharding-JDBC的知识。 一、分表（举例） 做分库分表前，大家要有一个明确注意的点就是分表字段的选择，它是非常重要的，与业务场景非常相关。在明确了分库分表字段以后，甚至在功能上都要做一些妥协。比如分库分表字段在查询管理中做为查询条件是必须带上的，不然效率只会更低。 Step1 新建ShardingModel模型 ShardingModel模型是用于分表测试的模型，我们选定userId作为分表字段。分表字段不允许更新，所以这里更新策略设置类永不更新，并在设置了在页面修改的时候为readonly package pro.shushi.pamirs.demo.api.model; import pro.shushi.pamirs.boot.base.ux.annotation.field.UxWidget; import pro.shushi.pamirs.boot.base.ux.annotation.view.UxForm; import pro.shushi.pamirs.meta.annotation.Field; import pro.shushi.pamirs.meta.annotation.Model; import pro.shushi.pamirs.meta.enmu.FieldStrategyEnum; @Model.model(ShardingModel.MODEL_MODEL) @Model(displayName = "分表模型",summary="分表模型",labelFields ={"name"} ) public class ShardingModel extends AbstractDemoIdModel { public static final String MODEL_MODEL="demo.ShardingModel"; @Field(displayName = "名称") private String name; @Field(displayName = "用户id",summary = "分表字段",immutable=true/* 不可修改 **/) @UxForm.FieldWidget(@UxWidget(readonly = "scene == 'redirectUpdatePage'"/* 在编辑页面只读 **/ )) @Field.Advanced(updateStrategy = FieldStrategyEnum.NEVER) private Long userId; } 图4-1-24-1 新建ShardingModel模型 Step2 配置分表策略 配置ShardingModel模型走分库分表的数据源pamirsSharding 为pamirsSharding配置数据源以及sharding规则 a. pamirs.sharding.define用于oinone的数据库表创建用 b. pamirs.sharding.rule用于分表规则配置 pamirs: load: sessionMode: true framework: system: system-ds-key: base system-models: – base.WorkerNode data: default-ds-key: pamirs ds-map: base: base modelDsMap: "[demo.ShardingModel]": pamirsSharding #配置模型对应的库 图4-1-24-2 指定模型对应数据源 pamirs: sharding: define: data-sources: ds: pamirs pamirsSharding: pamirs #申明pamirsSharding库对应的pamirs数据源 models: "[trigger.PamirsSchedule]": tables: 0..13 "[demo.ShardingModel]": tables: 0..7 table-separator: _ rule: pamirsSharding: #配置pamirsSharding库的分库分表规则 actual-ds: – pamirs #申明pamirsSharding库对应的pamirs数据源 sharding-rules: # Configure sharding rule ，以下配置跟sharding-jdbc配置一致 – tables: demo_core_sharding_model: #demo_core_sharding_model表规则配置 actualDataNodes: pamirs.demo_core_sharding_model_${0..7} tableStrategy: standard: shardingColumn: user_id shardingAlgorithmName: table_inline shardingAlgorithms: table_inline: type: INLINE props: algorithm-expression: demo_core_sharding_model_${(Long.valueOf(user_id) % 8)} props: sql.show: true 图4-1-24-3 分库分表规则配置 Step3 配置测试入口 修改DemoMenus类增加一行代码，为测试提供入口 @UxMenu("分表模型")@UxRoute(ShardingModel.MODEL_MODEL) class ShardingModelMenu{} 图4-1-24-4 配置测试入口 Step4 重启看效果 自行尝试增删改查 观察数据库表与数据分布 图4-1-24-5 自行尝试增删改查 图4-1-24-6 观察数据库表与数据分布 二、分库分表（举例） Step1 新建ShardingModel2模型 ShardingModel2模型是用于分库分表测试的模型，我们选定userId作为分表字段。分库分表字段不允许更新，所以这里更新策略设置类永不更新，并在设置了在页面修改的时候为readonly package pro.shushi.pamirs.demo.api.model; import pro.shushi.pamirs.boot.base.ux.annotation.field.UxWidget; import pro.shushi.pamirs.boot.base.ux.annotation.view.UxForm; import…
