3.1 环境搭建

相关推荐

• Oinone 7天入门到精通

  3.5.1 构建第一个Menu

  在前面章节中我们也涉及到菜单，因为菜单我们模块就是地图、导航，没有地图、导航就无法畅游模块并进行相关业务操作。在3.3.4【模块的继承】一文关于多表继承的内容就有涉及到菜单的初始化，本文将展开介绍初始化Menu的两种方式分别是：注解式、数据初始化式。 注解式(举例) Step1 分析现有菜单注解 用@UxMenus声明DemoMenus为菜单初始化入口，同时该类在DemoModule配置扫描路径中，那么通过DemoMenus初始化的菜单都挂在demo_core这个模块上。 如果采用这种模式，建议同一个模块的菜单都只配置在一处 package pro.shushi.pamirs.demo.core.init; import pro.shushi.pamirs.boot.base.constants.ViewActionConstants; import pro.shushi.pamirs.boot.base.ux.annotation.action.UxRoute; import pro.shushi.pamirs.boot.base.ux.annotation.navigator.UxMenu; import pro.shushi.pamirs.boot.base.ux.annotation.navigator.UxMenus; import pro.shushi.pamirs.demo.api.model.*; import pro.shushi.pamirs.demo.api.proxy.PetShopProxy; import pro.shushi.pamirs.demo.api.proxy.PetShopProxyA; import pro.shushi.pamirs.demo.api.proxy.PetShopProxyB; @UxMenus public class DemoMenus implements ViewActionConstants { @UxMenu("商店管理")@UxRoute(PetShopProxy.MODEL_MODEL) class PetShopProxyMenu{} @UxMenu("商店管理A")@UxRoute(PetShopProxyA.MODEL_MODEL) class PetShopProxyAMenu{} @UxMenu("商店管理B")@UxRoute(PetShopProxyB.MODEL_MODEL) class PetShopProxyBMenu{} @UxMenu("商品管理")@UxRoute(PetItem.MODEL_MODEL) class ItemMenu{} @UxMenu("宠狗商品")@UxRoute(PetDogItem.MODEL_MODEL) class DogItemMenu{} @UxMenu("萌猫商品")@UxRoute(PetCatItem.MODEL_MODEL) class CatItemMenu{} @UxMenu("宠物品种")@UxRoute(PetType.MODEL_MODEL) class PetTypeMenu{} @UxMenu("萌猫品种")@UxRoute(PetCatType.MODEL_MODEL) class CatTypeMenu{} @UxMenu("宠狗品种")@UxRoute(PetDogType.MODEL_MODEL) class DogTypeMenu{} @UxMenu("宠物达人")@UxRoute(PetTalent.MODEL_MODEL) class PetTalentMenu{} } 图3-5-1-1 菜单注解 Step2 改造现有菜单注解 菜单的层级关系通过@UxMenu的嵌套进行描述 菜单点击效果有三种分别对应不同的Action的类型，关于Action的类型详见3.5.3【Action的类型】一文。 通过@UxRoute定义一个与菜单绑定的viewAction，@UxMenu("创建商店")@UxRoute(value = PetShop.MODEL_MODEL,viewName = "redirectCreatePage",viewType = ViewTypeEnum.FORM)，其中viewName代表视图的name(其默认值为redirectListPage，也就是跳转到列表也)，value代码视图所属模型的编码，viewType代表view类型（其默认值为ViewTypeEnum.TABLE） @UxServer定义一个与菜单绑定的serverAction，@UxMenu("UxServer")@UxServer(model = PetCatItem.MODEL_MODEL,name = "uxServer") ，其中name代表serverAction的name，model或value代码serverAction所属模型的编码 @UxLink定义一个与菜单绑定的UrlAction，@UxMenu("Oinone官网")@UxLink(value = "http://www.oinone.top”,openType= ActionTargetEnum.OPEN_WINDOW) ，其中value为跳转url，openType为打开方式默认为ActionTargetEnum.ROUTER，打开方式有以下几种 ROUTER("router", "页面路由", "页面路由") DIALOG("dialog", "页面弹窗", "页面弹窗") DRAWER("drawer", "打开抽屉", "打开抽屉") OPEN_WINDOW("openWindow", "打开新窗口", "打开新窗口") 配合菜单演示，PetCatItemAction增加一个uxServer的ServerAction package pro.shushi.pamirs.demo.core.action; ……包引用 @Model.model(PetCatItem.MODEL_MODEL) @Component public class PetCatItemAction extends DataStatusBehavior<PetCatItem> { ……省略其他代码 @Action(displayName = "uxServer") public PetCatItem uxServer(PetCatItem data){ PamirsSession.getMessageHub().info("uxServer"); return data; } } 图3-5-1-2 示例代码 新的菜单初始化代码如下 package pro.shushi.pamirs.demo.core.init; import pro.shushi.pamirs.boot.base.constants.ViewActionConstants; import pro.shushi.pamirs.boot.base.enmu.ActionTargetEnum; import pro.shushi.pamirs.boot.base.ux.annotation.action.UxLink; import pro.shushi.pamirs.boot.base.ux.annotation.action.UxRoute; import pro.shushi.pamirs.boot.base.ux.annotation.action.UxServer; import pro.shushi.pamirs.boot.base.ux.annotation.navigator.UxMenu; import pro.shushi.pamirs.boot.base.ux.annotation.navigator.UxMenus; import pro.shushi.pamirs.demo.api.model.*; import pro.shushi.pamirs.demo.api.proxy.PetShopProxy; import pro.shushi.pamirs.demo.api.proxy.PetShopProxyA; import pro.shushi.pamirs.demo.api.proxy.PetShopProxyB; import pro.shushi.pamirs.meta.enmu.ViewTypeEnum; @UxMenus public class DemoMenus implements ViewActionConstants { @UxMenu("商店") class ShopMenu{ @UxMenu("UxServer")@UxServer(model = PetCatItem.MODEL_MODEL,name = "uxServer") class ShopSayHelloMenu{ } @UxMenu("创建商店")@UxRoute(value = PetShop.MODEL_MODEL,viewName = "redirectCreatePage",viewType = ViewTypeEnum.FORM) class ShopCreateMenu{ }…

  史, 昂

  2024年5月23日

  1.9K000
• Oinone 7天入门到精通

  4.2.5 框架之网络请求-Request

  在中后台业务场景中，大部分的请求时候是可以被枚举的，比如创建、删除、更新、查询。在上文中，我们讲了httpClient如何自定义请求，来实现自己的业务诉求。本文中讲到的Request是离业务更近一步的封装，他提供了开箱即用的API，比如insertOne、updateOne，它是基于HttpClient做的二次封装，当你熟悉Request时，在中后台的业务场景中，所有的业务接口自定义将事半功倍。 一、Request详细介绍 元数据-model 获取模型实例 import { getModel } from '@kunlun/dependencies' getModel('modelName'); 图4-2-5-1 获取模型实例 清除所有缓存的模型 import { cleanModelCache } from '@kunlun/dependencies' cleanModelCache(); 图4-2-5-2 清除所有缓存的模型 元数据-module 获取应用实例，包含应用入口和菜单 import { queryModuleByName } from '@kunlun/dependencies' queryModuleByName('moduleName') 图4-2-5-3 获取应用实例 查询当前用户所有的应用 import { loadModules } from '@kunlun/dependencies' loadModules() 图4-2-5-4 查询当前用户所有的应用 query 分页查询 import { queryPage } from '@kunlun/dependencies' queryPage(modelName, { pageSize: 15, // 一次查询几条 currentPage, 1, // 当前页码 condition?: '' // 查询条件 maxDepth?: 1, // 查几层模型出来，如果有2，会把所有查询字段的关系字段都查出来 sort?: []; // 排序规则 }, fields, variables, context) 图4-2-5-5 分页查询 自定义分页查询-可自定义后端接口查询数据 import { customQueryPage } from '@kunlun/dependencies' customQueryPage(modelName, methodName, { pageSize: 15, // 一次查询几条 currentPage, 1, // 当前页码 condition?: '' // 查询条件 maxDepth?: 1, // 查几层模型出来，如果有2，会把所有查询字段的关系字段都查出来 sort?: []; // 排序规则 }, fields, variables, context) 图4-2-5-6 自定义分页查询 查询一条-根据params匹配出一条数据 import { queryOne } from '@kunlun/dependencies' customQueryPage(modelName, params, fields, variables, context) 图4-2-5-7 根据params匹配出一条数据 自定义查询 import { customQuery } from '@kunlun/dependencies' customQuery(methodName, modelName, record, fields, variables, context) 图4-2-5-8 自定义查询 update import { updateOne } from '@kunlun/dependencies' updateOne(modelName, record, fields, variables, context) 图4-2-5-9 update insert import { insertOne } from '@kunlun/dependencies' insertOne(modelName, record, fields, variables, context) 图4-2-5-10 insert delete import { deleteOne } from '@kunlun/dependencies'…

  史, 昂

  2024年5月23日

  1.8K000
• 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.8K000
• Oinone 7天入门到精通

  文件

  文件应用下包含“导入/导出模版、导入任务、导出任务”三个菜单。其中导入/导出任务菜单比较常用。 导入/导出模版 当前版本会为租户的表格视图自动创建导出模版，此处可进行编辑、查看详情的操作。 导入任务 导入任务可以下载导入文档，点击详情可以查看该条记录的导入结果，任务信息分组中可以查看错误信息。 导出任务 和导入任务一致，导出任务菜单中可以下载导出文档，点击详情可以查看该条记录的导出结果，任务信息分组中可以查看错误信息。

  史, 昂

  2024年6月20日

  1.4K000
• Oinone 7天入门到精通

  2.4.1 Oinone独特性之单体与分布式的灵活切换

  企业数字化转型需要处理分布式带来的复杂性和成本问题。尽管这些问题令人望而却步，但分布式架构对于大部分企业仍然是必须的选择。如果一个低代码平台缺乏分布式能力，那么它的性能就无法满足客户的要求。相比之下，Oinone平台通过对部署的创新（如图2-6所示），成功实现了分布式架构的支持，而且能够按照客户的业务发展需求，灵活选择不同的部署模式，同时节约企业成本，提升创新效率。这一创新是Oinone平台与其他低代码平台的重要区别，能够满足客户预期发展并兼顾成本效益。 图2-6 传统部署方式VS Oinone部署方式 实现原理 要实现灵活部署的特性，必须满足两个基本要求： 开发过程中不需要过多关注分布式技术，就像开发单体应用一样简单。代码在运行时应该能够根据模块是否在运行容器中，来决定路由走本地还是远程。这样可以大大减少研发人员的工作量和技术复杂度。 研发与部署要分离，即"开发单体应用一样开发分布式应用，而部署形式由后期决定"。为此，我们的工程结构支持多种启动模式，并逐一介绍了针对不同场景的工程结构类型（如下图2-7所示）。这样可以让客户在后期根据业务发展情况和需求，选择最适合的部署模式，从而达到灵活部署的目的。 图2-7 Oinone工程结构梳理 在整个工程结构上，我们秉承了Spring Boot的规范，不会改变大家的工程习惯。而Oinone的部署能力则可以让我们更灵活地应对各种情况。现在，我们来逐一介绍几种常规的工程结构以及它们适用的场景： 单模块工程结构（常规操作） a. 这是非常标准的Spring Boot工程，适用于简单的应用场景开发以及入门学习。 多模块工程结构（常规操作） a. 这是非常标准的多Spring Boot工程，可以实现分布式独立启动，适用于常规的分布式应用场景开发。 多模块工程结构-独立boot工程模式 a. 这种工程结构在多模块工程的基础上，通过独立的boot工程来支撑多部署方式。适用于中大型分布式应用场景开发。 b. 然而，随着工程越来越多，我们也会面临一些问题： ⅰ研发：环境准备非常困难，每个模块都要单独启动，研发调试跟踪困难。 ⅱ部署：分布式的高可靠性保证需要每个模块至少有两个部署节点，但在模块较多的情况下，起步成本非常高。同时，企业初期业务不稳定且规模较小，使用多模块工程的第二种模式会增加问题排查难度和成本。 c. 此时，Oinone的多模块工程下的独立boot工程模式部署就可以发挥其灵活性，让研发和业务起步阶段可以选择all-in-one模式，等到业务发展到一定规模的时候，只需要把线上部署模式切换成模块独立部署，而研发还可以保留all-in-one模式的优势。 d. 值得注意的是，分分合合的部署模式在传统互联网架构和低代码或无代码平台上都是有代价的，但是Oinone却可以灵活适配，只需要在boot工程的yml文件中写入需要加载的模块就可以解决。此处我们仅介绍多模块加载配置，选择性忽略其他无关配置，具体配置（如下图2-8所示）。 pamirs: boot: init: true sync: true modules: – base – resource – sequence – user – auth – web tenants: – pamirs 图2-8 Oinone yml配置图大型多场景工程结构-独立boot工程模式： a. 在多模块工程结构基础上的加强版，增加CDM层设计，让不同场景即保持数据统一，又保持逻辑独立。这种工程结构特别适用于大型企业软件开发，其中涉及到多个场景的情况，例如B端和C端的应用，或者跨不同业务线的应用，能够保证数据的一致性，同时也能够保持逻辑独立，避免不同场景间的代码冲突。 b. 这种工程结构是我们Oinone支撑“企业级软件生态”的核心，我们可以把场景A当作我们官方应用，场景B当作其他第三方伙伴应用。在这个工程结构下，我们的客户可以定制化开发自己的应用，同时我们也可以通过这种模式来支持我们的伙伴们进行开发，实现多方共赢。 c. 基于独立boot工程模式，我们同样对应多种部署模式应对不同情况，并统一管理所有伙伴应用。这种工程结构的优点是扩展性好，可以支持不同规模的应用，并且可以根据需要进行快速扩展或缩小规模，具有很高的灵活性。 基于标准产品的二开工程结构，是指基于标准产品进行二次开发，满足客户特定需求的工程结构。这种模式下，Oinone提供标准产品，客户可以根据自己的需求进行二次开发，实现定制化需求，同时可以利用我们的模块化开发特性，将每一个需求作为一个模块进行开发和管理。这种工程结构的优点是能够快速满足客户特定需求，同时也具有很好的可维护性和可扩展性，因为每个需求都是一个独立的模块，可以方便地进行维护和扩展。在下一篇“Oinone独特性之每一个需求都是一个模块”文章中有详细介绍。

  史, 昂

  2024年5月23日

  2.4K000