Oinone社区 作者：史, 昂原创文章，如若转载，请注明出处：https://doc.oinone.top/oio4/9315.html
访问Oinone官网:https://www.oinone.top获取数式Oinone低代码应用平台体验
5.1 CDM的背景介绍
Previous
2024年5月23日 am8:23
4.5.2 研发辅助之SQL优化
Next
2024年5月23日
相关推荐
-
3.2.2 启动前端工程
本节核心是带大家直观的感受下我们上节构建的demo模块，并搭建前端环境为后续学习打下基础 一、使用vue-cli构建工程 ##demo-front是项目名，可以替换成自己的 vue create –preset http://ss.gitlab.pamirs.top/:qilian/pamirs-archetype-front4 –clone demo-front –registry http://nexus.shushi.pro/repository/kunlun/ 图3-2-2-1 使用vue-cli构建工程 如果启动报错，清除node_modules后重新npm i mac清除命令：npm run cleanOs windows清除命令: npm run clean 若安装失败，检查本地node、npm、vue对应的版本 图3-2-2-2 检查本地的版本 或者下载前端工程本地运行[oinone-front.zip](oinone-front)(575 KB) 二、启动前端工程 找到README.MD文件，根据文件一步一步操作就行。 找到vue.config.js文件，修改devServer.proxy.pamirs.target为后端服务的地址和端口 const WidgetLoaderPlugin = require('@kunlun/widget-loader/dist/plugin.js').default; const Dotenv = require('dotenv-webpack'); module.exports = { lintOnSave: false, runtimeCompiler: true, configureWebpack: { module: { rules: [ { test: /\.widget$/, loader: '@kunlun/widget-loader' } ] }, plugins: [new WidgetLoaderPlugin(), new Dotenv()], resolveLoader: { alias: { '@kunlun/widget-loader': require.resolve('@kunlun/widget-loader') } } }, devServer: { port: 8080, disableHostCheck: true, progress: false, proxy: { pamirs: { // 支持跨域 changeOrigin: true, target: 'http://127.0.0.1:8090' } } } }; 图3-2-2-3 修改后端服务地址与端口 注：要用localhost域名访问，.env文件这里也要改成localhost。如果开发中一定要出现前后端域名不一致，老版本Chrome会有问题，修改可以请参考https://www.cnblogs.com/willingtolove/p/12350429.html 。或者下载新版本Chrome 进入前端工程demo-front文件目录下，执行 npm run dev，最后出现下图就代表启动成功 图3-2-2-4 前端启动成功提示 使用 http://127.0.0.1:8081/login 进行访问，并用admin账号登陆，默认密码为admin 图3-2-2-5 系统登陆页面 点击左上角进行应用切换，会进入App Finder页面，可以看到所有已经安装的应用，可以对照boot的yml配置文件看。但细心的小伙伴应该注意到了，在App Finder页面出现的应用跟我们启动工程yml配置文件中加载的启动模块数不是一一对应的，同时也没有看到我们demo模块。 图3-2-2-6 已安装应用界面 boot工作的yml文件中加载模块 App Finder的应用 说明 – base- common- sequence- expression 无 模块的application = false，为非应用类的模块 – resource – user – auth – business- message – apps- my_center（show=INACTIVE ）- sys_setting （show=INACTIVE ） 有 模块的application = true，为应用类的模块但show=INACTIVE 的则不展示，通过以下方式定义：@Module(show = ActiveEnum.INACTIVE) – demo_core 无 刚建的oinoneDemo工程，默认为false 设计器：无 设计器：无 因为boot中没有加载设计器模块，所以App Finder中的设计器tab选项卡下没有应用 表3-2-2-1 boot工作的yml文件中加载模块及App Finder应用说明 只需要修改oinoneDemo工程的模块定义如下图，那么就可以在App Finder页面看见“oinoneDemo工程”。 图3-2-2-7 修改模块的application属性为true 图3-2-2-8 在App Finder 页面即可看见“OinoneDemo工程” 目前oinone的Demo模块还是一个全空的模块，所以我们点击后会进入一个空白页面。在后续的学习过程中我们会不断完善该模块。 至此恭喜您，前端工程已经启动完成。 三、前端工程结构介绍 ├── public 发布用的目录，index.html入口文件将在这里 │ ├── src 源代码…
-
5.7 商业支撑之库存域
库存的差异会反馈到企业的整个价值链上，所以对库存的设计是至关重要的 一、基础介绍 我们先抛开仓库中对库存的实操管理和整个流通领域的库存，只围绕企业自身一级的采销链路上我们可以从管理和销售两个角度去看。 从管理角度上我们会关心：实物库存、在途库存、在产库存、库存批次等等，也就是企业有多少库存分布在哪里在什么环节。 从销售角度上我们会关心：可售库存、安全库存等等，也就是企业在特定渠道销售中库存分配规则。 在商业场景中库存管理一头对接仓库、生成、采购，另一头对接多个销售渠道。它的挑战在于不同行业不同特征商品都有比较大的差异。比如家具行业卖的是生产能力，家电区域化销售，生鲜拼车销售，服饰一仓销全国。热销的要分配提升体验防止超卖，滞销的要活动拉流量，普通的要渠道共享最大化可售。库存管理的差异会反馈到企业的整个价值链上，所以对库存的设计是至关重要的。 库存设计挑战在于： 技术上：库存类似账户账本的设计，需要能追溯库存变化的过程，且库存操作都能可追溯业务单据。热点数据的并发控制 业务上：在管理角度上游能跟仓库、采购、生产等进行对接、对账、并为其设置可售规则，下游能为各个销售渠道设置库存分配与同步规则 二、模型介绍 图5-7-1 模型介绍 核心设计逻辑： 单据链路：业务单据（外部业务单据+库存业务单据）产生库存指令（库存调整入\出库单），再由库存指令操作库存并记录库存流水。 管理链路：基础数据维护仓库、供应商、服务范围与费用。这些数据是订单履约路由和可售库存同步的基础 库存数据：对外跟商品域，通过库存指令进行操作。不同库存各自维护自身库存与流水记录，确保可追溯。 如果跟销售渠道对接，还需要扩展可售库存逻辑规则以及同步规则。比如oms类似的应用
-
3.5.6.3 布局的配置
布局是将页面拆分成一个一个的小单元，按照上下中左右进行排列。 前沿 在前端领域中，布局可以分为三大块「Float、Flex、Grid 」，Float可以说的上是上古时期的布局了，如今市面还是很少见的，除了一些古老的网站。 目前，平台主要支持通过配置XML上面的cols和span来进行布局。平台也同样支持自由布局，合理的使用row、col、containers和container四个布局容器相关组件，将可以实现各种类型的布局样式，换句话说，平台实现的自由布局功能是Flex和Grid的结合体。 这里主要是讲解Flex和Grid布局，以及目前新的模板布局实现的思路。 Flex布局 Flex布局采用的是一维布局，那么什么是一维布局呢，所谓的一维布局就是只有一个方向、没有体积、面积，比如一条直线。它适合做局部布局，就像我们原来的顶部菜单、面包屑导航，以及现在的主视图字段配置。 图3-5-6-19 Flex布局示意 图3-5-6-20 Flex布局示意 图3-5-6-21 Flex布局示意 从上图可以看看出，Flex布局只能在X、Y轴进行转换，它无法对上下左右四个方向同时处理，因为它没“面积”的概念。所以它最适合做局部布局。 优点 图3-5-6-22 Flex兼容性 Flex的兼容性，可以看得出来，目前主流的浏览器都支持该属性。所以Flex兼容性强，如果你想对局部做布局处理，Flex是最好选择。 缺陷 刚刚也提到了，用户想要的布局是千奇百怪的，如果他想要的布局在现有的功能中无法实现怎么办？让用户放弃？还是说服他使用现在的布局。 Grid布局 Grid布局系统采用的是二维布局，二维布局有四个方向：上、下、左、右，它只有面积没有体积，比如一张纸、网格。 Grid布局 <div id="grid-container-one"> <div class="one-1">Grid Item 1</div> <div>Grid Item 2</div> <div>Grid Item 3</div> <div>Grid Item 4</div> <div>Grid Item 5</div> <div class="one-6">Grid Item 6</div> </div> <div id="grid-container-two"> <div class="tow-1">Grid Item 1</div> <div class="tow-2">Grid Item 2</div> <div>Grid Item 3</div> <div>Grid Item 4</div> <div>Grid Item 5</div> <div>Grid Item 6</div> </div> <div id="grid-container-three"> <div>Grid Item 1</div> <div>Grid Item 2</div> <div class="grid">Grid Item 3</div> <div class="grid-column">Grid Item 4</div> <div>Grid Item 5</div> <div>Grid Item 6</div> <div>Grid Item 7</div> <div class="grid-column">Grid Item 8</div> </div> HTML CSSResult Skip Results Iframe EDIT ON * { box-sizing: border-box; padding: 0; margin: 0; line-height: 1.5; font-weight: bold; text-align: center; } #grid-container-one{ background-color: black; display: grid; grid-template-columns: repeat(3, 1fr); grid-template-rows: repeat(2, 50px); gap: 10px; border: solid black 2px; margin-bottom: 20px; color: salmon; } #grid-container-one div { border: solid white 2px; padding: 10px; } #grid-container-one .one-1 { grid-area: span 1/span 3; text-aligin: center } #grid-container-one .one-6 { grid-column: 3 /4; } #grid-container-two{ background-color: CADETBLUE; display: grid; grid-template-columns: 15% repeat(2, 1fr);…
-
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' })…